From nobody Tue Jun 3 17:25:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226931A00C9 for ; Tue, 3 Jun 2014 17:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.143 X-Spam-Level: * X-Spam-Status: No, score=1.143 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i09kCaFTwg62 for ; Tue, 3 Jun 2014 17:25:48 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [69.93.243.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8CD1A0388 for ; Tue, 3 Jun 2014 17:25:47 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id 28626159D3885; Tue, 3 Jun 2014 19:25:41 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 075E2159D380D for ; Tue, 3 Jun 2014 19:25:40 -0500 (CDT) Received: from [96.231.225.192] (port=60168 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wrz1Q-0002ug-Ca for tls@ietf.org; Tue, 03 Jun 2014 19:25:40 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sean Turner In-Reply-To: Date: Tue, 3 Jun 2014 20:25:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "" X-Mailer: Apple Mail (2.1878.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1Wrz1Q-0002ug-Ca X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:60168 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fQtiyZE0yDt_4a1d53P9oUnuVNM Subject: [TLS] audio recordings (was Re: Minutes from the Spring 2014 TLS Interim) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 00:25:49 -0000 The audio recordings have also been posted: May 15: = https://ietf.webex.com/ietf/ldr.php?RCID=3D1809da525b302b27811752e23af27e7= 1 May 16: = https://ietf.webex.com/ietf/ldr.php?RCID=3D7c56aa01b2c3b48fe61f4e55fa9c05f= c spt On May 27, 2014, at 20:06, Joseph Salowey (jsalowey) = wrote: > The meeting minutes from the TLS Interim meeting have been uploaded to = http://www.ietf.org/proceedings/interim/2014/05/15/tls/minutes/minutes-int= erim-2014-tls-1 >=20 > Let me know if you have any corrections. >=20 > Thanks, >=20 > Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jun 3 17:40:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91C11A0350 for ; Tue, 3 Jun 2014 17:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.008 X-Spam-Level: X-Spam-Status: No, score=0.008 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RADwNs5fug8g for ; Tue, 3 Jun 2014 17:40:04 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [64.5.52.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1B74A1A00C9 for ; Tue, 3 Jun 2014 17:40:04 -0700 (PDT) Received: by gateway11.websitewelcome.com (Postfix, from userid 500) id 698B26103DA93; Tue, 3 Jun 2014 19:39:58 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway11.websitewelcome.com (Postfix) with ESMTP id 202B06103D9C3 for ; Tue, 3 Jun 2014 19:39:58 -0500 (CDT) Received: from [96.231.225.192] (port=60210 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WrzFF-0004hi-Gl; Tue, 03 Jun 2014 19:39:57 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sean Turner In-Reply-To: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> Date: Tue, 3 Jun 2014 20:39:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> To: Kurt Roeckx X-Mailer: Apple Mail (2.1878.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1WrzFF-0004hi-Gl X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:60210 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8kVB23fc-T9orwVUBHQBeCwQWYQ Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 00:40:06 -0000 I believe that draft has been abandoned in favor of: http://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ Personally, I don=92t think this draft is applicable to the TLS WG and = would be better suited as an AD sponsored draft. I know PHB approached = me about sponsoring it but I think we both got busy before the end of my = term. I=92ve not doubt PHB will at some point approach Stephen/Kathleen = about sponsoring it. If you=92re interested in supporting it, sending = them a message might help (sec-ads@tools.ietf.org). spt On May 28, 2014, at 15:00, Jeremy Rowley = wrote: > We do. I believe PHB was waiting for an OID assigned by IANA for must > staple. I'm not sure the request was ever submitted, but I'll follow = up > and make sure this moves forward. >=20 > Jeremy >=20 > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Kurt Roeckx > Sent: Wednesday, May 28, 2014 12:48 PM > To: tls@ietf.org > Subject: [TLS] OCSP must staple >=20 > Hi, >=20 > It seems there is a draft to have OCSP must staple > (draft-hallambaker-muststaple-00). Does anybody know what the status = of > that is? I've tried to contact the author but didn't get any reply. >=20 > Is this something we want adopt? >=20 >=20 > Kurt >=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 Tue Jun 3 17:49:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2C71A03B3 for ; Tue, 3 Jun 2014 17:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlMFegqqpmCt for ; Tue, 3 Jun 2014 17:49:44 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [67.18.52.11]) by ietfa.amsl.com (Postfix) with ESMTP id 02F6A1A0350 for ; Tue, 3 Jun 2014 17:49:44 -0700 (PDT) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 56EB7884B01B5; Tue, 3 Jun 2014 19:49:38 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 3AD28884B0188 for ; Tue, 3 Jun 2014 19:49:38 -0500 (CDT) Received: from [96.231.225.192] (port=60284 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WrzOb-00027q-Fm; Tue, 03 Jun 2014 19:49:37 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Jun 2014 20:49:33 -0400 Message-Id: To: "" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1WrzOb-00027q-Fm X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:60284 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 9 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eRgUu4ZzWirn-ajFBXaGsQcd8uQ Subject: [TLS] progressing draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 00:49:45 -0000 draft-ietf-tls-encrypt-then-mac has completed WGLC, the latest version = addresses all outstanding issues. I=92ve entered a Shepherd write-up, = and am passing the buck to our AD. Stay tuned for an AD review. spt= From nobody Wed Jun 4 03:37:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED5C1A02BA for ; Wed, 4 Jun 2014 03:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjbJX3UeelUF for ; Wed, 4 Jun 2014 03:37:32 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1DD1A02BD for ; Wed, 4 Jun 2014 03:37:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5BA29BF05; Wed, 4 Jun 2014 11:37:25 +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 dVGKO2D9QGcK; Wed, 4 Jun 2014 11:37:24 +0100 (IST) Received: from [10.43.50.173] (unknown [193.190.253.145]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4EC72BF30; Wed, 4 Jun 2014 11:37:24 +0100 (IST) Message-ID: <538EF6E5.9020605@cs.tcd.ie> Date: Wed, 04 Jun 2014 11:37:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Sean Turner , "" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DkpqvQf6kKP2rixHAt93Ys7e75Y Subject: Re: [TLS] progressing draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 10:37:34 -0000 On 04/06/14 01:49, Sean Turner wrote: > draft-ietf-tls-encrypt-then-mac has completed WGLC, the latest > version addresses all outstanding issues. Ive entered a Shepherd > write-up, and am passing the buck to our AD. Stay tuned for an AD > review. Thanks. Got it. Will give it a read and get back in a couple of days. Cheers, S. > > spt > From nobody Wed Jun 4 03:40:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBD31A02D1 for ; Wed, 4 Jun 2014 03:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9FC8dFOtQ-m for ; Wed, 4 Jun 2014 03:40:38 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1391A02BD for ; Wed, 4 Jun 2014 03:40:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F0765BF31; Wed, 4 Jun 2014 11:40: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 1u4r-uxtVGnE; Wed, 4 Jun 2014 11:40:26 +0100 (IST) Received: from [10.43.50.173] (unknown [193.190.253.145]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8B79ABF30; Wed, 4 Jun 2014 11:40:26 +0100 (IST) Message-ID: <538EF79B.3000506@cs.tcd.ie> Date: Wed, 04 Jun 2014 11:40:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Sean Turner , Kurt Roeckx , Phillip Hallam-Baker References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> In-Reply-To: <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NMlbX5HDl4Fb1fTgHOAjK9cAdxY Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 10:40:40 -0000 Hiya, On 04/06/14 01:39, Sean Turner wrote: > I believe that draft has been abandoned in favor of: > > http://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ > > Personally, I dont think this draft is applicable to the TLS WG and > would be better suited as an AD sponsored draft. I know PHB > approached me about sponsoring it but I think we both got busy before > the end of my term. Ive not doubt PHB will at some point approach > Stephen/Kathleen about sponsoring it. If youre interested in > supporting it, sending them a message might help > (sec-ads@tools.ietf.org). I did discuss AD sponsoring this with Phill and am fine with that plan since there is (I believe) support for implementing it in some browsers. So Phill - please tell me when you think this is ready and if possible recruit a document shepherd if you've not already. S. > > spt > > On May 28, 2014, at 15:00, Jeremy Rowley > wrote: > >> We do. I believe PHB was waiting for an OID assigned by IANA for >> must staple. I'm not sure the request was ever submitted, but >> I'll follow up and make sure this moves forward. >> >> Jeremy >> >> -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] >> On Behalf Of Kurt Roeckx Sent: Wednesday, May 28, 2014 12:48 PM To: >> tls@ietf.org Subject: [TLS] OCSP must staple >> >> Hi, >> >> It seems there is a draft to have OCSP must staple >> (draft-hallambaker-muststaple-00). Does anybody know what the >> status of that is? I've tried to contact the author but didn't get >> any reply. >> >> Is this something we want adopt? >> >> >> Kurt >> >> _______________________________________________ TLS mailing list >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ TLS mailing list >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ TLS mailing list > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Jun 4 05:09:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97B71A01C6 for ; Wed, 4 Jun 2014 05:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGzFvDJnfx2f for ; Wed, 4 Jun 2014 05:09:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 54BA81A016D for ; Wed, 4 Jun 2014 05:09:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 24E71BF36; Wed, 4 Jun 2014 13:09:44 +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 cMLn6PO_EgWV; Wed, 4 Jun 2014 13:09:43 +0100 (IST) Received: from [10.43.50.173] (unknown [193.190.253.145]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D8679BF31; Wed, 4 Jun 2014 13:09:42 +0100 (IST) Message-ID: <538F0C88.7030107@cs.tcd.ie> Date: Wed, 04 Jun 2014 13:09:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Sean Turner , "" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9gFn_WQt-NbNST4ZMmLuTTcQKeI Subject: [TLS] AD review of draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 12:09:51 -0000 Hiya, I got to this today in the end. I have one question only and a couple of nits. Not sure if the answer to the question will mean a change or not... On 04/06/14 01:49, Sean Turner wrote: > draft-ietf-tls-encrypt-then-mac has completed WGLC, the latest > version addresses all outstanding issues. Ive entered a Shepherd > write-up, and am passing the buck to our AD. Stay tuned for an AD > review. section 3: "Once the use of encrypt-then-MAC has been negotiated..." do you need to be more explicit about this? The client clearly has to start by sending the extension, but MUST the server also include the response extension as well, or can a server just start using e-t-m if a client has sent it the extension? (You do say that if the server is using a stream cipher or AEAD then the server MUST NOT send the response extension.) This might be determined in 5246 already, but even so might be worth repeating here. nits - why the ' quotes in the abstract? - intro: better to say "RFC 5246 [2] and..." rather than "[2] and..." Cheers, S. From nobody Wed Jun 4 06:01:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F10F1A01D2 for ; Wed, 4 Jun 2014 06:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgqYEWbGlbLP for ; Wed, 4 Jun 2014 06:01:20 -0700 (PDT) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4801A01F4 for ; Wed, 4 Jun 2014 06:01:13 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id q58so8437038wes.39 for ; Wed, 04 Jun 2014 06:01:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:reply-to:from:to:references :in-reply-to:subject:date:organization:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=DNOYNNWk+SV4wr/pArwIgNvy9rTgCjZ/VWQ966z06y8=; b=eb34EzFDy5ZNn4WCJAdzkKz1t8JuSOHi6Kiv3vIaaEabQTp2LGYzVa2KqO95s8IWdH 9nC7sGSWnnhjG41iJqf1avuT7xzXqVWpnfrUusjrWvP3vUfIwm3BZIvOoNVtZhLAtpj0 nPEdNRqjVU9peLZQhySpI1ZhFXixbuzwyfYIh8Tqnm8kCBIlpGEpGl5VGKHHBmP6kLhE kQsrB/9XlCQpY7ndGqfwobqUvh7mdrFDb5/7EMp/qyQvkofKD+KWytVmQ6hN9Lir7h8I Kg5sw3eXI61b+DHrxcr52YTvZLbOgD6GXvGBI3t8O5h7+UPK77Qk+ASP5/bDv0IAfu/b 34bQ== X-Gm-Message-State: ALoCoQndtOV5eKXU2UVReT+eogt5+OuQfS564ogvIadMf35hAF25KSiRn1APib/Cp1qXdI4iqvPX X-Received: by 10.15.33.140 with SMTP id c12mr1017498eev.41.1401886866438; Wed, 04 Jun 2014 06:01:06 -0700 (PDT) Received: from THINK2 ([82.119.170.75]) by mx.google.com with ESMTPSA id w9sm5663622eev.4.2014.06.04.06.01.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Jun 2014 06:01:05 -0700 (PDT) Message-ID: <538f1891.092b0f0a.6229.ffffd809@mx.google.com> X-Google-Original-Message-ID: <000001cf7ff5$0b7202d0$22560870$@kahlo@ageto.net> From: "Christian Kahlo" To: "'Stephen Farrell'" , "'Sean Turner'" , References: <538F0C88.7030107@cs.tcd.ie> In-Reply-To: <538F0C88.7030107@cs.tcd.ie> Date: Wed, 4 Jun 2014 15:01:03 +0200 Organization: AGETO Innovation GmbH MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9/7fWCQLivYJS6Rdi1elp8u7i1dgAATG8g Content-Language: de Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FXZyhp96cUy-z0yh8cfqhIKX7ks Subject: Re: [TLS] AD review of draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: c.kahlo@ageto.net List-Id: "This is the mailing list 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 Jun 2014 13:01:22 -0000 Hi there, > On 04/06/14 01:49, Sean Turner wrote: > > draft-ietf-tls-encrypt-then-mac has completed WGLC, the latest > version > > addresses all outstanding issues. I've entered a Shepherd write-up, > > and am passing the buck to our AD. Stay tuned for an AD review. > > section 3: "Once the use of encrypt-then-MAC has been negotiated..." do > you need to be more explicit about this? > The client clearly has to start by sending the extension, but MUST the > server also include the response extension as well, or can a server > just start using e-t-m if a client has sent it the extension? (You do > say that if the server is using a stream cipher or AEAD then the server > MUST NOT send the response extension.) This might be determined in 5246 > already, but even so might be worth repeating here. writing as the guy who did the first public testable implementation (eid.vx4.net) a server MUST send the extension if it was received from the client and the server wants to negotiate ETM. Otherwise the client wouldn't know how to encipher/decipher messages. This shouldn't be implicit. The part about AEAD and stream ciphers is correct so far. Best regards, Christian From nobody Thu Jun 5 06:00:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AD41A009A for ; Thu, 5 Jun 2014 06:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGHlKfOUsQF8 for ; Thu, 5 Jun 2014 06:00:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E0FAB1A008D for ; Thu, 5 Jun 2014 06:00:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 51362BF89; Thu, 5 Jun 2014 13:59:58 +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 38dm4NWMcHdn; Thu, 5 Jun 2014 13:59:57 +0100 (IST) Received: from [10.87.48.12] (unknown [86.44.75.78]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E0547BF88; Thu, 5 Jun 2014 13:59:56 +0100 (IST) Message-ID: <539069CC.5010304@cs.tcd.ie> Date: Thu, 05 Jun 2014 13:59:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/obmUn0zFddFPFHuF9RDk7UwhEA8 Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 13:00:06 -0000 Hiya, On 05/06/14 13:40, Phillip Hallam-Baker wrote: > By which I simply mean, lets make get people to actually read that > particular draft rather than start a cabal. So if we give folks a week > and then we can go forward with the document shepherd? Sure works for me. Can you try recruit a shepherd? I'll do an AD review in any case before I start IETF LC and will post a copy of that here. If other folks have comments I guess send those here or to PHB and me. I'd be happy to get a couple of mails saying "read it, its ready" after Phill's done his tweaks as well btw. Cheers, S. From nobody Thu Jun 5 08:12:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CB11A02B2 for ; Thu, 5 Jun 2014 08:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPtLGZ-I2FKt for ; Thu, 5 Jun 2014 08:11:59 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA7B1A02E6 for ; Thu, 5 Jun 2014 08:09:39 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D4EA04821F for ; Thu, 5 Jun 2014 15:09:32 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id BFF384825A for ; Thu, 5 Jun 2014 15:09:32 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id A3A329803E for ; Thu, 5 Jun 2014 15:09:32 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Thu, 5 Jun 2014 11:09:30 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Thu, 5 Jun 2014 11:09:30 -0400 Thread-Topic: CCS and key reset and renegotiation Thread-Index: Ac+Az/QcwlPSWuXNSkaoBvA5Idc1BA== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7130F434981USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sGGqWyjCsDu2QuUyTh2_RQU_9fA Subject: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 15:12:03 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130F434981USMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Have folks seen this yet? http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.= html I think it adds weight to my concern about using ChangeCipherSpec to do key= reset. I still prefer the trade-offs of having a "slow the TLS but keep t= he TCP layer open" and starting over. Much simpler to prove it's correct. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130F434981USMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Have folks seen = this yet?

  http://c= csinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html

 

I think it adds weight to my concern about using ChangeCipherSpec to do ke= y reset.  I still prefer the trade-offs of having a “slow the TL= S but keep the TCP layer open” and starting over.  Much simpler = to prove it’s correct.

 =

       &n= bsp;        /r$

 

--  =

Principal Security Engineer

Akamai Technologies, Cambridge, MA

IM: rsalz@jabber.me; Twitter= : RichSalz

 

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130F434981USMBX1msgcorp_-- From nobody Thu Jun 5 08:24:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8FA1A02B3 for ; Thu, 5 Jun 2014 08:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlGlv_T7AIyi for ; Thu, 5 Jun 2014 08:23:59 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0D71A0167 for ; Thu, 5 Jun 2014 08:21:44 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 992722AAB4F; Thu, 5 Jun 2014 15:21:37 +0000 (UTC) Date: Thu, 5 Jun 2014 15:21:37 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140605152137.GC27883@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xjFCZHNr9yq37nCD-W0KNfWcn5w Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 15:24:04 -0000 On Thu, Jun 05, 2014 at 11:09:30AM -0400, Salz, Rich wrote: > Have folks seen this yet? > http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html > > I think it adds weight to my concern about using ChangeCipherSpec > to do key reset. I still prefer the trade-offs of having a "slow > the TLS but keep the TCP layer open" and starting over. Much > simpler to prove it's correct. A STOPTLS feature could also be useful in the Postfix (TCP) connection cache. Because cached TCP connections move between processes through file descriptor passing, but serializing the SSL state of an active SSL connection is difficult, we currently can't cache TLS-protected TCP connections. If we could STOP TLS before moving connections into the cache, and resume with a handshake over cleartext (using a cached TLS session, session ticket, ...) that would make it possible to cache TLS connections (that negotiate TLS 1.3 if STOPTLS is a required or negotiated peer feature in 1.3). -- Viktor. From nobody Thu Jun 5 08:27:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9891A0290 for ; Thu, 5 Jun 2014 08:27:51 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGJ-LiqjdYDh for ; Thu, 5 Jun 2014 08:27:48 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7241A02DE for ; Thu, 5 Jun 2014 08:25:32 -0700 (PDT) Received: by mail-yk0-f175.google.com with SMTP id 131so930460ykp.20 for ; Thu, 05 Jun 2014 08:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=527VTTj/0CGBrd6ReOIB7aGMphteIXzEZScjh9+r9YQ=; b=F2jFL3pwHYQ5Hav/YGYfX9gYbm/V8iDIBrJajmR6tSsiJN4Qtwx5kVaKtJqIOKk/io X+OCPsrKasw2A4dCmqPiBXjgCWKaBzYZ9H5AGOPprtByYzfxyrjxb0/G2SVV2KCW/NwY 3m49acMSMNdG96ahkjyZI5neU6K7yDq5C+isShuIImvX4wDeDX5zIT4vNqdw6+LO+6t6 ADgTdVsWbYHzXs+a1V4HBMGVT5bqp6tIYP7g4qSMZlgI6Li6TnVk5vmYFtR4bj12KXcH qW/6sYPlvzx7Bnhvnd/kSdTlL0Jhf7tD44ZrX+ERqz5QWNqsiwFEKECKdc4RcrMhipGH zLgw== MIME-Version: 1.0 X-Received: by 10.236.130.51 with SMTP id j39mr86025392yhi.66.1401981926058; Thu, 05 Jun 2014 08:25:26 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Thu, 5 Jun 2014 08:25:26 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Thu, 5 Jun 2014 08:25:26 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> Date: Thu, 5 Jun 2014 08:25:26 -0700 Message-ID: From: Watson Ladd To: Rich Salz Content-Type: multipart/alternative; boundary=20cf3010e605af334904fb185a8f Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WwhWFBYOZJEHIUHhofs4CGklOkg Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 15:27:52 -0000 --20cf3010e605af334904fb185a8f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jun 5, 2014 8:12 AM, "Salz, Rich" wrote: > > Have folks seen this yet? > > http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.ht= ml > > > > I think it adds weight to my concern about using ChangeCipherSpec to do key reset. I still prefer the trade-offs of having a =E2=80=9Cslow the TLS= but keep the TCP layer open=E2=80=9D and starting over. Much simpler to prove = it=E2=80=99s correct. What can change when that happens? Furthermore, rekeying is a matter of getting more PRF output: how does that introduce security concerns. I don't see why the incompetence of implementors should govern our decisions. If something cannot be implemented correctly it must be removed, but why is rekeying such a thing? > > > > /r$ > > > > -- > > Principal Security Engineer > > Akamai Technologies, Cambridge, MA > > IM: rsalz@jabber.me; Twitter: RichSalz > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --20cf3010e605af334904fb185a8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 5, 2014 8:12 AM, "Salz, Rich" <rsalz@akamai.com> wrote:
>
> Have folks seen this yet?
>
> =C2=A0 http://ccsinjection.lepidum.co.jp/blog/2014-06-0= 5/CCS-Injection-en/index.html
>
> =C2=A0
>
> I think it adds weight to my concern about using ChangeCipherSpec to d= o key reset.=C2=A0 I still prefer the trade-offs of having a =E2=80=9Cslow = the TLS but keep the TCP layer open=E2=80=9D and starting over.=C2=A0 Much = simpler to prove it=E2=80=99s correct.

What can change when that happens? Furthermore, rekeying is = a matter of getting more PRF output: how does that introduce security conce= rns.

I don't see why the incompetence of implementors should = govern our decisions. If something cannot be implemented correctly it must = be removed,=C2=A0 but why is rekeying such a thing?
>
> =C2=A0
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 /r$
>
> =C2=A0
>
> --=C2=A0
>
> Principal Security Engineer
>
> Akamai Technologies, Cambridge, MA
>
> IM: rsalz@jabber.me; Twitter: R= ichSalz
>
> =C2=A0
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls
>

--20cf3010e605af334904fb185a8f-- From nobody Thu Jun 5 08:40:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6691A1A01F7 for ; Thu, 5 Jun 2014 08:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpirwN4cTq1T for ; Thu, 5 Jun 2014 08:40:39 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 979B01A0167 for ; Thu, 5 Jun 2014 08:40:39 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 5AD1131805C for ; Thu, 5 Jun 2014 08:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=EuDthbdhwLYUCjMALJBBKH1IyFc=; b=EerwrfQiovL /jC0aaFbEEj/vXLvKntMfu1r29UG989iubADyg06xebDltSmr4yAQMkuyOEENQJn frgOM9ACVCBI9EQvY34+/jyk2veUhusUGq8uagSnNNwmZ19UCLpYUCvsBllBTnud OKsu0EuvV+95AyjWP61ZwK3TzjwD2Y2I= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id D80B8318059 for ; Thu, 5 Jun 2014 08:40:32 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id bs8so10718617wib.12 for ; Thu, 05 Jun 2014 08:40:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.93.202 with SMTP id cw10mr16675198wjb.95.1401982829712; Thu, 05 Jun 2014 08:40:29 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 5 Jun 2014 08:40:29 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> Date: Thu, 5 Jun 2014 10:40:29 -0500 Message-ID: From: Nico Williams To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pN_AfuicMqptzGA5jE9DdI6v8LM Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 15:40:42 -0000 On Thu, Jun 5, 2014 at 10:09 AM, Salz, Rich wrote: > I think it adds weight to my concern about using ChangeCipherSpec to do k= ey > reset. I still prefer the trade-offs of having a =E2=80=9Cslow the TLS b= ut keep the > TCP layer open=E2=80=9D and starting over. Much simpler to prove it=E2= =80=99s correct. The good news is these bugs are getting found, and that this and Heartbleed aren't protocol bugs -- sure, the protocol made it easier for programmers without automatic bounds checking and so on to screw up, but, the problem is the lack of bounds checking and so on. And, frankly, this bug is just the result of failure to keep one bit of state: if there's no key, then CCS should cause a protocol failure -- the sort of bug that the protocol can't be blamed for, like the goto fail bug. I know the discoverer thinks that the description of CCS is to blame, but I don't. I think it's just this one bit of state, not kept or not checked where it matters. The bad news is that there's no plan to replace OpenSSL with something better; there is nothing better with sufficiently friendly licensing terms. What other serious bugs lurk unknown to the public? There's no light yet at the end of this tunnel. Nico -- From nobody Thu Jun 5 08:41:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A241A01A0 for ; Thu, 5 Jun 2014 08:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVNoYMrVS38l for ; Thu, 5 Jun 2014 08:41:36 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 73FB61A019C for ; Thu, 5 Jun 2014 08:41:36 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0309F48252; Thu, 5 Jun 2014 15:41:30 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id EB1DF48251; Thu, 5 Jun 2014 15:41:29 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id C849A98052; Thu, 5 Jun 2014 15:41:29 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Thu, 5 Jun 2014 11:41:29 -0400 From: "Salz, Rich" To: Watson Ladd Date: Thu, 5 Jun 2014 11:41:28 -0400 Thread-Topic: [TLS] CCS and key reset and renegotiation Thread-Index: Ac+A0mTB0/YpgdS/S6+hIQK2VdgFkAAAaXrw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130F4349C2@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7130F4349C2USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LclkT9pTeNqx-GsstLHiRIcNwuI Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 15:41:38 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130F4349C2USMBX1msgcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJIGRvbid0IHNlZSB3aHkgdGhlIGluY29tcGV0ZW5jZSBvZiBpbXBsZW1lbnRvcnMgc2hvdWxk IGdvdmVybiBvdXIgZGVjaXNpb25zLiBJZiBzb21ldGhpbmcgY2Fubm90IGJlIGltcGxlbWVudGVk IGNvcnJlY3RseSBpdCBtdXN0IGJlIHJlbW92ZWQsICBidXQgd2h5IGlzIHJla2V5aW5nIHN1Y2gg YSB0aGluZz8NCg0KQmVjYXVzZSB0aGUgbGluZSBiZXR3ZWVuIOKAnG9mdGVuIGdldCBpdCB3cm9u Z+KAnSBhbmQg4oCcY2Fubm90IGJlIGltcGxlbWVudGVk4oCdIGlzIG9mdGVuIGEgdmVyeSB0aGlu IG9uZSBhbmQgaXTigJlzIGJldHRlciB0byBiZSBjYXV0aW91cyBhbmQgc2FmZSwgdGhlbiBwZWRh bnRpY2FsbHkgY29ycmVjdCBhbmQgdXN1YWxseSBicm9rZW4uDQoNCi9yJA0KDQotLQ0KUHJpbmNp cGFsIFNlY3VyaXR5IEVuZ2luZWVyDQpBa2FtYWkgVGVjaG5vbG9naWVzLCBDYW1icmlkZ2UsIE1B DQpJTTogcnNhbHpAamFiYmVyLm1lPG1haWx0bzpyc2FsekBqYWJiZXIubWU+OyBUd2l0dGVyOiBS aWNoU2Fseg0K --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130F4349C2USMBX1msgcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9o ZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdv cmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mZ3Q7 PC9zcGFuPiBJIGRvbid0IHNlZSB3aHkgdGhlIGluY29tcGV0ZW5jZSBvZiBpbXBsZW1lbnRvcnMg c2hvdWxkIGdvdmVybiBvdXIgZGVjaXNpb25zLiBJZiBzb21ldGhpbmcgY2Fubm90IGJlIGltcGxl bWVudGVkIGNvcnJlY3RseSBpdCBtdXN0IGJlIHJlbW92ZWQsJm5ic3A7IGJ1dCB3aHkgaXMgcmVr ZXlpbmcgc3VjaCBhIHRoaW5nPzxicj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ QmVjYXVzZSB0aGUgbGluZSBiZXR3ZWVuIOKAnG9mdGVuIGdldCBpdCB3cm9uZ+KAnSBhbmQg4oCc Y2Fubm90IGJlIGltcGxlbWVudGVk4oCdIGlzIG9mdGVuIGEgdmVyeSB0aGluIG9uZSBhbmQgaXTi gJlzIGJldHRlciB0byBiZSBjYXV0aW91cyBhbmQgc2FmZSwgdGhlbiBwZWRhbnRpY2FsbHkgY29y cmVjdCBhbmQgdXN1YWxseSBicm9rZW4uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDouNWluJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPi9yJDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS3CoCA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UHJpbmNpcGFs IFNlY3VyaXR5IEVuZ2luZWVyPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFrYW1haSBUZWNobm9sb2dpZXMsIENhbWJyaWRnZSwg TUE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+SU06IDxhIGhyZWY9Im1haWx0bzpyc2FsekBqYWJiZXIubWUiPjxzcGFuIHN0eWxl PSdjb2xvcjpibHVlJz5yc2FsekBqYWJiZXIubWU8L3NwYW4+PC9hPjsgVHdpdHRlcjogUmljaFNh bHo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130F4349C2USMBX1msgcorp_-- From nobody Thu Jun 5 08:54:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095CE1A028A for ; Thu, 5 Jun 2014 08:54: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhfhltKbzvRU for ; Thu, 5 Jun 2014 08:54:03 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E981A0246 for ; Thu, 5 Jun 2014 08:54:02 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n15so3781120wiw.14 for ; Thu, 05 Jun 2014 08:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jIgqWNvYlgUrdqdfpsV6kiGHIHekJMXf355hXQtO0mo=; b=EW3hrVkDgs1NJqmq7NMBaLElhU4n7ePLlah66CRyHICn37AT3+XkSYbJux9Aug2msk gwc4r5429Bemg5gR7WSL3GUgQqNQ/Y52nvQOmmvz71U6Mi8bd18zoaZVIIVbeIi+vhkp Bd1/5TTDwswBJ8bHmTGDvyPKi/DwclRxixdEVEsZpC88Rmram9A++0gqU7OXnZIkn3Rc 1S6rcZoik7Nobvc7qREsvjrpOr/YURCUCDuVMpAEOsFPTJzIjb0UkU2zTseOMODKzS9g Cvxz3sdDqb9hNKHhqwrzsaK7nNuxGoyx7v3uaDrY1d/dOQYZd7b8aFNoQXVoBi8LrGur s7gQ== MIME-Version: 1.0 X-Received: by 10.195.18.8 with SMTP id gi8mr17546691wjd.75.1401983632937; Thu, 05 Jun 2014 08:53:52 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Thu, 5 Jun 2014 08:53:52 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F4349C2@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130F4349C2@USMBX1.msg.corp.akamai.com> Date: Thu, 5 Jun 2014 08:53:52 -0700 Message-ID: From: Martin Thomson To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nk_kP-zr9sMexeL5WuT43djZWF8 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 15:54:09 -0000 On 5 June 2014 08:41, Salz, Rich wrote: >> I don't see why the incompetence of implementors should govern our >> decisions. If something cannot be implemented correctly it must be remov= ed, >> but why is rekeying such a thing? > > Because the line between =E2=80=9Coften get it wrong=E2=80=9D and =E2=80= =9Ccannot be implemented=E2=80=9D is > often a very thin one and it=E2=80=99s better to be cautious and safe, th= en > pedantically correct and usually broken. I tend to agree with Watson here. This is a problem that happens during the initial handshake only. Maybe we can design the handshake to ensure that CCS cannot be abused for TLS 1.3. But I don't see how this vulnerability extends to subsequent handshakes or rekeying exchanges. From nobody Thu Jun 5 09:02:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCAF1A0253 for ; Thu, 5 Jun 2014 09:02:49 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXzRrrHtBfGb for ; Thu, 5 Jun 2014 09:02:39 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6371D1A0268 for ; Thu, 5 Jun 2014 09:01:48 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id f73so1020966yha.0 for ; Thu, 05 Jun 2014 09:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=86BQwsyP0wL7yPaEs7Q2OZgbtlcHC0kGRpHHKvGe8R4=; b=AZX6x4pe5btvAs4U9+J/CMFRKq/aMdcp8D+hgi1xPn/G6subS6ks19JpfqSQ/FAz1Y FQN7LC4Em73jAsIsOoN8+nvZegsEoXfo5lPLx4hmwC9YJDcNY8XwzaZ8FGGAx2wFbKun GXq8GE+UzD75qo4EgMwmd4CFrBoAMan4f1vvFK8hW9/O4wH8iCNHZTZnxvinENaJcTLt DK6cC3T0tRHSwIUI28dwtzpSSssbxCSBxICnP+JMTW6jwym1UkosBPfD6LUtOxM3gRMH iXZcAaNsddtOrVAYwA6Dva8onJh74hYbIvn3LEjCM1ugq/Iq6BrDOjAKpaLAekTq+c9t 4CGw== MIME-Version: 1.0 X-Received: by 10.236.1.229 with SMTP id 65mr51800474yhd.107.1401984101616; Thu, 05 Jun 2014 09:01:41 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Thu, 5 Jun 2014 09:01:41 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Thu, 5 Jun 2014 09:01:41 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130F4349C2@USMBX1.msg.corp.akamai.com> Date: Thu, 5 Jun 2014 09:01:41 -0700 Message-ID: From: Watson Ladd To: Martin Thomson Content-Type: multipart/alternative; boundary=089e01183b4c5b92a504fb18dc22 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/J__okSGtFm7IBEo8OxMmZ9cGPM4 Cc: tls@ietf.org Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 16:02:50 -0000 --089e01183b4c5b92a504fb18dc22 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jun 5, 2014 8:53 AM, "Martin Thomson" wrote: > > On 5 June 2014 08:41, Salz, Rich wrote: > >> I don't see why the incompetence of implementors should govern our > >> decisions. If something cannot be implemented correctly it must be removed, > >> but why is rekeying such a thing? > > > > Because the line between =E2=80=9Coften get it wrong=E2=80=9D and =E2= =80=9Ccannot be implemented=E2=80=9D is > > often a very thin one and it=E2=80=99s better to be cautious and safe, = then > > pedantically correct and usually broken. > > > I tend to agree with Watson here. This is a problem that happens > during the initial handshake only. Maybe we can design the handshake > to ensure that CCS cannot be abused for TLS 1.3. But I don't see how > this vulnerability extends to subsequent handshakes or rekeying > exchanges. We did design that part of the handshake correctly provided you read the example handshake as dictating the possible flows: that's why only OpenSSL is vulnerable. The spec needs a state machine. --089e01183b4c5b92a504fb18dc22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 5, 2014 8:53 AM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>
> On 5 June 2014 08:41, Salz, Rich <rsalz@akamai.com> wrote:
> >> I don't see why the incompetence of implementors should g= overn our
> >> decisions. If something cannot be implemented correctly it mu= st be removed,
> >> but why is rekeying such a thing?
> >
> > Because the line between =E2=80=9Coften get it wrong=E2=80=9D and= =E2=80=9Ccannot be implemented=E2=80=9D is
> > often a very thin one and it=E2=80=99s better to be cautious and = safe, then
> > pedantically correct and usually broken.
>
>
> I tend to agree with Watson here. =C2=A0This is a problem that happens=
> during the initial handshake only. =C2=A0Maybe we can design the hands= hake
> to ensure that CCS cannot be abused for TLS 1.3. =C2=A0But I don't= see how
> this vulnerability extends to subsequent handshakes or rekeying
> exchanges.

We did design that part of the handshake correctly provided = you read the example handshake as dictating the possible flows: that's = why only OpenSSL is vulnerable.

The spec needs a state machine.

--089e01183b4c5b92a504fb18dc22-- From nobody Thu Jun 5 09:27:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144F51A0220 for ; Thu, 5 Jun 2014 09:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jV9CUrzoryW for ; Thu, 5 Jun 2014 09:27:27 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D51011A023E for ; Thu, 5 Jun 2014 09:27:27 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id A40B72007F008 for ; Thu, 5 Jun 2014 09:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=GuGpxR71gwuyuYlZ+7zJTHtwTYE=; b=iHzife0av3C DzG0CZCXyR6RFA6uqS/3X58hG6BKhsaV/4RqSl1CbgfyOBMG9tet/7brs57NN0sH LXTTE08UCFaW2VbHRhfqlmtdWdVMB4W2/sG/ZeOP3ftg707G32FYtUvtE9dhLTsN wRi39A69gpzsFqjyaDnU0sSrXv6wVlbE= Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPSA id 492272007F005 for ; Thu, 5 Jun 2014 09:27:20 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id f8so10859251wiw.2 for ; Thu, 05 Jun 2014 09:27:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.77.225 with SMTP id v1mr17178243wiw.5.1401985638115; Thu, 05 Jun 2014 09:27:18 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 5 Jun 2014 09:27:18 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130F4349C2@USMBX1.msg.corp.akamai.com> Date: Thu, 5 Jun 2014 11:27:18 -0500 Message-ID: From: Nico Williams To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/n4PTnsE9YRvb-ohnAhRvxVLUYE0 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 16:27:30 -0000 On Thu, Jun 5, 2014 at 10:53 AM, Martin Thomson wrote: > On 5 June 2014 08:41, Salz, Rich wrote: >>> I don't see why the incompetence of implementors should govern our >>> decisions. If something cannot be implemented correctly it must be remo= ved, >>> but why is rekeying such a thing? >> >> Because the line between =E2=80=9Coften get it wrong=E2=80=9D and =E2=80= =9Ccannot be implemented=E2=80=9D is >> often a very thin one and it=E2=80=99s better to be cautious and safe, t= hen >> pedantically correct and usually broken. > > > I tend to agree with Watson here. This is a problem that happens > during the initial handshake only. Maybe we can design the handshake > to ensure that CCS cannot be abused for TLS 1.3. But I don't see how > this vulnerability extends to subsequent handshakes or rekeying > exchanges. A single bit of state was not kept or checked. How do we prevent that sort of implementation bug with protocol design? How could we prevent the goto fail bug with protocol design? (Well, DANE helps, to be sure, by cutting out the PKIX. But really, even then there will be plenty of opportunities to commit bugs of these types.) At some point using silly implementation bugs as a justification for protocol design decisions... will probably lead to bad protocol design decisions. There are cases where I think that protocol design decisions do impact implementation quality. For example, using ASN.1 w/ BER/DER/CER in new protocols is asking for trouble because a) cheap tooling is still not widely available, b) BER is very redundant, and redundancy doesn't help programmers get it right. ASN.1 w/ PER, or XDR -- these are superior to BER. Nico -- From nobody Thu Jun 5 09:42:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02651A0075 for ; Thu, 5 Jun 2014 09:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEVbQLDILDmf for ; Thu, 5 Jun 2014 09:42:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110C21A016B for ; Thu, 5 Jun 2014 09:42:50 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 41AA22AB160; Thu, 5 Jun 2014 16:42:42 +0000 (UTC) Date: Thu, 5 Jun 2014 16:42:42 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140605164241.GJ27883@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZYlqS1TTKIAWjjfeBUEPkmX7Ou8 Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 16:42:51 -0000 On Thu, Jun 05, 2014 at 08:25:26AM -0700, Watson Ladd wrote: > > I think it adds weight to my concern about using ChangeCipherSpec to do > > key reset. I still prefer the trade-offs of having a ?slow the TLS but > > keep the TCP layer open? and starting over. Much simpler to prove it?s > > correct. > > What can change when that happens? Furthermore, rekeying is a matter of > getting more PRF output: how does that introduce security concerns. Whether or not rekeying is easier to implement with a STOPTLS, or by switching directly from one keyset to another, without an intermediate transition to cleartext, a STOPTLS feature has additional upside. I don't recall whether this idea got dropped, or whether STOPTLS might yet happen in TLS 1.3. Anyone care to bring me up to speed? -- Viktor. From nobody Thu Jun 5 10:05:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787A01A024D for ; Thu, 5 Jun 2014 10:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgMat87RhKlq for ; Thu, 5 Jun 2014 10:05:40 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C824E1A02A1 for ; Thu, 5 Jun 2014 10:05:29 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id w8so1777047qac.24 for ; Thu, 05 Jun 2014 10:05:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dCrNNOKTiFr08kWHXOeLGLomfHLweLBFY3i5M7YjM3E=; b=EU4hl9mqz+Rh4i1yXCYGY62ueykUMPotF6hxQcfHPK4mzuQm93BiqA7rAP4oaPfFLQ +jnXLMS36OA6QcuuGkwCLR13D+yvYr6MQTBUqdX8qm0hqIrE4OE/WE8R8lRoe2kHJ3Ba QwWrLrq4+x8qjBs4AXKO9a69Pg5iWhy/XGWBrdFc8r14LdVqZ0ecMtsO0ceYZ3lTHpdM eWBXnGm5SoPbMotUF5sKO2s2purSsnnEEiPB2++XNDN9IB9IcG2TrXZ7oAtlCAOzNYiO t2JGwjofjH4Zahq36nWq6ysBJp4U3Q9va4g0PwXUePb3IFojnEh3aV2hvd2btne4D6l+ jLYQ== X-Gm-Message-State: ALoCoQn8ucor59wskM27YpdjmZOy1VyZFnGKrPQ0gs3rGRE2uOD83br886ItPxzz4V2mH4Wgk1NR MIME-Version: 1.0 X-Received: by 10.224.52.6 with SMTP id f6mr15591719qag.63.1401987922846; Thu, 05 Jun 2014 10:05:22 -0700 (PDT) Received: by 10.224.201.193 with HTTP; Thu, 5 Jun 2014 10:05:22 -0700 (PDT) In-Reply-To: <539069CC.5010304@cs.tcd.ie> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> Date: Thu, 5 Jun 2014 10:05:22 -0700 Message-ID: From: Brian Smith To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c2d6d01efdbd04fb19c04c Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1CZ14oOMFWC5aCq6OA2pOZ45uy8 Cc: Phillip Hallam-Baker , "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:05:45 -0000 --001a11c2d6d01efdbd04fb19c04c Content-Type: text/plain; charset=UTF-8 On Thu, Jun 5, 2014 at 5:59 AM, Stephen Farrell wrote: > I'll do an AD review in any case before I start IETF LC and will > post a copy of that here. If other folks have comments I guess > send those here or to PHB and me. I'd be happy to get a couple > of mails saying "read it, its ready" after Phill's done his > tweaks as well btw. > I read the document. I disagree with the documented semantics of the extension when it appears in a CA certificate. The specification says that when the extension appears in a CA certificate, then the extension with the same values must also appear in all certificates under that CA certificate. And, it says that a client may ignore the extension in CA certificates. It would be safer if clients were required to enforce the Must-Staple restriction if the extension appears in any CA certificate in the chain. That way, the mechanism would work even against an attacker that can issue themselves an end-entity certificate that does not have the "must-staple" feature. If this change were made, then the encoding of certificates as sent on the wire would also become more efficient because fewer copies of the extension would be needed: For example, in a chain EE <- Int1 <- Int2 <- Int3, where Int3 contains the extension, the savings would be 3x the size of the extension. Granted, the extension isn't large, but we should avoid such waste since the size of certificates does have a significant impact on TLS handshake performance. IIRC, one previous version of the draft specified a mechanism for a CA certificate to indicate that the OCSP response for the CA certificate must also be stapled, using the OCSP multi-stapling mechanism. I think this is a useful feature and we should bring this feature back. Otherwise, we'll have to specify a new version of Must-Staple to support this later. A more minor concern: It seems strange to have an X.509 extension, which is identified by an OID, which is simply a list of unrelated features identified by OID. In particular, why not just have a "Must-Staple" X.509 extension (or two: Must-Staple-End-Entity and Must-Staple-All) that is (are) empty, and avoid the need for the "feature" wrapper extension? The wrapper made more sense in earlier drafts because there was more than one feature specified. Now, it doesn't seem to make sense. Removing the wrapper would make the mechanism simpler and I think we should remove the wrapper. Let's say a website's certificate's private key has been compromised and that certificate was NOT Must-Staple. The website has no truly effective mechanism to revoke that certificate, at least as far as browsers are concerned. We saw how this played out (is playing out) with the Heartbleed stuff. I think in the many years before Must-Staple could become ubiquitous, we'll need another mechanism to indicate that all certificates for a given hostname must be Must-Staple, whether they contain the Must-Staple feature in the X.509 certificate or not. I don't know that that has to be addressed in *this* draft or in a draft of a different feature, but it seems like in the near term we should also have a mechanism that applies to certificates that do not contain the feature. Cheers, Brian --001a11c2d6d01efdbd04fb19c04c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 5, 2014 at 5:59 AM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:
I'll do an AD review in any case before = I start IETF LC and will
post a copy of that here. If other folks have comments I guess
send those here or to PHB and me. I'd be happy to get a couple
of mails saying "read it, its ready" after Phill's done his tweaks as well btw.

I read the document= . I disagree with the documented semantics of the extension when it appears= in a CA certificate.

The specification says that when the extension= appears in a CA certificate, then the extension with the same values must = also appear in all certificates under that CA certificate. And, it says tha= t a client may ignore the extension in CA certificates. It would be safer i= f clients were required to enforce the Must-Staple restriction if the exten= sion appears in any CA certificate in the chain. That way, the mechanism wo= uld work even against an attacker that can issue themselves an end-entity c= ertificate that does not have the "must-staple" feature.

If this change were made, then the encoding of certificates as sent on = the wire would also become more efficient because fewer copies of the exten= sion would be needed: For example, in a chain EE <- Int1 <- Int2 <= - Int3, where Int3 contains the extension, the savings would be 3x the size= of the extension. Granted, the extension isn't large, but we should av= oid such waste since the size of certificates does have a significant impac= t on TLS handshake performance.

IIRC, one previous version of the draft specified a mechanis= m for a CA certificate to indicate that the OCSP response for the CA certif= icate must also be stapled, using the OCSP multi-stapling mechanism. I thin= k this is a useful feature and we should bring this feature back. Otherwise= , we'll have to specify a new version of Must-Staple to support this la= ter.

A more minor concern: It seems strange to have an X.509 exte= nsion, which is identified by an OID, which is simply a list of unrelated f= eatures identified by OID. In particular, why not just have a "Must-St= aple" X.509 extension (or two: Must-Staple-End-Entity and Must-Staple-= All) that is (are) empty, and avoid the need for the "feature" wr= apper extension? The wrapper made more sense in earlier drafts because ther= e was more than one feature specified. Now, it doesn't seem to make sen= se. Removing the wrapper would make the mechanism simpler and I think we sh= ould remove the wrapper.

Let's say a website's certificate's private key = has been compromised and that certificate was NOT Must-Staple. The website = has no truly effective mechanism to revoke that certificate, at least as fa= r as browsers are concerned. We saw how this played out (is playing out) wi= th the Heartbleed stuff. I think in the many years before Must-Staple could= become ubiquitous, we'll need another mechanism to indicate that all c= ertificates for a given hostname must be Must-Staple, whether they contain = the Must-Staple feature in the X.509 certificate or not. I don't know t= hat that has to be addressed in *this* draft or in a draft of a different f= eature, but it seems like in the near term we should also have a mechanism = that applies to certificates that do not contain the feature.

Cheers,
Brian

--001a11c2d6d01efdbd04fb19c04c-- From nobody Thu Jun 5 10:14:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BF21A01F6 for ; Thu, 5 Jun 2014 10:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 347vKjS_qV0P for ; Thu, 5 Jun 2014 10:14:45 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250091A0090 for ; Thu, 5 Jun 2014 10:14:45 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id hq11so1521994vcb.12 for ; Thu, 05 Jun 2014 10:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sqNVnIgA5P/v18XtLGStcAt9MIVQB7AJ2HZenfOGieI=; b=Eimzh0HMUmwxtej08f1J/UkCMsaFyOJx44QDyeecLoBGIIVX53Vwi4hyN9u+1Xrmbi evD7ct4dqF+jjUWgLp0MZGoE1KkfC2+WHOLRqGKb50fYyaeQkLtr76TgrBe7eZXL0Yc8 ee3HAtEj6S810nD4wpTtinVCwlYSm4Ojp186o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sqNVnIgA5P/v18XtLGStcAt9MIVQB7AJ2HZenfOGieI=; b=SvqIF7taeteDPIb+E+AHOohCVxEj4kqD19Ke7fWyIIcLk8opZhWRuYODhtR9cKjp6y /E7Wj0clxpMwWMzwcebWDKLOmZhZr5fPm8Pn9mN1yJM65WO7Ygtxn8JKNL672cJwVLQL 0ipj2dLmCWzkEFpOiO1wjY4graBmV5lF940DbwLQPJy+8vkCfy1lhKGHslJbfMw55vDN kroR1JMN+0ouThHmwaBvfJs8VHZuLlWQpxiUvNTgFBrARwj3K46PQZaTC8TXw5JvonE1 9BP15BHdRuJZnZnnm/3B4OiLXQuXRRTzF75T3wa0Io4+ZzXGu64dhB2aN5GlKknZoDBZ cdMQ== X-Gm-Message-State: ALoCoQl60PtbeKNBVhlGBlIuhKLMCxgY/DE/EFxyDe0lgLkdS0/TurKM9NQLmCXia2viUDPEtj1U X-Received: by 10.220.44.141 with SMTP id a13mr3061290vcf.71.1401988478184; Thu, 05 Jun 2014 10:14:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.106.39 with HTTP; Thu, 5 Jun 2014 10:14:18 -0700 (PDT) In-Reply-To: References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> From: Tom Ritter Date: Thu, 5 Jun 2014 13:14:18 -0400 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=047d7b34309438c49f04fb19e113 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/z8jZk63huiwwiwEk0b_s3Gopyp8 Cc: Phillip Hallam-Baker , "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:14:46 -0000 --047d7b34309438c49f04fb19e113 Content-Type: text/plain; charset=ISO-8859-1 On 5 June 2014 13:05, Brian Smith wrote: > I think in the many years before Must-Staple could become ubiquitous, > we'll need another mechanism to indicate that all certificates for a given > hostname must be Must-Staple, whether they contain the Must-Staple feature > in the X.509 certificate or not. I don't know that that has to be addressed > in *this* draft or in a draft of a different feature, but it seems like in > the near term we should also have a mechanism that applies to certificates > that do not contain the feature. > I believe it is many people's intention (at least it is mine) to include it as a directive in HSTS. There'a an argument to make it a separate header, like PKP. "What if I want my site not to require SSL, but if it does, to use these certs and that they should be stapled." -tom --047d7b34309438c49f04fb19e113 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 5= June 2014 13:05, Brian Smith <brian@briansmith.org> wrot= e:
I think in the many years before Must-Staple could become ubiqu= itous, we'll need another mechanism to indicate that all certificates f= or a given hostname must be Must-Staple, whether they contain the Must-Stap= le feature in the X.509 certificate or not. I don't know that that has = to be addressed in *this* draft or in a draft of a different feature, but i= t seems like in the near term we should also have a mechanism that applies = to certificates that do not contain the feature.

I believe it is many people's intention (at least it is mine) to i= nclude it as a directive in HSTS. =A0There'a an argument to make it a s= eparate header, like PKP. =A0"What if I want my site not to require SS= L, but if it does, to use these certs and that they should be stapled."= ; =A0

-tom
<= /div> --047d7b34309438c49f04fb19e113-- From nobody Thu Jun 5 10:24:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290091A021A for ; Thu, 5 Jun 2014 10:24:04 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33Vhf-HMAyhc for ; Thu, 5 Jun 2014 10:24:02 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92FEA1A017F for ; Thu, 5 Jun 2014 10:24:02 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u57so1520580wes.29 for ; Thu, 05 Jun 2014 10:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=/8Uy2Ez954XNVmMvdwv9RF9VDisoDSXOnWfrf0fxMYo=; b=mzwLCzcbjdL1Y2QlwiBPOM9NcIb1rUEmzkC8mBrQ6VIcI4amHsF+3EO29RX/pi0ZG8 zPuvLsuLZBjMYL7OxgF1J9PQUWV90oCf3ewD5ugdbd38Em78IoFGmMkToGwFB9cLyIiP FE3dMfSp6TtVD8X/c8ay4o8Z1RBBk1NwrKPqAhZ95brEyFz3otAAM257OqGD5xvolo3j c3oNbaoLr5vlkUDWTKiTQftTsYO2sKh7v6T+VPse5yjbGbEnNom5+dB0Q1Mxqh0Im5r8 tPKloOjRoXZqTs4aWbZt5eWLrZ/yPhoWNp6uCJEtz8TxaETJzTeB8gllG1x5tKfNVwFa yarw== X-Received: by 10.180.13.113 with SMTP id g17mr17994722wic.48.1401989032954; Thu, 05 Jun 2014 10:23:52 -0700 (PDT) Received: from [192.168.1.102] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id b19sm16632674wic.5.2014.06.05.10.23.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 10:23:52 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: <20140605164241.GJ27883@mournblade.imrryr.org> Date: Thu, 5 Jun 2014 20:23:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3211431A-4A22-487F-B23B-1794BCFFB009@gmail.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> <20140605164241.GJ27883@mournblade.imrryr.org> To: tls@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ehbELPXw2YEcPpNEDxcnJkLMZhQ Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:24:04 -0000 On Jun 5, 2014, at 7:42 PM, Viktor Dukhovni = wrote: > On Thu, Jun 05, 2014 at 08:25:26AM -0700, Watson Ladd wrote: >=20 >>> I think it adds weight to my concern about using ChangeCipherSpec to = do >>> key reset. I still prefer the trade-offs of having a ?slow the TLS = but >>> keep the TCP layer open? and starting over. Much simpler to prove = it?s >>> correct. >>=20 >> What can change when that happens? Furthermore, rekeying is a matter = of >> getting more PRF output: how does that introduce security concerns. >=20 > Whether or not rekeying is easier to implement with a STOPTLS, or > by switching directly from one keyset to another, without an > intermediate transition to cleartext, a STOPTLS feature has additional > upside. I don't recall whether this idea got dropped, or whether > STOPTLS might yet happen in TLS 1.3. Anyone care to bring me up > to speed? Sure.=20 StopTLS is just an idea I threw around ([1]) in response to some other = idea that someone said in the room (no idea who and don=92t remember = what) in pretty much the last minute of the Interim meeting. I think it = was a response to some other suggestions to get rid of renegotiation for = rekeying, such as requiring everyone to start a new connection (StopTLS = saves a round-trip), or various kinds of abbreviated handshake (StopTLS = is simpler).=20 StopTLS would need some mechanism to prevent a Dispensa/Ray/Rex prefix = injection attack. It=92s not currently a part of any plan for any version of TLS. Yoav [1] http://www.ietf.org/jabber/logs/tls/2014-05-16.html at time = 19:40:04= From nobody Thu Jun 5 10:32:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FBE1A0123 for ; Thu, 5 Jun 2014 10:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDYoILr8SDs6 for ; Thu, 5 Jun 2014 10:32:30 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1D91A00EA for ; Thu, 5 Jun 2014 10:32:30 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9F49B2AAB4F; Thu, 5 Jun 2014 17:32:23 +0000 (UTC) Date: Thu, 5 Jun 2014 17:32:23 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140605173223.GK27883@mournblade.imrryr.org> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oxAjcY7ujbCKtAHdLR5a0CPW95w Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:32:32 -0000 On Thu, Jun 05, 2014 at 10:05:22AM -0700, Brian Smith wrote: > I read the document. I disagree with the documented semantics of the > extension when it appears in a CA certificate. [ Apologies if my understanding of how the revocation process works in practice is a bit stale, perhaps things are better now than the last time I looked. ] This extension introduces a requirement to implement OCSP stapling predicated on the assumption, that we have usable revocation mechanisms, and that all that remains is for clients to learn in a reasonably timely manner that a certificate has been revoked. It also assumes that servers are generally deployed in environments where periodically obtaining OCSP responses from the server's CA for stapling is practical. There at this time to my knowledge no standard companion protocol for OCSP that allows the holder of a key pair (when the private key is not lost) to sign a request to the CA to revoke the certificate. Instead, it is my impression, that we have "challenge phrases" that are often not set or lost, and CA-specific interfaces to activate revocation. If, this is indeed the case, then I claim that mandatory OCSP stapling is putting the cart before the horse. Only a tiny fraction of certificates can be effectively revoked. I would like to see CAs stop publishing CRLs entirely (solving the scaling issue for mass revocations as with Heartbleed), implement only OCSP, and provide a standard zero-cost revocation protocol when the private key is available (or when a miracle happens and the "challenge" password is actually known). Once revocation is a scalable working process, then we can benefit from insisting on OCSP stapling, provided we figure out what to do with servers that don't have any way to reach out and refresh OCSP responses for stapling, nor support interface for an agent to obtain the response on the server's behalf and push it into the server's configuration. -- Viktor. From nobody Thu Jun 5 10:36:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8C71A0144 for ; Thu, 5 Jun 2014 10:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_ZKtPuuQ5GN for ; Thu, 5 Jun 2014 10:36:45 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3DE1A0123 for ; Thu, 5 Jun 2014 10:36:45 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B3FD91655D1 for ; Thu, 5 Jun 2014 17:36:38 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id A977D1655CC for ; Thu, 5 Jun 2014 17:36:38 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 90DD39803D for ; Thu, 5 Jun 2014 17:36:38 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Thu, 5 Jun 2014 13:36:37 -0400 From: "Salz, Rich" To: "tls@ietf.org" Date: Thu, 5 Jun 2014 13:36:37 -0400 Thread-Topic: [TLS] OCSP must staple Thread-Index: Ac+A5C3jcjwS24Y2T/yMJXwQltnNDgAADDJw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434A6B@USMBX1.msg.corp.akamai.com> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <20140605173223.GK27883@mournblade.imrryr.org> In-Reply-To: <20140605173223.GK27883@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SRa4vZnvnd8ZjY6naBa09WhkJzM Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:36:48 -0000 EV certs, which are important to many businesses, basically require browser= s to do OCSP. An offline protocol -- "yes, this is Larry, please revoke and re-issue all = Google certificates" -- suffices for those large organizations. Yes this leaves the smaller players out. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Thu Jun 5 10:43:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E821A0123 for ; Thu, 5 Jun 2014 10:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xmh46GGUQJKy for ; Thu, 5 Jun 2014 10:43:19 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6AE1A011F for ; Thu, 5 Jun 2014 10:43:18 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 39FF52AAB4F; Thu, 5 Jun 2014 17:43:12 +0000 (UTC) Date: Thu, 5 Jun 2014 17:43:12 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140605174312.GL27883@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> <20140605164241.GJ27883@mournblade.imrryr.org> <3211431A-4A22-487F-B23B-1794BCFFB009@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3211431A-4A22-487F-B23B-1794BCFFB009@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XpnOPfYBNJOuDFDdgtj2--Z2mP0 Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:43:20 -0000 On Thu, Jun 05, 2014 at 08:23:46PM +0300, Yoav Nir wrote: > > I don't recall whether this idea got dropped, or whether > > STOPTLS might yet happen in TLS 1.3. Anyone care to bring me up > > to speed? > > Sure. Thanks. > StopTLS would need some mechanism to prevent a Dispensa/Ray/Rex > prefix injection attack. Would it suffice to ban application-data messages after STOPTLS before a new handshake completes, and to require a subsequent handshake to be a resumption of the previous session (or a new session handshake in cleartext, but channel-bound to the previous session). The purpose of STOPTLS would not be a downgrade to cleartext data tranfer, but rather a transition from one key-set to another via a cleartext handshake that can happen with minimal crypto-state transfer (saved session object or some opaque shared secret sufficient). > It's not currently a part of any plan for any version of TLS. If it does come back, I can put it to good use. -- Viktor. From nobody Thu Jun 5 11:07:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F681A0144 for ; Thu, 5 Jun 2014 11:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMjBb6BFQLEo for ; Thu, 5 Jun 2014 11:07:09 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A861A01A0 for ; Thu, 5 Jun 2014 11:07:08 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id k15so1607110qaq.40 for ; Thu, 05 Jun 2014 11:07:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=K3ckpkFB1YvsLU4WUYOVN5tiK17oJCONuN+sj0KOfjM=; b=cz3Z2skxlI5s9vvjTiwGuaBQsMg19NgVj8tQcG74Mgop/IOn4tpE+GjqCjtz2DfMHn TRQUxg4j/Q2/c5zKRssBH1LKQCNsLAJH79WlvEeqVGrn7gFqrwccMFqc95Ua3/42/8Ct VvFU58rZU7J5A+pOHay6Hpe0kz6iSTUFaZoS1eDaWXRaf7LUIVkjou6AR5JJ+4wlQ1I2 9gh3TrQ3Lvk7TVuUsRz0dxQqDHp6ypTbumRWIrBAxta6wEFz7TrhgUWV37mPqUcg0wr9 zcEu6MV+OnSotnISzUknG9J/BiDzRCpIySLzY4QbOfRs921pnfaNZYT9xOW571XytvGa mrDQ== X-Gm-Message-State: ALoCoQmVviH8GBHl2ghpBgOFUJpa8qyAr2DGAkW5C/hwMPuX03VYyCndNlhFQCUWUX4BGXYp1A9O X-Received: by 10.224.166.73 with SMTP id l9mr19686542qay.34.1401991621737; Thu, 05 Jun 2014 11:07:01 -0700 (PDT) Received: from [192.168.1.102] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id b7sm10528844qae.32.2014.06.05.11.07.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 11:07:01 -0700 (PDT) Message-ID: <5390B1D6.5010105@nthpermutation.com> Date: Thu, 05 Jun 2014 14:07:18 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> In-Reply-To: <539069CC.5010304@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FeROtAFkt4ZjJJmqIMSX-7wRAcI Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 18:07:24 -0000 Hi - The note by Brian Smith made me take a second look at http://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/. From the list chatter, I thought it was pretty much a standard CA extension. I didn't realize that PHB had defined it as a transitive (i.e. if the CA has it, then it applies all the way down the chain) extension, rather than just a simple one-off application. Given the above, I would reject the document and suggest instead that this use the CertificatePolicies extension. Two ways of doing this: First: 1) Define a policy OID for each TLS feature - the set is pretty small right now and I don't see it growing all that much. This is probably the right approach and doesn't require anything more than a description of the OID and the related policy processing. or Second 1) Define a policy OID for TLS Features 2) Define a PolicyQualifier OID for a FeatureIds qualifier 3) Define "FeatureIds ::= SEQUENCE of TlsFeatures" 4) Define "TlsFeatures ::= INTEGER { feature1 (1), feature2(2), ...} This is more flexible, but seems to violate the spirit of RFC5280, section 4.2.1.4 - the "RECOMMENDS" items. Doing it one of the above ways doesn't require modification to the cert path building logic (which isn't fully specified in the draft and should be). The first also - mostly - doesn't require changes to code that build certificates which means it could enter production on the cert side much quicker. Mike On 6/5/2014 8:59 AM, Stephen Farrell wrote: > Hiya, > > On 05/06/14 13:40, Phillip Hallam-Baker wrote: >> By which I simply mean, lets make get people to actually read that >> particular draft rather than start a cabal. So if we give folks a week >> and then we can go forward with the document shepherd? > Sure works for me. Can you try recruit a shepherd? > > I'll do an AD review in any case before I start IETF LC and will > post a copy of that here. If other folks have comments I guess > send those here or to PHB and me. I'd be happy to get a couple > of mails saying "read it, its ready" after Phill's done his > tweaks as well btw. > > Cheers, > S. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Jun 5 11:34:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F161A02B5 for ; Thu, 5 Jun 2014 11:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56B7ppldqiKy for ; Thu, 5 Jun 2014 11:34:52 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A22481A024D for ; Thu, 5 Jun 2014 11:34:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F3D62BF85 for ; Thu, 5 Jun 2014 19:34: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 OX85_NU_ljEq for ; Thu, 5 Jun 2014 19:34:44 +0100 (IST) Received: from [10.87.48.12] (unknown [86.44.75.78]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 92401BED5 for ; Thu, 5 Jun 2014 19:34:44 +0100 (IST) Message-ID: <5390B844.9020207@cs.tcd.ie> Date: Thu, 05 Jun 2014 19:34:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "tls@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/c9KY9W7QIhnm0VN0rAxLnEpzbsM Subject: [TLS] Fwd: [IANA #764648] Re: Early codepoint assignment for draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 18:34:54 -0000 FYI -------- Original Message -------- Subject: [IANA #764648] Re: [TLS] Early codepoint assignment for draft-ietf-tls-encrypt-then-mac Date: Thu, 5 Jun 2014 18:33:26 +0000 From: Amanda Baber via RT Reply-To: iana-prot-param@iana.org To: draft-ietf-tls-encrypt-then-mac@tools.ietf.org, stephen.farrell@cs.tcd.ie, tls-chairs@tools.ietf.org Hi, We've made the following temporary assignment in the ExtensionType Values registry: 22 encrypt_then_mac (TEMPORARY - expires 2015-06-05) [draft-ietf-tls-encrypt-then-mac] See http://www.iana.org/assignments/tls-extensiontype-values Please add the name of the registration and the registry to the IANA Considerations section. From nobody Thu Jun 5 11:59:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D451A00FC for ; Thu, 5 Jun 2014 11:59:30 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew0EjRfS5L8Y for ; Thu, 5 Jun 2014 11:59:28 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CAF91A02CB for ; Thu, 5 Jun 2014 11:59:24 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id l18so1599738wgh.23 for ; Thu, 05 Jun 2014 11:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=AVmb+VR2+O1vqUKhG2RPiV8a0Lu8xJ7UFckPhEx4kDE=; b=YYawFTnjObLCYsvRT7RKuZecmHq5vj97lXKv8XcBcnrw8bU/m0vXwlbCxKgF+tWVar f/IgOCyb9wGkNrmTH+4ZLkv0sZWwc+HAoqnVqG1v0eA4UcDHKr9oHR941DiDN8xEXSbb AnFeLtWucrsPTaz+jBGTV5Okq2/7M0I6xno+GwtEPbptiL/+z7czRrCLbrGnWrV/C4WD KlOPHcACgmT02cyGPT+Iq4VdXdCWh+jfbQcKpYpLub3HdQYXHPjzt4uNwVgoePPgLQIh FcszJsJioictgRQc1S1FXph8vzFuZgbF3OQ0Vn+i2T+nBGTPo6IUYkbFV+TDYwb65H5R Yxeg== X-Received: by 10.180.211.146 with SMTP id nc18mr528241wic.53.1401994757459; Thu, 05 Jun 2014 11:59:17 -0700 (PDT) Received: from [192.168.1.102] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id na4sm55619112wic.21.2014.06.05.11.59.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 11:59:16 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_08FFAD85-31FF-4B20-AE6F-FC33D37F61DF" Message-Id: <3255D953-9F23-4F98-AA60-2C844B9E41A8@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Thu, 5 Jun 2014 21:59:12 +0300 References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> <20140605164241.GJ27883@mournblade.imrryr.org> <3211431A-4A22-487F-B23B-1794BCFFB009@gmail.com> <20140605174312.GL27883@mournblade.imrryr.org> To: tls@ietf.org In-Reply-To: <20140605174312.GL27883@mournblade.imrryr.org> X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sT0_7-V5bgiyY6EY9A7Lhj5ZF7A Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 18:59:30 -0000 --Apple-Mail=_08FFAD85-31FF-4B20-AE6F-FC33D37F61DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 5, 2014, at 8:43 PM, Viktor Dukhovni = wrote: > On Thu, Jun 05, 2014 at 08:23:46PM +0300, Yoav Nir wrote: >=20 >>> I don't recall whether this idea got dropped, or whether >>> STOPTLS might yet happen in TLS 1.3. Anyone care to bring me up >>> to speed? >>=20 >> Sure.=20 >=20 > Thanks. >=20 >> StopTLS would need some mechanism to prevent a Dispensa/Ray/Rex >> prefix injection attack. >=20 > Would it suffice to ban application-data messages after STOPTLS > before a new handshake completes, and to require a subsequent > handshake to be a resumption of the previous session (or a new > session handshake in cleartext, but channel-bound to the previous > session). The Ray/Dispensa/Rex attack would be a MitM starting a TLS connection, = sending to the server =93GET /form.html?Button=3DShutdown = HTTP/1.0\nx-fake-header: =93 and then sending a StopTLS and forwarding = the client=92s real ClientHello. The server would see this: GET /form.html?Button=3DShutdown HTTP/1.0 x-fake-header: GET /form.html?Button=3DStatus HTTP/1.1 Cookie: authorization=3Dwxvr7Z7hL8GXSQLqaIU6Cg=3D=3D And the client=92s cookie would authorize the attacker=92s request and = the device would shut down. Yes, this was a real application, and yes, = the attack worked. As you say, binding the new handshake to the old handshake should = suffice, whether it=92s done through the channel binding or through the = resumption cache. On a more philosophical level we might want to = consider whether providing the application with a single, steady stream = regardless of rekeying/renegotiation/new state is the right thing. In = other words, it=92s not clear to me that these events should not be = reflected to the application so that application context does not flow = from one TLS context to another. >=20 > The purpose of STOPTLS would not be a downgrade to cleartext data > tranfer, but rather a transition from one key-set to another via > a cleartext handshake that can happen with minimal crypto-state > transfer (saved session object or some opaque shared secret > sufficient). >=20 >> It's not currently a part of any plan for any version of TLS. >=20 > If it does come back, I can put it to good use. >=20 > --=20 > Viktor. --Apple-Mail=_08FFAD85-31FF-4B20-AE6F-FC33D37F61DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 5, 2014, at 8:43 PM, Viktor = Dukhovni <viktor1dane@dukhovni.org> = wrote:

On Thu, Jun 05, 2014 at 08:23:46PM +0300, Yoav Nir = wrote:

I = don't recall whether this idea got dropped, or whether
STOPTLS might = yet happen in TLS 1.3.  Anyone care to bring me up
to = speed?

Sure. =

Thanks.

StopTLS = would need some mechanism to prevent a Dispensa/Ray/Rex
prefix = injection attack.

Would it suffice to ban = application-data messages after STOPTLS
before a new handshake = completes, and to require a subsequent
handshake to be a resumption = of the previous session (or a new
session handshake in cleartext, but = channel-bound to the = previous
session).

The = Ray/Dispensa/Rex attack would be a MitM starting a TLS connection, = sending to the server =93GET /form.html?Button=3DShutdown = HTTP/1.0\nx-fake-header: =93 and then sending a StopTLS and forwarding = the client=92s real ClientHello. The server would see = this:

GET /form.html?Button=3DShutdown = HTTP/1.0
x-fake-header: GET /form.html?Button=3DStatus = HTTP/1.1
Cookie: authorization=3Dwxvr7Z7hL8GXSQLqaIU6Cg=3D=3D

And the client=92s cookie would authorize the = attacker=92s request and the device would shut down. Yes, this was a = real application, and yes, the attack = worked.

As you say, binding the = new handshake to the old handshake should suffice, whether it=92s done = through the channel binding or through the resumption cache. On a more = philosophical level we might want to consider whether providing the = application with a single, steady stream regardless of = rekeying/renegotiation/new state is the right thing. In other words, = it=92s not clear to me that these events should not be reflected = to the application so that application context does not flow from = one TLS context to another.


The = purpose of STOPTLS would not be a downgrade to cleartext = data
tranfer, but rather a transition from one key-set to another = via
a cleartext handshake that can happen with minimal = crypto-state
transfer (saved session object or some opaque shared = secret
sufficient).

It's not = currently a part of any plan for any version of = TLS.

If it does come back, I can put it to good = use.

--
= Viktor.

= --Apple-Mail=_08FFAD85-31FF-4B20-AE6F-FC33D37F61DF-- From nobody Thu Jun 5 12:12:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EB01A026E for ; Thu, 5 Jun 2014 12:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtquhnE4Cv66 for ; Thu, 5 Jun 2014 12:12:08 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A512F1A026F for ; Thu, 5 Jun 2014 12:12:08 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id a108so2363590qge.25 for ; Thu, 05 Jun 2014 12:12:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=O6o+Pe6ZMz2qe2PZdl7IDi84dv62P92qlyTXNYrO4iU=; b=PWBDUJt87bum41SNpUL4I3JPn3mobh5WB4lz4U5m+euMJ6TKGWmNEF4tZUz5WasjtY nIyK3nZeFvZatfF6lAY+UPUPM/6RhFYFU5Yl6SZEkMsWY4+FmDNHujSh8s8PzvUUT9E8 RG0vbdE7Uw3Q689QYqaKG0Td9wi2f09r5twbfbeSvl2e55qVJvoMDYHcoYFr1R4FA4fx 7iKovl/Vg09y3GoM/Wm05Oxg08WyXkFv4XWdp4lFJ1qTkVjZUGtU7GaJizs0thScgJjz Ty2gxU1t3fDotS0hFi2TPV8dcBk+MEUGVsPyLgsWfroasKa21pdrJjRWwcpAuoH/TVbu lkAA== X-Gm-Message-State: ALoCoQkAPu2J0VZj7mVf7VWcdBj6lzYhA0o59IxlrXMZoBRvIN6bf7+bKLrFq1UTZcbn3gP0QPv4 MIME-Version: 1.0 X-Received: by 10.229.79.2 with SMTP id n2mr85114728qck.11.1401995521796; Thu, 05 Jun 2014 12:12:01 -0700 (PDT) Received: by 10.224.201.193 with HTTP; Thu, 5 Jun 2014 12:12:01 -0700 (PDT) In-Reply-To: <5390B1D6.5010105@nthpermutation.com> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <5390B1D6.5010105@nthpermutation.com> Date: Thu, 5 Jun 2014 12:12:01 -0700 Message-ID: From: Brian Smith To: Michael StJohns Content-Type: multipart/alternative; boundary=001a1133a1a00df9a604fb1b85df Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uMlbd73RFcRUaQBkzQYdIGN0Q_4 Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 19:12:10 -0000 --001a1133a1a00df9a604fb1b85df Content-Type: text/plain; charset=UTF-8 On Thu, Jun 5, 2014 at 11:07 AM, Michael StJohns wrote: > I didn't realize that PHB had defined it as a transitive (i.e. if the CA > has it, then it applies all the way down the chain) extension, rather than > just a simple one-off application. > I don't think it actually is transitive. That is why I was asking it to be changed to be transitive. I guess either way the draft should be clarified regarding this. Given the above, I would reject the document and suggest instead that this > use the CertificatePolicies extension. > 1) Define a policy OID for TLS Features > 2) Define a PolicyQualifier OID for a FeatureIds qualifier > 3) Define "FeatureIds ::= SEQUENCE of TlsFeatures" > 4) Define "TlsFeatures ::= INTEGER { feature1 (1), feature2(2), ...} > > This is more flexible, but seems to violate the spirit of RFC5280, section > 4.2.1.4 - the "RECOMMENDS" items. > Right, we should avoid going against RFC 5280's recommendation here, so I don't think this is a reasonable option. Doing it one of the above ways doesn't require modification to the cert > path building logic (which isn't fully specified in the draft and should > be). The first also - mostly - doesn't require changes to code that build > certificates which means it could enter production on the cert side much > quicker. > Is it really significantly easier for CAs to add new certificate policies compared to adding new certificate extensions? I could see how that could be the case, but I think it would be good to hear from CAs about this. I think one consideration is whether somebody that is operating an externally-operated sub-CA using closed-source, slow-release-cycle software (e.g. Microsoft's CA software) could implement the policy-based approach without waiting for any patch/update from their vendor. If that is the case, that would be a significant benefit of your (policy-OID-per-feature) policy-based approach. Cheers, Brian --001a1133a1a00df9a604fb1b85df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 5, 2014 at 11:07 AM, Michael StJohns <msj@nthpermutation.com= > wrote:
I didn't realize that PHB had defined it= as a transitive (i.e. if the CA has it, then it applies all the way down t= he chain) extension, rather than just a simple one-off application.

I don't think it actually is transitiv= e. That is why I was asking it to be changed to be transitive. I guess eith= er way the draft should be clarified regarding this.

Given the above, I would reject the document and suggest instead that this = use the CertificatePolicies extension.

<snip>

1) Define a policy OID for TLS Feature= s
2) Define a PolicyQualifier OID for a FeatureIds qualifier
3) Define "FeatureIds ::=3D SEQUENCE of TlsFeatures"
4) Define "TlsFeatures ::=3D INTEGER { feature1 (1), feature2(2), ...}=

This is more flexible, but seems to violate the spirit of RFC5280, section = 4.2.1.4 - the "RECOMMENDS" items.

=
Right, we should avoid going against RFC 5280's=C2=A0 recommendati= on here, so I don't think this is a reasonable option.

Doing it one of the above ways doesn't require modification to the cert= path building logic (which isn't fully specified in the draft and shou= ld be). =C2=A0The first also - mostly - doesn't require changes to code= that build certificates which means it could enter production on the cert = side much quicker.

Is it really significantl= y easier for CAs to add new certificate policies compared to adding new cer= tificate extensions? I could see how that could be the case, but I think it= would be good to hear from CAs about this.

I think one consideration is whether s= omebody that is operating an externally-operated sub-CA using closed-source= , slow-release-cycle software (e.g. Microsoft's CA software) could impl= ement the policy-based approach without waiting for any patch/update from t= heir vendor. If that is the case, that would be a significant benefit of yo= ur (policy-OID-per-feature) policy-based approach.

Cheer= s,
Brian
--001a1133a1a00df9a604fb1b85df-- From nobody Thu Jun 5 12:51:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AF71A0325 for ; Thu, 5 Jun 2014 12:51:25 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGacqh79gFRS for ; Thu, 5 Jun 2014 12:51:23 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B3A1A02F9 for ; Thu, 5 Jun 2014 12:51:23 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id q108so2407201qgd.41 for ; Thu, 05 Jun 2014 12:51:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YpewoTznkPV4PoBdMw1sQoK8ahfXZRMjfLxL42NZcsc=; b=gksDBtULqdZDzsnEdH8IV5RotC83Oi0ZiNZ4KG5rOEGK+KULOHfHoK164M+hjrkD7j E6Coan4XaKIgNMJsFoSPLEy3weLXICJl6osdOc2GbWi1QM1H9M7zAOi3Ve8ZkaHEJcin ddK1x145v2VkWAO+5TGfHzbKyOvmD/GngJ9tWP5/UyaMJc+4GBeFmdjiwWhpwGSTA/ku w82JJbbVu1S1Zq9utoFXQ39fKe3RhCD7+e5r+Gz4hvk0HoWf6XVwjJEmMaVGIwv2Cade IyMJ9wGs76QVnnlKaOnStO7L/ZnT8hM6BYOmnjAIUu032lc3wcJELMx95c21055VeXMO Kiyw== X-Gm-Message-State: ALoCoQnuRDkES7/1LMF1AwUYTyPyk5+zAb6pfIfhnHSOWT85mFGOfvDVEjr8F1zEKAbfJpgE2RKC X-Received: by 10.229.44.194 with SMTP id b2mr85657358qcf.0.1401997876786; Thu, 05 Jun 2014 12:51:16 -0700 (PDT) Received: from [192.168.1.102] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id u6sm10937840qah.28.2014.06.05.12.51.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 12:51:16 -0700 (PDT) Message-ID: <5390CA45.1050504@nthpermutation.com> Date: Thu, 05 Jun 2014 15:51:33 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian Smith References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <5390B1D6.5010105@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XuH-fc2SJsyBOP4fCMxxh6mXcbw Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 19:51:25 -0000 On 6/5/2014 3:12 PM, Brian Smith wrote: > Is it really significantly easier for CAs to add new certificate > policies compared to adding new certificate extensions? I could see > how that could be the case, but I think it would be good to hear from > CAs about this. Mostly the "put a policy object in the ca certificate" reduces to "configure the text string of the OIDs you want to include". https://www.openssl.org/docs/apps/x509v3_config.html#Certificate_Policies_ for example. The certificate policy extension is pretty well formed, which means that its pretty easy to specify in configuration language (e.g. xml, label=value) what you want to be included rather than having to go back and add new ASN1 encode/decode/translate to and from string logic. Things like Dogtag and EJBCA support it via a gui. From nobody Thu Jun 5 14:52:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDB71A0292 for ; Thu, 5 Jun 2014 14:52:07 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1hjcdjc6tEC for ; Thu, 5 Jun 2014 14:52:04 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB751A0188 for ; Thu, 5 Jun 2014 14:52:04 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id la4so1965381vcb.0 for ; Thu, 05 Jun 2014 14:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=kIjvRXLij8Tz7jZi34riQXtNm9OPRmiQRAL1Sj31LQ0=; b=SGL1AuoecLwWxtRvmJmxS8jQCX/CB7iOqg6Mo4ojISawNotmDsuL9ZVZhgqvSJRyii MFZJIQvyxOR0n44QGZijf+2O9crC7183gBAAPPhrfFbjkW/cB0QChPcyxdhj2fMEnFXL 23l8xPK8qwjR9NRJddFqlxB1vo3w9PAFd/WT/Hm6yPqj+hDgxpq/i1EPpvZ1tahlUnKM vgB2q6/nhfFMtOlrP4QnmzQyyDRFbGYfSMv+rvC2ViZuM1XvyDTHmHuo1pvjSeVIud4k nT+f7Q7oomikn3IWNBKqRjdjE1+VSb1A5VmZI24Wxq6qJtnX4hPVhOcLtnyjqmWGHOpX LcFQ== MIME-Version: 1.0 X-Received: by 10.58.143.13 with SMTP id sa13mr685452veb.44.1402005117383; Thu, 05 Jun 2014 14:51:57 -0700 (PDT) Received: by 10.220.227.7 with HTTP; Thu, 5 Jun 2014 14:51:57 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> Date: Thu, 5 Jun 2014 17:51:57 -0400 Message-ID: From: Jeffrey Walton To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zrwhvC05phCvSrkEZX1hPjhsyIw Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 21:52:07 -0000 On Thu, Jun 5, 2014 at 11:25 AM, Watson Ladd wrote: > > On Jun 5, 2014 8:12 AM, "Salz, Rich" wrote: >> >> Have folks seen this yet? >> >> http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index= .html >> >> I think it adds weight to my concern about using ChangeCipherSpec to do >> key reset. I still prefer the trade-offs of having a =E2=80=9Cslow the = TLS but keep >> the TCP layer open=E2=80=9D and starting over. Much simpler to prove it= =E2=80=99s correct. > > What can change when that happens? Furthermore, rekeying is a matter of > getting more PRF output: how does that introduce security concerns. > > I don't see why the incompetence of implementors should govern our > decisions. If something cannot be implemented correctly it must be remove= d, > but why is rekeying such a thing? I'm reading two points in that last statement: first, some implementers are incompetent; and second, the TLS WG does not make bad decisions. For the first point, I think its too easy to blame an implementer. Perhaps there's a gap that needs to be addressed for implementers. Has the TLS WG considered providing a comprehensive test framework to ensure their designs are realized in an implementation? The working group is in a unique position to offer the best and most complete set of tests. They are in that position because they understand what they want, they know why they want it, and they know what they rejected. So a testing framework with positive and negative self tests would probably be very helpful to implementers. And that's all implementers, and not just the ones that are labeled incompetent. Plus, the implementers should *NOT* be asked to create their own test cases. That's simply bad engineering, and the problem has been known for years. Gutmann and Anderson talk about in their respective books on security and engineering. Those books are 10 or 15 years old, so its not bleeding edge knowledge. For the second point, Authenticate-then-Encrypt has proven to be problematic for years. I would not blame the implementers or call them incompetent for subtle problems in the construction. Especially when it took a formal analysis by practicing cryptographers to uncover and present the problems [0]. The problems with Authenticate-then-Encrypt have been known since at least 2000 [0]. I question why the folks responsible for the standard did not acknowledge the problem and provide safer or better alternatives more expediaently. Nearly ten [1] or fifteen years [2] to address the [re-occuring] problem seems a bit excessive to me. The folks responsible for the standard are collectively smarter people than the folks implementing the standard and using the standard. We (the dumb users) need the group to act expediently when gaps are uncovered. For completeness, CompSci 101 mistakes are an implementers problem. ----- [0] H. Krawczyk. The Order of Encryption and Authentication for Protecting Communications, http://www.iacr.org/archive/crypto2001/21390309.pdf [1] J. Salowey, et al. AES Galois Counter Mode (GCM) Cipher Suites for TLS, http://tools.ietf.org/html/rfc5288 [2] P. Gutmann. Encrypt-then-MAC for TLS, http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-00 From nobody Thu Jun 5 18:42:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126E41A037C for ; Thu, 5 Jun 2014 18:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D38RplG1aVBQ for ; Thu, 5 Jun 2014 18:42:16 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA751A0383 for ; Thu, 5 Jun 2014 18:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1402018929; x=1433554929; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=CjRXwURGJXlo3kEwrj023z6TuGf6qCBicrnjfW2FUi0=; b=mpsRvCHi66uzGA1rEgGjbdeuQWo6n971nW3eZA8UaDSPn6AZmIE6TNYA o5bA2Lecj/gRTMbGfAXiB7mLhevyQgWGSh2U3gAJ8zG1an5UYfP6KJK4G +Vwjtu/2pxyDfDv0Pwy8EuINdZLSoEaK6en4Txvv+9mx/FfXROxco2DAR g=; X-IronPort-AV: E=Sophos;i="4.98,985,1392116400"; d="scan'208";a="256866508" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 06 Jun 2014 13:41:54 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 13:41:53 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] CCS and key reset and renegotiation Thread-Index: Ac+BKH58FWpJjkJqS7qDQbPV52MNUA== Date: Fri, 6 Jun 2014 01:41:53 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DEC3033@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RV9iCz7HPEbCApKycWyOtHJhyo8 Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 01:42:20 -0000 Watson Ladd writes:=0A= =0A= >The spec needs a state machine.=0A= =0A= No, it's this that created the problem in the first place. SSL/TLS (and SS= H,=0A= and others) are best described using a ladder diagram (and in fact that's h= ow=0A= pretty much every diagram of the protocols that I've ever seen does them).= =0A= The fact that the spec dresses it up like a state machine means that anyone= =0A= who actually tries to implement it that way ends up vulnerable to mistakes= =0A= like the current OpenSSL one. So the spec needs to take a protocol that=0A= exists as a ladder diagram and describe it as such, not pretend that it's= =0A= meant to be a state machine.=0A= =0A= Peter.= From nobody Thu Jun 5 19:59:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873281A03E7 for ; Thu, 5 Jun 2014 19:59:20 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgYubsho7NmG for ; Thu, 5 Jun 2014 19:59:15 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F321A03F3 for ; Thu, 5 Jun 2014 19:59:15 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id hw13so2780719qab.18 for ; Thu, 05 Jun 2014 19:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JQAyRFz7nrSOhP/Vds8o0rnt1kule5DvgYgehTEjZ/M=; b=qENdSh4zn5q0UOuVK/aTri62lUqgsXFoqlKZ4vJbx4vepMvARIzUkGRfJ9vqGKFBSH GMDd1WWL2ofsGJW16XEPYwfnJeqBmeSOiNuWllPUkYUoQWK+Qd5ct/exkC9LP5LXVVhS tqK+lSqATeXWTEy2Cjb2RlzJLYEDt92WHVPvpM4K2gjq1aYKds9mZqf7CZyHx9sCILMZ eTNr0hoyCmB/RDeObZ4dd96g7TOPNdKmzkQt5030GJV0TS1XgGh7Po5oBYQaeiEJg+97 ZC3xFyj//iIrynyE/zgVTSoFhedYcd5m5XVcE4eixmyr8sxfUdFMTimjwkfYzGD/XNYf ysJg== MIME-Version: 1.0 X-Received: by 10.140.96.51 with SMTP id j48mr3268336qge.24.1402023548134; Thu, 05 Jun 2014 19:59:08 -0700 (PDT) Received: by 10.140.19.229 with HTTP; Thu, 5 Jun 2014 19:59:08 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738DEC3033@uxcn10-tdc06.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C738DEC3033@uxcn10-tdc06.UoA.auckland.ac.nz> Date: Thu, 5 Jun 2014 19:59:08 -0700 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CdxXqAXCXadsQV174fMxbj8E8QE Cc: "" Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 02:59:21 -0000 On Thu, Jun 5, 2014 at 6:41 PM, Peter Gutmann wrote: > Watson Ladd writes: > >>The spec needs a state machine. > > No, it's this that created the problem in the first place. SSL/TLS (and SSH, > and others) are best described using a ladder diagram (and in fact that's how > pretty much every diagram of the protocols that I've ever seen does them). > The fact that the spec dresses it up like a state machine means that anyone > who actually tries to implement it that way ends up vulnerable to mistakes > like the current OpenSSL one. So the spec needs to take a protocol that > exists as a ladder diagram and describe it as such, not pretend that it's > meant to be a state machine. Because the Certificate, Certificate Request, ServerKeyExchange, and some other messages in the handshake are optional, I don't see how a ladder diagram can encapsulate the protocol. That's ignoring the fact that you can send as much application data as you desire before terminating the connection, so there is a branch: either we get app data, or a termination. To me a spec based on a state machine says in each state what all the allowed transitions are, and what is emitted in each state, and what drives the transitions. Either way 5 out of 6 implementors got it right. It's not even a barrier to formalization: what the protocol does is a much bigger issue, and that's where I hope to send a lengthy email laying out what TLS 1.3 should look like. (There is also another issue: X509 is massively complicated and is the only certificate format TLS supports. Perhaps we should consider lightweight alternatives) Sincerely, Watson Ladd > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Jun 6 01:01:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741771A0408 for ; Fri, 6 Jun 2014 01:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMxgcE1NIEGk for ; Fri, 6 Jun 2014 01:00:55 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB151A03D8 for ; Fri, 6 Jun 2014 01:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1402041649; x=1433577649; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=lq8r+NUmvr94bTBawPz+vemW9CRW+5xkRYJty3MNsWc=; b=Ogh1JYh0NBWSRyfOjrNeksDyiLMOaEPdEinHqPTd9TjehCz7dQXWVuYM RhM52299jglHBCsCpgnP+MpmGFBah/YbhXg+t8ssupjKBoP46EksO8JGI XNAj4x9xI0CLARzJi7TuK4d2SU70cLLNDmS13J3dIbLS5coYKXQ1WJ0k4 o=; X-IronPort-AV: E=Sophos;i="4.98,987,1392116400"; d="scan'208";a="256939522" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 06 Jun 2014 20:00:44 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 20:00:44 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] CCS and key reset and renegotiation Thread-Index: Ac+BXWoQe30NmmY6SaW1Ol8GBexjFg== Date: Fri, 6 Jun 2014 08:00:42 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DEC335D@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6r8BDLGWrwlV25F6pFmNGAlB7gc Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 08:00:59 -0000 Watson Ladd writes:=0A= =0A= >Because the Certificate, Certificate Request, ServerKeyExchange, and some= =0A= >other messages in the handshake are optional, I don't see how a ladder=0A= >diagram can encapsulate the protocol. =0A= =0A= ... and yet somehow everyone who's ever tried to document it this way has= =0A= succeeded.=0A= =0A= (Well, OK, that's a bit absolute, there may be thousands of people out ther= e=0A= who've tried to do this and given up that we don't know about, but somehow = I=0A= doubt it. When I did SSL it was so obviously a ladder diagram that I just= =0A= ignored all the state-machine stuff in the spec and implemented the protoco= l=0A= as such. My implementation couldn't be made vulnerable to the recent OpenS= SL=0A= issue without rewriting half the code).=0A= =0A= Peter.= From nobody Fri Jun 6 02:25:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479401A0445 for ; Fri, 6 Jun 2014 02:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMArWW-jjRQJ for ; Fri, 6 Jun 2014 02:25:03 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35191A0442 for ; Fri, 6 Jun 2014 02:25:02 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 4153A1A0071 for ; Fri, 6 Jun 2014 11:24:54 +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 LMTP id MpIgx14EfFCh for ; Fri, 6 Jun 2014 11:24:49 +0200 (CEST) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id 520611A0075 for ; Fri, 6 Jun 2014 11:24:49 +0200 (CEST) Received: from [10.53.40.205] (port=17565 helo=mail-essen-02.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1WsqOH-0003dg-Mq for ; Fri, 06 Jun 2014 11:24:49 +0200 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.0181.006; Fri, 6 Jun 2014 11:24:49 +0200 From: =?iso-8859-1?Q?Schmidt=2C_J=F6rn-Marc?= To: "" Thread-Topic: Symmetric PAKE for TLS Thread-Index: Ac+BZl0orOotk0jDSUe2wzH1yJLRkA== Date: Fri, 6 Jun 2014 09:24:48 +0000 Message-ID: <38634A9C401D714A92BB13BBA9CCD34F071673D1@mail-essen-01.secunet.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.208.1.85] Content-Type: multipart/alternative; boundary="_000_38634A9C401D714A92BB13BBA9CCD34F071673D1mailessen01secu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/l1ZQuRSdethtoaBhFc0B7zRfZVU Subject: [TLS] Symmetric PAKE for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 09:25:05 -0000 --_000_38634A9C401D714A92BB13BBA9CCD34F071673D1mailessen01secu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I'd like to come back to a topic that has raised intensive discussions in t= he past: Introducing a symmetric PAKE scheme for TLS that supports ECC. I b= elieve such a protocol is very useful, e.g. for enrollment of certificates = on constrained devices like IP phones. My proposal is to use PACE [1] with a flexible mapping to support Weierstra= ss as well as Montgomery and Edwards curves. The rationale behind this sugg= estion is: - It's patent-free [2] - It comes with a security proof [3] - It received a lot of attention as it is used in European travel documents I think the mapping of a random number to an ECC point that is used by the = protocol should be very flexible, so that it is possible to use e.g. simpli= fied SWU [4] for Weierstrass or Elligator [5] for Montgomery and Edwards. I= f you hold the appropriate license, you can even use Icart's function [6]. Cause of the intense previous discussion, I'd like to collect some opinions= on the list before moving forward and writing a draft. Any feedback and th= oughts are welcome. Best, J=F6rn [1] BSI TR-03110 Advanced Security Mechanisms for Machine Readable Travel D= ocuments [2] PACE has been used in travel documents for years without patent discuss= ions - the only critical thing is the mapping. [3] Security Analysis of the PACE Key-Agreement Protocol. Jens Bender, Marc= Fischlin and Dennis K=FCgler [4] Efficient Indifferentiable Hashing into Ordinary Elliptic Curves. Eric = Brier et. al [5] http://elligator.cr.yp.to/ [6] How to Hash into Elliptic Curves. Thomas Icart --_000_38634A9C401D714A92BB13BBA9CCD34F071673D1mailessen01secu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,<= /p>

I'd like to come back to a t= opic that has raised intensive discussions in the past: Introducing a symme= tric PAKE scheme for TLS that supports ECC. I believe such a protocol is ve= ry useful, e.g. for enrollment of certificates on constrained devices like IP phones.

 

My proposal is to use PACE [= 1] with a flexible mapping to support Weierstrass as well as Montgomery and= Edwards curves. The rationale behind this suggestion is:=

 

- It's patent-free [2]<= /o:p>

- It comes with a security p= roof [3]

- It received a lot of atten= tion as it is used in European travel documents

 

I think the mapping of a ran= dom number to an ECC point that is used by the protocol should be very flex= ible, so that it is possible to use e.g. simplified SWU [4] for Weierstrass= or Elligator [5] for Montgomery and Edwards. If you hold the appropriate license, you can even use Icart's fun= ction [6].

 

Cause of the intense previou= s discussion, I'd like to collect some opinions on the list before moving f= orward and writing a draft. Any feedback and thoughts are welcome.

Best,

 

J=F6rn

 

 

[1] BSI TR-03110 Advanced Se= curity Mechanisms for Machine Readable Travel Documents

[2] PACE has been used in tr= avel documents for years without patent discussions - the only critical thi= ng is the mapping.

[3] Security Analysis of the= PACE Key-Agreement Protocol. Jens Bender, Marc Fischlin and Dennis K=FCgle= r

[4] Efficient Indifferentiab= le Hashing into Ordinary Elliptic Curves. Eric Brier et. al

[5] http://elligator.cr.yp.to/

[6] How to Hash into Ellipti= c Curves. Thomas Icart

 

--_000_38634A9C401D714A92BB13BBA9CCD34F071673D1mailessen01secu_-- From nobody Fri Jun 6 04:43:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0A21A0470; Fri, 6 Jun 2014 04:43:34 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dUY6tuKCrTG; Fri, 6 Jun 2014 04:43:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B35591A0245; Fri, 6 Jun 2014 04:43:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140606114333.14050.1961.idtracker@ietfa.amsl.com> Date: Fri, 06 Jun 2014 04:43:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FkpAsy0zfuMQlgIJ79AbwWhwzh8 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-encrypt-then-mac-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 11:43:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Encrypt-then-MAC for TLS and DTLS Author : Peter Gutmann Filename : draft-ietf-tls-encrypt-then-mac-02.txt Pages : 7 Date : 2014-06-06 Abstract: This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of TLS'/DTLS' existing MAC-then-encrypt one, which has been the subject of a number of security vulnerabilities over a period of many years. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-encrypt-then-mac-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-encrypt-then-mac-02 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 Fri Jun 6 05:16:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4521A0068 for ; Fri, 6 Jun 2014 05:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNrk9UWDPfLx for ; Fri, 6 Jun 2014 05:16:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A174D1A0040 for ; Fri, 6 Jun 2014 05:16:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A4063BF8F; Fri, 6 Jun 2014 13:16:42 +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 WGiF_deThuCe; Fri, 6 Jun 2014 13:16:42 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7A5BDBF88; Fri, 6 Jun 2014 13:16:42 +0100 (IST) Message-ID: <5391B12B.1060400@cs.tcd.ie> Date: Fri, 06 Jun 2014 13:16:43 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Sean Turner , "" References: <7D555152-6398-41DB-85A6-EBE7C9B66CA5@ieca.com> In-Reply-To: <7D555152-6398-41DB-85A6-EBE7C9B66CA5@ieca.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Qjds40OaVTBA-0Nz41zwS1WkxQI Subject: Re: [TLS] ipr disclosure: draft-ietf-tls-applayerprotoneg X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 12:16:51 -0000 Hiya, Hearing nothing on this, I will shortly ask the RFC editor to resume the publication process. Thanks, S. On 23/05/14 23:03, Sean Turner wrote: > All, > > I would like to make the WG aware of a potential IPR issues with > draft-ietf-tls-applayerprotoneg, which is in the RFC editors queue. > On May 12th and 13th, INEOVATION filed IPR disclosures: > http://datatracker.ietf.org/ipr/2357/ > http://datatracker.ietf.org/ipr/2359/ The IPR concerns are that the > "document defines an extension to negotiate the application layer > type in a similar way as described draft-ietf-tls-applayerprotoneg." > > Given that this IPR was submitted/disclosed late in the process, I > would like to get a sense of the WG as to whether it is OK to > continue with the publication of the draft as-is. Please respond by > May 30th if you think the WG should not proceed. > > spt _______________________________________________ TLS mailing list > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > From nobody Fri Jun 6 07:47:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFE91A019A for ; Fri, 6 Jun 2014 07:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIzjYAir9Mwo for ; Fri, 6 Jun 2014 07:47:04 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8A31D1A010D for ; Fri, 6 Jun 2014 07:47:04 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 72DC82864A; Fri, 6 Jun 2014 14:46:57 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 60B332861D; Fri, 6 Jun 2014 14:46:57 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 3DF232026; Fri, 6 Jun 2014 14:46:57 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Fri, 6 Jun 2014 10:46:56 -0400 From: "Salz, Rich" To: Peter Gutmann , "" Date: Fri, 6 Jun 2014 10:46:55 -0400 Thread-Topic: [TLS] CCS and key reset and renegotiation Thread-Index: Ac+BXWoQe30NmmY6SaW1Ol8GBexjFgAOB8ZA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434D72@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C738DEC335D@uxcn10-tdc06.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738DEC335D@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CTjoL9AtlnY0W4LBSib8tuT4K4c Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 14:47:07 -0000 So, of course, a ladder is a state machine where there's no going backward = or loops. That means that it's simpler, right? Perhaps someone can go to https://www.websequencediagrams.com and sketch it= out? /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Fri Jun 6 07:52:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9DC1A04B1; Fri, 6 Jun 2014 07:52: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQTLSWd2nb0w; Fri, 6 Jun 2014 07:52:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6991A04A7; Fri, 6 Jun 2014 07:52:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140606145220.8187.67355.idtracker@ietfa.amsl.com> Date: Fri, 06 Jun 2014 07:52:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kzxtm5zIv8TCVwnnlOQNgB8RkyM Cc: tls@ietf.org Subject: [TLS] Last Call: (Encrypt-then-MAC for TLS and DTLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 14:52:22 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Encrypt-then-MAC for TLS and DTLS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-06-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of TLS'/DTLS' existing MAC-then-encrypt one, which has been the subject of a number of security vulnerabilities over a period of many years. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/ballot/ No IPR declarations have been submitted directly on this I-D. ID nits found an Obsolete normative reference: "RFC 4366 (ref. '3') (Obsoleted by RFC 5246, RFC 6066)" which will be replaced. From nobody Fri Jun 6 08:26:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94C01A010D for ; Fri, 6 Jun 2014 08:26:27 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpBu29qbAHiQ for ; Fri, 6 Jun 2014 08:26:25 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0227D1A00F6 for ; Fri, 6 Jun 2014 08:26:24 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id 63so4737386qgz.16 for ; Fri, 06 Jun 2014 08:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wT6cnNbwc38MaoInsal/vDJCMUNIQGfep2rlQ879bfc=; b=GKYOe+7vuPRnHyTBVfZyfM7a6DGnGmt84GDPWjLIWpf6jeC6MqLcobHtF/6FU8TjvO tXrkZmXZDzWL3HKpfzDL58JmCkqu7StT0jlJIudY8lzAaOKD0Fxu5qkJNFlICCaJwlN5 b84SNc9OEW3VFBD1tqnQIFTNgH19P7t2bO+0Jpy5rQkYSqf2DnJtKUf93knVUpPntN9M TlhRnhP2klb3yBGUq9qGWLl7h9VDQbmzdyeUSBFGisYlDcjD1xQvPNNAEmiYgGG/K9KX KayU3QGKc3mHCqPw2NMHelulJxQIKODODrwAh0UfiyDQP8EBsfHo9Y/x5ljT/k0oLVgd NirA== MIME-Version: 1.0 X-Received: by 10.140.44.34 with SMTP id f31mr9104802qga.73.1402068377695; Fri, 06 Jun 2014 08:26:17 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Fri, 6 Jun 2014 08:26:17 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Fri, 6 Jun 2014 08:26:17 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434D72@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C738DEC335D@uxcn10-tdc06.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434D72@USMBX1.msg.corp.akamai.com> Date: Fri, 6 Jun 2014 08:26:17 -0700 Message-ID: From: Watson Ladd To: Rich Salz Content-Type: multipart/alternative; boundary=001a1139fdda9a7d5004fb2c7b1d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xqMwCfigkTXUmjcnPJJ9bMCSlQA Cc: tls@ietf.org Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 15:26:27 -0000 --001a1139fdda9a7d5004fb2c7b1d Content-Type: text/plain; charset=UTF-8 There is a loop! When receiving application data the state doesn't advance. Also renegotiation loops, as does resumption. As for the ladder diagram, early in the RFC there is one. On Fri, Jun 6, 2014 at 7:46 AM, Salz, Rich wrote: > So, of course, a ladder is a state machine where there's no going backward or loops. That means that it's simpler, right? > > Perhaps someone can go to https://www.websequencediagrams.com and sketch it out? > > /r$ > > -- > Principal Security Engineer > Akamai Technologies, Cambridge, MA > IM: rsalz@jabber.me; Twitter: RichSalz > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin --001a1139fdda9a7d5004fb2c7b1d Content-Type: text/html; charset=UTF-8

There is a loop! When receiving application data the state doesn't advance.

Also renegotiation loops, as does resumption.

As for the ladder diagram, early in the RFC there is one.

On Fri, Jun 6, 2014 at 7:46 AM, Salz, Rich <rsalz@akamai.com> wrote:
> So, of course, a ladder is a state machine where there's no going backward or loops. That means that it's simpler, right?
>
> Perhaps someone can go to https://www.websequencediagrams.com and sketch it out?
>
> /r$
>
> --
> Principal Security Engineer
> Akamai Technologies, Cambridge, MA
> IM: rsalz@jabber.me; Twitter: RichSalz
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--
"Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin

--001a1139fdda9a7d5004fb2c7b1d-- From nobody Fri Jun 6 08:29:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB381A0173 for ; Fri, 6 Jun 2014 08:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYtuwceFU5cj for ; Fri, 6 Jun 2014 08:29:09 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 687471A010D for ; Fri, 6 Jun 2014 08:29:09 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8CDF3165615; Fri, 6 Jun 2014 15:29:02 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 81DCB165611; Fri, 6 Jun 2014 15:29:02 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 547781E045; Fri, 6 Jun 2014 15:29:02 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Fri, 6 Jun 2014 11:29:01 -0400 From: "Salz, Rich" To: Watson Ladd Date: Fri, 6 Jun 2014 11:29:01 -0400 Thread-Topic: [TLS] CCS and key reset and renegotiation Thread-Index: Ac+Bm6yCmyfsGt2PREKfO7WuMZOr3wAAB7fw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434DAB@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C738DEC335D@uxcn10-tdc06.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434D72@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7130F434DABUSMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HUIdJdClQ5qW1M8wL_BtRxPLPdI Cc: "tls@ietf.org" Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 15:29:12 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130F434DABUSMBX1msgcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBndWVzcywgcGVkYW50aWNhbGx5LCB0aGUgYXBwZGF0YSBpcyBhIGxvb3AuICBCdXQgcmVuZWdv dGlhdGlvbiBpcyBnb2luZyBhd2F5LCBhbmQgSSBuZWVkIHRvIHRoaW5rIGFib3V0IHJlc3VtcHRp b24gYSBiaXQuDQoNClBlcmhhcHMgUGV0ZXIsIHdoZW4gaGUgc2VlcyB0aGVzZSBub3RlcyBpbiBo aXMgdGltZXpvbmUsIGNhbiBjb21tZW50Lg0KDQogICAgICAgICAgICAgICAgL3IkDQoNCi0tDQpQ cmluY2lwYWwgU2VjdXJpdHkgRW5naW5lZXINCkFrYW1haSBUZWNobm9sb2dpZXMsIENhbWJyaWRn ZSwgTUENCklNOiByc2FsekBqYWJiZXIubWU8bWFpbHRvOnJzYWx6QGphYmJlci5tZT47IFR3aXR0 ZXI6IFJpY2hTYWx6DQoNCkZyb206IFdhdHNvbiBMYWRkIFttYWlsdG86d2F0c29uYmxhZGRAZ21h aWwuY29tXQ0KU2VudDogRnJpZGF5LCBKdW5lIDA2LCAyMDE0IDExOjI2IEFNDQpUbzogU2Fseiwg UmljaA0KQ2M6IFBldGVyIEd1dG1hbm47IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNd IENDUyBhbmQga2V5IHJlc2V0IGFuZCByZW5lZ290aWF0aW9uDQoNCg0KVGhlcmUgaXMgYSBsb29w ISBXaGVuIHJlY2VpdmluZyBhcHBsaWNhdGlvbiBkYXRhIHRoZSBzdGF0ZSBkb2Vzbid0IGFkdmFu Y2UuDQoNCkFsc28gcmVuZWdvdGlhdGlvbiBsb29wcywgYXMgZG9lcyByZXN1bXB0aW9uLg0KDQpB cyBmb3IgdGhlIGxhZGRlciBkaWFncmFtLCBlYXJseSBpbiB0aGUgUkZDIHRoZXJlIGlzIG9uZS4N Cg0KT24gRnJpLCBKdW4gNiwgMjAxNCBhdCA3OjQ2IEFNLCBTYWx6LCBSaWNoIDxyc2FsekBha2Ft YWkuY29tPG1haWx0bzpyc2FsekBha2FtYWkuY29tPj4gd3JvdGU6DQo+IFNvLCBvZiBjb3Vyc2Us IGEgbGFkZGVyIGlzIGEgc3RhdGUgbWFjaGluZSB3aGVyZSB0aGVyZSdzIG5vIGdvaW5nIGJhY2t3 YXJkIG9yIGxvb3BzLiBUaGF0IG1lYW5zIHRoYXQgaXQncyBzaW1wbGVyLCByaWdodD8NCj4NCj4g UGVyaGFwcyBzb21lb25lIGNhbiBnbyB0byBodHRwczovL3d3dy53ZWJzZXF1ZW5jZWRpYWdyYW1z LmNvbSBhbmQgc2tldGNoIGl0IG91dD8NCj4NCj4gL3IkDQo+DQo+IC0tDQo+IFByaW5jaXBhbCBT ZWN1cml0eSBFbmdpbmVlcg0KPiBBa2FtYWkgVGVjaG5vbG9naWVzLCBDYW1icmlkZ2UsIE1BDQo+ IElNOiByc2FsekBqYWJiZXIubWU8bWFpbHRvOnJzYWx6QGphYmJlci5tZT47IFR3aXR0ZXI6IFJp Y2hTYWx6DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IFRMUyBtYWlsaW5nIGxpc3QNCj4gVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5v cmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoNCi0tDQoi VGhvc2Ugd2hvIHdvdWxkIGdpdmUgdXAgRXNzZW50aWFsIExpYmVydHkgdG8gcHVyY2hhc2UgYSBs aXR0bGUgVGVtcG9yYXJ5IFNhZmV0eSBkZXNlcnZlIG5laXRoZXIgTGliZXJ0eSBub3IgU2FmZXR5 LiINCi0tIEJlbmphbWluIEZyYW5rbGluDQo= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130F434DABUSMBX1msgcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48 ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5JIGd1ZXNzLCBwZWRhbnRpY2FsbHksIHRoZSBhcHBkYXRhIGlzIGEgbG9vcC7CoCBC dXQgcmVuZWdvdGlhdGlvbiBpcyBnb2luZyBhd2F5LCBhbmQgSSBuZWVkIHRvIHRoaW5rIGFib3V0 IHJlc3VtcHRpb24gYSBiaXQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QZXJoYXBzIFBldGVyLCB3aGVu IGhlIHNlZXMgdGhlc2Ugbm90ZXMgaW4gaGlzIHRpbWV6b25lLCBjYW4gY29tbWVudC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAvciQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPi0twqAgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5B a2FtYWkgVGVjaG5vbG9naWVzLCBDYW1icmlkZ2UsIE1BPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklNOiA8YSBocmVmPSJtYWls dG86cnNhbHpAamFiYmVyLm1lIj48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+cnNhbHpAamFiYmVy Lm1lPC9zcGFuPjwvYT47IFR3aXR0ZXI6IFJpY2hTYWx6PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz4gV2F0c29uIExhZGQgW21haWx0bzp3YXRzb25ibGFkZEBnbWFpbC5jb21dIDxicj48 Yj5TZW50OjwvYj4gRnJpZGF5LCBKdW5lIDA2LCAyMDE0IDExOjI2IEFNPGJyPjxiPlRvOjwvYj4g U2FseiwgUmljaDxicj48Yj5DYzo8L2I+IFBldGVyIEd1dG1hbm47IHRsc0BpZXRmLm9yZzxicj48 Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIENDUyBhbmQga2V5IHJlc2V0IGFuZCByZW5lZ290aWF0 aW9uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48cD5UaGVyZSBpcyBhIGxvb3AhIFdoZW4gcmVjZWl2aW5nIGFwcGxpY2F0aW9uIGRh dGEgdGhlIHN0YXRlIGRvZXNuJ3QgYWR2YW5jZS48bzpwPjwvbzpwPjwvcD48cD5BbHNvIHJlbmVn b3RpYXRpb24gbG9vcHMsIGFzIGRvZXMgcmVzdW1wdGlvbi48bzpwPjwvbzpwPjwvcD48cD5BcyBm b3IgdGhlIGxhZGRlciBkaWFncmFtLCBlYXJseSBpbiB0aGUgUkZDIHRoZXJlIGlzIG9uZS4gPG86 cD48L286cD48L3A+PHAgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5PbiBGcmksIEp1biA2 LCAyMDE0IGF0IDc6NDYgQU0sIFNhbHosIFJpY2ggJmx0OzxhIGhyZWY9Im1haWx0bzpyc2FsekBh a2FtYWkuY29tIj5yc2FsekBha2FtYWkuY29tPC9hPiZndDsgd3JvdGU6PGJyPiZndDsgU28sIG9m IGNvdXJzZSwgYSBsYWRkZXIgaXMgYSBzdGF0ZSBtYWNoaW5lIHdoZXJlIHRoZXJlJ3Mgbm8gZ29p bmcgYmFja3dhcmQgb3IgbG9vcHMuIFRoYXQgbWVhbnMgdGhhdCBpdCdzIHNpbXBsZXIsIHJpZ2h0 Pzxicj4mZ3Q7PGJyPiZndDsgUGVyaGFwcyBzb21lb25lIGNhbiBnbyB0byA8YSBocmVmPSJodHRw czovL3d3dy53ZWJzZXF1ZW5jZWRpYWdyYW1zLmNvbSI+aHR0cHM6Ly93d3cud2Vic2VxdWVuY2Vk aWFncmFtcy5jb208L2E+IGFuZCBza2V0Y2ggaXQgb3V0Pzxicj4mZ3Q7PGJyPiZndDsgL3IkPGJy PiZndDs8YnI+Jmd0OyAtLTxicj4mZ3Q7IFByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcjxicj4m Z3Q7IEFrYW1haSBUZWNobm9sb2dpZXMsIENhbWJyaWRnZSwgTUE8YnI+Jmd0OyBJTTogPGEgaHJl Zj0ibWFpbHRvOnJzYWx6QGphYmJlci5tZSI+cnNhbHpAamFiYmVyLm1lPC9hPjsgVHdpdHRlcjog UmljaFNhbHo8YnI+Jmd0Ozxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPiZndDsgVExTIG1haWxpbmcgbGlzdDxicj4mZ3Q7IDxhIGhyZWY9 Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48YnI+Jmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PG86cD48L286cD48L3A+PHA+LS0gPGJyPiZx dW90O1Rob3NlIHdobyB3b3VsZCBnaXZlIHVwIEVzc2VudGlhbCBMaWJlcnR5IHRvIHB1cmNoYXNl IGEgbGl0dGxlIFRlbXBvcmFyeSBTYWZldHkgZGVzZXJ2ZSBuZWl0aGVyIExpYmVydHkgbm9yIFNh ZmV0eS4mcXVvdDs8YnI+LS0gQmVuamFtaW4gRnJhbmtsaW48bzpwPjwvbzpwPjwvcD48L2Rpdj48 L2JvZHk+PC9odG1sPg== --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130F434DABUSMBX1msgcorp_-- From nobody Fri Jun 6 08:35:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144791A00E7 for ; Thu, 5 Jun 2014 05:40: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL2f9k_dQmFe for ; Thu, 5 Jun 2014 05:40:30 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67DFF1A00D7 for ; Thu, 5 Jun 2014 05:40:30 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q59so1034810wes.35 for ; Thu, 05 Jun 2014 05:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RvtTJIpwCSv2SMYB2C1oJ5qTyLcn8O6W/UQrObmjgAw=; b=Ydd+T51XdKmUBLlODYgGIjuMJgCBK4Pnxr+pFtqnTIG0ePVO9t+5LfXE6zJCKiwsfv NlvgJ8RycLI6Zgie7zbjAL7eW5guijs4+YQ/hWFo8LDCgUomTiQO5wbf23YPWUPimgcm +srlyvCjYuT7XD/YmHClXizk60Krr6s4UUsLThOPwHap4b/HWN7rLhUHqss45cVFcaE7 qH8z9W51Gi231xu4cRJQeQW5VXhGiwDKgBD/D9V3UXQO1ifFgndCJq2sH8p/4VHAi2jS MaKaoiRYXFEWJsXtIkXYt+9+3mypKay92exKbHbcbzUCTcCSwJLLWNihaIVUE24r7Rxi o6Dg== MIME-Version: 1.0 X-Received: by 10.180.38.107 with SMTP id f11mr15222170wik.59.1401972022923; Thu, 05 Jun 2014 05:40:22 -0700 (PDT) Received: by 10.194.79.136 with HTTP; Thu, 5 Jun 2014 05:40:22 -0700 (PDT) In-Reply-To: <538EF79B.3000506@cs.tcd.ie> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> Date: Thu, 5 Jun 2014 08:40:22 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/48DS4e68JA5Id6Vzfl_ip7rbrlc X-Mailman-Approved-At: Fri, 06 Jun 2014 08:35:39 -0700 Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 12:40:36 -0000 On Wed, Jun 4, 2014 at 6:40 AM, Stephen Farrell wrote: > > Hiya, > > On 04/06/14 01:39, Sean Turner wrote: >> I believe that draft has been abandoned in favor of: >> >> http://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ >> >> Personally, I don=E2=80=99t think this draft is applicable to the TLS WG= and >> would be better suited as an AD sponsored draft. I know PHB >> approached me about sponsoring it but I think we both got busy before >> the end of my term. I=E2=80=99ve not doubt PHB will at some point appro= ach >> Stephen/Kathleen about sponsoring it. If you=E2=80=99re interested in >> supporting it, sending them a message might help >> (sec-ads@tools.ietf.org). > > I did discuss AD sponsoring this with Phill and am fine with > that plan since there is (I believe) support for implementing > it in some browsers. > > So Phill - please tell me when you think this is ready and > if possible recruit a document shepherd if you've not already. With that answer in hand, I suggest that we first do an internal last call on the draft currently on the table to see that everyone is happy. By which I simply mean, lets make get people to actually read that particular draft rather than start a cabal. So if we give folks a week and then we can go forward with the document shepherd? I do need to write an IANA piece which I will do today. At the time I wrote it the assignment was not an IANA one. I am pretty sure the document is ready otherwise. I took out the bit that allowed a minimum version of TLS to be specified after discovering that is not practical from one of the browser providers. --=20 Website: http://hallambaker.com/ From nobody Fri Jun 6 08:35:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588951A00C6 for ; Thu, 5 Jun 2014 06:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dvQ3h6wk2_t for ; Thu, 5 Jun 2014 06:27:55 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C171A007C for ; Thu, 5 Jun 2014 06:27:54 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n15so10345112wiw.15 for ; Thu, 05 Jun 2014 06:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=lchCXp8bsZ6f3JqdhlF2cLZNH2eCZ61Fq4Q9uKAMAyY=; b=edROBYDIFnR0EHcGVn1VlUkAaXXoUs9gE9epG+45l5hDPQnLh81CtgNRWtSsXf4b/D x+z6kb856IlwMoE23HD2n+1ggOhepofPcAOakaNCL9n9m8IDYLcxLWARC5y6yN5O2k0A hTy8pr7GP3C3Bh7j/TISyU2mXXTrsb0bbSuRvJ0lyAGV9aKLSIxZ5FLBJsNfJpbH2Ba2 MzeZLZW0ex+fRACtP3tZvl02xE8fi1YJZQ/PYwQfRI/qCrm8kSewDNjnKk1LNQ49fhQO YkYZ+0ABrWMJW8Alw973wSpUoa2I32QO1qNPrGpDyJzr2bghJKyKYPRYZTwHsYyFafcS 8eOQ== MIME-Version: 1.0 X-Received: by 10.180.7.227 with SMTP id m3mr15638412wia.59.1401974866995; Thu, 05 Jun 2014 06:27:46 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Thu, 5 Jun 2014 06:27:46 -0700 (PDT) Date: Thu, 5 Jun 2014 09:27:46 -0400 X-Google-Sender-Auth: 9-S4-cAR1xIpqz4jHwbCKx7lzCc Message-ID: From: Phillip Hallam-Baker To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RARyQqIyAev-x3qpqt6HcPj_4hs X-Mailman-Approved-At: Fri, 06 Jun 2014 08:35:38 -0700 Subject: [TLS] Why there should not be a TLS 2.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 13:27:56 -0000 There was discussion of TLS 2.0 in London. As I have been thinking about it further I think it is the wrong direction entirely. Rather than thinking about a TLS 2.0 we should look at a new scheme that is the next generation of IPSEC, TLS and WS-Security. While this might sound fantastically hard, it is in fact more practical than TLS 2.0 and has far better deployment prospects. The immediate problem that has me thinking this way is Private-DNS which is my proposal to provide encryption and integrity protections for DNS which is itself built on technology that I developed to provide the JSON/REST world with the same security features as WS-* in a draft of 25 pages or less (done). First lets look at the current situation. We have IPSEC and TLS deployed. They are both enormously complicated and adopt completely different design approaches, different encodings and different key exchanges. But 90% of the underlying technology is identical: IPSEC and TLS both deliver a secure tunnel between endpoints. The only point at which IPSEC and TLS differ as a result of their function is in the application to the communication medium. IPSEC is applied at the IP packet layer, TLS is applied to the TCP stream. And that is all the difference there is. There is no reason that a protocol can't have one key exchange mechanism to serve both purposes. The success of TLS VPNs and SSH tunneling demonstrates that this is the case. So rather than thinking about TLS 2.0, I think we should instead consider the problem of establishing a security context separately from the problem of how to apply that context to a communication medium. Once that separation is made we can apply it at the packet, transport and application levels. Instead of TLS/2.0 we should be thinking about IPSEC/2.0 and HTTP-SEC. Factoring out the key exchange has other major advantages. It makes a three legged 'Kerberos style' interaction possible as well (or even four legged). the machine that performs the public key crypto needed to establish the security context does not need to be the same as the machine that uses the security context. This means that instead of an SSL accelerator box having to be strapped into the middle of my communication path as a pipe, it can be a separate server. Most boxes are more than capable of doing AES and SHA-2-256 without impacting server performance. It is the public key cryptography that is the problem, especially because each operation is quite significant. Kerberos does a lot of things right which is why people still use it. But right now it is a separate world to TLS. A convergence of TLS and Kerberos would be much more useful. At the moment I am relying on TLS to secure the confidentiality and integrity of the security context exchange in SXS-Connect: http://tools.ietf.org/html/draft-hallambaker-wsconnect-08 A security context consists of * A session identifier (opaque series of octets) * Algorithm choices (e.g. AES-128 + SHA-2-256) * A shared master secret * Expiry/invalidity information (when to stop using, renegotiate, etc) The size of the session identifier can be between 0 and 255 bytes depending on how much state the issuer needs and how much of that state is to be encoded into the identifier. So identifiers might be * 0 bytes - implicit in the IP Address and Port. * 8 bytes - just a key. * 24 bytes - is sufficient for a minimal stateless server scheme. * 64 bytes - what my code uses for a stateless server scheme. * 128 bytes - what my code uses during initial negotiation of a security context. Obviously, the lower down you are in the stack, the greater the overhead of a large session ID. But giving this tradeoff to the issuer allows the tradeoff to be made depending on specific needs at a specific installation rather than making it a global tradeoff decided by a Working Group with no knowledge of the particular requirements. From nobody Fri Jun 6 08:35:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF4B1A040E for ; Fri, 6 Jun 2014 01:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2cCZ3ym5ng3 for ; Fri, 6 Jun 2014 01:21:08 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3C78A1A0409 for ; Fri, 6 Jun 2014 01:21:08 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CFA7B1801C0; Fri, 6 Jun 2014 01:19:59 -0700 (PDT) To: tim@dierks.org, ekr@rtfm.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, turners@ieca.com, jsalowey@cisco.com, ekr@rtfm.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140606081959.CFA7B1801C0@rfc-editor.org> Date: Fri, 6 Jun 2014 01:19:59 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-UaKt6hnq-fGFLu0gJP4MzH_94Q X-Mailman-Approved-At: Fri, 06 Jun 2014 08:35:39 -0700 Cc: rfc-editor@rfc-editor.org, kikuchi@lepidum.co.jp, tls@ietf.org Subject: [TLS] [Technical Errata Reported] RFC5246 (4007) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 08:21:10 -0000 The following errata report has been submitted for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4007 -------------------------------------- Type: Technical Reported by: KIKUCHI Masashi Section: 7.3. Original Text ------------- Note: To help avoid pipeline stalls, ChangeCipherSpec is an independent TLS protocol content type, and is not actually a TLS handshake message. Corrected Text -------------- Note: To avoid ChangeCipherSpec being transmitted in mix with other handshake fragments in one record, ChangeCipherSpec is an independent TLS protocol content type, and is not actually a TLS handshake message. To help avoid pipeline stalls, ChangeCipherSpec is sent from both the server and the client. Notes ----- The original text can be read like we can handle ChangeCipherSpec asynchronously. This is harmful and may be a cause of CCS Injection vulnerability. Instructions: ------------- This errata 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 (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Jun 6 08:48:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A181A0037 for ; Fri, 6 Jun 2014 08:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyv5fIp2_tCp for ; Fri, 6 Jun 2014 08:48:11 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C471A0039 for ; Fri, 6 Jun 2014 08:48:10 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s56FlwuC004113; Fri, 6 Jun 2014 08:47:58 -0700 Received: from sc-owa04.marvell.com ([199.233.58.150]) by mx0b-0016f401.pphosted.com with ESMTP id 1madcs7bkj-11 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 06 Jun 2014 08:47:58 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA04.marvell.com ([fe80::e56e:83a7:9eef:b5a1%16]) with mapi; Fri, 6 Jun 2014 08:47:57 -0700 From: Paul Lambert To: "Salz, Rich" , Peter Gutmann , "" Date: Fri, 6 Jun 2014 08:47:53 -0700 Thread-Topic: [TLS] CCS and key reset and renegotiation Thread-Index: Ac+Bnq+efi0MdDAPTNaMmiBtZMGcIA== Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C738DEC335D@uxcn10-tdc06.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434D72@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434D72@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-06_06:2014-06-06,2014-06-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406060208 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ol8V5xiO7c1cNCri98Ntu6Bspz0 Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 15:48:13 -0000 On 6/6/14, 7:46 AM, "Salz, Rich" wrote: >So, of course, a ladder is a state machine where there's no going >backward or loops. That means that it's simpler, right? =8A and incomplete. The ladder diagram or sequence diagram represents one possible path through the state transitions. With enough ladder diagrams you might cover all the behavior, but this is rarely done. Often a few diagrams cover all the interesting =8Cnormal=B9 behavior, but of course the many error condition behaviors are ignored. On the down side, state machines are hard to draw in ASCII text in an RFC. Paul=20 > >Perhaps someone can go to https://www.websequencediagrams.com and sketch >it out? > > /r$ > >-- =20 >Principal Security Engineer >Akamai Technologies, Cambridge, MA >IM: rsalz@jabber.me; Twitter: RichSalz > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From nobody Fri Jun 6 08:49:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88801A0069 for ; Fri, 6 Jun 2014 08:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITp8ObfIRFw8 for ; Fri, 6 Jun 2014 08:49:32 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 672B41A0064 for ; Fri, 6 Jun 2014 08:49:32 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5B2714828B; Fri, 6 Jun 2014 15:49:25 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 4F5E048284; Fri, 6 Jun 2014 15:49:25 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 373631E03E; Fri, 6 Jun 2014 15:49:25 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Fri, 6 Jun 2014 11:49:24 -0400 From: "Salz, Rich" To: Paul Lambert , Peter Gutmann , "" Date: Fri, 6 Jun 2014 11:49:24 -0400 Thread-Topic: [TLS] CCS and key reset and renegotiation Thread-Index: Ac+Bnq+efi0MdDAPTNaMmiBtZMGcIAAABI1Q Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434DBD@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C738DEC335D@uxcn10-tdc06.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434D72@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/saNu78v7pKPpIxm7X5VuECekMCM Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 15:49:35 -0000 I wasn't suggesting a set of ladders to replace a state machine. Peter sai= d it's not really a state machine but rather a ladder. I was emphasizing th= at, *if this is true*, then a ladder approach is way much better. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Fri Jun 6 15:31:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56861A02AA for ; Fri, 6 Jun 2014 15:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQwtz47i6f7F for ; Fri, 6 Jun 2014 15:30:56 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951A21A0273 for ; Fri, 6 Jun 2014 15:30:56 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s56MUjMq028572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Jun 2014 00:30:45 +0200 (MEST) In-Reply-To: To: Brian Smith Date: Sat, 7 Jun 2014 00:30:45 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fCAXeuF_dKDxfsczwWWqCspS6OE Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 22:30:59 -0000 Brian Smith wrote: > Martin Rex wrote: >> >> Conceptually, the TLS session cache is readonly after an entry >> is created, and that is GOOD, i.e. full TLS handshakes create new, >> distict session cache entries, and abbreviated TLS handshakes resume >> existing session cache entries and *NEVER* modify them. > > That is not true. During session resumption, the server can send a new > session ticket for the existing session and the client has the option of > adding the new ticket to the session (and removing the old ticket). > > Also often timestamps (e.g. for LRU replacement bookkeeping) and/or > counters (e.g. for cache hit rate statistics) in a session are updated > during resumption, though these are "just" implementation issues. With "conceptually", I referred to the requirements of the specification, not to the details of certain implementations of it. Counting how often sessions are resumed is nothing that the spec requires, and how you manage your cache entries (expiration) is not in scope of that concept. When the read-only concept is violated, and implementations start scribbling over _state_ of sessions that are in the cache during resumption handshakes, it may result in problems such as these: CVE-2010-3864 http://www.openssl.org/news/secadv_20101116.txt CVE-2010-4180 http://www.openssl.org/news/secadv_20101202.txt -Martin From nobody Fri Jun 6 20:31:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2DF1A02EF for ; Fri, 6 Jun 2014 20:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOrD7XpL1R5z for ; Fri, 6 Jun 2014 20:30:58 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8671A025F for ; Fri, 6 Jun 2014 20:30:58 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0D0D1165631 for ; Sat, 7 Jun 2014 03:30:50 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 0265E16562E for ; Sat, 7 Jun 2014 03:30:50 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id D3BE298046 for ; Sat, 7 Jun 2014 03:30:49 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Fri, 6 Jun 2014 23:30:49 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Fri, 6 Jun 2014 23:30:47 -0400 Thread-Topic: Pre-IETF meeting? Thread-Index: Ac+CALuoZXXeb3Z5TbmKv/YFEdiVxw== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F4F@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7130F434F4FUSMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7WfdDSk1jhXWcPYDslwLEyPgNdg Subject: [TLS] Pre-IETF meeting? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 03:31:00 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130F434F4FUSMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the Interim, we talked about meeting for a day before the next IETF. Ha= ve we decided? FWIW, I can't stay afterwards. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130F434F4FUSMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the Interim, = we talked about meeting for a day before the next IETF.  Have we decid= ed?  FWIW, I can’t stay afterwards.

 

-- 

Principal Security Engineer

Akamai Technologies, Cambridge, MA

IM: rsalz@jabber.me; Twitter: Rich= Salz

 

<= /html>= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7130F434F4FUSMBX1msgcorp_-- From nobody Sat Jun 7 06:15:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8A31A034E; Sat, 7 Jun 2014 06:15:24 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6Al5lqy711q; Sat, 7 Jun 2014 06:15:22 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85161A0076; Sat, 7 Jun 2014 06:15:21 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id m15so3899663wgh.8 for ; Sat, 07 Jun 2014 06:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Vt5mrnyXUQ0h+/kaLernYLvlafjA7JfhVkcsm6diBlI=; b=AjWKZ8sGdH9oGJLTNOuzIMgjwNdzZqnQReSRqW+Fheo69jE7vCkwnoNuu15cb6tXFp xKOG/hS3DGDPVrrLzQm/Q1ScUvwXCbbJbBzZDIIk25N2zUuMFas8xOhm6GItLk4PvVL/ YuzEJOzwZVjy6X3Ov+QxPu0JxRfmaWGPR0FFnQJhGSzc8N96MGsPYr6DsCdFS1dFxU2b 98nKvfuHn9VnJa+aBfiHiQWmbXKeNP6FHQcQ29HDuRewdAItv0KxfZcCoBsfQvTRGPZd MHserIaMMT05NyBJWNpuYrRX2eFb1HEXMm03Y0aryyMcBX1n/4cJRyLtfkNHsCqZZjah xEQg== X-Received: by 10.194.84.208 with SMTP id b16mr15654096wjz.55.1402146913167; Sat, 07 Jun 2014 06:15:13 -0700 (PDT) Received: from [192.168.1.102] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id p3sm521607wjw.28.2014.06.07.06.15.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 06:15:12 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: <20140606145220.8187.67355.idtracker@ietfa.amsl.com> Date: Sat, 7 Jun 2014 16:15:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <36137A9A-3503-4AF8-80D0-1FB53A7949EA@gmail.com> References: <20140606145220.8187.67355.idtracker@ietfa.amsl.com> To: "ietf\\@ietf.org" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8aqzV6vBqaESbAYgiCMyUz0qDpw Cc: TLS Mailing List Subject: Re: [TLS] Last Call: (Encrypt-then-MAC for TLS and DTLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 13:15:24 -0000 Hi I=92ve read the draft and I have a few comments: The motivation for this extension is not clear from the draft. The = introduction says that the MAC-then-encrypt construction is =93no longer = regarded as secure=94, and that it has been the subject of =93numerous = security vulnerabilities and attacks=94. For the latter claim, there are = no references given either in the document itself or in references. For = the former two articles are cited.=20 The first (reference [5]) is by Hugo Krawczyk. While that article shows = a theoretical weakness of MAC-then-encrypt, it also finds that (quoting = from the abstract) =93On the positive side we show that the = authenticate-then-encrypt method is secure if the encryption method in = use is either CBC mode (with an underlying secure block cipher) or a = stream cipher (that xor the data with a random or pseudorandom pad).=94. = It also concludes that =93the current practical implementations of [SSL] = that use the above modes of encryption are safe=94. So this is not a = great call for action. The second (reference [6]) is a better reference, but I=92m still = missing a reference to anything practical or close to practical. The rationale for the mandate in section 3.1 is not clear to me. Sure, = EtM is better than MtE, so renegotiating from MtE to EtM is a downgrade, = but there is no mandate for implementations that are configured to = support both algorithms to avoid downgrading from AES-256 to single DES, = so why add this here? Also, this section uses the terms =93state=94, = =93status=94 and =93mechanism=94 seemingly interchangeably, and doesn=92t = explain why changing mechanism during renegotiation is a SHOULD = NOT-level issue, or how AEAD ciphers figure in this mandate. One more thing, this time a nit: informative reference number 7 = describes a document as =93RFC xxxx=94. This is a reference to = =93draft-bmoeller-tls-downgrade-scsv=94, which according to the = datatracker is an individual draft that nobody=92s asked to publish yet. = It should be referenced with the draft name as a work in progress. Since = it=92s an informative reference, this won=92t block publication of this = document. Yoav =20 On Jun 6, 2014, at 5:52 PM, The IESG wrote: >=20 > The IESG has received a request from the Transport Layer Security WG > (tls) to consider the following document: > - 'Encrypt-then-MAC for TLS and DTLS' > as Proposed Standard >=20 > 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 2014-06-20. 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. >=20 > Abstract >=20 >=20 > This document describes a means of negotiating the use of the > encrypt-then-MAC security mechanism in place of TLS'/DTLS' existing > MAC-then-encrypt one, which has been the subject of a number of > security vulnerabilities over a period of many years. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/ >=20 > IESG discussion can be tracked via > = http://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 > ID nits found an Obsolete normative reference: "RFC 4366 (ref. '3')=20 > (Obsoleted by RFC 5246, RFC 6066)" which will be replaced. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Jun 7 07:56:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5327A1A00D4 for ; Sat, 7 Jun 2014 07:56:45 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_F5Zb23UgKl for ; Sat, 7 Jun 2014 07:56:44 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D149E1A0096 for ; Sat, 7 Jun 2014 07:56:43 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so6934759qgd.1 for ; Sat, 07 Jun 2014 07:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sby14Imgak6Uct9KoVzdorszOvB38BOI8EkZReFVXcg=; b=T+6nBwAKpg+2Lwri4IOXkWWXl7wZHMI9wyUjP2Sp76y1AOvZhCQeRK3rYTNeqwR4V3 Zz0Lp/zWkzi1vW5VppHp9r16J/seDH6r/J5e4t5PFvxpFF1idzqG72Y8H4MKtT2FkSfC 3D4S4GP3oB16fL5ad+C5ei4gbrkc/M3CVcdiN4gp0oUtFjuKj8pEyALjdBHTGEO9I692 NfRmA1lnzAe3m88EYajid4OMeGQ3ltrK2pAPupKjeZ/9fnDD2agP37n6jAlT1I5R5rgo Sz/voNU/vrwIpxnxSePnFgqrYhb7ItdD85tjE3eOBiOOK8fT41NA/2v9bI2Cihk/E9cZ j8Iw== MIME-Version: 1.0 X-Received: by 10.236.61.45 with SMTP id v33mr2002403yhc.20.1402152996388; Sat, 07 Jun 2014 07:56:36 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Sat, 7 Jun 2014 07:56:36 -0700 (PDT) Date: Sat, 7 Jun 2014 07:56:36 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zw1pDV5tb0qDOGNK_Hp1zNWtCl0 Subject: [TLS] No more GMT exposure in the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 14:56:45 -0000 Dear all, Putting the clock time in the TLS handshake enables fingerprinting. It's useless cryptographically: 32 random bytes is exceedingly unlikely to repeat. Sincerely, Watson Ladd From nobody Sat Jun 7 07:59:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB7F1A00C3 for ; Sat, 7 Jun 2014 07: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BU-kS779Jve4 for ; Sat, 7 Jun 2014 07:59:04 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95CEA1A00D7 for ; Sat, 7 Jun 2014 07:59:04 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id q107so6746518qgd.38 for ; Sat, 07 Jun 2014 07:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ud3lPuT25+NObIn6KD22FmZsSTf5ezTqux8QfeO3V18=; b=0e2CNDrjxaPW/OZbE5PlZnU29mXCdt+e8r5nz02AvA03LKhP4nCMUjZqKlTgl4SeZy dt3gpc/3zSS/ssQQMmaXV3gl+ZuAy9yG+a+pWGBl2TxuUOJBGZ96eNvgGCFGgOfOVvbH pV4ZimDqic2L93HcD6JR3BIeM0iCT1LahqckR5X6r9GlaL/2wn7hyrSTFl8dNyu60Ovi pzOgVRjOSyRq47Nt6FVNK9QgmVbTxnvoa621eXwX/skHUoo0LGQp5MaTe4TYh7DGHrz+ pT0p02C76FF35oaWB75Nvk6BVO2kveQYhDPkRmiI5AIFV+ubH9oNjuFAR0Yj2U8QdYRc 1EOA== MIME-Version: 1.0 X-Received: by 10.236.81.10 with SMTP id l10mr1400481yhe.18.1402153137090; Sat, 07 Jun 2014 07:58:57 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Sat, 7 Jun 2014 07:58:56 -0700 (PDT) In-Reply-To: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> Date: Sat, 7 Jun 2014 07:58:56 -0700 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G7iYIHIt8p51JXC4YOxC9R5A8Zs Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 14:59:08 -0000 On Fri, Jun 6, 2014 at 3:30 PM, Martin Rex wrote: > Brian Smith wrote: >> Martin Rex wrote: >>> >>> Conceptually, the TLS session cache is readonly after an entry >>> is created, and that is GOOD, i.e. full TLS handshakes create new, >>> distict session cache entries, and abbreviated TLS handshakes resume >>> existing session cache entries and *NEVER* modify them. >> >> That is not true. During session resumption, the server can send a new >> session ticket for the existing session and the client has the option of >> adding the new ticket to the session (and removing the old ticket). >> >> Also often timestamps (e.g. for LRU replacement bookkeeping) and/or >> counters (e.g. for cache hit rate statistics) in a session are updated >> during resumption, though these are "just" implementation issues. > > > With "conceptually", I referred to the requirements of the specification, > not to the details of certain implementations of it. Counting how often > sessions are resumed is nothing that the spec requires, and how you > manage your cache entries (expiration) is not in scope of that concept. > > When the read-only concept is violated, and implementations start scribbling > over _state_ of sessions that are in the cache during resumption > handshakes, it may result in problems such as these: What about this solution: separate TLS into a handshake and transport. The handshake computes a connection key associated with the ticket, then the transport computes a transport key based on that key and some conceptually separate random data from both sides exchanged in the handshake. When the transport is exhausted or we resume, the random numbers change, but the connection key does not. > > CVE-2010-3864 http://www.openssl.org/news/secadv_20101116.txt > CVE-2010-4180 http://www.openssl.org/news/secadv_20101202.txt > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sat Jun 7 08:12:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3275B1A00D7 for ; Sat, 7 Jun 2014 08:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1IUx6f6M6IL for ; Sat, 7 Jun 2014 08:12:07 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id BE1C71A00C3 for ; Sat, 7 Jun 2014 08:12:07 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 85BF016560B; Sat, 7 Jun 2014 15:12:00 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 7B243165603; Sat, 7 Jun 2014 15:12:00 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 631D098058; Sat, 7 Jun 2014 15:12:00 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Sat, 7 Jun 2014 11:12:00 -0400 From: "Salz, Rich" To: Watson Ladd , "mrex@sap.com" Date: Sat, 7 Jun 2014 11:11:58 -0400 Thread-Topic: [TLS] Proposed text for removing renegotiation Thread-Index: Ac+CYQ1Bdi7Yx8PpSdC8Rxe+c+7fCwAASk6g Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F76@USMBX1.msg.corp.akamai.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gha5-9iEy3dha1DMlRvCIyWefok Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 15:12:09 -0000 > What about this solution: separate TLS into a handshake and transport. That's a very interesting idea. The "HTTP/1.1 update" did that, turning RF= C2616 into something like seven separate, albeit interlocked, RFC's. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Sat Jun 7 08:42:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7B61A0219 for ; Sat, 7 Jun 2014 08:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvorKiL_C7M6 for ; Sat, 7 Jun 2014 08:41:58 -0700 (PDT) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D531A0190 for ; Sat, 7 Jun 2014 08:41:57 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id p10so3990507wes.6 for ; Sat, 07 Jun 2014 08:41:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1OxIhma504rcASxT3osmx0QVgUbVCsS8JEsGqDuUggA=; b=ihhmO6VOb1fRsc0FzQUalgXAInoVcQMCBzGj3Hb/KXIISeZLhwbAYsEHIOQa4Y0+Oe OtO9OSFvp+1WBEA6KLRtox7D4PBgKGj49nJeC6s1S+tlbkTo65YUPZvcARLVlw3Ko+iU 9C8+Ics4OcJguKe0yNxhBgGvx7XnVv2in5XIgGnNgQEG5+gYovVkMdXuWD+AEB6grLpF NZoq+zKcGv/V+Z1lwBJtUFo7bAL95iooROsr4zchTwhPmYc1a9MAgaevxTftRVlmbtWl fuJBV3jmLBKP6N2kZtDSi//Gy3bCp3/3yfzM1bvlIPPZJnr2swxY6c5FF5ndZRkXK3SW py/Q== X-Gm-Message-State: ALoCoQkCAoVgRwUHVd9l6E0IzezMK6r+1VCIsgy54nCD2TnxxbKiPN6nutuNYIi1GOu93MKniMMV X-Received: by 10.180.212.112 with SMTP id nj16mr15145217wic.1.1402155709306; Sat, 07 Jun 2014 08:41:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sat, 7 Jun 2014 08:41:08 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Sat, 7 Jun 2014 08:41:08 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11c2401af934b004fb40d0e2 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/noCPYqATOewBgRvbuNfmvv4qRT8 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 15:42:00 -0000 --001a11c2401af934b004fb40d0e2 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 7, 2014 at 7:58 AM, Watson Ladd wrote: > On Fri, Jun 6, 2014 at 3:30 PM, Martin Rex wrote: > > Brian Smith wrote: > >> Martin Rex wrote: > >>> > >>> Conceptually, the TLS session cache is readonly after an entry > >>> is created, and that is GOOD, i.e. full TLS handshakes create new, > >>> distict session cache entries, and abbreviated TLS handshakes resume > >>> existing session cache entries and *NEVER* modify them. > >> > >> That is not true. During session resumption, the server can send a new > >> session ticket for the existing session and the client has the option of > >> adding the new ticket to the session (and removing the old ticket). > >> > >> Also often timestamps (e.g. for LRU replacement bookkeeping) and/or > >> counters (e.g. for cache hit rate statistics) in a session are updated > >> during resumption, though these are "just" implementation issues. > > > > > > With "conceptually", I referred to the requirements of the specification, > > not to the details of certain implementations of it. Counting how often > > sessions are resumed is nothing that the spec requires, and how you > > manage your cache entries (expiration) is not in scope of that concept. > > > > When the read-only concept is violated, and implementations start > scribbling > > over _state_ of sessions that are in the cache during resumption > > handshakes, it may result in problems such as these: > > What about this solution: separate TLS into a handshake and transport. > The handshake computes a connection key associated with the ticket, > then the transport computes a transport key based on that key and some > conceptually separate random data from both sides exchanged in the > handshake. When the transport is exhausted or we resume, the random > numbers change, but the connection key does not. To some extent TLS already does try to make this separation, with separate "TLS Record Protocol" (Section 6) and "TLS Handshaking Protocols" (Section 7) with the handshake protocol establishing a Master Secret for the entire session which is then used to derive distinct record keys every time you reconnect (resume) in the same session, with diversity provided by the random values. So, arguably, TLS already behaves this way, with the exception of dealing with cryptographic exhaustion of the transport keys (e.g., GCM counter rollover). MT's basic suggestion is to fix the cryptographic exhaustion problem by having a signal to re-generate new transport level keys from the Master Secret. AFAIK this doesn't require any new random exchange because you already have existing random values that provide per-connection diversity, so you just need to generate new crypto keys, e.g., by cranking the PRF again starting with the PRF and the random values and some sort of iteration count and doesn't require any conceptual changes to the TLS session cache model of the kind that Martin Rex is discussion. Where things get interesting is that this solely addresses exhaustion but not PFS [0] I.e., as long as the Master Secret is stored somewhere (e.g., the session cache) then an attacker who recovers it can recover all the traffic keys. Traditionally, if you renegotiate without resumption (i.e., do a fresh key exchange), then you can address this issue, but if we remove renegotiation, that option is no longer available. That leaves us with a number of options: - Tell people they just need to reconnect if they want to limit the exposure of a given session (i.e., do nothing). - Provide a mechanism for re-keying the connection in a way that allows you to destroy the previous keys [1]. However, this still runs afoul of the fact that the Master Secret needs to be available to generate the connection keys. You can deal with this in two major ways: (a) Tell people not to use resumption (i.e., not to store the MS in the session cache) if they want to provide this feature. (b) Change the value stored in the session cache so it can only be used to make new connections but not to decrypt old ones. AFAIK this requires being willing to change the session cache [2] Or perhaps there's some clever idea I haven't thought of... Best, -Ekr [0] Maybe we need a new term other than PFS for this particular security feature. [1] E.g., have a per-connection "Connection Master Key" generated from the MS and then used to generate the traffic keys. When you initially connection, you would compute CMS[0] = PRF(MS, Randoms) and then do Traffic Keys = PRF(CMS[0], ...). Then when the keys were exhausted you would do CMS[1] = PRF(CMS[0], ...) and recompute the traffic keys with CMS[1]. Since the PRF is notionally irreversible, an attacker with access to the keys after the key change couldn't decrypt old traffic. [2] Vigorous handwaving: the trivial thing to do is just to have MS[0], MS[1], MS[2], etc. where every time you resume you generate the next generation MS and destroy the old one. Obviously this requires changing the session cache data, which is undesirable for the reasons indicated by Martin Rex. --001a11c2401af934b004fb40d0e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sat, Jun 7, 2014 at 7:58 AM, Watson Ladd <<= a href=3D"mailto:watsonbladd@gmail.com" target=3D"_blank">watsonbladd@gmail= .com> wrote:
On Fri, Jun 6, 2014 at 3:30 = PM, Martin Rex <mrex@sap.com> wro= te:
> Brian Smith wrote:
>> Martin Rex <mrex@sap.com>= ; wrote:
>>>
>>> Conceptually, the TLS session cache is readonly after an entry=
>>> is created, and that is GOOD, i.e. full TLS handshakes create = new,
>>> distict session cache entries, and abbreviated TLS handshakes = resume
>>> existing session cache entries and *NEVER* modify them.
>>
>> That is not true. During session resumption, the server can send a= new
>> session ticket for the existing session and the client has the opt= ion of
>> adding the new ticket to the session (and removing the old ticket)= .
>>
>> Also often timestamps (e.g. for LRU replacement bookkeeping) and/o= r
>> counters (e.g. for cache hit rate statistics) in a session are upd= ated
>> during resumption, though these are "just" implementatio= n issues.
>
>
> With "conceptually", I referred to the requirements of the s= pecification,
> not to the details of certain implementations of it. =C2=A0Counting ho= w often
> sessions are resumed is nothing that the spec requires, and how you > manage your cache entries (expiration) is not in scope of that concept= .
>
> When the read-only concept is violated, and implementations start scri= bbling
> over _state_ of sessions that are in the cache during resumption
> handshakes, it may result in problems such as these:

What about this solution: separate TLS into a handshake and transport= .
The handshake computes a connection key associated with the ticket,
then the transport computes a transport key based on that key and some
conceptually separate random data from both sides exchanged in the
handshake. When the transport is exhausted or we resume, the random
numbers change, but the connection key does not.

To some extent TLS already does try to make this separation, with
=
separate "TLS Record Protocol" (Section 6) and "T= LS Handshaking
Protocols" (Section 7) with the handshake protocol establishing a=
Master Secret for the entire session which is then used to deriv= e
distinct record keys every time you reconnect (resume) in the s= ame
session, with diversity provided by the random values. So, arguably,
TLS already behaves this way, with the exception of dealing with
cryptographic exhaustion of the transport keys (e.g., GCM counter<= /div>
rollover).

MT's basic suggestion is to fi= x the cryptographic exhaustion
problem by having a signal to = re-generate new transport level keys
from the Master Secret. AFAI= K this doesn't require any new random
exchange because you already have existing random values that
provide per-connection diversity, so you just need to generate new
<= div>crypto keys, e.g., by cranking the PRF again starting with the PRF
and the random values and some sort of iteration count and doesn't=
require any conceptual changes to the TLS session cache model
of the kind that Martin Rex is discussion.


Where things get interesting is that this solely addres= ses exhaustion
but not PFS [0] I.e., as long as the Master Secret= is stored somewhere
(e.g., the session cache) then an attacker w= ho recovers it can=C2=A0
recover all the traffic keys. Traditionally, if you renegotiate withou= t
resumption (i.e., do a fresh key exchange), then you can addres= s
this issue, but if we remove renegotiation, that option is no l= onger
available. That leaves us with a number of options:

- Tell people they just need to reconnect if they want to limit the<= /div>
=C2=A0 =C2=A0exposure of a given session (i.e., do nothing).

- Provide a mechanism for re-keying the connection in a way = that
=C2=A0 allows you to destroy the previous keys [1]. However,= this still
=C2=A0 runs afoul of the fact that the Master Secret = needs to be available
=C2=A0 to generate the connection keys. You can deal with this in two<= /div>
=C2=A0 major ways:

=C2=A0 (a) Tell peopl= e not to use resumption (i.e., not to store the MS in the
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 session cache) if they want to provide this feature.
=C2=A0 (b) Change the value stored in the session cache so it can only= be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 used to make new connections but = not to decrypt old ones.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 AFAIK this r= equires being willing to change the session cache [2]

Or perhaps there's some clever idea I haven't t= hought of...

Best,
-Ekr


[0] Maybe we need a new term other than PFS for thi= s particular
security feature.

[1] E.g., have a per-connec= tion "Connection Master Key" generated
from the MS and = then used to generate the traffic keys. When you
initially connec= tion, you would compute CMS[0] =3D PRF(MS, Randoms)
and then do Traffic Keys =3D PRF(CMS[0], ...). Then when the keys
were exhausted you would do CMS[1] =3D PRF(CMS[0], ...) and recompute=
the traffic keys with CMS[1]. =C2=A0Since the PRF is notionally = irreversible,
an attacker with access to the keys after the key change couldn't<= /div>
decrypt old traffic.

[2] Vigorous handwa= ving: the trivial thing to do is just to have MS[0],=C2=A0
MS[1],= MS[2], etc. where every time you resume you generate the next
generation MS and destroy the old one. Obviously this requires changin= g
the session cache data, which is undesirable for the reasons in= dicated
by Martin Rex.=C2=A0


<= div>
--001a11c2401af934b004fb40d0e2-- From nobody Sat Jun 7 08:51:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5CC1A01B4 for ; Sat, 7 Jun 2014 08:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XHQWFUrolEG for ; Sat, 7 Jun 2014 08:50:49 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78851A0376 for ; Sat, 7 Jun 2014 08:50:43 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so122236wgg.9 for ; Sat, 07 Jun 2014 08:50:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9LF1HISQw/WiFm36M02799+kEx9jHxy/feWTIWd0SpY=; b=HpJLWUViEBfsQSOPikzfIDIxisw7SS7y3Lg5UsDhNJ5qQjUcp6Bc1mvYD9YmEDDzhZ 3KPwyxh9zwF4Ar8f7R9jbnsQiJ8ZT0LKpOhfADubOgspDyYMJnV0tIE1H4wSNk6fBM8x gVOMjlAmG2JBashlV8gguu8gZvLTkq1OjO5H8APICFzqPVJ8Mj0MY6EAtQhpOhraBQp5 1DRidiaCwEndMwLQtGvb6PA4jgIYcSnCg3PY19Kc/0vJXTYlXXLn/2JpVLPh4cQfovNX JDdcU7iDcMxtWxGSWU2RORcrja6AlMfKPo8UEtvfQCwrk3q5bQ/WfZxvoNh1dSmdqkF6 nIGw== X-Gm-Message-State: ALoCoQk+S9nOIRi+1BKdne34AXQ8q9XtK9YcAAAj38oGBuaOj2qd/vQf7dMVk0dw6dnzK3cLQheJ X-Received: by 10.195.13.79 with SMTP id ew15mr16592420wjd.19.1402156235600; Sat, 07 Jun 2014 08:50:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sat, 7 Jun 2014 08:49:55 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F76@USMBX1.msg.corp.akamai.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F76@USMBX1.msg.corp.akamai.com> From: Eric Rescorla Date: Sat, 7 Jun 2014 08:49:55 -0700 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=047d7bfd093a57cf0f04fb40f0b1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rqEbUTTp2W_kQVEhWsYBfCEJ0Nc Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 15:51:00 -0000 --047d7bfd093a57cf0f04fb40f0b1 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 7, 2014 at 8:11 AM, Salz, Rich wrote: > > What about this solution: separate TLS into a handshake and transport. > > That's a very interesting idea. The "HTTP/1.1 update" did that, turning > RFC2616 into something like seven separate, albeit interlocked, RFC's. As I noted in my response to Watson, TLS does already attempt to make this split inside the RFC (Sections 6 and 7) so this seems like more a document structure question than a technical one. IIRC when HTTP did this, it was partly motivated by concerns that the document was getting unwieldy and indeed RFC 2616 is quite a bit larger than TLS (176 versus 104 pages). As part of what we are trying to do with TLS 1.3 is to remove stuff (my local draft with the initial non-AEAD removal is down to 94 pages) I'd prefer to keep everything in one place, at least, for now. Best, -Ekr --047d7bfd093a57cf0f04fb40f0b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sat, Jun 7, 2014 at 8:11 AM, Salz, Rich <rsalz@akamai.com>= ; wrote:
> What about this solutio= n: separate TLS into a handshake and transport.

That's a very interesting idea. =C2=A0The "HTTP/1.1 update&q= uot; did that, turning RFC2616 into something like seven separate, albeit i= nterlocked, RFC's.

As I noted in my res= ponse to Watson, TLS does already attempt to
make this split inside the RFC (Sections 6 and 7) so this seems like
more a document structure question than a technical one. IIRC when=
HTTP did this, it was partly motivated by concerns that the docu= ment
was getting unwieldy and indeed RFC 2616 is quite a bit larger than
TLS (176 versus 104 pages).

As part of wha= t we are trying to do with TLS 1.3 is to remove stuff
(my loc= al draft with the initial non-AEAD removal is down to 94 pages)
I'd prefer to keep everything in one place, at least, for now.=C2= =A0

Best,
-Ekr

<= /div>
--047d7bfd093a57cf0f04fb40f0b1-- From nobody Sat Jun 7 09:49:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29161A0084 for ; Sat, 7 Jun 2014 09:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIsWqIQ6u3Lk for ; Sat, 7 Jun 2014 09:49:54 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214A31A0081 for ; Sat, 7 Jun 2014 09:49:54 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 66C211C20F3 for ; Sat, 7 Jun 2014 18:49:45 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 484311FE0266; Sat, 7 Jun 2014 18:49:45 +0200 (CEST) Date: Sat, 7 Jun 2014 18:49:45 +0200 From: Kurt Roeckx To: tls@ietf.org Message-ID: <20140607164945.GA23329@roeckx.be> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <20140605173223.GK27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140605173223.GK27883@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bJkSBmdGpDsINGmUyt_1V-_ZWik Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 16:49:55 -0000 On Thu, Jun 05, 2014 at 05:32:23PM +0000, Viktor Dukhovni wrote: > > I would like to see > CAs stop publishing CRLs entirely (solving the scaling issue for > mass revocations as with Heartbleed) CRLs are useful. And I wish all CAs published them. But I do not recommend them to check that the certificate is revoked or not at the time of a connection. > implement only OCSP, and > provide a standard zero-cost revocation protocol when the private > key is available (or when a miracle happens and the "challenge" > password is actually known). > > Once revocation is a scalable working process, then we can benefit > from insisting on OCSP stapling, provided we figure out what to do > with servers that don't have any way to reach out and refresh OCSP > responses for stapling, nor support interface for an agent to > obtain the response on the server's behalf and push it into the > server's configuration. I do not understand what you're really trying to say here. I think we all agree that we want everybody to do OCSP. I think we also want everybody to do OCSP stapling by default when possible. But that doesn't mean we want everybody be forced to do OCSP stapling. I fail to see how this relates to revocation process. If there is a problem in the revocation process having CRL, OCSP, OCSP stapling, or OCSP must staple will all have the same effect. I am curious about your use case for servers that can't refresh the OCSP response. And is this any different in the case of CRLs? Or are you just happy to ignore the non-existence of the CRLs? Kurt From nobody Sat Jun 7 10:06:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178FF1A00FA for ; Sat, 7 Jun 2014 10:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.4 X-Spam-Level: X-Spam-Status: No, score=-101.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1vKWck9gmDQ for ; Sat, 7 Jun 2014 10:06:27 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2656C1A00F8 for ; Sat, 7 Jun 2014 10:06:27 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B9E412AB221; Sat, 7 Jun 2014 17:06:19 +0000 (UTC) Date: Sat, 7 Jun 2014 17:06:19 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140607170619.GC27883@mournblade.imrryr.org> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140607164945.GA23329@roeckx.be> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rprWS0EvgcxKUJLHqhwQjaPZNsE Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 17:06:28 -0000 On Sat, Jun 07, 2014 at 06:49:45PM +0200, Kurt Roeckx wrote: > > Once revocation is a scalable working process, then we can benefit > > from insisting on OCSP stapling, provided we figure out what to do > > with servers that don't have any way to reach out and refresh OCSP > > responses for stapling, nor support interface for an agent to > > obtain the response on the server's behalf and push it into the > > server's configuration. > > I do not understand what you're really trying to say here. > > I think we all agree that we want everybody to do OCSP. I think > we also want everybody to do OCSP stapling by default when > possible. But that doesn't mean we want everybody be forced to > do OCSP stapling. If CAs start issuing "must staple" certificates, isn't that "forced"? > I fail to see how this relates to revocation process. If there is > a problem in the revocation process having CRL, OCSP, OCSP > stapling, or OCSP must staple will all have the same effect. I don't see much value in (especially) CRLs or (even) OCSP stapling without a scalable effective revocation process. > I am curious about your use case for servers that can't refresh > the OCSP response. And is this any different in the case of CRLs? > Or are you just happy to ignore the non-existence of the CRLs? CRLs don't scale, client initiated OCSP to CA leaks too much sensitive data to the CA, and and fails open. OCSP stapling is the only revocation mechanism left standing, but some servers will have difficulty supporting it. Not all servers are HTTP servers, and servers may lack "HTTP client" capabilities to connect to the CA's OCSP responder. Servers may be on networks where they have to traverse various firewalls, proxies, ... to get to the OCSP responder, the burden may be too high. CRL's are a client-side issue I am prepared to "ignore" (would like to see disappear). -- Viktor. From nobody Sat Jun 7 10:26:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5031A00B2 for ; Sat, 7 Jun 2014 10:26:42 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bcd6MDd05s-P for ; Sat, 7 Jun 2014 10:26:40 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5CA1A00A2 for ; Sat, 7 Jun 2014 10:26:40 -0700 (PDT) Received: from [192.168.1.12] (ool-182c5087.dyn.optonline.net [24.44.80.135]) by che.mayfirst.org (Postfix) with ESMTPSA id 9A67EF984; Sat, 7 Jun 2014 13:26:31 -0400 (EDT) Message-ID: <53934B47.4090603@fifthhorseman.net> Date: Sat, 07 Jun 2014 13:26:31 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Watson Ladd , "tls@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0Nftf7pj5ocmPoq1fnwdd6J8OJ6THhsE0" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d-D5iJ3XkW3TFTC0tJ4oe04-kOo Subject: Re: [TLS] No more GMT exposure in the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 17:26:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0Nftf7pj5ocmPoq1fnwdd6J8OJ6THhsE0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/07/2014 10:56 AM, Watson Ladd wrote: > Putting the clock time in the TLS handshake enables fingerprinting. > It's useless cryptographically: 32 random bytes is exceedingly > unlikely to repeat. There seems to be a growing consensus on this point: https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime --dkg --0Nftf7pj5ocmPoq1fnwdd6J8OJ6THhsE0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTk0tHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcrCUP/R1ilpD+rSKrjlrm13cKcNJI M8QSQfZxKfjC+2N3gdmepkuuERCUAyxD0VaEum5zKs5DUQAINW2lwY2pOYZwZL48 teqz1J/o/5feOw6fg28SK1F+Ki+1q+i2SC6m2JwN1yQFMiuyTYkf6GCERun+lZSd 0O43tEUZbZExVwA18l+wst82P03p5vGjCFk+fioq84kXv17lAMZuoJoP8Mnsjpgw QPazQ7cwvbbH16Ljl/NkEnxt4huIqNxO+++OewW25/yf9HRiCUMUDND10O5a7KPl dx8TmMjsZx5yv7Qpf624wWdvZlbb/nj4eX44k1+s/5kMZHDi/lnfzSwnWmvS3RZL X+/peVp+B1X9xLnidCOSxKTfShiKCLNfh7DiZ5OeGaKOQFDUNQMvO1xLxmJg3CDJ 4gDjTO8niB+FZXh+GA3EwK61ISQv2QhTbgvW13JruOyAMeWf5gZT0l7WIWlVCb0G d280PqtR7VKDZBA7HGC85w7ursxOleWp7xGu61SNsOf8ks62LzDviLFbBnwMtROA fR7ZMyK7EpeJAs6QMxt9uZqYQ0EOfE1n9SzOcNZeemPJssp4xptwAqSKUUBlR95L 3Ed9tcSds+J8U3RG8T8SOUauw8i8otkTQxicZVZ4Rjgm2jFMab49KsGvcbCRrnCp 3admxNXJUBAjBtpn7liv =gs6e -----END PGP SIGNATURE----- --0Nftf7pj5ocmPoq1fnwdd6J8OJ6THhsE0-- From nobody Sat Jun 7 10:36:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9E61A0107 for ; Sat, 7 Jun 2014 10:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQ-LyI4X5Ig4 for ; Sat, 7 Jun 2014 10:36:29 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9451A0104 for ; Sat, 7 Jun 2014 10:36:29 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 153221C20F3 for ; Sat, 7 Jun 2014 19:36:21 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id E572F1FE0266; Sat, 7 Jun 2014 19:36:20 +0200 (CEST) Date: Sat, 7 Jun 2014 19:36:20 +0200 From: Kurt Roeckx To: tls@ietf.org Message-ID: <20140607173620.GA24909@roeckx.be> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140607170619.GC27883@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2Scg72KbuQCZnnu-HPyAu1xgtu4 Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 17:36:30 -0000 On Sat, Jun 07, 2014 at 05:06:19PM +0000, Viktor Dukhovni wrote: > On Sat, Jun 07, 2014 at 06:49:45PM +0200, Kurt Roeckx wrote: > > > > Once revocation is a scalable working process, then we can benefit > > > from insisting on OCSP stapling, provided we figure out what to do > > > with servers that don't have any way to reach out and refresh OCSP > > > responses for stapling, nor support interface for an agent to > > > obtain the response on the server's behalf and push it into the > > > server's configuration. > > > > I do not understand what you're really trying to say here. > > > > I think we all agree that we want everybody to do OCSP. I think > > we also want everybody to do OCSP stapling by default when > > possible. But that doesn't mean we want everybody be forced to > > do OCSP stapling. > > If CAs start issuing "must staple" certificates, isn't that "forced"? This will only add the posibility to do so. And CAs may wish to enforce this on some (high traffic) sites. But it's not because you make this posibile that they will do this for all certificates. > > I fail to see how this relates to revocation process. If there is > > a problem in the revocation process having CRL, OCSP, OCSP > > stapling, or OCSP must staple will all have the same effect. > > I don't see much value in (especially) CRLs or (even) OCSP stapling > without a scalable effective revocation process. So are you saying that if a CA wants to use "must staple" it must also do something about it's revocation process? I think that if you think there is something wrong with the revocation process you should try to address that problem independant of how we check the revocation status. > > I am curious about your use case for servers that can't refresh > > the OCSP response. And is this any different in the case of CRLs? > > Or are you just happy to ignore the non-existence of the CRLs? > > CRLs don't scale, client initiated OCSP to CA leaks too much > sensitive data to the CA, and and fails open. OCSP stapling is > the only revocation mechanism left standing, but some servers > will have difficulty supporting it. What is the difficulty in supporting it? > Not all servers are HTTP > servers, and servers may lack "HTTP client" capabilities to > connect to the CA's OCSP responder. If it can already to TLS, I would think that being an HTTP client to get an OCSP response can't be that hard. An HTTP server isn't special in being able to act as HTTP client. > Servers may be on networks > where they have to traverse various firewalls, proxies, ... > to get to the OCSP responder, the burden may be too high. If it's too high for the server, it's most likely to high for the clients to and you should consider using an internal CA instead. Kurt From nobody Sat Jun 7 11:13:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CAF1A00B2 for ; Sat, 7 Jun 2014 11:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BCeik6l13Lz for ; Sat, 7 Jun 2014 11:13:33 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id C9A541A016E for ; Sat, 7 Jun 2014 11:13:33 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 351DB1655FD for ; Sat, 7 Jun 2014 18:13:26 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 2A2111655FC for ; Sat, 7 Jun 2014 18:13:26 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 120C798057 for ; Sat, 7 Jun 2014 18:13:26 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Sat, 7 Jun 2014 14:13:25 -0400 From: "Salz, Rich" To: "tls@ietf.org" Date: Sat, 7 Jun 2014 14:13:24 -0400 Thread-Topic: [TLS] OCSP must staple Thread-Index: Ac+CctLWOJXclgUyS9aXPMRQQl860wACQ9bA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> In-Reply-To: <20140607170619.GC27883@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Rl4LjntOnjQwWoyyKTp3Xb09EJo Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 18:13:35 -0000 > If CAs start issuing "must staple" certificates, isn't that "forced"? In theory, but not in reality. What is the enforcement mechanism? Trust is= , ultimately, a relying party issue. Commerce and financial sites would li= ke to do OCSP stapling, but they won't require it if it means their custome= rs cannot connect. Er, trust me on this one. :) /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Sat Jun 7 11:47:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D051A01BF for ; Sat, 7 Jun 2014 11:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xxGIxt4XkRI for ; Sat, 7 Jun 2014 11:47:46 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0A31A01BD for ; Sat, 7 Jun 2014 11:47:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C6E852AB221; Sat, 7 Jun 2014 18:47:37 +0000 (UTC) Date: Sat, 7 Jun 2014 18:47:37 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140607184737.GD27883@mournblade.imrryr.org> References: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sdl24kdWCsKaVMJRxGXC_lTxI8Q Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 18:47:47 -0000 On Sat, Jun 07, 2014 at 02:13:24PM -0400, Salz, Rich wrote: > > If CAs start issuing "must staple" certificates, isn't that "forced"? > > In theory, but not in reality. What is the enforcement mechanism? > Trust is, ultimately, a relying party issue. Commerce and financial > sites would like to do OCSP stapling, but they won't require it if > it means their customers cannot connect. Er, trust me on this one. :) Well, if the server *is* OCSP stapling capable, there is little harm in having a "must staple" certificate. So those servers won't object to having such a certificate. That leaves servers that can't OCSP staple, and I guess you're sayign CAs will continue to provide certicates without the extension to anyone who wants it. So this another working revocation for the select few mechanism. :-) So be it, no harm done, but larger problem lies upstream, working revocation for the masses. -- Viktor. From nobody Sat Jun 7 13:12:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C864E1A0083 for ; Sat, 7 Jun 2014 13:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNuL3LDuRCuC for ; Sat, 7 Jun 2014 13:12:45 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 79C4A1A0073 for ; Sat, 7 Jun 2014 13:12:45 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 11D2A47504 for ; Sat, 7 Jun 2014 20:12:38 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 060A5474B8 for ; Sat, 7 Jun 2014 20:12:38 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id ED35D2026 for ; Sat, 7 Jun 2014 20:12:37 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Sat, 7 Jun 2014 16:12:37 -0400 From: "Salz, Rich" To: "tls@ietf.org" Date: Sat, 7 Jun 2014 16:12:35 -0400 Thread-Topic: [TLS] OCSP must staple Thread-Index: Ac+CgPo0EQsrCFWsSdGIITUhRv6y7wACmHhw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> References: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> In-Reply-To: <20140607184737.GD27883@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/otfC27reUvnLDrD-dRJcAo_-15k Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 20:12:47 -0000 > Well, if the server *is* OCSP stapling capable, there is little harm in h= aving a "must staple" certificate. Except that they are depending on the CA's OCSP responder, and trusting (wo= rrying is a more accurate term) that the browsers will do the right thing, = whatever that is. I'll be pretty surprised if the "select few," as you put= it, will want must-staple certificates.=20 > but larger problem lies upstream, working revocation for the masses. Which masses? For what? We're going through an exercise of checking the SS= L certs on the true origins of many of our customers. You'd be sadly surpr= ised how many of them are expired, have wrong SAN fields, unknown CA's, and= so on. And even sadder if you knew how many said "we'll deal with it late= r, if at all." And yet, the web commerce still marches on. I think the general public is put more at risk by erroneously-issued certi= ficates, whether by accident or malicious or "national security." Luckily,= it appears that Certificate Transparency seems likely to narrow that windo= w of exposure down to a fairly short time. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Sat Jun 7 14:55:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BAC1A021E for ; Sat, 7 Jun 2014 14:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4i7XuaiVnjA for ; Sat, 7 Jun 2014 14:55:31 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149FC1A0218 for ; Sat, 7 Jun 2014 14:55:30 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id i50so7183926qgf.31 for ; Sat, 07 Jun 2014 14:55:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dGu+An7w0uDTS3KZtxrf7fsqtHLCXJRSdH8P0El01v4=; b=mKqn+FP4Chq7xVAXJPHdRkab3tjtH0Ua1TA4uxnhP9Hri5ubynRi2yiDRj172H16ui Mz2pSZvPE6Dt7eLzxwQh/kZPsV8vM1MBu1jVZKBcGAeroG7creO3UZKsD2sgTDUKnYcc Bk1YNTQfux6ow0jof7bSR7UX58ya3WUkiGkC2MiBhFNHywWoRSau7ntxTd8J01vFUAt0 vioABm3eR4ly7QlFx2DoeAAUewpPVIfCGmwZSmjgAd5PtEBQeAXsK7hd4deSTyU99P3y B0OqI0aLmypdYxivL/Z/ojC8hEOWkrfzXUgiYmvhTu1Nwj37mZAXaRUegnX8YxIvTms1 P+3A== X-Gm-Message-State: ALoCoQmNbd+Axp36J7ZMMkVZLhSAxrTOmul3ydU/E+gl2DoyDjiy18UgW5nu+vSwSXVkENf32FMt MIME-Version: 1.0 X-Received: by 10.140.89.18 with SMTP id u18mr19742516qgd.90.1402178123380; Sat, 07 Jun 2014 14:55:23 -0700 (PDT) Received: by 10.140.100.205 with HTTP; Sat, 7 Jun 2014 14:55:23 -0700 (PDT) X-Originating-IP: [37.221.161.235] In-Reply-To: <53934B47.4090603@fifthhorseman.net> References: <53934B47.4090603@fifthhorseman.net> Date: Sat, 7 Jun 2014 21:55:23 +0000 Message-ID: From: Jacob Appelbaum To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dbh0y64mnIcXqnN9LZ2W2GsErrI Cc: "tls@ietf.org" Subject: Re: [TLS] No more GMT exposure in the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 21:55:32 -0000 On 6/7/14, Daniel Kahn Gillmor wrote: > On 06/07/2014 10:56 AM, Watson Ladd wrote: >> Putting the clock time in the TLS handshake enables fingerprinting. >> It's useless cryptographically: 32 random bytes is exceedingly >> unlikely to repeat. > > There seems to be a growing consensus on this point: > > https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime > I've said as much to Nick and to Eric (in the context of working on tlsdate[0]) but perhaps not on this tls list: I'd like to see servers provide 64bits of time resolution in the ServerHello and nothing but randomness in that field in the ClientHello. The current 32bit field isn't accurate enough for replacing NTP. If we can't make the time field useful for accurate secure time exchange - I hope we'll remove all network visible distinguishers, even ones that are currently useful for totally bizarre reasons. All the best, Jacob [0] https://www.github.com/ioerror/tlsdate From nobody Sat Jun 7 16:03:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD4C1A0248 for ; Sat, 7 Jun 2014 16:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biSUbFrJdTHC for ; Sat, 7 Jun 2014 16:03:02 -0700 (PDT) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C731A0246 for ; Sat, 7 Jun 2014 16:03:02 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id w61so4360413wes.12 for ; Sat, 07 Jun 2014 16:02:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Gvcnx7tvytHtGKaxAHjDSkYj247Rp/cfeSm5H8bQPUQ=; b=jlXq4laBxCPrJbB5I2o3IjOtRtsDxDxDoEgMrrMiVLsjyZLeaFPmSqmfac0yVI7k50 sjpHKveUkLz6fCQkxQ4MmiBJmApjyyWo8OvD2HiDRgKPO+NeqNhiuhbifQZwnXjT8rd6 RXpmuQTmk6a+SX5cTifQtTS+71DMybMzETH0SkfA2hrXyzvoHybByfYLgnlpv+mzC3Nf SoGmh3ZMjjKJlqIJcDwOeYd3WuB0XFafRKInXQGdp1zfPUOlo/F1954ek/v3Gh1IM3XL hgE8q9zXSvk7AhHhslMWk51FrjuqowHT9CbPNCwiKDr2Wv0AuKAtkRKGXqAoExenWcS/ AP3w== X-Gm-Message-State: ALoCoQmDWZtipM0pVvl54aB8FymDxfsIfN1r+4xZ5XJIjaQI9bqaDzFhYD0jYwK0XEE44vbzUo9A X-Received: by 10.194.246.234 with SMTP id xz10mr218406wjc.77.1402182173629; Sat, 07 Jun 2014 16:02:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sat, 7 Jun 2014 16:02:13 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <53934B47.4090603@fifthhorseman.net> From: Eric Rescorla Date: Sat, 7 Jun 2014 16:02:13 -0700 Message-ID: To: Jacob Appelbaum Content-Type: multipart/alternative; boundary=089e01681cd45eb89904fb46fa1e Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8RV7SdxNW2Lns0lR2Fcl4tI0Uxo Cc: "tls@ietf.org" Subject: Re: [TLS] No more GMT exposure in the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 23:03:04 -0000 --089e01681cd45eb89904fb46fa1e Content-Type: text/plain; charset=UTF-8 I've created a github issue [https://github.com/tlswg/tls13-spec/issues/42] to keep track of this. -Ekr On Sat, Jun 7, 2014 at 2:55 PM, Jacob Appelbaum wrote: > On 6/7/14, Daniel Kahn Gillmor wrote: > > On 06/07/2014 10:56 AM, Watson Ladd wrote: > >> Putting the clock time in the TLS handshake enables fingerprinting. > >> It's useless cryptographically: 32 random bytes is exceedingly > >> unlikely to repeat. > > > > There seems to be a growing consensus on this point: > > > > https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime > > > > I've said as much to Nick and to Eric (in the context of working on > tlsdate[0]) but perhaps not on this tls list: > > I'd like to see servers provide 64bits of time resolution in the > ServerHello and nothing but randomness in that field in the > ClientHello. > > The current 32bit field isn't accurate enough for replacing NTP. If we > can't make the time field useful for accurate secure time exchange - I > hope we'll remove all network visible distinguishers, even ones that > are currently useful for totally bizarre reasons. > > All the best, > Jacob > > [0] https://www.github.com/ioerror/tlsdate > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e01681cd45eb89904fb46fa1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've created a github issue


to keep track of this.
=

-Ekr




On Sat, Jun 7, 2014 at 2:55 PM, Ja= cob Appelbaum <jacob@appelbaum.net> wrote:
On 6/7/14, Daniel Kahn G= illmor <dkg@fifthhorseman.net> wrote:
> On 06/07/2014 10:56 AM, Watson Ladd wrote:
>> Putting the clock time in the TLS handshake enables fingerprinting= .
>> It's useless cryptographically: 32 random bytes is exceedingly=
>> unlikely to repeat.
>
> There seems to be a growing consensus on this point:
>
> =C2=A0 https://tools.ietf.org/html/draft-mathewson-no-gm= tunixtime
>

I've said as much to Nick and to Eric (in the context of wo= rking on
tlsdate[0]) but perhaps not on this tls list:

I'd like to see servers provide 64bits of time resolution in the
ServerHello and nothing but randomness in that field in the
ClientHello.

The current 32bit field isn't accurate enough for replacing NTP. If we<= br> can't make the time field useful for accurate secure time exchange - I<= br> hope we'll remove all network visible distinguishers, even ones that are currently useful for totally bizarre reasons.

All the best,
Jacob

[0] ht= tps://www.github.com/ioerror/tlsdate

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

--089e01681cd45eb89904fb46fa1e-- From nobody Sat Jun 7 21:02:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8921A02B4 for ; Sat, 7 Jun 2014 21:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.953 X-Spam-Level: X-Spam-Status: No, score=-4.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDPRg4NsZPka for ; Sat, 7 Jun 2014 21:02:44 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA5F1A02B2 for ; Sat, 7 Jun 2014 21:02:44 -0700 (PDT) Received: from JROWLEYL2 (c-67-166-110-179.hsd1.ut.comcast.net [67.166.110.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id CF0037FA482; Sat, 7 Jun 2014 22:02:36 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1402200157; bh=fzmJ845I+OV9JtqWpszm4TGzza/jEWlVV11L2r5eAZI=; h=From:To:References:In-Reply-To:Subject:Date; b=yKubcaQZoMxqUfJqikvMSxGeYcwPUpBYdwQRI18rLyVT9hOJnJYbBjTE6VVFe/pze KrTqEvcZbG6SmUJmuYylAdue6TTOHTYhNgLInDUVPHyJnhwn41pagzRaelYop8RY7d QU/R21y7j4Q+woeC0dvM8DfvOlGGbw1GyeoHsMBU= From: "Jeremy Rowley" To: "'Salz, Rich'" , References: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> Date: Sat, 7 Jun 2014 22:02:38 -0600 Message-ID: <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJxv6HtmB9uk8Yt5wEeFHdRD1knoQEt2WjqAP+sMUYCHog9/QJH2PNTApX9AA0COSwKkwNalKqnAp4CcngB5F3w/QJ8kG4OAaygmc2ZZtBTsA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/tls/76EcPO8ZuNU-0wU7dleTpFHKXm8 Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 04:02:46 -0000 >> Well, if the server *is* OCSP stapling capable, there is little harm in having a "must staple" certificate. >Except that they are depending on the CA's OCSP responder, and trusting (worrying is a more accurate term) that the browsers will do the right thing, whatever that is. I'll be pretty surprised if the "select few," as you put it, will want must-staple certificates. Any standard "trusts" that the implementers will do the right thing. Not sure that's an argument against adoption. CA OCSP responder availability isn't a concern with stapling, especially considering uptimes typically exceed 99.99% (http://ocspreport.x509labs.com/). We already have people interested in using must staple upon adoption so this shouldn't be a factor in the adopting the draft. >> but larger problem lies upstream, working revocation for the masses. >Which masses? For what? We're going through an exercise of checking the SSL certs on the true origins of many of our customers. You'd be sadly surprised how many of them are expired, have wrong SAN fields, unknown CA's, and so on. And even sadder if you knew how many said "we'll deal with it later, if at all." And yet, the web commerce still marches on. Non-compliance by certain CAs is really irrelevant to whether OCSP Must Staple should be adopted as a standard. Must staple is about letting server operators dictate whether stapling is required, not on improving CA certificate profiles. That should be addressed in a separate RFC by those concerned with current practices. >I think the general public is put more at risk by erroneously-issued certificates, whether by accident or malicious or "national security." Luckily, it appears that Certificate Transparency seems likely to narrow that window of exposure down to a fairly short time. Again, irrelevant to whether MUST Staple is adopted. CT does not preclude MUST Staple and vice versa. All security is a layered approach. This is just one more tool available to server operators to increase their level of security. Best of all, MUST staple doesn't necessarily require a change in current server software. Only a change in the browser to recognize the extension. Jeremy From nobody Sat Jun 7 21:59:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCC01A02C9 for ; Sat, 7 Jun 2014 21:59:28 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37ciyLHAh4Oc for ; Sat, 7 Jun 2014 21:59:27 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26BAC1A02CC for ; Sat, 7 Jun 2014 21:59:27 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id p10so4414623wes.20 for ; Sat, 07 Jun 2014 21:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/cc/gZL/1h089Un2LjE7POo9/TZLsrQymJ2vHcorRjo=; b=FuO97zTbdAHkL5ZQZXe1ZRNcL0BHvZKkpc8+KFN3rLGeMCGDJT+4m1QXvSlMC+fPK9 N/0Ute+26AX8bwXFqRSIFif9pqfxzQ+7kXesOmA2znkkIcVdfEM5hsLKJMPdxxhd4UNe XsoRNMaX3SHt6yhO01EKKDNHkkf/OIwtgjWhQzWWTMSklsIzSOOV48fXl/CEmUKbeXlz GYsrgPIcQr84B7mzPHly3J56PV4ka/bcVMk2ZkTInYOHyi9F4HOHb7UIYZAu70mvtnga ZquIthD0HVGLzZm6JPbU0d15dhxkBg6PYMQUJA0DwG7K7eDZ29xVYXPdllY5KmcgjlW1 u66A== X-Received: by 10.180.212.112 with SMTP id nj16mr18397025wic.1.1402203558854; Sat, 07 Jun 2014 21:59:18 -0700 (PDT) Received: from [192.168.1.102] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id s3sm19025162wje.36.2014.06.07.21.59.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 21:59:18 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> Date: Sun, 8 Jun 2014 07:59:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> To: Jeremy Rowley X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/z9GhI-goUHcInRgsM7A7hs_tmH8 Cc: tls@ietf.org Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 04:59:28 -0000 On Jun 8, 2014, at 7:02 AM, Jeremy Rowley = wrote: > Non-compliance by certain CAs is really irrelevant to whether OCSP = Must > Staple should be adopted as a standard. Must staple is about letting = server > operators dictate whether stapling is required, not on improving CA > certificate profiles.=20 dictate to whom? Isn=92t the presence of this extension a mandate on = the server operators themselves? And enforced how? Suppose a server sends the client a certificate with = the extension, and does not staple an OCSP response, are clients going = to cut the connection or are they going to try the OCSP server. And if = they try the OCSP server, is ti going to reject them? I=92m trying to get my head around how this extension is going to be = deployed. Yoav From nobody Sat Jun 7 22:11:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5C21A02D3 for ; Sat, 7 Jun 2014 22:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ziu6NBnLSguX for ; Sat, 7 Jun 2014 22:11:15 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE551A02D4 for ; Sat, 7 Jun 2014 22:11:15 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jw12so2295063veb.39 for ; Sat, 07 Jun 2014 22:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/Nye1xXJVwYTiUODSGHncv36/SdM3tKIucqy7fYK8ZA=; b=Y/NZ58qwr124HumBs8B9gNE62I58WGom5bDrvwihUIIPFLYifYBqipkuMVkx9RQY2/ KAk/HlY97mvmlBqYH+i7gISrq31LNXdSIkPbUBOGcIUUxqt1+vzHo3A0IcjonroT13HL pFhJY1WrsFssY7Gdnd7gNS7B81tXjajmkc++g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/Nye1xXJVwYTiUODSGHncv36/SdM3tKIucqy7fYK8ZA=; b=LauiyvzhmckNg+CBFFbIzRi6BR21hRRpeXLT4YYdPUUXI3M2RKZ88dMLxSXIgXHtDW wGDj8+7qEPqirOGAwtwcWD4YHLtlviSLOw7ioNwFuvXRDXoe3+dU65BVAa9IV3/q8CHA /Fc7fQ2f4cx0pWg3PmiyQhPBeonV0KpeAWCMSIwnQ0vX3fr96embV9nvuJY3f/dqR1zR TUbLTAEFlnJM33x6OqGIGkPPNZEIFa0cdxAtavC9XTCponuxImiL722TGjpYQPAC+wPF ipH0OVlE58FrUiOagQ34fGN7Lk7H2uHmhwB3UTGcZ/mwKlgWXLr1/PFaost4DYRaHXSV omFA== X-Gm-Message-State: ALoCoQmo2TCJxWQ31a7l8j/uzysXNkLanDsSN6fSUpHKvuZePFTExOCS5Hhgu6i5ZKqd2cOGNUDR X-Received: by 10.220.69.72 with SMTP id y8mr17185648vci.21.1402204267467; Sat, 07 Jun 2014 22:11:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.106.39 with HTTP; Sat, 7 Jun 2014 22:10:47 -0700 (PDT) In-Reply-To: References: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> From: Tom Ritter Date: Sun, 8 Jun 2014 01:10:47 -0400 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=047d7b3a925043ed1c04fb4c1f51 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5jBFEWMEhwg0aK9Xmlr3jKLtw6k Cc: "tls@ietf.org" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 05:11:17 -0000 --047d7b3a925043ed1c04fb4c1f51 Content-Type: text/plain; charset=ISO-8859-1 On 8 June 2014 00:59, Yoav Nir wrote: > dictate to whom? Isn't the presence of this extension a mandate on the > server operators themselves? > Well, yes, but in the same way that HSTS is a mandate on a server operator to make their site available over HTTPS. I think the mandate is more accurately terms as for the client. If a staple is not provided, you should reject the certificate as invalid. > And enforced how? Suppose a server sends the client a certificate with > the extension, and does not staple an OCSP response, are clients going to > cut the connection or are they going to try the OCSP server. And if they > try the OCSP server, is ti going to reject them? > While it looks some of the semantics of 'Must Staple', I think either behavior could be acceptable for a client. Either closing the connection without attempting to contact a OCSP server, or switching to a 'Hard Fail' OCSP lookup. I can imagine some servers deciding that they would want clients to fail if they didn't send a staple, rather than leak the OCSP lookup to the CA. I could imagine other servers wanting to hedge their bets and have the client make an attempt before giving up. I don't understand what you mean by the OCSP server rejcting them. > I'm trying to get my head around how this extension is going to be > deployed. > I see it as a server opting in to strict revocation checking for a certificate. (Later on, for the host itself, but for now, just the certificate.) -tom --047d7b3a925043ed1c04fb4c1f51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 8= June 2014 00:59, Yoav Nir <ynir.ietf@gmail.com> wrote:
dictate to whom?  Isn’t the presence of this ext= ension a mandate on the server operators themselves?
=

Well, yes, but in the same way that HSTS is a mandate o= n a server operator to make their site available over HTTPS.  I think = the mandate is more accurately terms as for the client.  If a staple i= s not provided, you should reject the certificate as invalid.
 
And enforced how?  Suppose a server sends the client a certificate wit= h the extension, and does not staple an OCSP response, are clients going to= cut the connection or are they going to try the OCSP server. And if they t= ry the OCSP server, is ti going to reject them?

While it looks some of the semantics of &#= 39;Must Staple', I think either behavior could be acceptable for a clie= nt.  Either closing the connection without attempting to contact a OCS= P server, or switching to a 'Hard Fail' OCSP lookup. 

I can imagine some servers deciding that they would wan= t clients to fail if they didn't send a staple, rather than leak the OC= SP lookup to the CA.  I could imagine other servers wanting to hedge t= heir bets and have the client make an attempt before giving up.

I don't understand what you mean by the OCSP server= rejcting them.
 
I’m trying to get my head around how this extension is going to be de= ployed.

I see it as a server opting in = to strict revocation checking for a certificate.  (Later on, for the h= ost itself, but for now, just the certificate.)

-tom
--047d7b3a925043ed1c04fb4c1f51-- From nobody Sun Jun 8 03:17:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9B21A0391 for ; Sun, 8 Jun 2014 03:17:34 -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, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQDai1lAetbw for ; Sun, 8 Jun 2014 03:17:31 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C9281A032C for ; Sun, 8 Jun 2014 03:17:31 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 400731C21A1; Sun, 8 Jun 2014 12:17:22 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 0CE501FE00EC; Sun, 8 Jun 2014 12:17:21 +0200 (CEST) Date: Sun, 8 Jun 2014 12:17:21 +0200 From: Kurt Roeckx To: Jacob Appelbaum Message-ID: <20140608101721.GA6189@roeckx.be> References: <53934B47.4090603@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mXRbrTWjlrkrjTKUrRXSXzwyFKU Cc: "tls@ietf.org" Subject: Re: [TLS] No more GMT exposure in the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 10:17:34 -0000 On Sat, Jun 07, 2014 at 09:55:23PM +0000, Jacob Appelbaum wrote: > On 6/7/14, Daniel Kahn Gillmor wrote: > > On 06/07/2014 10:56 AM, Watson Ladd wrote: > >> Putting the clock time in the TLS handshake enables fingerprinting. > >> It's useless cryptographically: 32 random bytes is exceedingly > >> unlikely to repeat. > > > > There seems to be a growing consensus on this point: > > > > https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime > > > > I've said as much to Nick and to Eric (in the context of working on > tlsdate[0]) but perhaps not on this tls list: > > I'd like to see servers provide 64bits of time resolution in the > ServerHello and nothing but randomness in that field in the > ClientHello. > > The current 32bit field isn't accurate enough for replacing NTP. If we > can't make the time field useful for accurate secure time exchange - I > hope we'll remove all network visible distinguishers, even ones that > are currently useful for totally bizarre reasons. Would that be in the same format as NTP, with 32 bit for the seconds and 32 bit for fractional second, and so a resolution of 0.2 nano seconds? I'm wondering what kind of accuracy you'll get. Anyway, how do you plan to deal with checking the status of the certificate if you don't know what the current time is? Kurt From nobody Sun Jun 8 05:28:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6451A03B5 for ; Sun, 8 Jun 2014 05:28:09 -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, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AATxAaHujOkW for ; Sun, 8 Jun 2014 05:28:07 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1DB1A03AE for ; Sun, 8 Jun 2014 05:28:07 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id CF0121C219E; Sun, 8 Jun 2014 14:27:58 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 9DC501FE00EC; Sun, 8 Jun 2014 14:27:58 +0200 (CEST) Date: Sun, 8 Jun 2014 14:27:58 +0200 From: Kurt Roeckx To: Phillip Hallam-Baker Message-ID: <20140608122758.GA10562@roeckx.be> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d9i6YLPft92NO7HDth66YtnSb_0 Cc: "tls@ietf.org" Subject: Re: [TLS] Why there should not be a TLS 2.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 12:28:09 -0000 On Thu, Jun 05, 2014 at 09:27:46AM -0400, Phillip Hallam-Baker wrote: > So rather than thinking about TLS 2.0, I think we should instead > consider the problem of establishing a security context separately > from the problem of how to apply that context to a communication > medium. Once that separation is made we can apply it at the packet, > transport and application levels. Instead of TLS/2.0 we should be > thinking about IPSEC/2.0 and HTTP-SEC. So I understand you want to split the encryption from the authentication? Would there still be a need for HTTP-SEC, and can't it be plain HTTP in that case? Do you expect the client (browser) to set up this IPSEC/2.0 possibly by a library, or do you expect a separate daemon or the kernel to provide that functionallity? I would imagine that the client would like to do a "please give me a tunnel to that hostname", and then get back some descriptor that it can use to talk to it. Please note that I say hostname, because I think that you can have several names each which it's own certificate on the same IP address. But then I wonder if it should be to a combination of hostname and port or not. Maybe you want to use a different certificate for HTTP and email? And if you do it to a combination of hostname and port, what really is the difference with TLS other than that it might run at a different layer? Kurt From nobody Sun Jun 8 08:10:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B071A0423 for ; Sun, 8 Jun 2014 08:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJILOTvPwi7z for ; Sun, 8 Jun 2014 08:10:47 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8D51A0420 for ; Sun, 8 Jun 2014 08:10:46 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id z60so7764098qgd.37 for ; Sun, 08 Jun 2014 08:10:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BrvemEWQRlS3D5esKIPopH0ONZXpsCZuEIfmIx3F4VA=; b=eMYZMOx2eKxPOSRCicg3/47ioVSC4G3e1NgYUE9OyMurvWJDvUX4HFw7QUMAKH0jMT bVVy68TgfLK9EbF7zJ3zc4OI83WIJiKX0pwn6Mr2pnqx3wR9+1Y2WG2mgfMlSsa9GlCl 5ndgO9kJsS0pnSTIZNDLtZdV6iYabkCozgtSNWUzMPqx+Df9gXFRF8ExUasnpXj7SUbS IL6Lem6e0VFmj+eaK9Yqyvi7xz0tzGDKj8S3DiASExachtMrsKRjLb+/qaWyB3Fr1KaR rc4C+yhUplAkhwtEc6DP/aqXEz3QZF2occtURil/sArD40eZu2WACRRZLnwksBGhMOzA 5AgA== X-Gm-Message-State: ALoCoQmsL6LfOQDiUR763++d4oG6ELf4OkGryi0G+7RuG253hWyRBeDxioBdai7A2BYw+oHntHVM MIME-Version: 1.0 X-Received: by 10.224.63.137 with SMTP id b9mr25924481qai.70.1402240246467; Sun, 08 Jun 2014 08:10:46 -0700 (PDT) Received: by 10.140.100.205 with HTTP; Sun, 8 Jun 2014 08:10:46 -0700 (PDT) X-Originating-IP: [81.4.108.61] In-Reply-To: <20140608101721.GA6189@roeckx.be> References: <53934B47.4090603@fifthhorseman.net> <20140608101721.GA6189@roeckx.be> Date: Sun, 8 Jun 2014 15:10:46 +0000 Message-ID: From: Jacob Appelbaum To: Kurt Roeckx Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MQKBZFMFMsaAu_OemvGRpfOpfHM Cc: "tls@ietf.org" Subject: Re: [TLS] No more GMT exposure in the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 15:10:48 -0000 On 6/8/14, Kurt Roeckx wrote: > On Sat, Jun 07, 2014 at 09:55:23PM +0000, Jacob Appelbaum wrote: >> On 6/7/14, Daniel Kahn Gillmor wrote: >> > On 06/07/2014 10:56 AM, Watson Ladd wrote: >> >> Putting the clock time in the TLS handshake enables fingerprinting. >> >> It's useless cryptographically: 32 random bytes is exceedingly >> >> unlikely to repeat. >> > >> > There seems to be a growing consensus on this point: >> > >> > https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime >> > >> >> I've said as much to Nick and to Eric (in the context of working on >> tlsdate[0]) but perhaps not on this tls list: >> >> I'd like to see servers provide 64bits of time resolution in the >> ServerHello and nothing but randomness in that field in the >> ClientHello. >> >> The current 32bit field isn't accurate enough for replacing NTP. If we >> can't make the time field useful for accurate secure time exchange - I >> hope we'll remove all network visible distinguishers, even ones that >> are currently useful for totally bizarre reasons. > > Would that be in the same format as NTP, with 32 bit for the > seconds and 32 bit for fractional second, and so a resolution > of 0.2 nano seconds? I'm wondering what kind of accuracy you'll > get. > That sounds fine to me, sure. I admit, I haven't put a lot of thought into the format because it seems that most of the momentum is in removing anything meaningful from that field. > Anyway, how do you plan to deal with checking the status of the > certificate if you don't know what the current time is? > tlsdate has a bunch of options for that situation. I'd suggest checking out how ChromeOS uses it as tlsdate is their default NTP-like client for ChromeOS. It has short comings, of course. With tlsdate, one may skip on checking the time and date constraints for the first connection by setting some other constraints. As an example, ensuring that the clock is moving forward while still having assurances that an attacker must control specific cryptographic keys, etc. In any case, having 64bits of timing information from a server would allow for a parasitic network time protocol that is as accurate as NTP to be built on top of TLS. I haven't checked but I believe Google still uses this to set clocks on ChromeOS. I have a lot to say about tlsdate but it seems out of scope here. Check out the code and please do help us to improve it! All the best, Jacob From nobody Sun Jun 8 08:40:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3341A0183 for ; Sun, 8 Jun 2014 08:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKOtk_jz-awP for ; Sun, 8 Jun 2014 08:39:52 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64BB01A0192 for ; Sun, 8 Jun 2014 08:39:38 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0CC702AB222; Sun, 8 Jun 2014 15:39:37 +0000 (UTC) Date: Sun, 8 Jun 2014 15:39:36 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140608153936.GF27883@mournblade.imrryr.org> References: <53934B47.4090603@fifthhorseman.net> <20140608101721.GA6189@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mDVat_lKKVEpXgmlNiZAIDyNppU Subject: Re: [TLS] No more GMT exposure in the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 15:40:14 -0000 X-List-Received-Date: Sun, 08 Jun 2014 15:40:14 -0000 On Sun, Jun 08, 2014 at 03:10:46PM +0000, Jacob Appelbaum wrote: > That sounds fine to me, sure. I admit, I haven't put a lot of thought > into the format because it seems that most of the momentum is in > removing anything meaningful from that field. A good thing. If the client wants a server time-stamp, it can ask for it via an extension. > In any case, having 64bits of timing information from a server would > allow for a parasitic network time protocol that is as accurate as NTP > to be built on top of TLS. I haven't checked but I believe Google > still uses this to set clocks on ChromeOS. "As accurate as NTP" is a bold claim. NTP "accuracy" (as opposed to precision which is a different beast entirely) comes from using multiple sourcs a PLL to estimate round-trip delay and smooth out noise, and when possible multiple sources, ... NTP runs over UDP which is less likely to be delayed, re-transmitted, ... Attaining NTP "accuracy" over TLS, seems rather implausible. -- Viktor. From nobody Sun Jun 8 08:49:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684CC1A00D2 for ; Sun, 8 Jun 2014 08:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTX4HDaQAOeX for ; Sun, 8 Jun 2014 08:49:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30401A0089 for ; Sun, 8 Jun 2014 08:49:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 940262AB222; Sun, 8 Jun 2014 15:49:01 +0000 (UTC) Date: Sun, 8 Jun 2014 15:49:01 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140608154901.GG27883@mournblade.imrryr.org> References: <20140608122758.GA10562@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140608122758.GA10562@roeckx.be> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_PcLI9zTahnpYCAny1JOjRSczYo Subject: Re: [TLS] Why there should not be a TLS 2.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 15:49:08 -0000 X-List-Received-Date: Sun, 08 Jun 2014 15:49:08 -0000 On Sun, Jun 08, 2014 at 02:27:58PM +0200, Kurt Roeckx wrote: > I would imagine that the client would like to do a "please give me > a tunnel to that hostname", and then get back some descriptor that > it can use to talk to it. Please note that I say hostname, > because I think that you can have several names each which it's > own certificate on the same IP address. Yes, but stronger yet, one needs (ala GSSAPI + Kerberos, which for all its limitations gets some things right) to be able to ask for service@hostname, not just hostname. The underlying Kerberos stack works with service/instance@REALM, which also makes sense. We could define new DANE record formats for scalable public-key cross realm authentication with Kerberos or a Kerberos-like system, and DNSSEC for a suitably secure hostname->realm mapping. -- Viktor. From nobody Sun Jun 8 09:03:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFD61A0139 for ; Sun, 8 Jun 2014 09:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWMU7rz0Uqlc for ; Sun, 8 Jun 2014 09:03:54 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF26E1A00E4 for ; Sun, 8 Jun 2014 09:03:54 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 290792AB222; Sun, 8 Jun 2014 16:03:54 +0000 (UTC) Date: Sun, 8 Jun 2014 16:03:54 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140608160354.GH27883@mournblade.imrryr.org> References: <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mzud_VG2mcpurJ3H0LWH5a60su0 Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 16:03:56 -0000 On Sun, Jun 08, 2014 at 01:10:47AM -0400, Tom Ritter wrote: > I don't understand what you mean by the OCSP server rejcting them. Well, the server was supposed to have stapled, so the OCSP server could in principle (knowing the server's certificate requires stapling) refuse to provide an unstapled response. -- Viktor. From nobody Sun Jun 8 09:13:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919E61A0114 for ; Sun, 8 Jun 2014 09:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tt6hMOwR5fPD for ; Sun, 8 Jun 2014 09:13:33 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7F91A0089 for ; Sun, 8 Jun 2014 09:13:32 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id y20so2375922ier.18 for ; Sun, 08 Jun 2014 09:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=sTPgLUF11egVk5MBJTfxSpXQF1SSBqs8yPc3GSqQ3+8=; b=0qUMeu+eIxSdOCZNljn5vNPbpHjwQKqPMHw/h8m1kRJJESQqk3jJGxmEnxVDvPLbJL tNT6TA8dSQCsE6agYskhDjIoD9J+PoIFAF74+Ec0DS41iqaCcaN+PZJ2oJJgNsHhT4V/ b6fPt7yEM9cL82J5KXDGu3N8D8Rj2/3rkjlQjPkhsVLmR94fmr6PYx0l318DfN0K44zL SQu3V1/K/fYjDxCa+GGMlaGbwwGw1/JBN1FVcDHwYio9RgY/lsZbv6pBvUmpHSiuVSMY ds1bzez9jUkfKuu1hLM8UKWzss2Ar+FBgWZfbVqBbFu07KtSivrRFGKPNi46qWFxwA/3 ngBQ== MIME-Version: 1.0 X-Received: by 10.68.231.7 with SMTP id tc7mr21260438pbc.32.1402244012235; Sun, 08 Jun 2014 09:13:32 -0700 (PDT) Received: by 10.70.56.3 with HTTP; Sun, 8 Jun 2014 09:13:32 -0700 (PDT) In-Reply-To: <20140608160354.GH27883@mournblade.imrryr.org> References: <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> <20140608160354.GH27883@mournblade.imrryr.org> Date: Sun, 8 Jun 2014 09:13:32 -0700 Message-ID: From: Peter Bowen To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sxxhfmjiVwSmYlKPK3m12lEvGwQ Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 16:13:34 -0000 On Sun, Jun 8, 2014 at 9:03 AM, Viktor Dukhovni wrote: > On Sun, Jun 08, 2014 at 01:10:47AM -0400, Tom Ritter wrote: > >> I don't understand what you mean by the OCSP server rejcting them. > > Well, the server was supposed to have stapled, so the OCSP server > could in principle (knowing the server's certificate requires > stapling) refuse to provide an unstapled response. The server is only supposed to staple if the client supports stapling. Clients that don't support stapling will still make OCSP requests. From nobody Sun Jun 8 09:21:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1791A018C for ; Sun, 8 Jun 2014 09:21:45 -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=[SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wzjKhmcXhpE for ; Sun, 8 Jun 2014 09:21:43 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927731A0089 for ; Sun, 8 Jun 2014 09:21:43 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 3EA141C219E for ; Sun, 8 Jun 2014 18:21:41 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 2353C1FE00EC; Sun, 8 Jun 2014 18:21:41 +0200 (CEST) Date: Sun, 8 Jun 2014 18:21:41 +0200 From: Kurt Roeckx To: tls@ietf.org Message-ID: <20140608162140.GA15151@roeckx.be> References: <53934B47.4090603@fifthhorseman.net> <20140608101721.GA6189@roeckx.be> <20140608153936.GF27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140608153936.GF27883@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yt9NRycSBitWMdmCL5B8H_l6O0w Subject: Re: [TLS] No more GMT exposure in the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 16:21:45 -0000 On Sun, Jun 08, 2014 at 03:39:36PM +0000, Viktor Dukhovni wrote: > > In any case, having 64bits of timing information from a server would > > allow for a parasitic network time protocol that is as accurate as NTP > > to be built on top of TLS. I haven't checked but I believe Google > > still uses this to set clocks on ChromeOS. > > "As accurate as NTP" is a bold claim. NTP "accuracy" (as opposed > to precision which is a different beast entirely) comes from using > multiple sourcs a PLL to estimate round-trip delay and smooth out > noise, and when possible multiple sources, ... > > NTP runs over UDP which is less likely to be delayed, re-transmitted, ... > > Attaining NTP "accuracy" over TLS, seems rather implausible. I think even getting it's precision will be hard. But I wonder what kind of accuracy do you really want? I think getting an accuracy smaller than 1 second shouldn't be that hard, but ntpd is only claiming an accuracy in the order of 0.1 seconds in most cases and if you're lucky you get an estimated one in the order of 1 ms. But do most people care about 1 second? Or even 10 seconds? And if you do care about the accuracy, why don't you run ntp? Kurt From nobody Sun Jun 8 09:33:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E251A0092 for ; Sun, 8 Jun 2014 09:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bg7Elu8qjGdN for ; Sun, 8 Jun 2014 09:33:37 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE5F1A006B for ; Sun, 8 Jun 2014 09:33:36 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jz11so1360227veb.2 for ; Sun, 08 Jun 2014 09:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=+3pX7jvXUWw+LmGUxJiX7FfRp33ny8tyZSwahX5eUJ8=; b=pcLEjui5Nh3sMluo1C+MQB6ugETvZ1ZEYCaGLa1g61pCht6lGHXP9xS1L3u8ZngTJU 3vwe+kKRUM6BKapAecHOie3Sv3AxbPSoKs0OlaZXq8TGu4WKhfwpAnIkmqFZndC6fE8C B0dH70pVEzop3+1TLGIbVI34rKDWoQPGeoQw0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=+3pX7jvXUWw+LmGUxJiX7FfRp33ny8tyZSwahX5eUJ8=; b=D9c/UhspALLyd1wMu7svtTZT2QULe/DoGo48/kHKciZ0U/OIdkCl5lZeT0ZGhwxAgb dJT8EXSWiNTzFRCIs4RcSQOkQw5Ta5yfAZK9q9ylOvDRA5wt3SUe5LBNWQEWCwMruAyk VFAmo+edOjx90RGYhOsGKzrGPQmrOrNbfUOR4bcUqdVC8zpi6Jg+LmkZmlDfmD4Fp7dZ 3beVhh5pKcHLfRaPf5oMce27756P+X14Wxri+J2Rpnbtn0jH1NAWWWXVTT+92rVUndap vLs03kXutIXkCJqjaHib/QomcInBUvVklW+BunvprTSOAMlvWgSO/R+7CIxNogHXFwqQ FePw== X-Gm-Message-State: ALoCoQmx8tBx2jbbAVC7FJDrOaAvtJfI2eBlXvCCc3mVAvJ2nTpvndR3ccrRgF1YhE6R9v0PisAL X-Received: by 10.58.160.164 with SMTP id xl4mr18326482veb.38.1402245215794; Sun, 08 Jun 2014 09:33:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.106.39 with HTTP; Sun, 8 Jun 2014 09:33:15 -0700 (PDT) In-Reply-To: <20140608160354.GH27883@mournblade.imrryr.org> References: <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> <20140608160354.GH27883@mournblade.imrryr.org> From: Tom Ritter Date: Sun, 8 Jun 2014 12:33:15 -0400 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b6763b2f9cf9e04fb55a715 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZD3HYdPntuCU2RlYGUaqLroy9nk Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 16:33:38 -0000 --047d7b6763b2f9cf9e04fb55a715 Content-Type: text/plain; charset=ISO-8859-1 On 8 June 2014 12:03, Viktor Dukhovni wrote: > On Sun, Jun 08, 2014 at 01:10:47AM -0400, Tom Ritter wrote: > > > I don't understand what you mean by the OCSP server rejcting them. > > Well, the server was supposed to have stapled, so the OCSP server > could in principle (knowing the server's certificate requires > stapling) refuse to provide an unstapled response. Ah I see. The CA could reject OCSP requests for a certificate if they were a jerk (or the customer didn't pay). But the server's OCSP request looks the same as a browser client OCSP request absent any non-standard fingerprinting. The CA's server can't reject all OCSP requests, because the (web) server needs to make the requests. -tom --047d7b6763b2f9cf9e04fb55a715 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 8= June 2014 12:03, Viktor Dukhovni <viktor1dane@dukhovni.org>= wrote:
On Sun, Jun 08, 2014 at 01:1= 0:47AM -0400, Tom Ritter wrote:

> I don't understand what you mean by the OCSP server rejcting them.=

Well, the server was supposed to have stapled, so the OCSP server
could in principle (knowing the server's certificate requires
stapling) refuse to provide an unstapled response.

Ah I see. =A0The CA could reject OCSP requests for a certificate if= they were a jerk (or the customer didn't pay). =A0But the server's= OCSP request looks the same as a browser client OCSP request absent any no= n-standard fingerprinting. =A0The CA's server can't reject all OCSP= requests, because the (web) server needs to make the requests. =A0

-tom
--047d7b6763b2f9cf9e04fb55a715-- From nobody Sun Jun 8 09:41:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C5F1A0092 for ; Sun, 8 Jun 2014 09:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlsxJlmekePS for ; Sun, 8 Jun 2014 09:41:36 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44F21A0089 for ; Sun, 8 Jun 2014 09:41:35 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id k14so3793509wgh.18 for ; Sun, 08 Jun 2014 09:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BsnBQgUcMNNcCI8s7v1CR6YF8T319L2dUlhwCCCam5U=; b=XHxtpbOAX9oQP1k7Mm2qK1SOkwg3pxsPUfysxdpJ+lI4Iuooobc2ms8moiib4yc+Hm vU7uylmAyWPkvDdnSa9CTX6k3QaIVHgGBtjAORS6etMLLR51qdkWLWGghtNZ9DEe1HvM DulRA/obirgU1/BYtgYesd2TDLIVAlDE72Kg2XF5+2u0Je5Zvmx3Gn84e8REsVMYeSct 2WJbruw5niXpcgWHNfHVvYHwNsefGcPZ2o0kyQGMv85nk+QeyhJEKCQGtDWXVepIJsc3 DWRpGhe3ggeE52T1mjRSALeOUM+5dyhP7nixlvhhzGvwSAu6IMqwi0AURq0VopbaU+Ej 8/Vw== MIME-Version: 1.0 X-Received: by 10.180.72.243 with SMTP id g19mr22019327wiv.44.1402245694261; Sun, 08 Jun 2014 09:41:34 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Sun, 8 Jun 2014 09:41:34 -0700 (PDT) In-Reply-To: References: <53934B47.4090603@fifthhorseman.net> Date: Sun, 8 Jun 2014 09:41:34 -0700 Message-ID: From: Martin Thomson To: Jacob Appelbaum Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/K8FSyu8MQUisFu8GatpElnG5eXc Cc: "tls@ietf.org" Subject: Re: [TLS] No more GMT exposure in the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 16:41:37 -0000 On 7 June 2014 14:55, Jacob Appelbaum wrote: > The current 32bit field isn't accurate enough for replacing NTP. If we > can't make the time field useful for accurate secure time exchange - I > hope we'll remove all network visible distinguishers, even ones that > are currently useful for totally bizarre reasons. I think that I'd prefer erasure. But the idea of parasitically updating time is intriguing. I assume that you need some sort of out of band method for determining if the server has OK time in the first place. I know Google have some techniques for good time sync, but most servers have completely rubbish clocks. From nobody Sun Jun 8 09:43:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A3E1A0092 for ; Sun, 8 Jun 2014 09:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lneQnYLiRMgB for ; Sun, 8 Jun 2014 09:43:02 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 598DA1A0089 for ; Sun, 8 Jun 2014 09:43:02 -0700 (PDT) Received: from [173.75.83.174] (helo=Williams-MacBook-Pro.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WtgBQ-0004jv-Lt; Sun, 08 Jun 2014 12:43:00 -0400 Date: Sun, 8 Jun 2014 09:43:00 -0700 From: Bill Frantz To: Kurt Roeckx X-Priority: 3 In-Reply-To: <20140608101721.GA6189@roeckx.be> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec799f2358dd76db645854529c7512f7b522350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.174 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/r8oi5eb0dmBxFOi_h67iQ0SlBPQ Cc: tls@ietf.org Subject: Re: [TLS] No more GMT exposure in the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 16:43:04 -0000 On 6/8/14 at 3:17 AM, kurt@roeckx.be (Kurt Roeckx) wrote: >Anyway, how do you plan to deal with checking the status of the >certificate if you don't know what the current time is? It seems to be a poor policy to trust time information from a=20 server whose certificate you are trying to validate. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Truth and love must prevail | Periwinkle (408)356-8506 | over lies and hate. | 16345=20 Englewood Ave www.pwpconsult.com | - Vaclav Havel | Los Gatos,=20 CA 95032 From nobody Sun Jun 8 12:47:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68D91A037B for ; Sun, 8 Jun 2014 12:46:56 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_O7Jzf06Al0 for ; Sun, 8 Jun 2014 12:46:55 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF00D1A037F for ; Sun, 8 Jun 2014 12:46:54 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id b6so543443yha.40 for ; Sun, 08 Jun 2014 12:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Gq84zm/3Jr3oKhrhm0kxuibkxCWaD4JSIWnlmcpFv4A=; b=BJjlKUagq0rVDzS3zgMKzx6gPr/kpCujRSOUXXqlCyGVBD8gB++o1qqDh9CHTEacsg 5LzEz2zpIiMUUlxqXrX9QwStsEsW9OEBRO0/ZLzvkDxoaIm1TQJZVIZCoeGCoeJl7/YH bVHGZiHbcavYOlQtzZIHUrg9RJ5I/kfUw9F8Pf/r7+nnKZ2zJyH2N0qHHIKGGEu+gsjW FzznOHptcAJjZ2WSqcaY2Y8HShevMfB0K1fbWOP3MniPrfvayU4J7rLRr8Eof0rqQsyD vyHwVPu9RvOEG0YIoaYsKLFs7jUkCzA9mUh5Eg1Juuyd5U6t63BymyjxKciV10LJvLYO 3bFA== MIME-Version: 1.0 X-Received: by 10.236.1.229 with SMTP id 65mr3126184yhd.107.1402256814023; Sun, 08 Jun 2014 12:46:54 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Sun, 8 Jun 2014 12:46:53 -0700 (PDT) In-Reply-To: <20140608154901.GG27883@mournblade.imrryr.org> References: <20140608122758.GA10562@roeckx.be> <20140608154901.GG27883@mournblade.imrryr.org> Date: Sun, 8 Jun 2014 12:46:53 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3n2lAaSzpq-FlziczG_PGtQyGi4 Subject: Re: [TLS] Why there should not be a TLS 2.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 19:46:57 -0000 On Sun, Jun 8, 2014 at 8:49 AM, Viktor Dukhovni wrote: > On Sun, Jun 08, 2014 at 02:27:58PM +0200, Kurt Roeckx wrote: > >> I would imagine that the client would like to do a "please give me >> a tunnel to that hostname", and then get back some descriptor that >> it can use to talk to it. Please note that I say hostname, >> because I think that you can have several names each which it's >> own certificate on the same IP address. > > Yes, but stronger yet, one needs (ala GSSAPI + Kerberos, which for > all its limitations gets some things right) to be able to ask for > service@hostname, not just hostname. The underlying Kerberos > stack works with service/instance@REALM, which also makes sense. See also Ethos, where the network protocol authenticates services and users to each other. The kicker is services no longer need to authenticate users. > > We could define new DANE record formats for scalable public-key > cross realm authentication with Kerberos or a Kerberos-like system, > and DNSSEC for a suitably secure hostname->realm mapping. Or one could use a certificate format that supported this natively. The fact that TLS is (mostly) tied to X509 is a real shame when it comes to extending. Yes, you could define extensions for certificate type and use them: at some point SPKI may have been used this way. But as Viktor points out GSSAPI dominates this space (unfortunately: anonymous users are hard to rope in here). Sincerely, Watson Ladd > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Jun 8 15:19:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E67B1A03F2 for ; Sun, 8 Jun 2014 15:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwZnWwATa1JR for ; Sun, 8 Jun 2014 15:19:32 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F691A0192 for ; Sun, 8 Jun 2014 15:19:31 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id dc16so7206114qab.14 for ; Sun, 08 Jun 2014 15:19:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ijBsAeMiDKk3de1myBqONRXJBRUSeXo3U+FGLtyknzM=; b=dQS+ZtCS3MjH3GguHn0Hjo4eJrPk34BK/howiiELWNDB1ZdtzWtu+axo4tJOM7CYvu BNA7lYpgngEu2GwHvAkJDvCDCZyAtOvSZXD+Db0nhmgZX7Z6e2+4nHl9bteAg6wyhWVS PvYEPBej2+etgpHPnwWWjJCiDfxB840//66CKPaG15fv+f5J1O7SAoJlQh6IhuPtCGgb ZO0IDxbvOXXQpFyLiEweAL29cNoC63yEp9abqSzJ0GwnjovuQmidswetxF4X7h14qn63 dWSZG6lsUfSwLR9+EP61WZoX8GA3o0OPA0F+Tahc+8GTPHtEbsoIFr+zMirZJ/yTBi0o yqUQ== X-Gm-Message-State: ALoCoQnCT2LoJ8Ou6QAx0muqzs1vygMnVz8sDQy6lgqANdJIW5gt8I+ytaC3sJ7t4sLz0fMdjU7j MIME-Version: 1.0 X-Received: by 10.224.50.136 with SMTP id z8mr27981544qaf.66.1402265971057; Sun, 08 Jun 2014 15:19:31 -0700 (PDT) Received: by 10.140.100.205 with HTTP; Sun, 8 Jun 2014 15:19:30 -0700 (PDT) X-Originating-IP: [5.104.224.5] In-Reply-To: <20140608153936.GF27883@mournblade.imrryr.org> References: <53934B47.4090603@fifthhorseman.net> <20140608101721.GA6189@roeckx.be> <20140608153936.GF27883@mournblade.imrryr.org> Date: Sun, 8 Jun 2014 22:19:30 +0000 Message-ID: From: Jacob Appelbaum To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jCcjW0zGg91KIfcglJ5IeopMVE4 Subject: Re: [TLS] No more GMT exposure in the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 22:19:34 -0000 On 6/8/14, Viktor Dukhovni wrote: > On Sun, Jun 08, 2014 at 03:10:46PM +0000, Jacob Appelbaum wrote: > >> That sounds fine to me, sure. I admit, I haven't put a lot of thought >> into the format because it seems that most of the momentum is in >> removing anything meaningful from that field. > > A good thing. If the client wants a server time-stamp, it can ask > for it via an extension. What extension provides a time-stamp? I'd love to see a 64bit time stamp extension but I wasn't aware of such a thing. Is there such a thing or was that a different spec feature request? > >> In any case, having 64bits of timing information from a server would >> allow for a parasitic network time protocol that is as accurate as NTP >> to be built on top of TLS. I haven't checked but I believe Google >> still uses this to set clocks on ChromeOS. > > "As accurate as NTP" is a bold claim. NTP "accuracy" (as opposed > to precision which is a different beast entirely) comes from using > multiple sourcs a PLL to estimate round-trip delay and smooth out > noise, and when possible multiple sources, ... Sure, I understand how NTP (and SNTP and TLS) works. That is something that could be done with TLS and probably very easily with tlsdate. Using a phase locked loop isn't something that exclusively functions over UDP. In any case, I mean accuracy of detecting false tickers, ensuring hostile networks aren't able to tamper with results (only delaying or dropping them), as well as providing the precision provided by a given NTP server. The precision is possible if the TLS protocol is modified to provide the right data. At the moment, the best we can get as an IETF compliant trick is 32bits (of seconds since 1970). > > NTP runs over UDP which is less likely to be delayed, re-transmitted, ... I was told that part of why ChromeOS uses tlsdate is because UDP is often delayed, dropped, and sometimes outright blocked. Also, NTP punches a hole in a lot of firewalls that is hilariously dangerous for some NTP implementations. > > Attaining NTP "accuracy" over TLS, seems rather implausible. > I think "over" TLS is a weird statement. Have you seen how tlsdate works in practice? ( I often joke that tlsdate is stratum 11 but few people are fans of Spinal Tap these days. ) All the best, Jacob From nobody Sun Jun 8 15:27:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6187C1ACAD6 for ; Sun, 8 Jun 2014 15:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL=0.141] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6P3cGgOKwn4d for ; Sun, 8 Jun 2014 15:27:08 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA261A854C for ; Sun, 8 Jun 2014 15:27:08 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q108so7929732qgd.5 for ; Sun, 08 Jun 2014 15:27:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DCJHdoYn1GMDSifrJ5wVP4TaSNnAJULs9GGJWn4GDf8=; b=e8hrWw0CQcZvMzBNOMRwBtKyjdchVrPeFCqci9o4QLCn/YW/5GLp/3cdTmGlDNyOGx zExPrXRiL/RU6N3muMpXsQP5pVx3v90ij+x0l87SWoiKn3b5I9wplhyT2AE5p0b9TwZX Lz1tmepRCOKwZyseHcdZspNkvLXl25ApGBPDT99p3vFWSuyQX5clNCBxdMJzvMti6NL5 f/CPnii5t6879NCINuZan/6quvPPovhlX3YZ+BgjPWXECUgeEXRpo4QbYaFv4WVoj1NK S7tJopzQY4Y+i4aQBcASJrMCoZdBvdrh2ecloXK+aA7Rd9+7r6B4xjfhgXvawmll4w/q Ie+w== X-Gm-Message-State: ALoCoQmpW7Sx7BLf+1UCPkkLprXTUhMS780BJPNSKHWy0ugvXYiTuELeFmtWVw7pGVhO77Dh2Mdb MIME-Version: 1.0 X-Received: by 10.224.47.2 with SMTP id l2mr24200505qaf.85.1402266427627; Sun, 08 Jun 2014 15:27:07 -0700 (PDT) Received: by 10.140.100.205 with HTTP; Sun, 8 Jun 2014 15:27:07 -0700 (PDT) X-Originating-IP: [37.0.123.207] In-Reply-To: References: <20140608101721.GA6189@roeckx.be> Date: Sun, 8 Jun 2014 22:27:07 +0000 Message-ID: From: Jacob Appelbaum To: Bill Frantz Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XLTFg9YwcSZwd5YF4x0rBBtw8Qc Cc: "tls@ietf.org" Subject: Re: [TLS] No more GMT exposure in the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 22:27:09 -0000 On 6/8/14, Bill Frantz wrote: > On 6/8/14 at 3:17 AM, kurt@roeckx.be (Kurt Roeckx) wrote: > >>Anyway, how do you plan to deal with checking the status of the >>certificate if you don't know what the current time is? > > It seems to be a poor policy to trust time information from a > server whose certificate you are trying to validate. Isn't it worse to trust a network protocol without any cryptographic assurances at all? I think so... I also tend to think the right choice is to fix NTP but we'll almost always have this first leap of something. I'd prefer it not to be a mere leap of faith but rather a leap of cryptographic assertion pinned to a set of keys that I trust. Until the time that NTP is fixed to deal with hostile networks, we've got hundreds of thousands of SSL/TLS servers on the internet that serve mostly accurate time. All the best, Jacob From nobody Sun Jun 8 15:52:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584A51A041D for ; Sun, 8 Jun 2014 15:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0am0IGudJKx for ; Sun, 8 Jun 2014 15:52:01 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 379581AD62A for ; Sun, 8 Jun 2014 15:51:57 -0700 (PDT) Received: from [173.75.83.174] (helo=Williams-MacBook-Pro.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WtlwS-0008N5-V9; Sun, 08 Jun 2014 18:51:57 -0400 Date: Sun, 8 Jun 2014 15:51:56 -0700 From: Bill Frantz To: Jacob Appelbaum 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.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec794ff1a770b3ea9ee2301e26b17d11952f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.174 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Y2BF4i0b76Vz8WS4EGpm9kaAxC8 Cc: tls@ietf.org Subject: Re: [TLS] No more GMT exposure in the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 22:52:02 -0000 On 6/8/14 at 3:27 PM, jacob@appelbaum.net (Jacob Appelbaum) wrote: >On 6/8/14, Bill Frantz wrote: >>On 6/8/14 at 3:17 AM, kurt@roeckx.be (Kurt Roeckx) wrote: >> >>>Anyway, how do you plan to deal with checking the status of the >>>certificate if you don't know what the current time is? >> >>It seems to be a poor policy to trust time information from a >>server whose certificate you are trying to validate. > >Isn't it worse to trust a network protocol without any cryptographic >assurances at all? I think so... I also tend to think the right choice >is to fix NTP but we'll almost always have this first leap of >something. I'd prefer it not to be a mere leap of faith but rather a >leap of cryptographic assertion pinned to a set of keys that I trust. > >Until the time that NTP is fixed to deal with hostile networks, we've >got hundreds of thousands of SSL/TLS servers on the internet that >serve mostly accurate time. OK, after making a flip remark, now I need to actually think=20 about the requirements. For validating certificates (only): Time accuracy +- 24 hours or so. Trust in the time source. If I get my time from the server I'm validating, then continued=20 use of expired certificates is really easy. If I get it from a=20 separate NTP server,then the attack becomes harder, but someone=20 controlling my network traffic still has a relatively easy=20 problem. If I use almost any source of time, and verify big=20 jumps from my local clock with my user, the problem becomes=20 almost impossibly difficult. BTW, I have two devices, a radio and a Raspberry Pi, which have=20 internal clocks which are reset to zero at power on. These would=20 be vulnerable to the first two scenarios and not able to=20 implement the third scenario. Its a good thing my plans for them=20 don't involve network connections. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz |"Web security is like medicine - trying to=20 do good for 408-356-8506 |an evolved body of kludges" - Mark Miller www.pwpconsult.com | From nobody Sun Jun 8 18:25:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECAF1B279D for ; Sun, 8 Jun 2014 18:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKfAF-EA1Vbj for ; Sun, 8 Jun 2014 18:24:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8291B279C for ; Sun, 8 Jun 2014 18:24:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E59D92AB222; Mon, 9 Jun 2014 01:24:55 +0000 (UTC) Date: Mon, 9 Jun 2014 01:24:55 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140609012455.GN27883@mournblade.imrryr.org> References: <20140608122758.GA10562@roeckx.be> <20140608154901.GG27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MuMhRqfxO0swBkKNzvUmpg_ObKc Subject: Re: [TLS] Why there should not be a TLS 2.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 01:25:00 -0000 On Sun, Jun 08, 2014 at 12:46:53PM -0700, Watson Ladd wrote: > Yes, you could define extensions for certificate type and use them: at > some point SPKI may have been used this way. But as Viktor points out > GSSAPI dominates this space (unfortunately: anonymous users are hard > to rope in here). Kerberos has "kinit --anonymous" (Heimdal CLI syntax). The client principal is then (IIRC) WELLKNOWN/ANONYMOUS@REALM. In this context the KDC has a client-trusted public key issued by some suitable X.509 trust anchor (no DANE binding yet). -- Viktor. From nobody Sun Jun 8 18:51:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6367D1A026C for ; Sun, 8 Jun 2014 18:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdhQWUMcjf6O for ; Sun, 8 Jun 2014 18:51:49 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id EE1831A01E2 for ; Sun, 8 Jun 2014 18:51:48 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F00C92876B; Mon, 9 Jun 2014 01:51:47 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id DA9AE28769; Mon, 9 Jun 2014 01:51:47 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id A15258003C; Mon, 9 Jun 2014 01:51:47 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Sun, 8 Jun 2014 21:51:47 -0400 From: "Salz, Rich" To: Jeremy Rowley , "tls@ietf.org" Date: Sun, 8 Jun 2014 21:51:46 -0400 Thread-Topic: [TLS] OCSP must staple Thread-Index: AQJxv6HtmB9uk8Yt5wEeFHdRD1knoQEt2WjqAP+sMUYCHog9/QJH2PNTApX9AA0COSwKkwNalKqnAp4CcngB5F3w/QJ8kG4OAaygmc2ZZtBTsIABcG7Q Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434FB5@USMBX1.msg.corp.akamai.com> References: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> In-Reply-To: <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k1SdPj47ynfn2CxnCAueqZ8Otlw Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 01:51:52 -0000 > Any standard "trusts" that the implementers will do the right thing.=20 I don't recall any uptime requirements in any OCSP-related specs. > We already have people interested in using must staple upon adoption so t= his shouldn't be a factor in the adopting the draft. That's interesting you have customers interested in I, and that point is as= valid as mine saying I don't think our customers will be. But I didn't sa= y it to forestall adoption of the draft, sorry if I gave you that impressio= n. > Non-compliance by certain CAs is really irrelevant to whether OCSP Must S= taple should be adopted as a standard. I didn't say that, either :) I was just describing what I saw as a bigger = issue. And yes, it's completely orthogonal to OCSP; sorry if I wasn't clear= . /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Sun Jun 8 21:15:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359F41A0654 for ; Sun, 8 Jun 2014 21:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOsdZ4SBFcKV for ; Sun, 8 Jun 2014 21:15:11 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5C06E1A04AE for ; Sun, 8 Jun 2014 21:15:11 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id E542920047B59; Sun, 8 Jun 2014 21:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=LDCtzb3vKt0v4vIOvXnFmHnE4JA=; b=NS1WfV8qSffKvWURP +4J0mG29S3Sw3oiFQCdqyuy8tkHRlyJBcp2ad2THpPI2BSao1fS7Fvs0ZJi8T5Gt cj1aUTKjNZvzMeUZSeT0W6SxQ+baqU5NtAS95LMxBwFUMZiXZeYf02t9l68+W0gb YRITdMxvf6WHkshhaoBCO3FmR4= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id BEF4F20047B57; Sun, 8 Jun 2014 21:15:10 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Sun, 8 Jun 2014 21:15:10 -0700 Message-ID: <455964081e9c154c6a68781b35d87ba9.squirrel@webmail.dreamhost.com> In-Reply-To: References: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> Date: Sun, 8 Jun 2014 21:15:10 -0700 From: "Ryan Sleevi" To: "Tom Ritter" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1xLijw2Hk0Ay8vxygQ8kRmWAGDk Cc: "tls@ietf.org" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 04:15:12 -0000 On Sat, June 7, 2014 10:10 pm, Tom Ritter wrote: > While it looks some of the semantics of 'Must Staple', I think either > behavior could be acceptable for a client. Either closing the connect= ion > without attempting to contact a OCSP server, or switching to a 'Hard F= ail' > OCSP lookup. > > I can imagine some servers deciding that they would want clients to fa= il > if > they didn't send a staple, rather than leak the OCSP lookup to the CA.= I > could imagine other servers wanting to hedge their bets and have the > client > make an attempt before giving up. > > I don't understand what you mean by the OCSP server rejcting them. It's not really "must staple" if clients fall back to doing lookups, is it? It's more like "should consider staple" (RFC 6919) I would expect conforming clients to fail if must-staple is present but not stapled. This includes ignoring OCSP cached responses, and prevents online lookups. This interpretation is key among the reasons why Chrom{e/ium} has not (yet) begun experimenting with must staple, since the APIs used don't offer as much flexibility. However, that interpretation is exactly what ensures interoperability - these sorts of "soft fallbacks" cause a number of issues, as everyone in the TLS WG can attest to elsewhere (eg: TLS version rollback, AIA chasing, etc) From nobody Sun Jun 8 22:44:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F6B1B27E4 for ; Sun, 8 Jun 2014 22: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uity7YBfhpEL for ; Sun, 8 Jun 2014 22:44:11 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD791B27E5 for ; Sun, 8 Jun 2014 22:44:10 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id v10so4437568pde.23 for ; Sun, 08 Jun 2014 22:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=0NhdskUNmnhf4INhGnTGnDAuGLX26yAYIpo028ckb4Q=; b=YukgBkKawB7UDkzAKDkZS4eWdZ6On4M/z7xS/atvx0tmt92eMHhoxIwxmQ/BRtyZLA 536LDrSUiMQV5pX1wSXJyTBl5RPf6cjOxM3HmSoCVYiP+aLxtwIcstomxxOHDOFOCfkp aY8rhMesfZKjCALxAASHMP9Vnhk7tVOPuyr8DXEOmdcaLRmGidRLDqiVwgZUoGKegFaw oTsdmoMHPIW/DgFJqDIYOBxaW2laiieyBn1iiVgHIo5zt9jx3mpPzth6c6UP2+ZgoFDv LpAM41Z1espvDILO1xuoHI/hDGQT8Zctv4wF9QLgxhLUiNTHZSsUr4ECc5bdAVjvZfZ5 YAZQ== X-Received: by 10.66.231.40 with SMTP id td8mr2283101pac.103.1402292650452; Sun, 08 Jun 2014 22:44:10 -0700 (PDT) Received: from [192.168.254.10] (ip70-189-237-85.lv.lv.cox.net. [70.189.237.85]) by mx.google.com with ESMTPSA id ir10sm61771721pbc.59.2014.06.08.22.44.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Jun 2014 22:44:09 -0700 (PDT) Message-ID: <539549A8.1040008@gmail.com> Date: Sun, 08 Jun 2014 22:44:08 -0700 From: Kyle Hamilton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Salz, Rich" , tls@ietf.org References: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434FB5@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434FB5@USMBX1.msg.corp.akamai.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070709080107030001060507" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aQuq3jyXZsLy9_CO1UOQpqkAFQY Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 05:44:12 -0000 This is a cryptographically signed message in MIME format. --------------ms070709080107030001060507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 6/8/2014 6:51 PM, Salz, Rich wrote: >> We already have people interested in using must staple upon adoption s= o this shouldn't be a factor in the adopting the draft. > That's interesting you have customers interested in I, and that point i= s as valid as mine saying I don't think our customers will be. But I did= n't say it to forestall adoption of the draft, sorry if I gave you that i= mpression. > >> Non-compliance by certain CAs is really irrelevant to whether OCSP Mus= t Staple should be adopted as a standard. > I didn't say that, either :) I was just describing what I saw as a big= ger issue. And yes, it's completely orthogonal to OCSP; sorry if I wasn't= clear. > > /r$ I've had people tell me that they honestly believe that they're paying the CA for the OCSP and revocation bandwidth. This kind of viewpoint undermines any kind of mandate for any kind of "must staple".=20 Personally, I think this view is moderately short-sighted, as it relies on a third party to be available at all times (particularly with Firefox's "security.OCSP.require" configuration option). When I write protocols I include stapling as par for the course. On the other hand, I think that relying on a stapled response is perhaps shortsighted, as it potentially opens a window of vulnerability. Say the OCSP response is valid for 7 days (the maximum time that EV cert OCSP responses can be valid for): if the cert is revoked on day 2, that's still 5 and change days of potential validity. This is the kind of vulnerability that clients can use the OCSP nonce extension to protect themselves from, but it only works if it's used and queried from the OCSP responder by the client itself. Thus, the proposal to prevent clients from checking OCSP from the source in the presence of an "OCSP must staple" extension is harmful to user security and thus wrong-minded.= -Kyle H --------------ms070709080107030001060507 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKSDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFJjCCBA6gAwIBAgIRALbv5xh8RSMuXP9qrA/5ONAwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQw NjAzMDAwMDAwWhcNMTUwNjAzMjM1OTU5WjAjMSEwHwYJKoZIhvcNAQkBFhJhZXJvd29sZkBn bWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIrYxg/oIPfnNfvNCm OoctdpmYxFYygtJ7eHGCGyUvGnqaiNacsYgsvtfyyC3Hwq82Va9Sr2/y8+iPB/oAWPvlfJUO viFkCFsPBRsuRo8Iul6GElOiZSq9Q4PtVseJt9JK4cee8GPeD3kWIp0ynktDPW17XhOK8J4U Hrvn04Yaa6eK7nLDnsboaxRBHOZ1B/3qAWGznF5L/oQf0NV6rdz+v31CyOoZhvtldC9ooK3t q7Xve075VrnrkqM2HQe8Whg5J1Oo1TfNeqFWayZU9o0jK07oGv7wYsKHVc5FpIFZ8j9odB3J gM7hmtCYuwOMzqp0jxeQA38k2yqAxWHx1W/nAgMBAAGjggHiMIIB3jAfBgNVHSMEGDAWgBR6 E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUENa7REnXA37GDe/Ytjs6PmRVaE4wDgYD VR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQB sjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATAr MCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBO MEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNh dGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKG Rmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNv bTAdBgNVHREEFjAUgRJhZXJvd29sZkBnbWFpbC5jb20wDQYJKoZIhvcNAQEFBQADggEBADaN kVFmWQxIp1qk5r4R1WaTVb77fED2CFEihXNvIfJEWIdFKRtlfSAyCGQzarMxf5HMRjYi62Tl H4OMGUgc3Eult0EtdO/hFBz9lYNTQmi+uY6GZM7ZjXxkmHexycQoWR8fQg+w3UMkVKxEiVji OZOuer7R79KVw18rDZcQipSO/n/Zz4i5CAk1cC/kWnBcs3VOm+rr27gQrO0/QQfCjcRu0WE0 ymEHunnNm9F/vZbvBL4V+xxUvxrsR4JeQoePKCFprHnaVmuHHluZq5UPZNTRq7C5Q+T9YvYW e525UiAj1LD9eV58LWTurmayjoxYqaktJf4x9Og0h9Gz2mopU5sxggQcMIIEGAIBATCBqTCB kzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALbv5xh8RSMuXP9q rA/5ONAwCQYFKw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNjA5MDU0NDA4WjAjBgkqhkiG9w0BCQQxFgQU4Si8F5nIbNORE/JjXvpw u72BTXcwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCBugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAtu/nGHxFIy5c/2qsD/k40DCBvAYLKoZIhvcNAQkQAgsxgayg gakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQC27+cYfEUj Llz/aqwP+TjQMA0GCSqGSIb3DQEBAQUABIIBALkQxdKeTTDQKuXyOK4jJJMvPXaB6ZAMOmLe NRdnJCf3A9AeeyCXjH/XBuKqDhkLOV34S/XkWEl82oe34u3lzQqPcIIb1fKfPWqj+jsoEuc9 u7QfQlBosSdu8pD+TyHDFq9XgwAsM7nHiY1VDcYTth2+qpkA8UYsiQRsHHanrwQW4wyRuCyw FLOYa/PShdZFD9vkOk9GQa6mzIVQkzqk2vZD32FIvSqBt1DcUoHtRMEnBzh+FzrVBuHDfzHt JX9/tRcFyo3UH2Kwy9jZ3xH/+iZHvZBl7VbmOK2XT7cr3/bXKPpxx+wJbBppK31MdQZDo6gJ HC3haItmtTWJmz4KuagAAAAAAAA= --------------ms070709080107030001060507-- From nobody Sun Jun 8 22:54:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A471B27E9 for ; Sun, 8 Jun 2014 22:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2ztIkchSSEE for ; Sun, 8 Jun 2014 22:54:15 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C341B27E5 for ; Sun, 8 Jun 2014 22:54:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5F4BD2AB26D; Mon, 9 Jun 2014 05:54:14 +0000 (UTC) Date: Mon, 9 Jun 2014 05:54:14 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140609055414.GP27883@mournblade.imrryr.org> References: <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434FB5@USMBX1.msg.corp.akamai.com> <539549A8.1040008@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <539549A8.1040008@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MC5Oxxua3kXtUnGCtRG3CiGGM2g Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 05:54:17 -0000 On Sun, Jun 08, 2014 at 10:44:08PM -0700, Kyle Hamilton wrote: > On the other hand, I think that relying on a stapled response is perhaps > shortsighted, as it potentially opens a window of vulnerability. Say > the OCSP response is valid for 7 days (the maximum time that EV cert > OCSP responses can be valid for) The CA may well generate new CRLs (and associated OCSP responder state) once every 7 days. Otherwise the OCSP response TTL should be shorter, we should address the "right" problem. That said there is no "right" upper bound for revocation latency. Whatever "acceptable" limit you set, someone will always present an argument along the lines of: > if the cert is revoked on day 2, > that's still 5 and change days of potential validity. This is the kind > of vulnerability that clients can use the OCSP nonce extension to > protect themselves from, but it only works if it's used and queried from > the OCSP responder by the client itself. Thus, the proposal to prevent > clients from checking OCSP from the source in the presence of an "OCSP > must staple" extension is harmful to user security and thus wrong-minded. One must be willing to accept some risk, and buy certificates from a CA whose OCSP response validity interval poses an acceptable risk. We can debate whether 7 days for EV certs is too long or not, and whether it should be adjusted down to 2 days or 2 hours, but the fundamental problem remains, and is independent of "must staple". -- Viktor. From nobody Mon Jun 9 00:12:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFC61A01AC for ; Mon, 9 Jun 2014 00:12: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YViSJKTr3Hzk for ; Mon, 9 Jun 2014 00:12:52 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595C91A0142 for ; Mon, 9 Jun 2014 00:12:52 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so1437738wib.2 for ; Mon, 09 Jun 2014 00:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xK7q+leOvx5JmPCvF7cv5tSeCpKqjh6LJdFuy/Rg3ss=; b=VTt+2PRPhPaaoRbjKs90OcCBXoEz0oz+lydvWhMqUgJTUnzW7d4jbn441wbCpcVhrH cZ3kXBHODTT1zDUAmtNzwfWCvkUjsWTehlnotgUgsNWT6EMa7I/wgtbfyMrWKMXWlp0O vmwihC8TU10Pg5m2EcBgfrcKZ4dx3fPd33TYtR+jRaDLW/ccF6i/g8oRPrnEjCbMHSVG aOhz94MY4x1tUliZ+umvtSOpDzD/yoWwRMWQILLbBIDCifkdikYRVDpGeMNGAYl5LlWg M6iQsM8wjBcR7n/uJhw3MZjWVuPxS2getkchP5qgFhb8a+AuOX8dKWmOk6/FXri3a16b e8dw== X-Received: by 10.180.91.104 with SMTP id cd8mr26578495wib.0.1402297970864; Mon, 09 Jun 2014 00:12:50 -0700 (PDT) Received: from [172.24.249.169] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id ba9sm13019157wib.24.2014.06.09.00.12.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 00:12:50 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: <539549A8.1040008@gmail.com> Date: Mon, 9 Jun 2014 10:12:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434FB5@USMBX1.msg.corp.akamai.com> <539549A8.1040008@gmail.com> To: Kyle Hamilton X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fdoy2AuWPGJq0-JsJdfqZZTpFlw Cc: tls@ietf.org Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 07:12:54 -0000 On Jun 9, 2014, at 8:44 AM, Kyle Hamilton wrote: >=20 > On the other hand, I think that relying on a stapled response is = perhaps > shortsighted, as it potentially opens a window of vulnerability. Say > the OCSP response is valid for 7 days (the maximum time that EV cert > OCSP responses can be valid for): if the cert is revoked on day 2, > that's still 5 and change days of potential validity. This is the = kind > of vulnerability that clients can use the OCSP nonce extension to > protect themselves from, but it only works if it's used and queried = from > the OCSP responder by the client itself. Thus, the proposal to = prevent > clients from checking OCSP from the source in the presence of an "OCSP > must staple" extension is harmful to user security and thus = wrong-minded. I think one of the points of =93must staple=94 is that it allows the CA = to shorten the TTL without having its OCSP responder overwhelmed with = traffic from clients. Yoav= From nobody Mon Jun 9 00:24:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFAC1A0004 for ; Mon, 9 Jun 2014 00:24: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3Zl2O9bT1sU for ; Mon, 9 Jun 2014 00:24:31 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B559D1A0002 for ; Mon, 9 Jun 2014 00:24:31 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id bj1so465289pad.3 for ; Mon, 09 Jun 2014 00:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=Ie+hEHO94QcEG/lWun7qpf7xsM0LNezl1H7N87YkXKg=; b=p9/FixMc4zWlHSuJ+41m9y9nYsgtzSBR/hUtpq7OUVf+wYhgDHAKVP+HxsY15IAa+/ yIUFZd9hB5Agm7iucNV14ESHMj7iaxqnMlVKGdltyNIc+PHXxkZLK5JzgB5pynB1pjdC IYM+N61KXfXjBm2fOrs4ba8hMuS3n3/v2FNwnGe2sMjFBq+LJApzO4kpB5afKuQEdf/8 ShJBcOk7Q50QDO2Gm0yseDczZuRaBzf1CxbiZryux7hEsNjwx+Abpbo+ZxLFRGOcBgwY jsXa9FA/G15CfVJGWD/hr1tAbmUOlqpsvlRzVkEvTZv85p0YC4tWbkCSw5dTmKcPd1dC ITuw== X-Received: by 10.66.219.6 with SMTP id pk6mr2951891pac.9.1402298671433; Mon, 09 Jun 2014 00:24:31 -0700 (PDT) Received: from [192.168.254.10] (ip70-189-237-85.lv.lv.cox.net. [70.189.237.85]) by mx.google.com with ESMTPSA id ak1sm62300932pbc.58.2014.06.09.00.24.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 00:24:30 -0700 (PDT) Message-ID: <5395612C.4080705@gmail.com> Date: Mon, 09 Jun 2014 00:24:28 -0700 From: Kyle Hamilton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434FB5@USMBX1.msg.corp.akamai.com> <539549A8.1040008@gmail.com> <20140609055414.GP27883@mournblade.imrryr.org> In-Reply-To: <20140609055414.GP27883@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080609000309080704020203" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JpiiBO8f2_fF7dOMn0doL0E4PgA Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 07:24:33 -0000 This is a cryptographically signed message in MIME format. --------------ms080609000309080704020203 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 6/8/2014 10:54 PM, Viktor Dukhovni wrote: > On Sun, Jun 08, 2014 at 10:44:08PM -0700, Kyle Hamilton wrote: > >> On the other hand, I think that relying on a stapled response is perha= ps >> shortsighted, as it potentially opens a window of vulnerability. Say >> the OCSP response is valid for 7 days (the maximum time that EV cert >> OCSP responses can be valid for) > The CA may well generate new CRLs (and associated OCSP responder > state) once every 7 days. Otherwise the OCSP response TTL should > be shorter, we should address the "right" problem. My assumption is that a new OCSP response SHALL be generated when the certificate's status changes, because it is up to the CA to provide authoritative information about records held by the CA. In other words, by not generating a new OCSP response when a certificate is revoked, the CA becomes complicit to any fraud done with that certificate until the old OCSP response expires. And, this completely ignores OCSP capacity to request a signature over a nonce. > That said there is no "right" upper bound for revocation latency. > Whatever "acceptable" limit you set, someone will always present > an argument along the lines of: >> if the cert is revoked on day 2, >> that's still 5 and change days of potential validity. This is the kin= d >> of vulnerability that clients can use the OCSP nonce extension to >> protect themselves from, but it only works if it's used and queried fr= om >> the OCSP responder by the client itself. Thus, the proposal to preven= t >> clients from checking OCSP from the source in the presence of an "OCSP= >> must staple" extension is harmful to user security and thus wrong-mind= ed. > One must be willing to accept some risk, and buy certificates from a > CA whose OCSP response validity interval poses an acceptable risk. One must also be able to set the level of risk that they accept. You're saying that there is a legal way that this can be taken out of their hands by the CA or by "common practice". The specifications appear to permit a means by which this risk can be short-circuited; however, you're asserting that "one must be willing to accept some risk", and thus apparently applying a "MUST NOT attempt to reduce risk beyond the CA's normally-provided limits" requirement. > We can debate whether 7 days for EV certs is too long or not, and > whether it should be adjusted down to 2 days or 2 hours, but the > fundamental problem remains, and is independent of "must staple". I used EV certificates only as an example. (I do believe that 7 days for EV is "too long", but that's beside the point.) I do agree that the fundamental problem remains, but the reason I don't see that it's independent of "must staple" is in light of your earlier assertion that "Well, the server was supposed to have stapled, so the OCSP server could in principle (knowing the server's certificate requires stapling) refuse to provide an unstapled response." in explanation of Yoaf Nir's query (paraphrased) "if the client tries the OCSP server on a must-staple certificate, will the OCSP server reject the= m?" Hypothetically speaking, that kind of back-end manipulation of "you can only have this much assurance" would make me not want to do business with anyone who insists on doing business with that CA; but, chances are (particularly for CAs for larger sites) I would quite often be forced to. I wish we had a means to present multiple certificate chains terminating in multiple end-entity certificates of multiple keys, all of which signed the single key presented and evidenced by the TLS peer.=20 That way, any individual CA's policy to limit one's ability to reduce one's risk would be mitigated by the policies of other CAs that the site might decide to hire. But this has now gone far afield from "must staple". -Kyle H --------------ms080609000309080704020203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKSDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFJjCCBA6gAwIBAgIRALbv5xh8RSMuXP9qrA/5ONAwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQw NjAzMDAwMDAwWhcNMTUwNjAzMjM1OTU5WjAjMSEwHwYJKoZIhvcNAQkBFhJhZXJvd29sZkBn bWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIrYxg/oIPfnNfvNCm OoctdpmYxFYygtJ7eHGCGyUvGnqaiNacsYgsvtfyyC3Hwq82Va9Sr2/y8+iPB/oAWPvlfJUO viFkCFsPBRsuRo8Iul6GElOiZSq9Q4PtVseJt9JK4cee8GPeD3kWIp0ynktDPW17XhOK8J4U Hrvn04Yaa6eK7nLDnsboaxRBHOZ1B/3qAWGznF5L/oQf0NV6rdz+v31CyOoZhvtldC9ooK3t q7Xve075VrnrkqM2HQe8Whg5J1Oo1TfNeqFWayZU9o0jK07oGv7wYsKHVc5FpIFZ8j9odB3J gM7hmtCYuwOMzqp0jxeQA38k2yqAxWHx1W/nAgMBAAGjggHiMIIB3jAfBgNVHSMEGDAWgBR6 E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUENa7REnXA37GDe/Ytjs6PmRVaE4wDgYD VR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQB sjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATAr MCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBO MEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNh dGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKG Rmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNv bTAdBgNVHREEFjAUgRJhZXJvd29sZkBnbWFpbC5jb20wDQYJKoZIhvcNAQEFBQADggEBADaN kVFmWQxIp1qk5r4R1WaTVb77fED2CFEihXNvIfJEWIdFKRtlfSAyCGQzarMxf5HMRjYi62Tl H4OMGUgc3Eult0EtdO/hFBz9lYNTQmi+uY6GZM7ZjXxkmHexycQoWR8fQg+w3UMkVKxEiVji OZOuer7R79KVw18rDZcQipSO/n/Zz4i5CAk1cC/kWnBcs3VOm+rr27gQrO0/QQfCjcRu0WE0 ymEHunnNm9F/vZbvBL4V+xxUvxrsR4JeQoePKCFprHnaVmuHHluZq5UPZNTRq7C5Q+T9YvYW e525UiAj1LD9eV58LWTurmayjoxYqaktJf4x9Og0h9Gz2mopU5sxggQcMIIEGAIBATCBqTCB kzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALbv5xh8RSMuXP9q rA/5ONAwCQYFKw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNjA5MDcyNDI4WjAjBgkqhkiG9w0BCQQxFgQUDKtnjtQu/yuhMtU5Fzo4 21vHFo8wbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCBugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhEAtu/nGHxFIy5c/2qsD/k40DCBvAYLKoZIhvcNAQkQAgsxgayg gakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQC27+cYfEUj Llz/aqwP+TjQMA0GCSqGSIb3DQEBAQUABIIBAKYUx6wJ5Qsqna/NG3uABfft8inXLqrunmQ8 T2UGtx8I+1jUwWnpczCuVXuZy9tE5I+ihknUel+Y5ki1p8WTdqI4fjLg9AuS8uaj60Aej3NT ADxBDDgk2QRAz2oUSnFXGn0U4ucC7iZziz9P03PIm5s3BAvjkEPNDWY5vztLuhuo5idMIcd0 OLW/LHVAsy9iwuOIUri5jOjaK3812Tswya3KEHVSu3oMyr4u6+TowQ6FJct8q7UG0jaxx2yP A8ZCcEWv0yalnjaBnhwUBy7y4CZveUA6aGncLeMyrWfHd1rDoFiZUhB5Dr9Qo+OJ7V0Sr5jI ag+eR26UhY+nOcyAlF8AAAAAAAA= --------------ms080609000309080704020203-- From nobody Mon Jun 9 00:34:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D4D1A0005 for ; Mon, 9 Jun 2014 00:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.654 X-Spam-Level: X-Spam-Status: No, score=-5.654 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yikFm1lDlenC for ; Mon, 9 Jun 2014 00:34:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3F41A0002 for ; Mon, 9 Jun 2014 00:34:23 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s597YM7p026697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 9 Jun 2014 03:34:22 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s597YKIu024401 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 03:34:22 -0400 Message-ID: <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla Date: Mon, 09 Jun 2014 09:34:20 +0200 In-Reply-To: References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ki92ZgEMsGQCpNihAK44VtrOj2A Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 07:34:24 -0000 On Sat, 2014-06-07 at 08:41 -0700, Eric Rescorla wrote: > > separate "TLS Record Protocol" (Section 6) and "TLS Handshaking > Protocols" (Section 7) with the handshake protocol establishing a > Master Secret for the entire session which is then used to derive > distinct record keys every time you reconnect (resume) in the same > session, with diversity provided by the random values. So, arguably, > TLS already behaves this way, with the exception of dealing with > cryptographic exhaustion of the transport keys (e.g., GCM counter > rollover). > MT's basic suggestion is to fix the cryptographic exhaustion Could somebody elaborate on what is that issue and why does it need to be solved? (it is not even mentioned in the TLS 1.3 charter) As someone who follows the mailing list that proposal comes out of the blue with no context whatsoever. regards, Nikos From nobody Mon Jun 9 07:57:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F591A01D5 for ; Mon, 9 Jun 2014 07:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaJwub1alY-i for ; Mon, 9 Jun 2014 07:57:30 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D1A1A01C2 for ; Mon, 9 Jun 2014 07:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4781; q=dns/txt; s=iport; t=1402325850; x=1403535450; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wE+mAbYoyxTgd+l67/lufw8g/MEBf+khGTaLYR+3Tv4=; b=CEGmhQS9tHArENxPDEC6L55+V7IBDTCYVKTNrRFvbfX3fy8pPEqQ9A14 3Xp/1tuUcD8KGAnD0BFO3DLgDIR5yaatlm8bY4ogKVXTmXoUMEj8Eocwr JFWZmim+ImD+FkxiUV4fgpKkII4Icy6TQ+ned2abxDyv+dTYZKzNpZ1Ur 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwLAFvKlVOtJV2P/2dsb2JhbABZgw1SWapkBQGRVIc8AYERFnWEAwEBAQMBAQEBNzQCCQULAgEINhAnCyUCBA4FiDoIDcp/F4VdiDshMweDK4EWBJohgUKSA4M8gi8 X-IronPort-AV: E=Sophos;i="4.98,1002,1392163200"; d="scan'208";a="331697592" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP; 09 Jun 2014 14:57:29 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s59EvTEj016850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Jun 2014 14:57:29 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.225]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 9 Jun 2014 09:57:28 -0500 From: "Joseph Salowey (jsalowey)" To: "tls@ietf.org" Thread-Topic: [TLS] Why there should not be a TLS 2.0 Thread-Index: AQHPgZ0BKVDNb367OUq6Hxi/1wjpMptpNtgA Date: Mon, 9 Jun 2014 14:57:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PPzJ1riW7Zw2T_rGHfcprY3tarQ Cc: Phillip Hallam-Baker Subject: Re: [TLS] Why there should not be a TLS 2.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 14:57:32 -0000 Hi Folks, This working group is chartered to work on TLS. While there are many thin= gs to talk about that are not TLS, they do not belong on this list. You may= send an announcement for a place to discuss other related work that is not= TLS to the list, but the discussion should be handled off the TLS list. = =20 Thanks, Joe=20 [For the Chairs] On Jun 5, 2014, at 6:27 AM, Phillip Hallam-Baker wr= ote: > There was discussion of TLS 2.0 in London. As I have been thinking > about it further I think it is the wrong direction entirely. Rather > than thinking about a TLS 2.0 we should look at a new scheme that is > the next generation of IPSEC, TLS and WS-Security. While this might > sound fantastically hard, it is in fact more practical than TLS 2.0 > and has far better deployment prospects. >=20 > The immediate problem that has me thinking this way is Private-DNS > which is my proposal to provide encryption and integrity protections > for DNS which is itself built on technology that I developed to > provide the JSON/REST world with the same security features as WS-* in > a draft of 25 pages or less (done). >=20 >=20 > First lets look at the current situation. We have IPSEC and TLS > deployed. They are both enormously complicated and adopt completely > different design approaches, different encodings and different key > exchanges. But 90% of the underlying technology is identical: IPSEC > and TLS both deliver a secure tunnel between endpoints. >=20 > The only point at which IPSEC and TLS differ as a result of their > function is in the application to the communication medium. IPSEC is > applied at the IP packet layer, TLS is applied to the TCP stream. And > that is all the difference there is. There is no reason that a > protocol can't have one key exchange mechanism to serve both purposes. > The success of TLS VPNs and SSH tunneling demonstrates that this is > the case. >=20 >=20 > So rather than thinking about TLS 2.0, I think we should instead > consider the problem of establishing a security context separately > from the problem of how to apply that context to a communication > medium. Once that separation is made we can apply it at the packet, > transport and application levels. Instead of TLS/2.0 we should be > thinking about IPSEC/2.0 and HTTP-SEC. >=20 > Factoring out the key exchange has other major advantages. It makes a > three legged 'Kerberos style' interaction possible as well (or even > four legged). the machine that performs the public key crypto needed > to establish the security context does not need to be the same as the > machine that uses the security context. >=20 > This means that instead of an SSL accelerator box having to be > strapped into the middle of my communication path as a pipe, it can be > a separate server. Most boxes are more than capable of doing AES and > SHA-2-256 without impacting server performance. It is the public key > cryptography that is the problem, especially because each operation is > quite significant. >=20 > Kerberos does a lot of things right which is why people still use it. > But right now it is a separate world to TLS. A convergence of TLS and > Kerberos would be much more useful. >=20 >=20 > At the moment I am relying on TLS to secure the confidentiality and > integrity of the security context exchange in SXS-Connect: >=20 > http://tools.ietf.org/html/draft-hallambaker-wsconnect-08 >=20 > A security context consists of >=20 > * A session identifier (opaque series of octets) > * Algorithm choices (e.g. AES-128 + SHA-2-256) > * A shared master secret > * Expiry/invalidity information (when to stop using, renegotiate, etc) >=20 > The size of the session identifier can be between 0 and 255 bytes > depending on how much state the issuer needs and how much of that > state is to be encoded into the identifier. >=20 > So identifiers might be >=20 > * 0 bytes - implicit in the IP Address and Port. > * 8 bytes - just a key. > * 24 bytes - is sufficient for a minimal stateless server scheme. > * 64 bytes - what my code uses for a stateless server scheme. > * 128 bytes - what my code uses during initial negotiation of a > security context. >=20 > Obviously, the lower down you are in the stack, the greater the > overhead of a large session ID. But giving this tradeoff to the issuer > allows the tradeoff to be made depending on specific needs at a > specific installation rather than making it a global tradeoff decided > by a Working Group with no knowledge of the particular requirements. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jun 9 08:03:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD561A0102 for ; Sun, 8 Jun 2014 11:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.477 X-Spam-Level: X-Spam-Status: No, score=-0.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_NUMERIC_HELO=1.164, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5jdWz2VmpKE for ; Sun, 8 Jun 2014 11:17:58 -0700 (PDT) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8101A00F8 for ; Sun, 8 Jun 2014 11:17:58 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WthfI-0005Sa-M4 for tls@ietf.org; Sun, 08 Jun 2014 20:17:56 +0200 Received: from 66.87.113.213 ([66.87.113.213]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Jun 2014 20:17:56 +0200 Received: from eternaleye by 66.87.113.213 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Jun 2014 20:17:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: tls@ietf.org From: Alex Elsayed Date: Sun, 08 Jun 2014 11:17:42 -0700 Lines: 56 Message-ID: References: <53934B47.4090603@fifthhorseman.net> <20140608101721.GA6189@roeckx.be> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 66.87.113.213 User-Agent: KNode/4.13.1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VSnYHT7mNbkeUZceoF2XXMMaTZ0 X-Mailman-Approved-At: Mon, 09 Jun 2014 08:03:00 -0700 Subject: Re: [TLS] No more GMT exposure in the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 18:18:00 -0000 Kurt Roeckx wrote: > On Sat, Jun 07, 2014 at 09:55:23PM +0000, Jacob Appelbaum wrote: >> On 6/7/14, Daniel Kahn Gillmor wrote: >> > On 06/07/2014 10:56 AM, Watson Ladd wrote: >> >> Putting the clock time in the TLS handshake enables fingerprinting. >> >> It's useless cryptographically: 32 random bytes is exceedingly >> >> unlikely to repeat. >> > >> > There seems to be a growing consensus on this point: >> > >> > https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime >> > >> >> I've said as much to Nick and to Eric (in the context of working on >> tlsdate[0]) but perhaps not on this tls list: >> >> I'd like to see servers provide 64bits of time resolution in the >> ServerHello and nothing but randomness in that field in the >> ClientHello. >> >> The current 32bit field isn't accurate enough for replacing NTP. If we >> can't make the time field useful for accurate secure time exchange - I >> hope we'll remove all network visible distinguishers, even ones that >> are currently useful for totally bizarre reasons. > > Would that be in the same format as NTP, with 32 bit for the > seconds and 32 bit for fractional second, and so a resolution > of 0.2 nano seconds? I'm wondering what kind of accuracy you'll > get. > > Anyway, how do you plan to deal with checking the status of the > certificate if you don't know what the current time is? 32 bit seconds in new protocols is probably not a good idea, as Linux/BSD/etc are having to deal with now - 2^32 seconds is a bit over 136 years, and while this use case will be unsigned (since it won't need to represent pre-epoch values, which cut time_t down to ~68 years) you're still going to run into something semantically identical to the Y2K38 problem. When that happens depends on what you pick as your epoch. If you use it to transmit GPS time using that epoch, or UTC using the Unix epoch, then you will have some real problems. The BSDs are switching wholesale to 64-bit tv_sec and 32-bit tv_nsec as I understand it; Linux is in the process of doing the same (but with stricter procedures on what's allowed to change ABI). Similarly, you also probably want to consider exactly what time base you use - UTC brings in the mess of leap seconds, TAI avoids them but is subtly different and may surprise implementers who don't realize that. In the end, I'd want to just chop it out - overloading TLS as a time-syncing protocol looks like the makings of a mess to me, since time handling is already quite messy. From nobody Mon Jun 9 08:08:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22851A01BA for ; Mon, 9 Jun 2014 08:08:31 -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, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjjyVSlV6osu for ; Mon, 9 Jun 2014 08:08:29 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FA811A01BF for ; Mon, 9 Jun 2014 08:08:29 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 4B5CF1C20BA; Mon, 9 Jun 2014 17:08:27 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 09E771FE01B4; Mon, 9 Jun 2014 17:08:26 +0200 (CEST) Date: Mon, 9 Jun 2014 17:08:26 +0200 From: Kurt Roeckx To: Alex Elsayed Message-ID: <20140609150826.GA9849@roeckx.be> References: <53934B47.4090603@fifthhorseman.net> <20140608101721.GA6189@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PXGoU4n3x3oGABrUPmnAQW7z2B8 Cc: tls@ietf.org Subject: Re: [TLS] No more GMT exposure in the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 15:08:32 -0000 On Sun, Jun 08, 2014 at 11:17:42AM -0700, Alex Elsayed wrote: > Kurt Roeckx wrote: > > > On Sat, Jun 07, 2014 at 09:55:23PM +0000, Jacob Appelbaum wrote: > >> On 6/7/14, Daniel Kahn Gillmor wrote: > >> > On 06/07/2014 10:56 AM, Watson Ladd wrote: > >> >> Putting the clock time in the TLS handshake enables fingerprinting. > >> >> It's useless cryptographically: 32 random bytes is exceedingly > >> >> unlikely to repeat. > >> > > >> > There seems to be a growing consensus on this point: > >> > > >> > https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime > >> > > >> > >> I've said as much to Nick and to Eric (in the context of working on > >> tlsdate[0]) but perhaps not on this tls list: > >> > >> I'd like to see servers provide 64bits of time resolution in the > >> ServerHello and nothing but randomness in that field in the > >> ClientHello. > >> > >> The current 32bit field isn't accurate enough for replacing NTP. If we > >> can't make the time field useful for accurate secure time exchange - I > >> hope we'll remove all network visible distinguishers, even ones that > >> are currently useful for totally bizarre reasons. > > > > Would that be in the same format as NTP, with 32 bit for the > > seconds and 32 bit for fractional second, and so a resolution > > of 0.2 nano seconds? I'm wondering what kind of accuracy you'll > > get. > > > > Anyway, how do you plan to deal with checking the status of the > > certificate if you don't know what the current time is? > > 32 bit seconds in new protocols is probably not a good idea, as > Linux/BSD/etc are having to deal with now - 2^32 seconds is a bit over 136 > years, and while this use case will be unsigned (since it won't need to > represent pre-epoch values, which cut time_t down to ~68 years) you're still > going to run into something semantically identical to the Y2K38 problem. > When that happens depends on what you pick as your epoch. Please note that NTP also uses the 32 bit for seconds, but has a concept of era's. You basicly need to know that it's not 136 years ago or in the future. Kurt From nobody Mon Jun 9 09:26:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAF21A0264 for ; Mon, 9 Jun 2014 09:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l59ZHp3261xa for ; Mon, 9 Jun 2014 09:26:27 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56101A026E for ; Mon, 9 Jun 2014 09:26:26 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q58so2543077wes.30 for ; Mon, 09 Jun 2014 09:26:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QkuhK70BQRBNwBrMpeokVsFAoW0ITbnNl3aGkJ9kZWQ=; b=FqRcU3goFuvjYwqXdJ99GJwQVVRHT1Bbxi9h/Gq8xNbBBeNRDyOAABb8gS7AZ9fp+k G9gs6xP9vjugxCGGyIWwNjTsqS9cj9SyRKdjuVEcjLm91VH75Bx/N/Xc/F+5BExJxwjd gepMfdREyPUgZnxMK0d/4zYLrEu8K8K9lJrOWcG/UBBksW1OIfay6Q0rxpqWGsMpQhPP G4czuS6epTPhPL2fhIJ6x9OD3DBJae/OfQdg1czddCEIqpVDBMmKoRBusInW5DNLkDzw HL5p0gLZl6H31lsV8p+dU5FOywfu2UkoKgEA9MHeuFMbE4lkFwIvjez30UMKAMj/DNk2 FhZA== X-Gm-Message-State: ALoCoQm2cHxx1KBlbIPmBp2ajW9NI1q6xmKRXMch4UAjJsRYGBLqcNrvXifHqyjdwvBSNOEt0BbD X-Received: by 10.194.187.107 with SMTP id fr11mr32440007wjc.70.1402331184961; Mon, 09 Jun 2014 09:26:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Mon, 9 Jun 2014 09:25:44 -0700 (PDT) X-Originating-IP: [63.245.221.34] In-Reply-To: <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> References: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> From: Eric Rescorla Date: Mon, 9 Jun 2014 09:25:44 -0700 Message-ID: To: "Joseph Salowey (jsalowey)" Content-Type: multipart/alternative; boundary=047d7bb03f6023324104fb69acf9 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DT_i9WiLMGjEOERRHhi4gkPG638 Cc: "" Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 16:26:28 -0000 --047d7bb03f6023324104fb69acf9 Content-Type: text/plain; charset=UTF-8 Per the direction below I have made the appropriate edits as a pull request: https://github.com/tlswg/tls13-spec/pull/44. I'll merge it in on Wednesday. Please let me know before then if this seems substantially wrong. As usual, minor editorial issues can be done by pull requests. Note that the changes here were a little more involved and left a few loose ends (e.g. issue #10). I'd like to try to handle any other loose ends people find as separate issues if possible. Thanks, -Ekr On Sat, Apr 26, 2014 at 8:24 AM, Joseph Salowey (jsalowey) < jsalowey@cisco.com> wrote: > The consensus from the IETF-89 meeting holds, TLS 1.3 will only use record > layer protection of type AEAD. The Editor is requested to make the > appropriate changes to the draft on github. > > Joe > [For the chairs] > On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) < > jsalowey@cisco.com> wrote: > > > TLS has supported a number of different cipher types for protecting the > record layer. In TLS 1.3 these include Stream Cipher, CBC Block Cipher > and AEAD Cipher. The construction of the CBC mode within TLS has been > shown to be flawed and stream ciphers are not generally applicable to DTLS. > Using a single mechanism for cryptographic transforms would make security > analysis easier. AEAD ciphers can be constructed from stream ciphers and > block ciphers and are defined as protocol independent transforms. The > consensus in the room at IETF-89 was to only support AEAD ciphers in TLS > 1.3. If you have concerns about this decision please respond on the TLS > list by April 11, 2014. > > > > Thanks, > > > > Joe > > [Speaking for the TLS chairs] > > _______________________________________________ > > 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 > --047d7bb03f6023324104fb69acf9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Per the direction below I have made the appropriate edits = as a pull request:

= I'll merge it in on Wednesday. Please let me know before then if
<= div style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px"> this seems substantially wrong. As usual, minor editorial issues
= can be done by=C2=A0pull=C2=A0requ= ests.

Note that the changes here were a little more involved and left a=
few loose ends (e.g. issue #10). I'd like to try to handle any other
loose ends people find as separate issues if possible.

Thanks,
-Ekr



On = Sat, Apr 26, 2014 at 8:24 AM, Joseph Salowey (jsalowey) &= lt;jsalowey@cisco.c= om> wrote:
The consensus from the IETF-89 meeting holds, TLS 1.3 will= only use record layer protection of type AEAD. The Editor is requested to = make the appropriate changes to the draft on github.

Joe
[For the chairs]
On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) <jsalowey@cisco.com> wrote:

> TLS has supported a number of = different cipher types for protecting the record layer. =C2=A0 In TLS 1.3 t= hese include Stream Cipher, CBC Block Cipher and AEAD Cipher. =C2=A0The con= struction of the CBC mode within TLS has been shown to be flawed and stream= ciphers are not generally applicable to DTLS. Using a single mechanism for= cryptographic transforms would make security analysis easier. =C2=A0 AEAD = ciphers can be constructed from stream ciphers and block ciphers and are de= fined as protocol independent transforms. =C2=A0The consensus in the room a= t IETF-89 was to only support AEAD ciphers in TLS 1.3. If you have concerns= about this decision please respond on the TLS list by April 11, 2014.
>
> Thanks,
>
> Joe
> [Speaking for the TLS chairs]
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

--047d7bb03f6023324104fb69acf9-- From nobody Mon Jun 9 10:00:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658CD1A0274 for ; Mon, 9 Jun 2014 10:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Br_B1-DsPnyw for ; Mon, 9 Jun 2014 10:00:01 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F701A01EF for ; Mon, 9 Jun 2014 10:00:01 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id x13so951600qcv.2 for ; Mon, 09 Jun 2014 10:00:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ad/bI76DgEgBAmyykwTzNNIDa2TgU1vSh2mj8Y55JOY=; b=BEb2S3LYE5JAXMaKVZg6nljmJVd5gtYQQnAHqbHBQydK4r5bx8GINN23ZSyRQaEKOa mIKHQIBB32tfK1M7bTZ2zhB8tYYbbaJzQ6gcqcGtFWjWJrOFq6INWp5IKogQv4nqY+e+ 41G9+3uKbzAJt4GNQ2SThzp/0XAJNB/Df3WtIEuidVmngk36UjWRtLoc1pRopJawPw2G AiKdGfuP9Pa9emLRsndOA61NzRQC+tmzvjoSn4O1/u4Sg879373kRUy1HwcZ+S57z/fw SfgO9AUEIzLJaiRO6Z1QyxH7fep2dJhPfx/eFmUoj5eQ4PdV9E5CJu1hsdqDCRvnb1sc X1qA== X-Gm-Message-State: ALoCoQmtP8urGHcvim8oL+t6VrCxrYnkUJORYot8iZXvx+gWciQ7TwuVLWh/ieICIW4QgmaFBTFv X-Received: by 10.229.227.5 with SMTP id iy5mr34356382qcb.1.1402333200150; Mon, 09 Jun 2014 10:00:00 -0700 (PDT) Received: from [192.168.1.114] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id g7sm31292688qab.8.2014.06.09.09.59.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 09:59:59 -0700 (PDT) Message-ID: <5395E810.5020003@nthpermutation.com> Date: Mon, 09 Jun 2014 13:00:00 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LK3NdWZeQlIXLviMfFJGGVHnCM4 Subject: Re: [TLS] Why there should not be a TLS 2.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 17:00:03 -0000 Hi Joe - Not to push back too hard, but how is discussion of items that might be added/deleted/modified from the charter not a valid topic for discussion on this list? Admittedly this particular thread is a little off in the weeds, but it's still talking about transport layer security and how it fits in with other things. I (*sigh*) can see how this might generate discussion on a TLS kerberos extension. Perhaps let it die its own death rather than setting out to kill it? It's only bits and its less noisier than some threads in the last year. Mike On 6/9/2014 10:57 AM, Joseph Salowey (jsalowey) wrote: > Hi Folks, > > This working group is chartered to work on TLS. While there are many things to talk about that are not TLS, they do not belong on this list. You may send an announcement for a place to discuss other related work that is not TLS to the list, but the discussion should be handled off the TLS list. > > Thanks, > > Joe > [For the Chairs] > On Jun 5, 2014, at 6:27 AM, Phillip Hallam-Baker wrote: > >> There was discussion of TLS 2.0 in London. As I have been thinking >> about it further I think it is the wrong direction entirely. Rather >> than thinking about a TLS 2.0 we should look at a new scheme that is >> the next generation of IPSEC, TLS and WS-Security. While this might >> sound fantastically hard, it is in fact more practical than TLS 2.0 >> and has far better deployment prospects. >> >> The immediate problem that has me thinking this way is Private-DNS >> which is my proposal to provide encryption and integrity protections >> for DNS which is itself built on technology that I developed to >> provide the JSON/REST world with the same security features as WS-* in >> a draft of 25 pages or less (done). >> >> >> First lets look at the current situation. We have IPSEC and TLS >> deployed. They are both enormously complicated and adopt completely >> different design approaches, different encodings and different key >> exchanges. But 90% of the underlying technology is identical: IPSEC >> and TLS both deliver a secure tunnel between endpoints. >> >> The only point at which IPSEC and TLS differ as a result of their >> function is in the application to the communication medium. IPSEC is >> applied at the IP packet layer, TLS is applied to the TCP stream. And >> that is all the difference there is. There is no reason that a >> protocol can't have one key exchange mechanism to serve both purposes. >> The success of TLS VPNs and SSH tunneling demonstrates that this is >> the case. >> >> >> So rather than thinking about TLS 2.0, I think we should instead >> consider the problem of establishing a security context separately >> from the problem of how to apply that context to a communication >> medium. Once that separation is made we can apply it at the packet, >> transport and application levels. Instead of TLS/2.0 we should be >> thinking about IPSEC/2.0 and HTTP-SEC. >> >> Factoring out the key exchange has other major advantages. It makes a >> three legged 'Kerberos style' interaction possible as well (or even >> four legged). the machine that performs the public key crypto needed >> to establish the security context does not need to be the same as the >> machine that uses the security context. >> >> This means that instead of an SSL accelerator box having to be >> strapped into the middle of my communication path as a pipe, it can be >> a separate server. Most boxes are more than capable of doing AES and >> SHA-2-256 without impacting server performance. It is the public key >> cryptography that is the problem, especially because each operation is >> quite significant. >> >> Kerberos does a lot of things right which is why people still use it. >> But right now it is a separate world to TLS. A convergence of TLS and >> Kerberos would be much more useful. >> >> >> At the moment I am relying on TLS to secure the confidentiality and >> integrity of the security context exchange in SXS-Connect: >> >> http://tools.ietf.org/html/draft-hallambaker-wsconnect-08 >> >> A security context consists of >> >> * A session identifier (opaque series of octets) >> * Algorithm choices (e.g. AES-128 + SHA-2-256) >> * A shared master secret >> * Expiry/invalidity information (when to stop using, renegotiate, etc) >> >> The size of the session identifier can be between 0 and 255 bytes >> depending on how much state the issuer needs and how much of that >> state is to be encoded into the identifier. >> >> So identifiers might be >> >> * 0 bytes - implicit in the IP Address and Port. >> * 8 bytes - just a key. >> * 24 bytes - is sufficient for a minimal stateless server scheme. >> * 64 bytes - what my code uses for a stateless server scheme. >> * 128 bytes - what my code uses during initial negotiation of a >> security context. >> >> Obviously, the lower down you are in the stack, the greater the >> overhead of a large session ID. But giving this tradeoff to the issuer >> allows the tradeoff to be made depending on specific needs at a >> specific installation rather than making it a global tradeoff decided >> by a Working Group with no knowledge of the particular requirements. >> >> _______________________________________________ >> 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 Jun 9 11:16:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2611B1A029B for ; Mon, 9 Jun 2014 11:16:45 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKLkCffth8_n for ; Mon, 9 Jun 2014 11:16:43 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D82A1A029A for ; Mon, 9 Jun 2014 11:16:43 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id B30EE33D190; Mon, 9 Jun 2014 18:16:42 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Kyle Hamilton References: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434FB5@USMBX1.msg.corp.akamai.com> <539549A8.1040008@gmail.com> From: Geoffrey Keating Date: 09 Jun 2014 11:16:42 -0700 In-Reply-To: <539549A8.1040008@gmail.com> Message-ID: Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4lQvQyjxN5uDYtqfLc0rBvwo-H8 Cc: tls@ietf.org Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 18:16:45 -0000 Kyle Hamilton writes: > On the other hand, I think that relying on a stapled response is perhaps > shortsighted, as it potentially opens a window of vulnerability. Say > the OCSP response is valid for 7 days (the maximum time that EV cert > OCSP responses can be valid for): if the cert is revoked on day 2, > that's still 5 and change days of potential validity. This is the kind > of vulnerability that clients can use the OCSP nonce extension to > protect themselves from, but it only works if it's used and queried from > the OCSP responder by the client itself. Thus, the proposal to prevent > clients from checking OCSP from the source in the presence of an "OCSP > must staple" extension is harmful to user security and thus wrong-minded. I think a CA that supports OCSP with nonces would probably not be using 'must staple'. However very few do so and so there are no clients that I know of that actually require a nonce in the reply; and the OCSP protocol doesn't distinguish between 'you sent a nonce but I will not reply with one' and 'you did not send a nonce', so the effect is that nonces do not practically contribute to OCSP security. From nobody Mon Jun 9 11:17:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C831A02A0 for ; Mon, 9 Jun 2014 11:17: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij9L3hfxp-Dj for ; Mon, 9 Jun 2014 11:17:21 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32551A0294 for ; Mon, 9 Jun 2014 11:17:20 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id k48so6098761wev.5 for ; Mon, 09 Jun 2014 11:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5br6CjETc1dnAQWcTufRkbyzCqxP9347XfIyhVWZRDY=; b=Y1dPEvCkMQNPmHKh3aKycaCKLwlhAbQMRMfhAK/3R9+D34mOGVB9R4LMna2e9k+Jz/ 0omfZo6YAsYVKV704KeDAqIl3wTHWYdUWkB5a1NUnizclGHPEo5u/V1pHWYZwVvHGwCN 7BwrUMVvNx/l4DUz3M38PdQXg0kKwTnsOGRJPMzaRmzqgjLumno9b5LmsH3e1CUmLpWa L1uek7jlmCu6+FSK9RxqnJozNj0voI9RYIrZlvYXqTwrmapAB+vuy+DjajSKV0fl7vmb XndRxkswcS9S+syDZB8w6+mnbgU0EOJHgXDUIkl4PAwVN21lVYhnfCwMBSHZQeQzD76i /ZKA== MIME-Version: 1.0 X-Received: by 10.194.133.1 with SMTP id oy1mr7373577wjb.87.1402337839355; Mon, 09 Jun 2014 11:17:19 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Mon, 9 Jun 2014 11:17:19 -0700 (PDT) In-Reply-To: <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 9 Jun 2014 11:17:19 -0700 Message-ID: From: Martin Thomson To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nLKFk0YDbn-TBOK2rvxOACSJb8o Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 18:17:22 -0000 On 9 June 2014 00:34, Nikos Mavrogiannopoulos wrote: > Could somebody elaborate on what is that issue and why does it need to > be solved? (it is not even mentioned in the TLS 1.3 charter) As someone > who follows the mailing list that proposal comes out of the blue with no > context whatsoever. I think that this has been covered in the thread, but piecemeal: * Renegotiation is a major source of security issues, both of the "we screwed the TLS design up" sort and of the "my application didn't realize that these things could change" sort. There is a clear desire to remove features that enable either sort of problem. * Renegotiation is just more protocol complexity. Removing it potentially makes implementations simpler. I think that either might be sufficient justification for removing the feature. However, a number of use cases depend on renegotiation to achieve their ends. Of these, we have identified: * mid-session client authentication, which uses renegotiation seems to only be used in HTTP * very long-lived connections, which require renegotiation to re-key occasionally The former we have decided to solve in HTTP. As a side note, we just decided to forbid renegotiation in HTTP/2. The latter can be addressed by my proposal, or any of a number of mechanisms. From nobody Mon Jun 9 11:50:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60701A02D2 for ; Mon, 9 Jun 2014 11:50:03 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PttVMA5VuQBS for ; Mon, 9 Jun 2014 11:49:59 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3AB91A029F for ; Mon, 9 Jun 2014 11:49:58 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) with Microsoft SMTP Server (TLS) id 15.0.954.9; Mon, 9 Jun 2014 18:49:56 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0954.000; Mon, 9 Jun 2014 18:49:56 +0000 From: Andrei Popov To: Martin Thomson , Nikos Mavrogiannopoulos Thread-Topic: [TLS] Proposed text for removing renegotiation Thread-Index: AQHPefQqRTsIIFK8gk6N5dkaAVUiXZtVJ/UAgAEX8YCADnobgIABFBgAgAALywCAApynAIAAs6aAgAAEdjA= Date: Mon, 9 Jun 2014 18:49:56 +0000 Message-ID: References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.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:80e0:ee43::2] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02379661A3 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51444003)(24454002)(13464003)(199002)(189002)(377454003)(31966008)(101416001)(77096999)(33646001)(2656002)(76576001)(19580405001)(74662001)(4396001)(54356999)(83322001)(99286001)(99396002)(83072002)(74502001)(85852003)(15202345003)(21056001)(76176999)(79102001)(87936001)(86362001)(76482001)(80022001)(81342001)(77982001)(50986999)(20776003)(19580395003)(92566001)(64706001)(15975445006)(74316001)(81542001)(93886002)(46102001)(561944003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB419; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/H7QZfuZwC98MmF7AYqlaRgfTlSM Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 18:50:03 -0000 Hi Martin, > The former we have decided to solve in HTTP. =20 Are you referring to these I-Ds: http://tools.ietf.org/html/draft-thomson-httpbis-cant-00 http://tools.ietf.org/html/draft-thomson-tls-care-00 Httpbis-cant talks (rather vaguely) about using "realm" or "other challenge= parameters" to select an appropriate client cert. I think client cert sele= ction should be clearly specified before we can say that the mid-session cl= ient auth problem has been solved, and remove renegotiation from TLS 1.3. It would be even better to solve this problem at the TLS layer, so that eac= h application protocol does not need to come up with a separate solution. A= nd avoiding the round-trips involved in establishing a TCP connection would= be awesome, too. The current solution using renegotiation has both of thes= e desirable properties. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Monday, June 9, 2014 11:17 AM To: Nikos Mavrogiannopoulos Cc: tls@ietf.org Subject: Re: [TLS] Proposed text for removing renegotiation On 9 June 2014 00:34, Nikos Mavrogiannopoulos wrote: > Could somebody elaborate on what is that issue and why does it need to=20 > be solved? (it is not even mentioned in the TLS 1.3 charter) As=20 > someone who follows the mailing list that proposal comes out of the=20 > blue with no context whatsoever. I think that this has been covered in the thread, but piecemeal: * Renegotiation is a major source of security issues, both of the "we screw= ed the TLS design up" sort and of the "my application didn't realize that t= hese things could change" sort. There is a clear desire to remove features= that enable either sort of problem. * Renegotiation is just more protocol complexity. Removing it potentially = makes implementations simpler. I think that either might be sufficient justification for removing the feat= ure. However, a number of use cases depend on renegotiation to achieve their end= s. Of these, we have identified: * mid-session client authentication, which uses renegotiation seems to only= be used in HTTP * very long-lived connections, which require renegotiation to re-key occasi= onally The former we have decided to solve in HTTP. As a side note, we just decid= ed to forbid renegotiation in HTTP/2. The latter can be addressed by my proposal, or any of a number of mechanism= s. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jun 9 12:50:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A831A02E3 for ; Mon, 9 Jun 2014 12:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.953 X-Spam-Level: X-Spam-Status: No, score=-4.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55uwctNH7EhJ for ; Mon, 9 Jun 2014 12:50:02 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id AA9871A02E2 for ; Mon, 9 Jun 2014 12:50:02 -0700 (PDT) Received: from JROWLEYL2 (unknown [67.137.52.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 3C6097FA217; Mon, 9 Jun 2014 13:50:02 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1402343402; bh=FjIeDvpgbwomhRbj1ueE3H33haJ7LmW9I8OuquadOLM=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=fU2cenkwBQQY9Rn2BiAzjJn8ayzcgBb8Cp2pRxT7Bju7YWYZu95iUl6t6UseWGi4d gLV9zEd+ZkLLPx+rFMJNLv54vVdwDT9+2H3ZI0lK80yHODV4eYtjzUdFM8qhyODPnq z4aYAA5seTZajHtoYUQBMPxR3q5TD5Q3pcKfQgZQ= From: "Jeremy Rowley" To: , "'Tom Ritter'" References: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <20140605173223.GK27883@mournblade.imrryr.org> <20140607164945.GA23329@roeckx.be> <20140607170619.GC27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7A@USMBX1.msg.corp.akamai.com> <20140607184737.GD27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F7D@USMBX1.msg.corp.akamai.com> <155f01cf82ce$7cfa8360$76ef8a20$@digicert.com> <455964081e9c154c6a68781b35d87ba9.squirrel@webmail.dreamhost.com> In-Reply-To: <455964081e9c154c6a68781b35d87ba9.squirrel@webmail.dreamhost.com> Date: Mon, 9 Jun 2014 13:50:01 -0600 Message-ID: <031701cf841c$00cab8b0$02602a10$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJxv6HtmB9uk8Yt5wEeFHdRD1knoQEt2WjqAP+sMUYCHog9/QJH2PNTApX9AA0COSwKkwNalKqnAp4CcngB5F3w/QJ8kG4OAaygmc0CNMpOtAIE/YvOAdczQaACTQHEx5kmeskw Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Lth-obF2nzWf-52m2TheYd9W75g Cc: tls@ietf.org Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 19:50:05 -0000 I agree with Ryan. In my view, if must staple is present, the server operator is requiring a stapled response and specially requesting the client not to communicate with the CA. In that case, the connection should fail instead of using a fallback. The RFC language already reflects this: If the TLS status_request feature is specified in the TLS Feature extension and a TLS client specifies the status_request feature in the Client Hello, a server MUST return a valid OCSP token for the specified server's End Entity certificate in the response. Also in Section 2: The inclusion of a TLS feature extension advertising the status_request feature in the server end entity certificate permits a client to fail immediately if the certificate status information is not provided by the server. Jeremy -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ryan Sleevi Sent: Sunday, June 8, 2014 10:15 PM To: Tom Ritter Cc: tls@ietf.org Subject: Re: [TLS] OCSP must staple On Sat, June 7, 2014 10:10 pm, Tom Ritter wrote: > While it looks some of the semantics of 'Must Staple', I think either > behavior could be acceptable for a client. Either closing the > connection without attempting to contact a OCSP server, or switching to a 'Hard Fail' > OCSP lookup. > > I can imagine some servers deciding that they would want clients to > fail if they didn't send a staple, rather than leak the OCSP lookup > to the CA. I could imagine other servers wanting to hedge their bets > and have the client make an attempt before giving up. > > I don't understand what you mean by the OCSP server rejcting them. It's not really "must staple" if clients fall back to doing lookups, is it? It's more like "should consider staple" (RFC 6919) I would expect conforming clients to fail if must-staple is present but not stapled. This includes ignoring OCSP cached responses, and prevents online lookups. This interpretation is key among the reasons why Chrom{e/ium} has not (yet) begun experimenting with must staple, since the APIs used don't offer as much flexibility. However, that interpretation is exactly what ensures interoperability - these sorts of "soft fallbacks" cause a number of issues, as everyone in the TLS WG can attest to elsewhere (eg: TLS version rollback, AIA chasing, etc) _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jun 9 14:21:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7BA1A020E for ; Mon, 9 Jun 2014 14:21:28 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl7jRL29s5et for ; Mon, 9 Jun 2014 14:21:26 -0700 (PDT) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804961A01CF for ; Mon, 9 Jun 2014 14:21:26 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id b6so1651344yha.7 for ; Mon, 09 Jun 2014 14:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PrZQAoVKPIbGoNHbGcv+aeQAu824H466iHINKqzf5is=; b=r9HPSDvA7lzix/8j58PD+mTCc3J08IruPoq2eLF0eCyUXRhbuYcUxAcJ4Q47EtZu4q f/hbWVCtIGf7d6Mgj7vU89OY+REFKWUJdoENN5oZKNEM4hwZToXsmZBAZbcxFcu+ASjG SX0l5CrAf1wDVxnsPX4ud3JSIdFJo3Q3N/4yU/pop0OYMREwhAvEzs+HTPfQ3KBVs4eq 3rYPPmGL9/j+WWZveaYE3+RBpcCtGEs6XEmcBV4h1/Q8hy4oOKTWBUXrR+NgnCNWwTRB R4zssFkyXyqvGdjZxv8gyarvbW4c6/SP5hwviAJEBMmebVOLzl9CqXRz1yH4LY5sb6+L D2wQ== MIME-Version: 1.0 X-Received: by 10.236.89.69 with SMTP id b45mr18936512yhf.16.1402348885817; Mon, 09 Jun 2014 14:21:25 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Mon, 9 Jun 2014 14:21:25 -0700 (PDT) In-Reply-To: References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 9 Jun 2014 18:21:25 -0300 Message-ID: From: Watson Ladd To: Andrei Popov Content-Type: multipart/alternative; boundary=20cf300e524130bf7304fb6dcb3f Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oXc7bpi2GB97cez_h3DdmRRfL30 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 21:21:28 -0000 --20cf300e524130bf7304fb6dcb3f Content-Type: text/plain; charset=UTF-8 On Mon, Jun 9, 2014 at 3:49 PM, Andrei Popov wrote: > Hi Martin, > > > The former we have decided to solve in HTTP. > > Are you referring to these I-Ds: > http://tools.ietf.org/html/draft-thomson-httpbis-cant-00 > http://tools.ietf.org/html/draft-thomson-tls-care-00 > > Httpbis-cant talks (rather vaguely) about using "realm" or "other > challenge parameters" to select an appropriate client cert. I think client > cert selection should be clearly specified before we can say that the > mid-session client auth problem has been solved, and remove renegotiation > from TLS 1.3. > > It would be even better to solve this problem at the TLS layer, so that > each application protocol does not need to come up with a separate > solution. And avoiding the round-trips involved in establishing a TCP > connection would be awesome, too. The current solution using renegotiation > has both of these desirable properties. > TLS still includes the Certificate Request message to indicate which client certificates are being used. If we have an extension to allow clients to say "I want to offer a cert, what cert do you want?", this can be used. > > Cheers, > > Andrei > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Monday, June 9, 2014 11:17 AM > To: Nikos Mavrogiannopoulos > Cc: tls@ietf.org > Subject: Re: [TLS] Proposed text for removing renegotiation > > On 9 June 2014 00:34, Nikos Mavrogiannopoulos wrote: > > Could somebody elaborate on what is that issue and why does it need to > > be solved? (it is not even mentioned in the TLS 1.3 charter) As > > someone who follows the mailing list that proposal comes out of the > > blue with no context whatsoever. > > > I think that this has been covered in the thread, but piecemeal: > > * Renegotiation is a major source of security issues, both of the "we > screwed the TLS design up" sort and of the "my application didn't realize > that these things could change" sort. There is a clear desire to remove > features that enable either sort of problem. > > * Renegotiation is just more protocol complexity. Removing it potentially > makes implementations simpler. > > I think that either might be sufficient justification for removing the > feature. > > However, a number of use cases depend on renegotiation to achieve their > ends. Of these, we have identified: > > * mid-session client authentication, which uses renegotiation seems to > only be used in HTTP > > * very long-lived connections, which require renegotiation to re-key > occasionally > > The former we have decided to solve in HTTP. As a side note, we just > decided to forbid renegotiation in HTTP/2. > > The latter can be addressed by my proposal, or any of a number of > mechanisms. > > _______________________________________________ > 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 > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin --20cf300e524130bf7304fb6dcb3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 9, 2014 at 3:49 PM, Andrei Popov <= Andrei.Popo= v@microsoft.com> wrote:
Hi Martin,

> The former we have decided to solve in HTTP.

Are you referring to these I-Ds:
http://tools.ietf.org/html/draft-thomson-httpbis-cant-00 http://tools.ietf.org/html/draft-thomson-tls-care-00

Httpbis-cant talks (rather vaguely) about using "realm" or "= other challenge parameters" to select an appropriate client cert. I th= ink client cert selection should be clearly specified before we can say tha= t the mid-session client auth problem has been solved, and remove renegotia= tion from TLS 1.3.

It would be even better to solve this problem at the TLS layer, so that eac= h application protocol does not need to come up with a separate solution. A= nd avoiding the round-trips involved in establishing a TCP connection would= be awesome, too. The current solution using renegotiation has both of thes= e desirable properties.

TLS still includes the Certificate Request= message to indicate which client certificates are being used. If we have a= n extension to allow clients to say "I want to offer a cert, what cert= do you want?", this can be used.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Monday, June 9, 2014 11:17 AM
To: Nikos Mavrogiannopoulos
Cc: tls@ietf.org
Subject: Re: [TLS] Proposed text for removing renegotiation

On 9 June 2014 00:34, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote= :
> Could somebody elaborate on what is that issue and why does it need to=
> be solved? (it is not even mentioned in the TLS 1.3 charter) As
> someone who follows the mailing list that proposal comes out of the > blue with no context whatsoever.


I think that this has been covered in the thread, but piecemeal:

* Renegotiation is a major source of security issues, both of the "we = screwed the TLS design up" sort and of the "my application didn&#= 39;t realize that these things could change" sort. =C2=A0There is a cl= ear desire to remove features that enable either sort of problem.

* Renegotiation is just more protocol complexity. =C2=A0Removing it potenti= ally makes implementations simpler.

I think that either might be sufficient justification for removing the feat= ure.

However, a number of use cases depend on renegotiation to achieve their end= s. =C2=A0Of these, we have identified:

* mid-session client authentication, which uses renegotiation seems to only= be used in HTTP

* very long-lived connections, which require renegotiation to re-key occasi= onally

The former we have decided to solve in HTTP. =C2=A0As a side note, we just = decided to forbid renegotiation in HTTP/2.

The latter can be addressed by my proposal, or any of a number of mechanism= s.

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

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



--
= "Those who would give up Essential Liberty to purchase a little Tempor= ary Safety deserve neither=C2=A0 Liberty nor Safety."
-- Benjamin F= ranklin=20
--20cf300e524130bf7304fb6dcb3f-- From nobody Mon Jun 9 14:28:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C651A020E for ; Mon, 9 Jun 2014 14:28:19 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTo9I6jDapMQ for ; Mon, 9 Jun 2014 14:28:17 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A04C1A01CF for ; Mon, 9 Jun 2014 14:28:17 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z12so2808649wgg.1 for ; Mon, 09 Jun 2014 14:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IiKqOEX1hPXdsNMQY/zHP8/TDVaaEgLphATsgXI+PRI=; b=dWC0pOqaXjBmlmWDyCm/9DGchzkyuhlSsM661lObp6Yznb/TCmVZbHiKmvVONJpKgV tkFTwQlfCqZkL8y/kEDtq4e5kiII5bDBD+2O9QzyZxCFud7Eyj0xPokKj7TqJPFrloit ygaCOMBgRP7Kit0jejEK445JV/C59zvnslpk4UbJVGjl6ZZzMs463ykWtu/QNw2D5pyX 4NvESAeVCezqxvNK0d1K78cBzHhfA0O5ogwEm4Sw1RdQJGMdmkl+i/s6iIlvl3fDniN0 2l4yZ6D5P77CoTuty2Y7z6VhbJm9qOECpUq99Sf9jIs/yEaBaegAkMyFTXT4VJ6nS2oN kHrw== MIME-Version: 1.0 X-Received: by 10.195.18.8 with SMTP id gi8mr35514384wjd.75.1402349295757; Mon, 09 Jun 2014 14:28:15 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Mon, 9 Jun 2014 14:28:15 -0700 (PDT) In-Reply-To: References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 9 Jun 2014 14:28:15 -0700 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0wwCbB4DUaqlbSq_e2vKu4aDAJ4 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 21:28:19 -0000 On 9 June 2014 11:49, Andrei Popov wrote: >> The former we have decided to solve in HTTP. > > Are you referring to these I-Ds: > http://tools.ietf.org/html/draft-thomson-httpbis-cant-00 > http://tools.ietf.org/html/draft-thomson-tls-care-00 > > Httpbis-cant talks (rather vaguely) about using "realm" or "other challen= ge parameters" to select an appropriate client cert. I think client cert se= lection should be clearly specified before we can say that the mid-session = client auth problem has been solved, and remove renegotiation from TLS 1.3. The selection problem is, as we discussed in Denver, worth addressing. The short term fix in HTTP/2 will actually be to force these users down to HTTP/1.1. That's suboptimal, certainly, but it does fix the immediate problem. As far as the -cant draft goes, I simply haven't uploaded an updated version after our discussion in Denver. There's a work in progress version on github: http://martinthomson.github.io/drafts/draft-thomson-httpbis-cant.html > It would be even better to solve this problem at the TLS layer, so that e= ach application protocol does not need to come up with a separate solution.= And avoiding the round-trips involved in establishing a TCP connection wou= ld be awesome, too. The current solution using renegotiation has both of th= ese desirable properties. I'm sympathetic to this, but if HTTP is the only one that wants this particular feature, then we are better off leaving them to work around this. At least in my opinion. From nobody Mon Jun 9 14:29:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9847D1A0331 for ; Mon, 9 Jun 2014 14:29:16 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEUGMdLo99HM for ; Mon, 9 Jun 2014 14:29:15 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD581A01CF for ; Mon, 9 Jun 2014 14:29:15 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q58so2841200wes.2 for ; Mon, 09 Jun 2014 14:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F81CBXRO2mcczI3lb4U56LIJmBZjztXe7HBLXo9TL7M=; b=A6/5RQxHxyICd3+1mmXpsxRcsiqCmUx/XC8ofyRHTihJL9qcMSOGIGyllqV/nceNEe ibsJIcZjBYm/H8yRh9wjBlTzXMdhDYYH+vhTx6gGwrWNN6sxlDmkbt1F5rfgEtkvPlC8 23KvghkApd3r6DXvfQI3kpfmANp3H4KBM+wCDz/LH5hdZivre5CgRC9cDdIDMIZNUrDE Xehh2EF/bZAXts1THyGwI+b7Ek11B83l5fIthOhUsRLez7A+RcMRfc5xoBMyMtZ6zXus 6WcAUbxan5I2RzdeuzTM+XCpJAW6pgR821YqmwKWXQHyG2d+2orLSTSBroLm3gnSu+uv oVDg== MIME-Version: 1.0 X-Received: by 10.194.92.148 with SMTP id cm20mr33608242wjb.53.1402349353724; Mon, 09 Jun 2014 14:29:13 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Mon, 9 Jun 2014 14:29:13 -0700 (PDT) In-Reply-To: References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 9 Jun 2014 14:29:13 -0700 Message-ID: From: Martin Thomson To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/g1-yunECGX7We4XbyRDeFxndBII Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 21:29:16 -0000 On 9 June 2014 14:21, Watson Ladd wrote: > TLS still includes the Certificate Request message to indicate which client > certificates are being used. If we have an extension to allow clients to say > "I want to offer a cert, what cert do you want?", this can be used. That would be the second draft that Andrei referenced. Note that my preference is to have the ability to unilaterally offer authentication as a client in TLS 1.3. From nobody Mon Jun 9 14:40:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DF71A0326 for ; Mon, 9 Jun 2014 14:40:05 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-Sara8B8MfM for ; Mon, 9 Jun 2014 14:40:04 -0700 (PDT) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276801A01CF for ; Mon, 9 Jun 2014 14:40:04 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id b6so1668981yha.7 for ; Mon, 09 Jun 2014 14:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ur2AycDQOHjMvxPGSV+C0CrkN0CUU9OTy5P6mOghonQ=; b=tnMiwOd/rLOxdiiCdC5aEAbMcoO+nDK7WPfSJ4Tu5OPnerHWS80K5d2KyboGiMTn8I PnHDxbouyFKcwb26eYHo5u6odnlPyAlhD4PbvHT6PD5T9j+7/Pd+zCil+JKmGcR2ppwt 1N3EPHfs4HRIkrONCa9OnhZ6lV+E6C9JJDR0WcxZqbsr2EFhXSur96LQiyxQqK3XwUJP vx7b/3h7dj+BsDyBjSGKoeHnMss1dxOYeLTZwi67iJz3fFy37BEpU4T/HTGDVSPC7JLX b5rPmc0uS5PP7Z9RMNS9UISQ56uvYEDKj/x+LYXwf01PTIiJypuzXaY1EOhxzC642lu+ yFFw== MIME-Version: 1.0 X-Received: by 10.236.26.72 with SMTP id b48mr17498586yha.59.1402350003551; Mon, 09 Jun 2014 14:40:03 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Mon, 9 Jun 2014 14:40:03 -0700 (PDT) Date: Mon, 9 Jun 2014 18:40:03 -0300 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8rXaT4dI_pGSUJ7gO6xiDzqhq54 Subject: [TLS] Obstacles to standardizing ECC in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 21:40:05 -0000 Dear all, While I think that ECC ciphersuites and some well chosen curves need to be core, MTI features of TLS 1.3 for performance issues, I think there a few issues that need to be addressed. The first is that RFC 6090 is wrong: the formulas are incorrect, and so it should not be cited. The second is that the CFRG has not yet decided which curves to use. For legacy reasons implementations are likely to need to implement P256 and P384 for signature verification on certificates. However, there are significant advantages in speed and security for Edwards curves. I think it is high time to, 30 years after the invention of ECC, make it MTI in TLS. But I do not think it will be an immediately doable task. Sincerely, Watson Ladd From nobody Mon Jun 9 14:55:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1131A0341 for ; Mon, 9 Jun 2014 14:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-TgSy7Qg75E for ; Mon, 9 Jun 2014 14:55:49 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28EF91A0326 for ; Mon, 9 Jun 2014 14:55:49 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id q59so1248824wes.41 for ; Mon, 09 Jun 2014 14:55:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=66Rfia3qi0BlB5ifASQkG+Gjadn25zQnZl0m8XNPg+U=; b=VFpR+woghv6pB5KwWOAQ9mbZcX/JFJpB5uaC83tZ5LhzuZfEKAgsSa1hPef/Wmcsq6 qFC2eNDKatoJqT/TwF8Z6wEtuEs+G52WNmZFzxI36wkMUkv6r+7fOAfFj1BP8lq653uy f5jfDyplsRENhY8EucSefn+oqteQG/uURlXYJyM7ktEg9wtLmCtl8JBGvwczojrZNsCT fAd7GFrs4ZVrYMVEum6uHCKRNzOZ9rBYVKy6WWrxkIZF4UJWHYYEWiETa6XyyO/xbQgk G1sUk5Wt73BRgJyeKYgI7lQNhOWdOtYwRo6Tmd3L0dDKCrIk7gCsR7/eZw7xmRth0EKH tEJw== X-Gm-Message-State: ALoCoQmyQ6Wl9Jcchp4QimCbETRxpR6xKWxb2scFL3yHxMNBef1Z5Y6DlIr7MdJRdq5I31g5io2T X-Received: by 10.194.2.75 with SMTP id 11mr35861044wjs.48.1402350947492; Mon, 09 Jun 2014 14:55:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Mon, 9 Jun 2014 14:55:07 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:c830:9a81:6768:eba4] In-Reply-To: References: From: Eric Rescorla Date: Mon, 9 Jun 2014 14:55:07 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7b3a834c137e3b04fb6e461a Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hnoekCbGaGmkVOMg_oYaHsl8QGA Cc: "tls@ietf.org" Subject: Re: [TLS] Obstacles to standardizing ECC in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 21:55:51 -0000 --047d7b3a834c137e3b04fb6e461a Content-Type: text/plain; charset=UTF-8 On Mon, Jun 9, 2014 at 2:40 PM, Watson Ladd wrote: > Dear all, > > While I think that ECC ciphersuites and some well chosen curves need > to be core, MTI features of TLS 1.3 for performance issues, I think > there a few issues that need to be addressed. > > The first is that RFC 6090 is wrong: the formulas are incorrect, and > so it should not be cited. > > The second is that the CFRG has not yet decided which curves to use. > For legacy reasons implementations are likely to need to implement > P256 and P384 for signature verification on certificates. However, > there are significant advantages in speed and security for Edwards > curves. > > I think it is high time to, 30 years after the invention of ECC, make > it MTI in TLS. But I do not think it will be an immediately doable > task. > Watson, Thanks for kicking off this conversation. As you no doubt know, TLS already specifies a number of ECC-based cipher suites (RFC 4492 and following) and there are interoperable implementations of many of these cipher suites. The two relevant questions for the TLS WG seem to me to be: - Should at least some of them be on the standards track rather than their current Informational status. - If we do standardize some ECC cipher suites, should we make one or more of them an (the?) MTI. The primary relevance of RFC 6090 to this conversation is that it may clarify the IPR situation and thus smooth the way to putting these ciphersuites on Standards Track. I have made https://github.com/tlswg/tls13-spec/issues/43 to track this topic. Best, -Ekr --047d7b3a834c137e3b04fb6e461a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 9, 2014 at 2:40 PM, Watson Ladd <watsonbladd@gmail.com>= wrote:
Dear all,

While I think that ECC ciphersuites and some well chosen curves need
to be core, MTI features of TLS 1.3 for performance issues, I think
there a few issues that need to be addressed.

The first is that RFC 6090 is wrong: the formulas are incorrect, and
so it should not be cited.

The second is that the CFRG has not yet decided which curves to use.
For legacy reasons implementations are likely to need to implement
P256 and P384 for signature verification on certificates. However,
there are significant advantages in speed and security for Edwards
curves.

I think it is high time to, 30 years after the invention of ECC, make
it MTI in TLS. But I do not think it will be an immediately doable
task.

Watson,

= Thanks for kicking off this conversation.

As you n= o doubt know, TLS already specifies a number of ECC-based
cipher = suites (RFC 4492 and following) and there are interoperable
implementations of many of these cipher suites. The two relevant quest= ions
for the TLS WG seem to me to be:

- = Should at least some of them be on the standards track rather than their
current Informational status.
- If we do standardize some EC= C cipher suites, should we make one or
more of them an (the?) MTI= .

The primary relevance of RFC 6090 to this conver= sation is that it may clarify
the IPR situation and thus smooth the way to putting these ciphersuite= s on
Standards Track.

I have made=C2=A0<= a href=3D"https://github.com/tlswg/tls13-spec/issues/43" target=3D"_blank">= https://github.com/tlswg/tls13-spec/issues/43 to track
this topic.

Best,
-Ekr

--047d7b3a834c137e3b04fb6e461a-- From nobody Mon Jun 9 16:06:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529A31A0285 for ; Mon, 9 Jun 2014 15:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.477 X-Spam-Level: X-Spam-Status: No, score=-0.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_NUMERIC_HELO=1.164, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApGcuX4YzbN7 for ; Mon, 9 Jun 2014 15:32:33 -0700 (PDT) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5AB1A0263 for ; Mon, 9 Jun 2014 15:32:32 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Wu878-0000Mk-Tp for tls@ietf.org; Tue, 10 Jun 2014 00:32:26 +0200 Received: from 50.245.141.77 ([50.245.141.77]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Jun 2014 00:32:26 +0200 Received: from eternaleye by 50.245.141.77 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Jun 2014 00:32:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: tls@ietf.org From: Alex Elsayed Date: Mon, 09 Jun 2014 15:32:16 -0700 Lines: 54 Message-ID: References: <53934B47.4090603@fifthhorseman.net> <20140608101721.GA6189@roeckx.be> <20140609150826.GA9849@roeckx.be> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 50.245.141.77 User-Agent: KNode/4.13.1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gzgRLU6ydA-wrRQg8fWK-vtWLsU X-Mailman-Approved-At: Mon, 09 Jun 2014 16:06:54 -0700 Subject: Re: [TLS] No more GMT exposure in the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 22:32:34 -0000 Kurt Roeckx wrote: > On Sun, Jun 08, 2014 at 11:17:42AM -0700, Alex Elsayed wrote: >> Kurt Roeckx wrote: >> >> > On Sat, Jun 07, 2014 at 09:55:23PM +0000, Jacob Appelbaum wrote: >> >> On 6/7/14, Daniel Kahn Gillmor wrote: >> >> > On 06/07/2014 10:56 AM, Watson Ladd wrote: >> >> >> Putting the clock time in the TLS handshake enables fingerprinting. >> >> >> It's useless cryptographically: 32 random bytes is exceedingly >> >> >> unlikely to repeat. >> >> > >> >> > There seems to be a growing consensus on this point: >> >> > >> >> > https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime >> >> > >> >> >> >> I've said as much to Nick and to Eric (in the context of working on >> >> tlsdate[0]) but perhaps not on this tls list: >> >> >> >> I'd like to see servers provide 64bits of time resolution in the >> >> ServerHello and nothing but randomness in that field in the >> >> ClientHello. >> >> >> >> The current 32bit field isn't accurate enough for replacing NTP. If we >> >> can't make the time field useful for accurate secure time exchange - I >> >> hope we'll remove all network visible distinguishers, even ones that >> >> are currently useful for totally bizarre reasons. >> > >> > Would that be in the same format as NTP, with 32 bit for the >> > seconds and 32 bit for fractional second, and so a resolution >> > of 0.2 nano seconds? I'm wondering what kind of accuracy you'll >> > get. >> > >> > Anyway, how do you plan to deal with checking the status of the >> > certificate if you don't know what the current time is? >> >> 32 bit seconds in new protocols is probably not a good idea, as >> Linux/BSD/etc are having to deal with now - 2^32 seconds is a bit over >> 136 years, and while this use case will be unsigned (since it won't need >> to represent pre-epoch values, which cut time_t down to ~68 years) you're >> still going to run into something semantically identical to the Y2K38 >> problem. When that happens depends on what you pick as your epoch. > > Please note that NTP also uses the 32 bit for seconds, but has > a concept of era's. You basicly need to know that it's not 136 > years ago or in the future. Yes, but TLS does not, hence my saying "in new protocols" (or new versions of existing protocols) - and in a very real sense, NTP's 'era' _is_ an extension of the time value beyond 32 bits; just in a way that splits it up somewhat strangely when we could just use a 64-bit value and thus handle it the same way as the operating systems we'd be using it on (64-bit seconds, 32-bit nanoseconds). From nobody Mon Jun 9 18:55:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EFC1A0342 for ; Mon, 9 Jun 2014 18:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5RG-UP2j8f5 for ; Mon, 9 Jun 2014 18:55:26 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 220E71A0338 for ; Mon, 9 Jun 2014 18:55:26 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 055214742F; Tue, 10 Jun 2014 01:55:25 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E379C4740D; Tue, 10 Jun 2014 01:55:24 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id AA6DB80040; Tue, 10 Jun 2014 01:55:24 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Mon, 9 Jun 2014 21:55:24 -0400 From: "Salz, Rich" To: Watson Ladd , "tls@ietf.org" Date: Mon, 9 Jun 2014 21:55:23 -0400 Thread-Topic: [TLS] Obstacles to standardizing ECC in TLS Thread-Index: Ac+EK2g2PW9AIL64TKGU1PaP6f5SPAAI4KVw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130F43545E@USMBX1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nQVigClaBfTujpu1iaUDj1OrPZU Subject: Re: [TLS] Obstacles to standardizing ECC in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 01:55:31 -0000 > The second is that the CFRG has not yet decided which curves to use. My recollection is that CFRG has picked 25519 as its (first perhaps) recomm= end curve. Sean Turner, which my assist, owes an I-D based on the original= paper. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Tue Jun 10 00:39:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307BC1A0424 for ; Tue, 10 Jun 2014 00:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyI-Ftd0DhVX for ; Tue, 10 Jun 2014 00:39:38 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ADBD1A023C for ; Tue, 10 Jun 2014 00:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1402385977; x=1433921977; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=GllN6V3apIxLw+U96lmu6V348S880qOFRe0OBPQP+1Q=; b=gDQI/SiE1vpnMdazCXHcbo5rMqEc+ww+o3LIV3WLj0SHnpWRvNj6W6Lm tUmMuHNxjlkFu23CIeVQuUza2cCXRcxaloeKSqS/fp+I/wC+ebRlEUx19 AuUIL81uOBCHJnQJ1iPMLkuqoKg9vC6BHl4v5nhHCBM6xPsFsp+QePqN0 E=; X-IronPort-AV: E=Sophos;i="4.98,1007,1392116400"; d="scan'208";a="257626718" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 10 Jun 2014 19:39:35 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 19:39:35 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Obstacles to standardizing ECC in TLS Thread-Index: Ac+Efx/fzHKqeHQmRFyR7lSFuQLAWA== Date: Tue, 10 Jun 2014 07:39:34 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DEC4D3D@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PgYxsKshm_hKfE-nB1g_yc6UEQE Subject: Re: [TLS] Obstacles to standardizing ECC in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 07:39:42 -0000 Eric Rescorla writes:=0A= =0A= >As you no doubt know, TLS already specifies a number of ECC-based cipher= =0A= >suites (RFC 4492 and following) and there are interoperable implementation= s=0A= >of many of these cipher suites. The two relevant questions for the TLS WG= =0A= >seem to me to be:=0A= >=0A= >[...]=0A= =0A= There are actually more issues than that with ECC, see=0A= http://tools.ietf.org/html/draft-gutmann-tls-eccsuites-05 for details:=0A= =0A= [3] provides an extremely flexible, and by extension extremely=0A= complex means of specifying a large number of options involving the=0A= use of ECC algorithms for [2]. As such the "cipher suites" in [3]=0A= aren't suites in the conventional TLS sense but more an indication of=0A= intent to negotiate a Chinese menu, with details to be decided on=0A= later via various TLS extensions and parameter settings. This makes=0A= deciding on a particular suite nondeterministic, since later=0A= parameter choices and settings can negate the initial "cipher suite"=0A= choice, requiring returning to the suite list to try with another=0A= Chinese-menu suite in the hope that later parameter choices allow it=0A= to be used.=0A= =0A= In practice no currently deployed implementation actually does this,=0A= either dropping the connection or aborting the handshake with a=0A= handshake-failure if the expected parameters aren't present=0A= throughout the various locations in the TLS handshake in which ECC=0A= parameters can be specified. This means that establishing a TLS=0A= connection using ECC often requires trial-and-error probing to=0A= ascertain what the other side is expecting to see before a connection=0A= can be established.=0A= =0A= Experience with deployed implementations indicates that all of them=0A= appear to implement a common subset of fixed ECC parameters that work=0A= in all cases (alongside the more obscure options), representing a de=0A= facto profile of standard cipher suites rather than Chinese-menu=0A= selection options. For example one widely-used implementation didn't=0A= send out TLS ECC extensions and yet other implementations had no=0A= problems interoperating with it, indicating that what this document=0A= specifies is already a de facto profile of implementations. This=0A= document standardises this de facto usage by defining a small number=0A= of standard ECC cipher suites with unambiguous parameters and=0A= settings.=0A= =0A= Peter.= From nobody Tue Jun 10 00:44:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146201A0422; Tue, 10 Jun 2014 00:43:56 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-Gzz46CkGCU; Tue, 10 Jun 2014 00:43:51 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13FD1A0424; Tue, 10 Jun 2014 00:43:49 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so2547546wes.35 for ; Tue, 10 Jun 2014 00:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U1nIhWGrI4FR57IsTtBUTLElzNVqOpt/pL+TsFurS18=; b=FUgLSiOf/ilyTynEAbP5L2QRn0iw7c1kkD5HdKvmoDhDYRKqpAmYLpHJOHS0j3GKbM xVo8kbTb7TaVmDLT7itolkE+22pgZZ/zv/0IJFxHZM6dfnJqOq2zbuqcduVD4RMUVgrG mW6TYcJvaJYuB4dbBf7Ejx4AmzjtpxqEln3WTpmRF/SAiV8qjTGvNJe+XUvK5UU6rSVt Y6XfNapPGC3YZHQx76d3DI1s5zkt3a0GycrqdkwhiJE0L2esR164/hD6iwRH+XHcQ7HZ kedr5BXDv05VYZV8Ut9gPAKLWD/ZnAmbcYe64OZMlXmFfYycSx9OLdXrhxS+6s0KEhVD Vv/Q== X-Received: by 10.180.38.107 with SMTP id f11mr26648702wik.59.1402386228088; Tue, 10 Jun 2014 00:43:48 -0700 (PDT) Received: from [172.24.249.169] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id cy4sm19117174wib.5.2014.06.10.00.43.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 00:43:47 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: <36137A9A-3503-4AF8-80D0-1FB53A7949EA@gmail.com> Date: Tue, 10 Jun 2014 10:43:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2262735E-0D70-42B4-8571-75B0A1EC6321@gmail.com> References: <20140606145220.8187.67355.idtracker@ietfa.amsl.com> <36137A9A-3503-4AF8-80D0-1FB53A7949EA@gmail.com> To: "ietf\\@ietf.org" , draft-ietf-tls-encrypt-then-mac.all@tools.ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2uEC_OstA0cODiy2GV8p7m3k7Jw Cc: TLS Mailing List Subject: Re: [TLS] Last Call: (Encrypt-then-MAC for TLS and DTLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 07:43:56 -0000 [adding draft address] On Jun 7, 2014, at 4:15 PM, Yoav Nir wrote: > Hi >=20 > I=92ve read the draft and I have a few comments: >=20 > The motivation for this extension is not clear from the draft. The = introduction says that the MAC-then-encrypt construction is =93no longer = regarded as secure=94, and that it has been the subject of =93numerous = security vulnerabilities and attacks=94. For the latter claim, there are = no references given either in the document itself or in references. For = the former two articles are cited.=20 > The first (reference [5]) is by Hugo Krawczyk. While that article = shows a theoretical weakness of MAC-then-encrypt, it also finds that = (quoting from the abstract) =93On the positive side we show that the = authenticate-then-encrypt method is secure if the encryption method in = use is either CBC mode (with an underlying secure block cipher) or a = stream cipher (that xor the data with a random or pseudorandom pad).=94. = It also concludes that =93the current practical implementations of [SSL] = that use the above modes of encryption are safe=94. So this is not a = great call for action. > The second (reference [6]) is a better reference, but I=92m still = missing a reference to anything practical or close to practical. >=20 > The rationale for the mandate in section 3.1 is not clear to me. Sure, = EtM is better than MtE, so renegotiating from MtE to EtM is a downgrade, = but there is no mandate for implementations that are configured to = support both algorithms to avoid downgrading from AES-256 to single DES, = so why add this here? Also, this section uses the terms =93state=94, = =93status=94 and =93mechanism=94 seemingly interchangeably, and doesn=92t = explain why changing mechanism during renegotiation is a SHOULD = NOT-level issue, or how AEAD ciphers figure in this mandate. >=20 > One more thing, this time a nit: informative reference number 7 = describes a document as =93RFC xxxx=94. This is a reference to = =93draft-bmoeller-tls-downgrade-scsv=94, which according to the = datatracker is an individual draft that nobody=92s asked to publish yet. = It should be referenced with the draft name as a work in progress. Since = it=92s an informative reference, this won=92t block publication of this = document. >=20 > Yoav >=20 > On Jun 6, 2014, at 5:52 PM, The IESG wrote: >=20 >>=20 >> The IESG has received a request from the Transport Layer Security WG >> (tls) to consider the following document: >> - 'Encrypt-then-MAC for TLS and DTLS' >> as Proposed Standard >>=20 >> 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 2014-06-20. 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. >>=20 >> Abstract >>=20 >>=20 >> This document describes a means of negotiating the use of the >> encrypt-then-MAC security mechanism in place of TLS'/DTLS' existing >> MAC-then-encrypt one, which has been the subject of a number of >> security vulnerabilities over a period of many years. >>=20 >>=20 >>=20 >>=20 >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/ >>=20 >> IESG discussion can be tracked via >> = http://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/ballot/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >> ID nits found an Obsolete normative reference: "RFC 4366 (ref. '3')=20= >> (Obsoleted by RFC 5246, RFC 6066)" which will be replaced. >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Tue Jun 10 01:20:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238C71A02D9 for ; Tue, 10 Jun 2014 01:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNDFqBrJrSHq for ; Tue, 10 Jun 2014 01:20:04 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9498C1A0286 for ; Tue, 10 Jun 2014 01:20:04 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5A8K2F9000608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Jun 2014 04:20:02 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5A8JxL4026257 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2014 04:20:01 -0400 Message-ID: <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Martin Thomson Date: Tue, 10 Jun 2014 10:19:59 +0200 In-Reply-To: References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XGErEm-SrEuQQONNaHQMmnQg6XY Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 08:20:06 -0000 On Mon, 2014-06-09 at 11:17 -0700, Martin Thomson wrote: > On 9 June 2014 00:34, Nikos Mavrogiannopoulos wrote: > > Could somebody elaborate on what is that issue and why does it need to > > be solved? (it is not even mentioned in the TLS 1.3 charter) As someone > > who follows the mailing list that proposal comes out of the blue with no > > context whatsoever. > > > I think that this has been covered in the thread, but piecemeal: Not in my opinion. The arguments being presented are very vague, as the ones you quote below. > * Renegotiation is a major source of security issues, both of the "we > screwed the TLS design up" sort and of the "my application didn't > realize that these things could change" sort. There is a clear desire > to remove features that enable either sort of problem. Could you please cite these security issues. In the 17 years of the protocol I have only seen one. > * Renegotiation is just more protocol complexity. Removing it > potentially makes implementations simpler. Where do you base this conclusion? Have you implemented it and you found it complex, or have you tried to model it in some formal model and was impossible? Renegotiation, is one of the most simple parts of the protocol (Martin Rex argued for that in a previous e-mail and I concur). Your proposal to solve this "complexity" is more complex than the current solution. > I think that either might be sufficient justification for removing the feature. Not to me. I believe that unless hard evidence of the problems are presented, this call for action here is unwarranted. regards, Nikos From nobody Tue Jun 10 04:29:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C587F1B27B8 for ; Tue, 10 Jun 2014 04:29: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JX0PK7682V4c for ; Tue, 10 Jun 2014 04:29:28 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA3A1A007F for ; Tue, 10 Jun 2014 04:29:28 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 142so3435900ykq.18 for ; Tue, 10 Jun 2014 04:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hPvOKGqBtc8l8TSt8awH/VvZYKfZbOK6w2GT9IuF6w0=; b=JKyxO1uD5qKogVrbtGlJ9JpHCvexQBus0lCC0R1EgSYeGNPyE60Xc2PrL5HO+alxrK H+4cb8mcrty6MPAYJcBmnbkzG6slx5nyn/PW8ZsJgg9jjlc7Uz7NUa2V4prBToWKc/ER LrlHMtpUrtOIxGaI+CiPA4pEoXbL+bD33fZELOomlW6KS+5w3BFATqfvQE2lW3iVt6+O k6pWXTLVjtaqCimY2i19+Rg8YLMnVnd+k3oQolk/2l1ivCNfZJUtGJOe7Zoz4Ko+cb6S Yb6aVmk7XF8S8zBWqVsY+81KODGMm6YpjrytXN1T5qRsYV0d94yNpHjOAt0GxP1KrD4Q oIDA== MIME-Version: 1.0 X-Received: by 10.236.126.9 with SMTP id a9mr12329034yhi.83.1402399767719; Tue, 10 Jun 2014 04:29:27 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Tue, 10 Jun 2014 04:29:27 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F43545E@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F43545E@USMBX1.msg.corp.akamai.com> Date: Tue, 10 Jun 2014 08:29:27 -0300 Message-ID: From: Watson Ladd To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LXOdDBdFp30lqoNekLxHZTIOiXo Cc: "tls@ietf.org" Subject: Re: [TLS] Obstacles to standardizing ECC in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 11:29:29 -0000 On Mon, Jun 9, 2014 at 10:55 PM, Salz, Rich wrote: >> The second is that the CFRG has not yet decided which curves to use. > > My recollection is that CFRG has picked 25519 as its (first perhaps) recommend curve. Sean Turner, which my assist, owes an I-D based on the original paper. I thought this was the case also, but it's very unclear: And the accepted curves extension indicates curves acceptable in certificates, unless I am wildly off base, and we don't quite yet have an ID for Ed25519, which we need for signatures. I would welcome making 25519/Ed25519 MTI. Sincerely, Watson Ladd > > /r$ > > -- > Principal Security Engineer > Akamai Technologies, Cambridge, MA > IM: rsalz@jabber.me; Twitter: RichSalz > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue Jun 10 07:53:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33871A0190 for ; Tue, 10 Jun 2014 07:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EN8drGef_jvL for ; Tue, 10 Jun 2014 07:53:43 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 66D641A017A for ; Tue, 10 Jun 2014 07:53:43 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CAC162864C; Tue, 10 Jun 2014 14:53:42 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id B648B28568; Tue, 10 Jun 2014 14:53:42 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id B3D9580040; Tue, 10 Jun 2014 14:53:42 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Tue, 10 Jun 2014 10:53:42 -0400 From: "Salz, Rich" To: Nikos Mavrogiannopoulos , Martin Thomson Date: Tue, 10 Jun 2014 10:53:32 -0400 Thread-Topic: [TLS] Proposed text for removing renegotiation Thread-Index: Ac+EhM2687Vem64ESzWI2L3SIlBOaQAMQsmg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130F43560C@USMBX1.msg.corp.akamai.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w35xKcGVDPpeFQ_L2nGWyIiNow0 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 14:53:44 -0000 > Could you please cite these security issues. In the 17 years of the proto= col I have only seen one. Which one are you omitting -- Marsh's or triple-handshake? What's the old quote, when there is nothing more to take away... [1] In th= at light, then, can we remove renegotiation without unduly making things wo= rse? So far, it seems to be yes. [1] http://www.quotationspage.com/quote/26979.html -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Tue Jun 10 08:02:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7958E1A01AB; Tue, 10 Jun 2014 08:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3ND-kq8BfvE; Tue, 10 Jun 2014 08:02:04 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E3151B27DF; Tue, 10 Jun 2014 08:02:04 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id j5so502710qaq.40 for ; Tue, 10 Jun 2014 08:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=qMi+UPnYOSUMQROXc2H3z23kJykyHOPsViVKmMeSMsk=; b=syPkiklYLunINr73tHX0ZjwICtG1DD5fArk8ZsuxyjDGUphe65CB/dwf+ThIiZfJMx qfAc9p3sUuk+NLN82C3zUyHhWJvJ60v98fBc/XEg5ELy0SxhYO+29yQiTRb2P0zuUzw3 bn/cCXphi0XyH6QPg7FzmP6N+uK5Xx7JbCNREbCMXhjOx0ikwiU6ibUcCPDru1sFkWNI W/u3Pr8uaO9g/7KqC8PT05JusQ6izJ8BtrPVwwM3cuSVU8WNnq5YMrRz/ToOLTHRDN8j FvH8GJvbgQkeORDCvo7i04CeF9aO8tEznqULaPvUhkWrOHMnbn9ee8B0QuHup4HIa4zX kH/Q== X-Received: by 10.140.48.1 with SMTP id n1mr13696772qga.107.1402412523157; Tue, 10 Jun 2014 08:02:03 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.96.83.106 with HTTP; Tue, 10 Jun 2014 08:01:32 -0700 (PDT) In-Reply-To: <36137A9A-3503-4AF8-80D0-1FB53A7949EA@gmail.com> References: <20140606145220.8187.67355.idtracker@ietfa.amsl.com> <36137A9A-3503-4AF8-80D0-1FB53A7949EA@gmail.com> From: Hugo Krawczyk Date: Tue, 10 Jun 2014 11:01:32 -0400 X-Google-Sender-Auth: UgyLiWocyaQ8Cvms9qXhc7IGS_A Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=001a11350eac458a1f04fb7c9c02 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gSrJQm7UdSiVaP0EZ5oagXRC8ao Cc: "ietf\\@ietf.org" , TLS Mailing List Subject: Re: [TLS] Last Call: (Encrypt-then-MAC for TLS and DTLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:02:06 -0000 --001a11350eac458a1f04fb7c9c02 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The technical results in my 2001 paper are correct but the conclusion regarding SSL/TLS is wrong. I assumed that TLS was using fresh IVs and that the MAC was computed on the encoded plaintext, i.e. Encode-Mac-Encrypt while TLS is doing Mac-Encode-Encrypt which is exactly what my theoretical example shows is insecure. The later padding attacks showed that the theoretical example of insecurity had a very practical instantiation in TLS. While the paper shows correctly that MAC-then-Encrypt can be secure with both CBC and stream ciphers, it also shows that it requires a LOT of care about encoding - it turned out that TLS/SSL was not doing that. So if you want to keep Mac-then-Encrypt then you must change the encoding as well as how you apply the MAC. Changing to Encrypt-then-MAC is a much safer solution. Hugo On Sat, Jun 7, 2014 at 9:15 AM, Yoav Nir wrote: > Hi > > I=E2=80=99ve read the draft and I have a few comments: > > The motivation for this extension is not clear from the draft. The > introduction says that the MAC-then-encrypt construction is =E2=80=9Cno l= onger > regarded as secure=E2=80=9D, and that it has been the subject of =E2=80= =9Cnumerous security > vulnerabilities and attacks=E2=80=9D. For the latter claim, there are no = references > given either in the document itself or in references. For the former two > articles are cited. > The first (reference [5]) is by Hugo Krawczyk. While that article shows a > theoretical weakness of MAC-then-encrypt, it also finds that (quoting fro= m > the abstract) =E2=80=9COn the positive side we show that the > authenticate-then-encrypt method is secure if the encryption method in us= e > is either CBC mode (with an underlying secure block cipher) or a stream > cipher (that xor the data with a random or pseudorandom pad).=E2=80=9D. I= t also > concludes that =E2=80=9Cthe current practical implementations of [SSL] th= at use the > above modes of encryption are safe=E2=80=9D. So this is not a great call = for action. > The second (reference [6]) is a better reference, but I=E2=80=99m still m= issing a > reference to anything practical or close to practical. > > The rationale for the mandate in section 3.1 is not clear to me. Sure, Et= M > is better than MtE, so renegotiating from MtE to EtM is a downgrade, but > there is no mandate for implementations that are configured to support bo= th > algorithms to avoid downgrading from AES-256 to single DES, so why add th= is > here? Also, this section uses the terms =E2=80=9Cstate=E2=80=9D, =E2=80= =9Cstatus=E2=80=9D and =E2=80=9Cmechanism=E2=80=9D > seemingly interchangeably, and doesn=E2=80=99t explain why changing mecha= nism > during renegotiation is a SHOULD NOT-level issue, or how AEAD ciphers > figure in this mandate. > > One more thing, this time a nit: informative reference number 7 describes > a document as =E2=80=9CRFC xxxx=E2=80=9D. This is a reference to > =E2=80=9Cdraft-bmoeller-tls-downgrade-scsv=E2=80=9D, which according to t= he datatracker is > an individual draft that nobody=E2=80=99s asked to publish yet. It should= be > referenced with the draft name as a work in progress. Since it=E2=80=99s = an > informative reference, this won=E2=80=99t block publication of this docum= ent. > > Yoav > > On Jun 6, 2014, at 5:52 PM, The IESG wrote: > > > > > The IESG has received a request from the Transport Layer Security WG > > (tls) to consider the following document: > > - 'Encrypt-then-MAC for TLS and DTLS' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2014-06-20. Exceptionally, comments may > be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document describes a means of negotiating the use of the > > encrypt-then-MAC security mechanism in place of TLS'/DTLS' existing > > MAC-then-encrypt one, which has been the subject of a number of > > security vulnerabilities over a period of many years. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > ID nits found an Obsolete normative reference: "RFC 4366 (ref. '3') > > (Obsoleted by RFC 5246, RFC 6066)" which will be replaced. > > > > _______________________________________________ > > 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 > --001a11350eac458a1f04fb7c9c02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The technical results in my 2001 paper are corr= ect but the conclusion regarding SSL/TLS is wrong. I assumed that TLS was u= sing fresh IVs and that the MAC was computed on the encoded plaintext, i.e.= Encode-Mac-Encrypt while TLS is doing Mac-Encode-Encrypt which is exactly = what my theoretical example shows is insecure. The later padding attacks sh= owed that the theoretical example of insecurity had a very practical instan= tiation in TLS.=C2=A0 While the paper shows correctly that MAC-then-Encrypt= can be secure with both CBC and stream ciphers, it also shows that it requ= ires a LOT of care about encoding - it turned out that TLS/SSL was not doin= g that. So if you want to keep Mac-then-Encrypt then you must change the en= coding as well as how you apply the MAC. Changing to Encrypt-then-MAC is a = much safer solution.

Hugo




On Sat, Jun 7, 2014 at 9:15 AM, Yoav Nir= <ynir.ietf@gmail.com> wrote:
Hi

I=E2=80=99ve read the draft and I have a =C2=A0few comments:

The motivation for this extension is not clear from the draft. The introduc= tion says that the MAC-then-encrypt construction is =E2=80=9Cno longer rega= rded as secure=E2=80=9D, and that it has been the subject of =E2=80=9Cnumer= ous security vulnerabilities and attacks=E2=80=9D. For the latter claim, th= ere are no references given either in the document itself or in references.= For the former two articles are cited.
The first (reference [5]) is by Hugo Krawczyk. While that article shows a t= heoretical weakness of MAC-then-encrypt, it also finds that (quoting from t= he abstract) =E2=80=9COn the positive side we show that the authenticate-th= en-encrypt method is secure if the encryption method in use is either CBC m= ode (with an underlying secure block cipher) or a stream cipher (that xor t= he data with a random or pseudorandom pad).=E2=80=9D. It also concludes tha= t =E2=80=9Cthe current practical implementations of [SSL] that use the abov= e modes of encryption are safe=E2=80=9D. So this is not a great call for ac= tion.
The second (reference [6]) is a better reference, but I=E2=80=99m still mis= sing a reference to anything practical or close to practical.

The rationale for the mandate in section 3.1 is not clear to me. Sure, EtM = is better than MtE, so renegotiating from MtE to EtM is a downgrade, but th= ere is no mandate for implementations that are configured to support both a= lgorithms to avoid downgrading from AES-256 to single DES, so why add this = here? =C2=A0 Also, this section uses the terms =E2=80=9Cstate=E2=80=9D, =E2= =80=9Cstatus=E2=80=9D and =E2=80=9Cmechanism=E2=80=9D seemingly interchange= ably, and doesn=E2=80=99t explain why changing mechanism during renegotiati= on is a SHOULD NOT-level issue, or how AEAD ciphers figure in this mandate.=

One more thing, this time a nit: informative reference number 7 describes a= document as =E2=80=9CRFC xxxx=E2=80=9D. This is a reference to =E2=80=9Cdr= aft-bmoeller-tls-downgrade-scsv=E2=80=9D, which according to the datatracke= r is an individual draft that nobody=E2=80=99s asked to publish yet. It sho= uld be referenced with the draft name as a work in progress. Since it=E2=80= =99s an informative reference, this won=E2=80=99t block publication of this= document.

Yoav

On Jun 6, 2014, at 5:52 PM, The IESG <iesg-secretary@ietf.org> wrote:

>
> The IESG has received a request from the Transport Layer Security WG > (tls) to consider the following document:
> - 'Encrypt-then-MAC for TLS and DTLS'
> =C2=A0<draft-ietf-tls-encrypt-then-mac-02.txt> as Proposed Stand= ard
>
> The IESG plans to make a decision in the next few weeks, and solicits<= br> > final comments on this action. Please send substantive comments to the=
> ietf@ietf.org mailing lists by 20= 14-06-20. 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
>
>
> =C2=A0 This document describes a means of negotiating the use of the > =C2=A0 encrypt-then-MAC security mechanism in place of TLS'/DTLS&#= 39; existing
> =C2=A0 MAC-then-encrypt one, which has been the subject of a number of=
> =C2=A0 security vulnerabilities over a period of many years.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-tls-enc= rypt-then-mac/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-= tls-encrypt-then-mac/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
> ID nits found an Obsolete normative reference: "RFC 4366 (ref. &#= 39;3')
> (Obsoleted by RFC 5246, RFC 6066)" which will be replaced.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

--001a11350eac458a1f04fb7c9c02-- From nobody Tue Jun 10 08:58:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E7D1A01BF for ; Tue, 10 Jun 2014 08:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzpQHhtYI58H for ; Tue, 10 Jun 2014 08:58:21 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A238A1A01A7 for ; Tue, 10 Jun 2014 08:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1402415901; x=1433951901; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=IfdBHVxUShY+Bzf57m2HMKsCkNlXSsw1M6msl1SGm5o=; b=shQou9hc7OwOLsfSQBq/pB4lBgjG0nTiqj7mqz+Z9sf4LKY5+08H6/Ph I9S9X1UaazGgMKcFayGYk+59buHRXTaSIVdhl8F9HXgwxmwTkuZKGn+OM a5rE6YjowyhkWP4H252uKIN7q7Cqm88erCBH8HzwfBs773wkNTVpKjrD5 A=; X-IronPort-AV: E=Sophos;i="4.98,1009,1392116400"; d="scan'208";a="257674042" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 11 Jun 2014 03:58:19 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 11 Jun 2014 03:58:18 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] CCS and key reset and renegotiation Thread-Index: Ac+ExMsoZ2ayMH5PR0ecN/N6iGB4KQ== Date: Tue, 10 Jun 2014 15:58:17 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DEC4F7F@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QsyyfrIofuZ9pdc5kELJThCG5nU Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:58:26 -0000 "Salz, Rich" writes:=0A= =0A= >I wasn't suggesting a set of ladders to replace a state machine. Peter sa= id=0A= >it's not really a state machine but rather a ladder. I was emphasizing tha= t,=0A= >*if this is true*, then a ladder approach is way much better.=0A= =0A= So I did some simple diagrams for SSL years and years ago, see page 10 of= =0A= https://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf. I didn't include= =0A= renegotiation because my code doesn't do it (I'd always seen it as a proble= m,=0A= not a solution) and optional add-ons like client cert auth which can easily= be=0A= added. The whole thing is so obviously a ladder that I never understood wh= y=0A= the RFC tried to make it a state machine.=0A= =0A= (Interestingly, the same page also contains the SSH protocol as a ladder=0A= diagram. SSH does more or less the same thing as TLS, only a lot more=0A= awkwardly, and they don't try and present the protocol as a state machine.= =0A= Mind you they don't do it as a ladder diagram either without a lot of diggi= ng=0A= in the text "both sides send X, then once X has been sent they go on to Y,= =0A= then once that's done they do Z, ...").=0A= =0A= Peter.= From nobody Tue Jun 10 09:04:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD131A01CE for ; Tue, 10 Jun 2014 09:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uancVF1pZ0W for ; Tue, 10 Jun 2014 09:04:22 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 34CA81A01A7 for ; Tue, 10 Jun 2014 09:04:22 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5AG4Lft021866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Jun 2014 12:04:21 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5AG4JR4000473 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2014 12:04:20 -0400 Message-ID: <1402416258.11505.7.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "Salz, Rich" Date: Tue, 10 Jun 2014 18:04:18 +0200 In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F43560C@USMBX1.msg.corp.akamai.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130F43560C@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mw-5ZSyyGuGsMNouRLRZx-73CgQ Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:04:23 -0000 On Tue, 2014-06-10 at 10:53 -0400, Salz, Rich wrote: > > Could you please cite these security issues. In the 17 years of the protocol I have only seen one. > > Which one are you omitting -- Marsh's or triple-handshake? The triple handshake identified many issues in TLS but no issue in the renegotiation. Renegotiation cannot solve the protocol's vulnerability the triple handshake exploits. Nevertheless, you can see the importance of renegotiation in the triple handshake attack by checking the preconditions for the attack. The authors on their website clarify on the vulnerabilities they identified and quoting them for renegotiation: "During renegotiation, both the server and client certificates can change. This is allowed by TLS (and supported in its main implementations) but no definitive guidance is given to applications on how to deal with such changes". Mentioning the lack of application level guidance (for applications that need and make use of it) as a reason to drop renegotiation, is a bit far fetched. regards, Nikos From nobody Tue Jun 10 10:04:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE0E1A022F for ; Tue, 10 Jun 2014 10:04: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwxeDxEu_ydG for ; Tue, 10 Jun 2014 10:04:20 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D2E1A0040 for ; Tue, 10 Jun 2014 10:04:19 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 79so3839652ykr.31 for ; Tue, 10 Jun 2014 10:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U1NtEXCSflOtU93UlA6/opL3l8w93hewlkPlrUW6jHc=; b=0AxZjVqRA5tXEgMjWcBD6+M6R5xH+85tmUZWMbCMs9dTbwQ93pU6VU4nLQS5DDPkJW NwyltiiJas/gVnvanjyMaNZ5OItRWtAWs5gDc32VJZ0LB9OeYaUC0nr4wIcXlZlu0obT no9VabpAf/cTEq4WKqtl6o3HIPFvzhxE2j9ZAD0Jo/sePWsmhiAmA7p3yFCM6OV4oSRZ Tnlu3XPZ7eBp5oqiVL/smc90P7Ysd2L2eubLW3yqBKVnDzd9AB1epg9OvB3gM09p4LCL rlFoGUF0tdKwIM2OkCDNpB0U1taDJlu9hEx3pvTPfFpKIRokZiC/8wl8HvVBub6TDlFN h+ug== MIME-Version: 1.0 X-Received: by 10.236.1.229 with SMTP id 65mr4984353yhd.107.1402419859182; Tue, 10 Jun 2014 10:04:19 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Tue, 10 Jun 2014 10:04:19 -0700 (PDT) In-Reply-To: <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> Date: Tue, 10 Jun 2014 14:04:19 -0300 Message-ID: From: Watson Ladd To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/x6Lv9mVeqDjsmpiu3S9Rx2pnJb0 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 17:04:21 -0000 On Tue, Jun 10, 2014 at 5:19 AM, Nikos Mavrogiannopoulos wrote: > On Mon, 2014-06-09 at 11:17 -0700, Martin Thomson wrote: >> On 9 June 2014 00:34, Nikos Mavrogiannopoulos wrote: >> > Could somebody elaborate on what is that issue and why does it need to >> > be solved? (it is not even mentioned in the TLS 1.3 charter) As someone >> > who follows the mailing list that proposal comes out of the blue with no >> > context whatsoever. >> >> >> I think that this has been covered in the thread, but piecemeal: > > Not in my opinion. The arguments being presented are very vague, as the > ones you quote below. > >> * Renegotiation is a major source of security issues, both of the "we >> screwed the TLS design up" sort and of the "my application didn't >> realize that these things could change" sort. There is a clear desire >> to remove features that enable either sort of problem. > > Could you please cite these security issues. In the 17 years of the > protocol I have only seen one. Triple Handshake depends on renegotiation confusion in part. > >> * Renegotiation is just more protocol complexity. Removing it >> potentially makes implementations simpler. > > Where do you base this conclusion? Have you implemented it and you found > it complex, or have you tried to model it in some formal model and was > impossible? Renegotiation, is one of the most simple parts of the > protocol (Martin Rex argued for that in a previous e-mail and I concur). > Your proposal to solve this "complexity" is more complex than the > current solution. Quick: what is the proper response when the Certificate changes between a negotiation and a renegotiation? What is the relation between the two connections? Can there ever be sensible semantics for this? Renegotiation makes reads block on writes, a problem for all event-based systems. Exposing renegotiation to application level code is hard. Show me a formalization of renegotiation semantics, and I might be convinced otherwise. But to say that it is "not complex" belies the experience of implementors, theorists, and the past 17 years of security The only thing not complex about it is making a terrible implementation that fails to do the right thing. You are right this is not in the charter: security was not placed in it, despite repeated failures on the part of this WG to assure that data protected by TLS is not folded, spindled, mutilated, or read in transit. The complexity of the TLS protocol and its resistance to modeling is directly responsible for many of these flaws, while encouraging the continued use and expansion of several rather poor > >> I think that either might be sufficient justification for removing the feature. > > Not to me. I believe that unless hard evidence of the problems are > presented, this call for action here is unwarranted. > > regards, > Nikos > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue Jun 10 13:00:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F5D1A0332; Tue, 10 Jun 2014 12:59:40 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oI-LS20CL9bU; Tue, 10 Jun 2014 12:59:39 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD3A1A02D0; Tue, 10 Jun 2014 12:59:38 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so3141283wgh.11 for ; Tue, 10 Jun 2014 12:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7CReMo8ryZyMUI0fhbyfXjBIF3PAEYIRz3f30gGCuJI=; b=Czve1MmkGyAUgKzqxu51it/hbnVepVWHcWCvAtZnU0CxZr19KF+rb/bNZHpF3EVGNx zt9nDK5rsNle7pYEvW3v/W9e1/30E+YqyKAPH7sZ93XwOJB6V8cO+JbfZlqDIZhlIPSv sO8VXjptn+6wvc/59aQvfzsy4Fr1cX58QJzzY646E0eTWYvegchamz7oDwJaVrztoIK9 1YRwcdNkpBZKSrOqeStPchm9OVQT747euPeFsyd45V4YzIV91PVr/dW3E80OS3t0Bebq 0Xv1gE/vsY4qSo5MF+/qVnZxWqepIkbQ42zk0U95onNtN2gnMwqoZ5DoqkvwbLgDmCd+ 42tQ== X-Received: by 10.194.175.106 with SMTP id bz10mr7342333wjc.96.1402430377180; Tue, 10 Jun 2014 12:59:37 -0700 (PDT) Received: from [192.168.1.101] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id ey16sm1915527wid.14.2014.06.10.12.59.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 12:59:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_745AF1FA-2345-468C-B408-26F610CF7747" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: Date: Tue, 10 Jun 2014 22:59:32 +0300 Message-Id: <7E22B933-C3EE-4F58-873D-88FEE7C9778F@gmail.com> References: <20140606145220.8187.67355.idtracker@ietfa.amsl.com> <36137A9A-3503-4AF8-80D0-1FB53A7949EA@gmail.com> To: Hugo Krawczyk X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MegIVROmgHqqBORy1OHWYb41Cr4 Cc: "ietf\\@ietf.org" , TLS Mailing List Subject: Re: [TLS] Last Call: (Encrypt-then-MAC for TLS and DTLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:59:40 -0000 --Apple-Mail=_745AF1FA-2345-468C-B408-26F610CF7747 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 10, 2014, at 6:01 PM, Hugo Krawczyk = wrote: > The technical results in my 2001 paper are correct but the conclusion = regarding SSL/TLS is wrong. I assumed that TLS was using fresh IVs and = that the MAC was computed on the encoded plaintext, i.e. = Encode-Mac-Encrypt while TLS is doing Mac-Encode-Encrypt which is = exactly what my theoretical example shows is insecure. The later padding = attacks showed that the theoretical example of insecurity had a very = practical instantiation in TLS. While the paper shows correctly that = MAC-then-Encrypt can be secure with both CBC and stream ciphers, it also = shows that it requires a LOT of care about encoding - it turned out that = TLS/SSL was not doing that. So if you want to keep Mac-then-Encrypt then = you must change the encoding as well as how you apply the MAC. Changing = to Encrypt-then-MAC is a much safer solution. >=20 > Hugo Thanks Yoav= --Apple-Mail=_745AF1FA-2345-468C-B408-26F610CF7747 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jun 10, 2014, at 6:01 = PM, Hugo Krawczyk <hugo@ee.technion.ac.il> = wrote:

The technical = results in my 2001 paper are correct but the conclusion regarding = SSL/TLS is wrong. I assumed that TLS was using fresh IVs and that the = MAC was computed on the encoded plaintext, i.e. Encode-Mac-Encrypt while = TLS is doing Mac-Encode-Encrypt which is exactly what my theoretical = example shows is insecure. The later padding attacks showed that the = theoretical example of insecurity had a very practical instantiation in = TLS.  While the paper shows correctly that MAC-then-Encrypt can be = secure with both CBC and stream ciphers, it also shows that it requires = a LOT of care about encoding - it turned out that TLS/SSL was not doing = that. So if you want to keep Mac-then-Encrypt then you must change the = encoding as well as how you apply the MAC. Changing to Encrypt-then-MAC = is a much safer solution.

Hugo

Thanks

Yoav
<= /body>= --Apple-Mail=_745AF1FA-2345-468C-B408-26F610CF7747-- From nobody Tue Jun 10 16:45:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC8F1A0264 for ; Tue, 10 Jun 2014 16:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CblHFHwHG3HB for ; Tue, 10 Jun 2014 16:45:16 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49AAC1A0195 for ; Tue, 10 Jun 2014 16:45:16 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id w8so3235683qac.39 for ; Tue, 10 Jun 2014 16:45:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dluXd4/gX1gYB/zSVwIWYngKUxUG4dptfqbgkvLMLxQ=; b=GatUG/bztT6Jru68df0V2GA/6vejW8O2lqWVUR5ZNkXDZgJzEBDZxYUezszR/aGwZU pIiBjiWSOuvLpB8c5+0YGSEPQQLbYsU27GJD98t3kyZzpI/bWM/3pyhc/0tk0cpTBT2a tzfowKHED1hw5V1FseyC6VBWDmPOk/3iY+mJHbNBdhV9/d0JI/RRGtOr6xhqUEoofWlc 1DtuZnIAq9A1Vo/T4YeQPo62VKGohKdGEYi60IBbAf0QxZ6B05qNs9ZQKy1KyoBHOQpt XsboTFa+3ptJoReETFg34GY6Nmc1ZzbuO/2dQSOXXu4R9A/Q34wfhJ6xNiB24xgyi7+u 9iwg== X-Gm-Message-State: ALoCoQmflWB1bshSS9US+U6U8XoCpZssM4G8rMBrNPbPWj9dDP+sRq8oaoDVqLfBfV4X31xIi4zC X-Received: by 10.224.36.141 with SMTP id t13mr43643921qad.75.1402443914337; Tue, 10 Jun 2014 16:45:14 -0700 (PDT) Received: from [192.168.1.114] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id i9sm38140833qaq.14.2014.06.10.16.45.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 16:45:13 -0700 (PDT) Message-ID: <5397988B.1040706@nthpermutation.com> Date: Tue, 10 Jun 2014 19:45:15 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C738DEC4F7F@uxcn10-tdc06.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738DEC4F7F@uxcn10-tdc06.UoA.auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Wc62XuUo-kv4nrC1O2Lh-JLOLOA Subject: Re: [TLS] CCS and key reset and renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 23:45:18 -0000 On 6/10/2014 11:58 AM, Peter Gutmann wrote: > "Salz, Rich" writes: > >> I wasn't suggesting a set of ladders to replace a state machine. Peter said >> it's not really a state machine but rather a ladder. I was emphasizing that, >> *if this is true*, then a ladder approach is way much better. > So I did some simple diagrams for SSL years and years ago, see page 10 of > https://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf. I didn't include > renegotiation because my code doesn't do it (I'd always seen it as a problem, > not a solution) and optional add-ons like client cert auth which can easily be > added. The whole thing is so obviously a ladder that I never understood why > the RFC tried to make it a state machine. The issue with understanding TLS via state machines is that it's not one state machine, but more like 6 - Client and server versions of a) negotiate cipher suite, b) negotiate keys, c) authenticate. The three state machines on either side are interconnected - events in one state machine trigger transitions in other state machines. Messages sent/received related to specific state machines are interleaved in TLS in an attempt to reduce roundtrips. Generally, if you can express things as a ladder diagram, you can find a way of expressing them as a state machine and vice versa. I tend to prefer state machines because I can generally figure out if I'm missing something (e.g. dead states, unhandled messages, exception handling). Ladder diagrams are linear, and don't give you great indications of how the exception cases are handled. But both have their place. Ladder diagrams are especially helpful when you're dealing with more than 2 entities and/or protocols and trying to understand who knows what when. Mike > > (Interestingly, the same page also contains the SSH protocol as a ladder > diagram. SSH does more or less the same thing as TLS, only a lot more > awkwardly, and they don't try and present the protocol as a state machine. > Mind you they don't do it as a ladder diagram either without a lot of digging > in the text "both sides send X, then once X has been sent they go on to Y, > then once that's done they do Z, ..."). > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Jun 10 16:56:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424241A0264 for ; Tue, 10 Jun 2014 16:56: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ieNy1iTlpx6 for ; Tue, 10 Jun 2014 16:56:09 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84381A00FD for ; Tue, 10 Jun 2014 16:56:08 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id f8so146342wiw.10 for ; Tue, 10 Jun 2014 16:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Tps0Nvh6TVp5TuK4yFVfaSFSHDyh3O+3YYHrbQF4298=; b=ZJJkRYkOc5BDgCFIj+dPyTYHBcOAAoMk3x/sYxqUBD3lCEMUVKgg4HwqfOZPkwOt7S tXPMW8SXuAHmJnTR2L3WgzapA7r+aq0r8dHQFgFcBdK15GBvzUcqzuCgFMXpyzmligUT PS6vx7fsw8biDOYTded6K99RsN/AhvKFh1ERW/ztLw4TDk4ku+Xu4y3nAbPh+mzAVs9S XTJY+evijThq5W4vwcoqEq4wkiYeOEuBxV7kLiMLHjWW4jUnkTUNR1AJ58DLAfdEMrCf u6i2KZFgcrPDVDMu++vkAQiQaV1+L1DEgRVWyvSpK4lYyZ80dCCxjw/UU+1jevT7Y16F /BmA== MIME-Version: 1.0 X-Received: by 10.194.7.36 with SMTP id g4mr46185718wja.37.1402444567202; Tue, 10 Jun 2014 16:56:07 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Tue, 10 Jun 2014 16:56:07 -0700 (PDT) Date: Tue, 10 Jun 2014 16:56:07 -0700 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7ky-U2mKLO3jWclS_GAu1NafzDs Subject: [TLS] On editorial discretion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 23:56:10 -0000 The talk about the various merits and drawbacks of state machines vs. ladder diagrams is distracting. Might I recommend that we leave this to editorial discretion? I'm sure that our editor won't mind receiving input in the form of proposals, if anyone cares enough to generate them. From nobody Tue Jun 10 19:56:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4FF1A0360 for ; Tue, 10 Jun 2014 19:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcrkahSsif45 for ; Tue, 10 Jun 2014 19:56:39 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18A5C1A035E for ; Tue, 10 Jun 2014 19:56:39 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id db12so6643122veb.7 for ; Tue, 10 Jun 2014 19:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tBtSi2f2u+gcqGDv6FVOxp77wtqmNIuOxoRMTnaaXyc=; b=eWFgQXaf46EL5lIWraNlneIYQGZipgvXapztQdzYwfNmzypwUPRHqIEUv+nNPS9eyT WuKVzuCasqjfS3Az7QnB0Q9AxSwvmXkvkqknGYP+mnfDbLkG4pkpxlFCFrU7wlpnnXJf 17N//FY1Npo+lJAhECQ5oS1RBus5TgRi3vrr0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tBtSi2f2u+gcqGDv6FVOxp77wtqmNIuOxoRMTnaaXyc=; b=GFEJEeE8gtVT/yPRzwdJySk7GWSQ5xHD59wo80EhEBX37TNvSo05yThy8biB2poPRq 03tO97Y0ShhOoA3CaUeDymrT829ReQ2/0jDD5zfAceaNO1ocLi3kGp3iflkzr1pBkH6j yYhZ1QnG5SYb6EK+JNu2J51Iyd2CNc1ctHi1bL0OXADu28KjUJwGqnbm+JaNvpvvTXEt MinL4CkVrH3nIBvgEMJ8lcXFn6awTDQJWDKFIVg2vPX8CKv/0da2XiAlqt9u6pIQFtqh soZOnnsDQ2fKCAoEntYH+uVkv8nkc4+ZmambiqswmpSCVUq4wQ3QCH4tnmGDFkfd/QSJ tdnA== X-Gm-Message-State: ALoCoQl+Zcg4ZPTP3ZMKART9xyDwpWQpRvOuOKUDz57ggtzDXuGOkekRPMzFE3U4xO/nK5onsqnW X-Received: by 10.58.120.195 with SMTP id le3mr15562223veb.7.1402455398183; Tue, 10 Jun 2014 19:56:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.106.39 with HTTP; Tue, 10 Jun 2014 19:56:18 -0700 (PDT) In-Reply-To: References: <537A5429.4030002@amacapital.net> From: Tom Ritter Date: Tue, 10 Jun 2014 22:56:18 -0400 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b5d2626d28ccb04fb8697ce Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OnsgL1MYcBiFj2MaW0j4iGT4-h0 Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 02:56:40 -0000 --047d7b5d2626d28ccb04fb8697ce Content-Type: text/plain; charset=ISO-8859-1 On 19 May 2014 15:26, Martin Thomson wrote: > On 19 May 2014 12:04, Adam Langley wrote: > > On Mon, May 19, 2014 at 11:57 AM, Andy Lutomirski > wrote: > >> There is a lot of redundancy here. The type, version, and length appear > >> twice. Of those, the version appears to be almost completely pointless, > >> and the type and length don't need to appear twice. If I'm counting > >> right, fixing this will save six bytes in every record. > > > > Putting the version in every record is a waste, but TLSPlaintext and > > TLSCiphertext don't work in the way that you think: the type, version > > and length aren't repeated on the wire. TLSPlaintext is more of a > > conceptual structure. A TLS record, on the wire, contains only the 5 > > byte header of the TLSCiphertext. > > > Bad presentation in RFC 5246 notwithstanding, I think that Andy's > proposal has merit. This drops the version, encrypts the type. > An advantage of encrypting the content type is making it possible for TLS padding to be built-in for no additional bytes. The existing content Content Type means no padding, and a new Content Type means the plaintext is padded, and the receiver should strip off the padding after decryption and ignore it. Encrypting the Content Type is necessary for this approach so that an observer can't be certain there is padding happening or not. -tom --047d7b5d2626d28ccb04fb8697ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 1= 9 May 2014 15:26, Martin Thomson <martin.thomson@gmail.com><= /span> wrote:
On 19 May 2014 12:04, Adam L= angley <agl@google.com> wrote:<= br> > On Mon, May 19, 2014 at 11:57 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> There is a lot of redundancy here. =A0The type, version, and lengt= h appear
>> twice. =A0Of those, the version appears to be almost completely po= intless,
>> and the type and length don't need to appear twice. =A0If I= 9;m counting
>> right, fixing this will save six bytes in every record.
>
> Putting the version in every record is a waste, but TLSPlaintext and > TLSCiphertext don't work in the way that you think: the type, vers= ion
> and length aren't repeated on the wire. TLSPlaintext is more of a<= br> > conceptual structure. A TLS record, on the wire, contains only the 5 > byte header of the TLSCiphertext.


Bad presentation in RFC 5246 notwithstanding, I think that Andy's=
proposal has merit. =A0This drops the version, encrypts the type.


An advantage of encrypting the co= ntent type is making it possible for TLS padding to be built-in for no addi= tional bytes. The existing content Content Type means no padding, and a new= Content Type means the plaintext is padded, and the receiver should strip = off the padding after decryption and ignore it. =A0Encrypting the Content T= ype is necessary for this approach so that an observer can't be certain= there is padding happening or not.

-tom
--047d7b5d2626d28ccb04fb8697ce-- From nobody Wed Jun 11 00:45:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80E71A0451 for ; Wed, 11 Jun 2014 00:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9q8l6IL446if for ; Wed, 11 Jun 2014 00:44:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4571A0061 for ; Wed, 11 Jun 2014 00:44:46 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5B7iiub004986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Jun 2014 03:44:44 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5B7igOx030824 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 03:44:43 -0400 Message-ID: <1402472681.2305.2.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Tom Ritter Date: Wed, 11 Jun 2014 09:44:41 +0200 In-Reply-To: References: <537A5429.4030002@amacapital.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hzv9MmBDm3uuIyYbWbaRJqri9fU Cc: "tls@ietf.org" Subject: Re: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 07:44:47 -0000 On Tue, 2014-06-10 at 22:56 -0400, Tom Ritter wrote: > An advantage of encrypting the content type is making it possible for > TLS padding to be built-in for no additional bytes. TLS padding can be built-in for no additional bytes and for no change in outside format of the TLS record: http://tools.ietf.org/html/draft-pironti-tls-length-hiding-02 regards, Nikos From nobody Wed Jun 11 01:45:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAF81B2830 for ; Wed, 11 Jun 2014 01:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOFCMViZLQLM for ; Wed, 11 Jun 2014 01:45:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2703A1A037C for ; Wed, 11 Jun 2014 01:45:08 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5B8j6Vs032691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Jun 2014 04:45:06 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5B8j4aM012486 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 04:45:05 -0400 Message-ID: <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Watson Ladd Date: Wed, 11 Jun 2014 10:45:04 +0200 In-Reply-To: References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0QtLzljRqJtX6AgYO5nkLzMyBJ8 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 08:45:10 -0000 On Tue, 2014-06-10 at 14:04 -0300, Watson Ladd wrote: > Quick: what is the proper response when the Certificate changes > between a negotiation and a renegotiation? That is on the application protocol to decide. > What is the relation between the two connections? Can there ever be > sensible semantics for this? > Renegotiation makes reads block on writes, a problem for all > event-based systems. Exposing renegotiation to application level code > is hard. It has been done already, and not only once. Could you provide evidence of this hardness that you claim? > Show me a formalization of renegotiation semantics, and I might be > convinced otherwise. I think it is up to the one proposing the change to provide evidence of the contrary and there has been none so far. Otherwise we do things like prove me TLS secure combination or we drop it completely. Formal models lag behind protocols. > But to say that it is > "not complex" belies the experience of implementors, theorists, and > the past 17 years of security It's good to know that you are representing them. Could you share your experience with implementing or modeling TLS? Or at least cite some document that backs up the claims that you make. regards, Nikos From nobody Wed Jun 11 04:46:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6CA1B2864 for ; Wed, 11 Jun 2014 04:45:52 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2GfQ3hfPO7H for ; Wed, 11 Jun 2014 04:45:51 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75171A004A for ; Wed, 11 Jun 2014 04:45:51 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f10so1476219yha.10 for ; Wed, 11 Jun 2014 04:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GBtY15G8WStaXcl8om8dL+HoSFoKULUjQL5cmGAtkhI=; b=eBlvwjTgEFnJSNOYoViFAELzT/Nlj5NAfzFYSes5DuKHhXDX+RVrAxq4h6RxnhDjn/ wpu72GeLTUq/PX72xHRGz+rYvrymf3bLo4HXaAtxpzvJSzDs54/dLvNEp9+XsjO6Sg4d YGog87DyLQKd5VdE3UnVTkpL8NZJrIsfpkqPvlU4wM9qxr1NkjOKzWQM+Qg0NyOYzXwH 3kQBHux8TkDtfQpWGHJ1qaNXRCajc/sIzOUwMTd++C3GdA4LSTgktYpSb+4I54wQEljt pH2ntpjYUZgqdI3whm6K4jj09g9Nz8/17qldASWr6x02juc/w/S8GEGhIrgjMtPBJDjH HWYw== MIME-Version: 1.0 X-Received: by 10.236.126.9 with SMTP id a9mr4956615yhi.83.1402487150808; Wed, 11 Jun 2014 04:45:50 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Wed, 11 Jun 2014 04:45:50 -0700 (PDT) In-Reply-To: <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> Date: Wed, 11 Jun 2014 08:45:50 -0300 Message-ID: From: Watson Ladd To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/82Qdbt1rVuezBoJ_nho_sJy31UA Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 11:45:53 -0000 On Wed, Jun 11, 2014 at 5:45 AM, Nikos Mavrogiannopoulos wrote: > On Tue, 2014-06-10 at 14:04 -0300, Watson Ladd wrote: > >> Quick: what is the proper response when the Certificate changes >> between a negotiation and a renegotiation? > > That is on the application protocol to decide. Always the wrong answer: we know more then the application layer people do about security, just as the networking people know more than we do about sending packets through the network. > >> What is the relation between the two connections? Can there ever be >> sensible semantics for this? >> Renegotiation makes reads block on writes, a problem for all >> event-based systems. Exposing renegotiation to application level code >> is hard. > > It has been done already, and not only once. Could you provide evidence > of this hardness that you claim? Where has this been done? As for the hardness, most applications expect a stream of bytes. Renegotation is OOB data. > >> Show me a formalization of renegotiation semantics, and I might be >> convinced otherwise. > > I think it is up to the one proposing the change to provide evidence of > the contrary and there has been none so far. Otherwise we do things like > prove me TLS secure combination or we drop it completely. Formal models > lag behind protocols. You guessed what the next email from me when EKR posted his draft was going to say. Since miTLS finished up this has been a reasonable position: TLS 1.2 has fairly well understood security, so TLS 1.3 should be better, not worse. Or do you think that three attacks in three years is acceptable? But as for theory vs. practice, that is false: there have been secure key exchange protocols since the dawn of cryptography. The reason the protocols have been hard to analyze is gratuitous complexity: there is no reason TLS could not have used a secure key exchange as IPSEC eventually did. Where is the usecase that needs renegotiation in TLS 1.3? I've not seen it: we've provided alternatives for all of them. Why do you care what we do to provide an easy protocol to analyze? If there is a case for keeping renegotation, make it: don't a > >> But to say that it is >> "not complex" belies the experience of implementors, theorists, and >> the past 17 years of security > > It's good to know that you are representing them. Could you share your > experience with implementing or modeling TLS? Or at least cite some > document that backs up the claims that you make. Let's see: there's the discussion in the Triple Handshake paper of how applications respond to these changes, the previous renegotiation bug, virtually every paper on the TLS handshake until miTLS, etc. Can you point to someone providing an adequate explanation of what renegotation does? > > regards, > Nikos > > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Jun 11 07:47:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CE71A0127 for ; Wed, 11 Jun 2014 07:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCAVYqJZ6pHD for ; Wed, 11 Jun 2014 07:47:14 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B01F1A00FA for ; Wed, 11 Jun 2014 07:47:14 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jw12so8302972veb.11 for ; Wed, 11 Jun 2014 07:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GrrPxRodnS4LOFMENzi9DLsullVjeIaAHURG2eLRZkM=; b=wBBMi60LK2vGBRGqeEMq+lOgQqu7qtQbSoNHzc3NKgJOX89Y86vNaTRnDInSO9ea/r qZwaJGTwmem+DCp/Ru6m96UZ8hblZ2sbSUmyqWjX4H+jbDz0DLkjf0GYvlTb9TRK816Z LozjDK2NpgoPwc5s2J5rExUSUz4T1qQXx8hFI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GrrPxRodnS4LOFMENzi9DLsullVjeIaAHURG2eLRZkM=; b=FU2mcVgdFTo8Qk5gai+j1SNfT4toMjq1kMRmWXRresMp012sxMhiccX9Ec2Km9NScG 3+OSdiPjyah3WdpRAcof679uXZav3izOgLhvav9Eip0cZva4vOjzTtisGCmSrkWY9wdc 9uQupxNhG1heT6P9kWcNlNtXZ5k1YUzaWNZPzu5lB0bFbBGDnyP3eeMkYpE5tLIDkWg2 /ImkRgZaVZI0tw4QYR3sn5TeBhVnVZLiJrLEa9tOT5DM4CYRykWYZ6UMrIn6qUVcQSwF wcsSbDvaunfjT6p5BeXjmM6778rEzAElKmlPyKAto5TCAOhOgCZaoo0R6nhSZGv3Xn6r RuRA== X-Gm-Message-State: ALoCoQn1XBWEckLQOx2ia6CAf7oWSkEoWNfGhwB3ysNos91P2z2wCYLjWDksZBl4ENLHviCul9XD X-Received: by 10.52.5.129 with SMTP id s1mr3562369vds.31.1402498033257; Wed, 11 Jun 2014 07:47:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.106.39 with HTTP; Wed, 11 Jun 2014 07:46:53 -0700 (PDT) In-Reply-To: <1402472681.2305.2.camel@dhcp-2-127.brq.redhat.com> References: <537A5429.4030002@amacapital.net> <1402472681.2305.2.camel@dhcp-2-127.brq.redhat.com> From: Tom Ritter Date: Wed, 11 Jun 2014 10:46:53 -0400 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=20cf302efab01227ff04fb90851d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9gJT4xy1DEXrj2xlmyFtMCeU2HE Cc: "tls@ietf.org" Subject: Re: [TLS] Simplifying the record protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 14:47:15 -0000 --20cf302efab01227ff04fb90851d Content-Type: text/plain; charset=ISO-8859-1 On 11 June 2014 03:44, Nikos Mavrogiannopoulos wrote: > On Tue, 2014-06-10 at 22:56 -0400, Tom Ritter wrote: > > > An advantage of encrypting the content type is making it possible for > > TLS padding to be built-in for no additional bytes. > > TLS padding can be built-in for no additional bytes and for no change in > outside format of the TLS record: > http://tools.ietf.org/html/draft-pironti-tls-length-hiding-02 > > I would strongly prefer padding not to require an extension and be built in. While some extensions could be protected in an encrypted handshake (See Type B extensions in [0]), this would require a significant change to extensions and I'm not banking on it. So assuming that extensions are in the clear, I would prefer an observer be unsure if there is padding or not. This is especially important because a large class of attacks we want to defend against are passive attacks, where the observer has only a single traffic stream and wants to try correlation, and is unable to induce multiple sends or streams with which to try statistical or timing correlation. (Re-reading the draft and minutes[1]) I believe that the padding in this draft, if we remove the extension, would add an additional two bytes to all messages to be unambiguous and indicate if there is padding or not. If I'm wrong about that, I don't think I'm the only one so I'd be happy to be corrected. My goal is to get padding support (for receiving, not necessarily sending) built in to the protocol, with no additional on-wire bytes for people who don't want to pad, and with no plaintext indicators of whether padding is being done or not. -tom [0] http://www.ietf.org/proceedings/interim/2014/05/15/tls/slides/slides-interim-2014-tls-1-4.pdf [1] http://www.ietf.org/proceedings/interim/2014/05/15/tls/minutes/minutes-interim-2014-tls-1 around "Padding issues " --20cf302efab01227ff04fb90851d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 1= 1 June 2014 03:44, Nikos Mavrogiannopoulos <nmav@redhat.com> w= rote:
On Tue, 2014-06-10 at 22:56 -0400, Tom Rit= ter wrote:

> An advantage of encrypting the content type is making it possible = for
> TLS padding to be built-in for no additional bytes.

TLS padding can be built-in for no additional bytes and for no change= in
outside format of the TLS record:
http://tools.ietf.org/html/draft-pironti-tls-length-hiding= -02


I would strongly prefer pad= ding not to require an extension and be built in. While some extensions cou= ld be protected in an encrypted handshake (See Type B extensions in [0]), t= his would require a significant change to extensions and I'm not bankin= g on it. =A0So assuming that extensions are in the clear, I would prefer an= observer be unsure if there is padding or not.

This is especially important because a large class of a= ttacks we want to defend against are passive attacks, where the observer ha= s only a single traffic stream and wants to try correlation, and is unable = to induce multiple sends or streams with which to try statistical or timing= correlation.

(Re-reading the draft and minutes[1]) I believe t= hat the padding in this draft, if we remove the extension, would add an add= itional two bytes to all messages to be unambiguous and indicate if there i= s padding or not. If I'm wrong about that, I don't think I'm th= e only one so I'd be happy to be corrected.

My goal is to get padding support (for receiving, not n= ecessarily sending) built in to the protocol, with no additional on-wire by= tes for people who don't want to pad, and with no plaintext indicators = of whether padding is being done or not.=A0

-tom

[0]=A0htt= p://www.ietf.org/proceedings/interim/2014/05/15/tls/slides/slides-interim-2= 014-tls-1-4.pdf
[1]=A0http://www.ietf= .org/proceedings/interim/2014/05/15/tls/minutes/minutes-interim-2014-tls-1<= /a> around "Padd= ing issues "
--20cf302efab01227ff04fb90851d-- From nobody Wed Jun 11 09:08:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A801A01E7 for ; Wed, 11 Jun 2014 09:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfMR9l5bOX7d for ; Wed, 11 Jun 2014 09:08:02 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) (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 862ED1A01A5 for ; Wed, 11 Jun 2014 09:08:02 -0700 (PDT) Received: from Odysseus.missi.ncsc.mil (odysseus.missi.ncsc.mil [144.51.60.172]) by stingray.missi.ncsc.mil with ESMTP id s5BG81PZ043738 for ; Wed, 11 Jun 2014 12:08:01 -0400 (EDT) Received: from PINTO.missi.ncsc.mil ([fe80::60c7:cec6:b35c:deed]) by Odysseus.missi.ncsc.mil ([fe80::a8ee:8532:895b:b420%14]) with mapi id 14.03.0181.006; Wed, 11 Jun 2014 12:08:01 -0400 From: "Kemp, David P." To: "tls@ietf.org" Thread-Topic: [TLS] Proposed text for removing renegotiation Thread-Index: AQHPhVGEfA6PTH75QESiVYAkFY18F5tsDc0A///9z+A= Date: Wed, 11 Jun 2014 16:08:00 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC8CB7F66D6@PINTO.missi.ncsc.mil> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.60.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8cnds29ac99FcgT26rxxAOw234E Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:08:10 -0000 A decision on the proper place to do access control has nothing to do with = the skill of implementers. If a web server (or any service provider) doesn't know how to grant access = to resources based on authenticated user identity, user attributes, resourc= e attributes and access policy, then a perfect bug-free network stack is no= t going to help them. If a "certificate changes", then either the application should have request= ed renegotiation synchronously or it should have asynchronously established= conditions for when the stack renegotiates and registered to be notified w= hen it happens. The proper response to renegotiation is identical to the p= roper response to negotiating the first time. "We know more than the application layer people" - pure hubris. TLS/IPSEC = practitioners should definitely know more about cryptography, which applica= tion developers should be able to largely ignore as a black box. But acces= s control to application resources is inherently an application function fo= r which TLS library coding expertise is no substitute. -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Watson Ladd Sent: Wednesday, June 11, 2014 7:46 AM To: Nikos Mavrogiannopoulos Cc: tls@ietf.org Subject: Re: [TLS] Proposed text for removing renegotiation On Wed, Jun 11, 2014 at 5:45 AM, Nikos Mavrogiannopoulos = wrote: > On Tue, 2014-06-10 at 14:04 -0300, Watson Ladd wrote: > >> Quick: what is the proper response when the Certificate changes=20 >> between a negotiation and a renegotiation? > > That is on the application protocol to decide. Always the wrong answer: we know more then the application layer people do = about security, just as the networking people know more than we do about se= nding packets through the network. From nobody Wed Jun 11 11:01:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9699D1B27C4 for ; Wed, 11 Jun 2014 11:01:20 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkwLNIbCKf6V for ; Wed, 11 Jun 2014 11:01:19 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 27C201B27C0 for ; Wed, 11 Jun 2014 11:01:19 -0700 (PDT) Received: from [10.70.10.68] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 51F1AF984 for ; Wed, 11 Jun 2014 14:01:16 -0400 (EDT) Message-ID: <5398995F.2080106@fifthhorseman.net> Date: Wed, 11 Jun 2014 14:01:03 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: "TLS@ietf.org (tls@ietf.org)" References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F4F@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F4F@USMBX1.msg.corp.akamai.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lElug8JTlu1f0KqX3V5obMtm9rJm8DW3p" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8oK3IdkiCxcqRTxxe_5_20vVXX8 Subject: Re: [TLS] Pre-IETF meeting? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 18:01:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lElug8JTlu1f0KqX3V5obMtm9rJm8DW3p Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/06/2014 11:30 PM, Salz, Rich wrote: > At the Interim, we talked about meeting for a day before the next IETF.= Have we decided? FWIW, I can't stay afterwards. I would very much appreciate nailing this down, if possible. during the day Sunday July 20th (overlapping only with the usual rampup and and IEPG, no?) would be preferable for me, rather than trying to extend to Saturday beforehand. How do we make this decision? --dkg --lElug8JTlu1f0KqX3V5obMtm9rJm8DW3p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTmJlfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcvFgP/27cv2+6GwbRQ5V7gx8zX6XM xLVxPs9I7uLSP3AQPsmJBhU/vhnPulPITTwrYYUTpr7w2wZtq5yoK+xyeCAi3bDz GZTDVUbg9ei/BEKSEAodAKZsQmk3k0thu/tL2qn2C/LBSZ9ISxlj/9XZZK8Mx6Mm f5eRFgUYwQxFKVcxnCGkoq48UH23Dc54RkYpGJn0RXIpHevjERWwJx2ZohNu5Kh3 l5AGvO81Yxq28ceb1y4DA0RMC5s8B2ty+fmX46fioIYgW6tTgQnJMKcLif3SANWg QXPDC7QEdw22pgMr6mhWsAzkq58trawPbJNJpdbKFeecS5PpfoEz3nzZ7yZ/XVtu KZQf38YK00tTTEoflI4RFMFdqBypSkNl+ew5oTSDo560CYDWf0ikpMxgWYk0+eqP J0ZdD7TSFGhftSa3c1VKLe295TaRwfMGVEPZWBaBBtUqru/BL3ihpruqHUsZLg60 3Xr5/7uSW7CQ7KWB83GIvEmLqVylkcWYYPzT9xfxXGhljeafUK/4Mky67TMQ117l MrQy0GPTJvq/241zNx+qA7ivO9VSrwiPlf9mfFMfcVdxkrF6ziQuNHxc8mInc6rU 29pAcJr6tQdcLLQFIQl5GTDzkxxL8M/OEnozpdDWoJSppn6WQeZ0AiBik31DchLQ 9fIV7GnNfzDiZuGw6xQW =z5d5 -----END PGP SIGNATURE----- --lElug8JTlu1f0KqX3V5obMtm9rJm8DW3p-- From nobody Wed Jun 11 11:10:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01AD1B27DF for ; Wed, 11 Jun 2014 11:10:48 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oFd_b03h5Hw for ; Wed, 11 Jun 2014 11:10:47 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C36B1A0254 for ; Wed, 11 Jun 2014 11:10:46 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so1644268wiv.2 for ; Wed, 11 Jun 2014 11:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+g+mMHamdLJv5Z4s69FaD7UNyNWVh99TYnHAYqPL4/A=; b=gp2l/wBf/bPtCcf225iafld+M3DjQk1PpSkGM64L5FcLdl7xOQEGVUbD9RE0KUR5Oo pbvSUE3aV1kIPMFcvIHfS9RaF2CgDcIKRZ9KpUs9sl4Aauxa9rNd2cLyoZft5lf/4xbQ tWaRJENKd5EttCAurjtBqgnk+ORoIVx2XjkeDvhe++reafOR6NyIBCybUDprO/z7/JrK VuHvpfwf5Em2ZJGYv/u0mBV6hcLpn1BMzTjxjClAxUrAU7KCDusroYFIrwwCXPSr+g3p 9pPhk+rcqmEy9SLO3Kd5D6NBVFYq6UdnOg1Kz8T/+1yYrNmPFzntSA2KUw8SiPkYODrv +pSw== MIME-Version: 1.0 X-Received: by 10.194.133.1 with SMTP id oy1mr7129542wjb.87.1402510245737; Wed, 11 Jun 2014 11:10:45 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Wed, 11 Jun 2014 11:10:45 -0700 (PDT) In-Reply-To: <5398995F.2080106@fifthhorseman.net> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F4F@USMBX1.msg.corp.akamai.com> <5398995F.2080106@fifthhorseman.net> Date: Wed, 11 Jun 2014 11:10:45 -0700 Message-ID: From: Martin Thomson To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/98XrzTzx6-nD-dUP0djl14ATeUw Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Pre-IETF meeting? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 18:10:49 -0000 On 11 June 2014 11:01, Daniel Kahn Gillmor wrote: > How do we make this decision? Hopefully not http://www.random.org/coins/?num=1&cur=60-ddm.1mark I know that other working groups have successfully gathered input on availability using http://doodle.com/. I'd be happy to drive that if it helps expedite a conclusion. From nobody Wed Jun 11 11:15:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A881B27F0 for ; Wed, 11 Jun 2014 11:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILi7KSKkl58A for ; Wed, 11 Jun 2014 11:15:25 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A9D1A00D4 for ; Wed, 11 Jun 2014 11:15:25 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so122410wgg.9 for ; Wed, 11 Jun 2014 11:15:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lIZ6PrcLnSRklHTqSzxYYgQbvr7TvU29tfwofpVTvVo=; b=NKF7j+KMdwUsVg3tnbnYZimMYAj5XIsA1W+Lb5UVQgf7CZqZ/3ff4pJ0hW/SsbUDfL es2ykfYHC+zyxrk3E1KQVqID6XYMqapFw8GNEbjxY13X6x/9HjbQeOT/aDix1MI0o1at hEI3lyrEyATfkMzQ/k/0oV9KqRBS6BLbqGaHDpV7fmN37WBzDyZSde9+qRZXWPYanU8k vKTijItyAtSyhIE8AmffvEVV4PPg7j3qEHJpx2o7sn6MeBH12CNolbr/9KrNTbLhaA64 fQ3fs7LChiHXscbvy9HcUUaVzFlT2g2/9c+FAN1GiRhuL/9qbgc+h4I9bTbsVLxghjF3 +0KA== X-Gm-Message-State: ALoCoQnA16VvhkiMNR+0fAJ2/rtvKxLZio7wiy3+qbGON7j5rFGUOQutqXAEyx2cxwxlSIqWehUA X-Received: by 10.180.76.132 with SMTP id k4mr33216914wiw.1.1402510523842; Wed, 11 Jun 2014 11:15:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 11 Jun 2014 11:14:43 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <5398995F.2080106@fifthhorseman.net> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F4F@USMBX1.msg.corp.akamai.com> <5398995F.2080106@fifthhorseman.net> From: Eric Rescorla Date: Wed, 11 Jun 2014 11:14:43 -0700 Message-ID: To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=f46d0435c02291729004fb936d00 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EtTgSxhi4I5TM-kx46ALX_Q8qBQ Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Pre-IETF meeting? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 18:15:27 -0000 --f46d0435c02291729004fb936d00 Content-Type: text/plain; charset=UTF-8 We'll be discussing this on the chair's call tomorrow. We need to figure out what the other constraints are. Expect an update tomorrow PM Best -Ekr On Wed, Jun 11, 2014 at 11:01 AM, Daniel Kahn Gillmor wrote: > On 06/06/2014 11:30 PM, Salz, Rich wrote: > > At the Interim, we talked about meeting for a day before the next IETF. > Have we decided? FWIW, I can't stay afterwards. > > I would very much appreciate nailing this down, if possible. during the > day Sunday July 20th (overlapping only with the usual rampup and and > IEPG, no?) would be preferable for me, rather than trying to extend to > Saturday beforehand. > > How do we make this decision? > > --dkg > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --f46d0435c02291729004fb936d00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We'll be discussing this on the chair's call tomor= row. We need to figure
out what the other constraints are. Expect an up= date tomorrow PM

Best
-Ekr



On Wed, Jun 11, 2014 at 11:01 AM, Daniel Kahn Gillmor <= span dir=3D"ltr"><dkg@fifthhorseman.net> wrote:
On 06/06/2014 11:30 PM, Salz= , Rich wrote:
> At the Interim, we talked about meeting for a day before the next IETF= . =C2=A0Have we decided? =C2=A0FWIW, I can't stay afterwards.

I would very much appreciate nailing this down, if possible. =C2=A0du= ring the
day Sunday July 20th (overlapping only with the usual rampup and and
IEPG, no?) would be preferable for me, rather than trying to extend to
Saturday beforehand.

How do we make this decision?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --dkg


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


--f46d0435c02291729004fb936d00-- From nobody Wed Jun 11 12:37:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF2E1B2896 for ; Wed, 11 Jun 2014 12:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUIIoN1xQb2G for ; Wed, 11 Jun 2014 12:37:04 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF03C1B2889 for ; Wed, 11 Jun 2014 12:37:04 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB417.namprd03.prod.outlook.com (10.141.92.12) with Microsoft SMTP Server (TLS) id 15.0.954.9; Wed, 11 Jun 2014 19:37:02 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0954.000; Wed, 11 Jun 2014 19:37:02 +0000 From: Andrei Popov To: Martin Thomson Thread-Topic: [TLS] Proposed text for removing renegotiation Thread-Index: AQHPefQqRTsIIFK8gk6N5dkaAVUiXZtVJ/UAgAEX8YCADnobgIABFBgAgAALywCAApynAIAAs6aAgAAEdjCAADDigIAC+Ggg Date: Wed, 11 Jun 2014 19:37:01 +0000 Message-ID: <319344a622ba450aa60d454fd9f97135@BL2PR03MB419.namprd03.prod.outlook.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.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:ed31::2] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(979002)(6009001)(428001)(13464003)(189002)(199002)(51704005)(377454003)(24454002)(15202345003)(81542001)(2656002)(54356999)(101416001)(74316001)(77096999)(83322001)(86362001)(87936001)(99396002)(76176999)(76576001)(85852003)(99286001)(83072002)(74502001)(92566001)(80022001)(21056001)(15975445006)(33646001)(79102001)(19580405001)(4396001)(46102001)(76482001)(81342001)(86612001)(31966008)(74662001)(19580395003)(50986999)(77982001)(20776003)(64706001)(93886003)(24736002)(3826001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB417; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G471OpcoXhiqTRkmiqbiTPQ9-Ro Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 19:37:08 -0000 VGhhbmtzIE1hcnRpbiBmb3IgcG9pbnRpbmcgb3V0IHRoZSB1cGRhdGVkIGh0dHBiaXMtY2FudCBJ LUQgb24gZ2l0aHViLiBJdCBzZWVtcyB0byBwcm92aWRlIHRoZSBzYW1lIGNlcnRpZmljYXRlIGZp bHRlcmluZyBmYWNpbGl0aWVzIGFzIHRoZSBDZXJ0aWZpY2F0ZVJlcXVlc3QuDQoNClRoZXJlIGFy ZSBvdGhlciBzaWduaWZpY2FudCBwcm9ibGVtcyB3aXRoIHRoZSByZW1vdmFsIG9mIHJlbmVnb3Rp YXRpb24gZnJvbSBUTFMgMS4zIChwbGVhc2UgY29ycmVjdCBtZSBpZiBJJ20gbWlzc2luZyBzb21l dGhpbmcpOg0KMS4gQW4gZXhpc3RpbmcgSFRUUC8xLjEgc2VydmVyIGNhbm5vdCB0YWtlIGFkdmFu dGFnZSBvZiBUTFMgMS4zIGlmIFRMUyBjbGllbnQgYXV0aCBpcyByZXF1aXJlZC4gVGhpcyBpcyBi ZWNhdXNlIGFuIGV4aXN0aW5nIEhUVFAvMS4xIHNlcnZlciBpcyBub3QgYXdhcmUgb2YgaHR0cGJp cy1jYW50Lg0KMi4gQW4gSFRUUC8yIHNlcnZlciByZXF1aXJlcyBhbiB1cGRhdGVkIFRMUyBzdGFj ayB3aXRoIHRscy1jYXJlIHN1cHBvcnQgaW4gb3JkZXIgdG8gcGVyZm9ybSBUTFMgY2xpZW50IGF1 dGguIFRoaXMgaXMgYmVjYXVzZSBIVFRQLzIgcHJvaGliaXRzIHJlbmVnb3RpYXRpb24uDQozLiBF dmVuIHdpdGggdGhlIHVwZGF0ZWQgVExTIHN0YWNrIGluIHBsYWNlLCBhbiBIVFRQLzIgc2VydmVy IGNhbm5vdCBuZWdvdGlhdGUgVExTIDEuMiBhbmQgZWFybGllciBpZiBUTFMgY2xpZW50IGF1dGgg aXMgcmVxdWlyZWQuIFRoaXMgaXMgYmVjYXVzZSBUTFMgMS4yIGFuZCBlYXJsaWVyIHdvdWxkIHNl bmQgdGhlIGNsaWVudCBjZXJ0IGluIHRoZSBjbGVhciwgd2hpY2ggaXMgYmFkIGZvciBjbGllbnQg cHJpdmFjeS4NCjQuIFdpdGhvdXQgcmVuZWdvdGlhdGlvbiwgVExTIGNsaWVudCBhdXRoIHJlcXVp cmVzIGFkZGl0aW9uYWwgcm91bmQtdHJpcHMgdG8gZXN0YWJsaXNoIGEgbmV3IFRDUCBjb25uZWN0 aW9uLg0KDQpQZXJoYXBzIHRoZSBmdW5kYW1lbnRhbCBwcm9ibGVtIGlzIHRoYXQgaHR0cGJpcy1j YW50IGludHJvZHVjZXMgYSBjbGllbnQgYXV0aGVudGljYXRpb24gY2hhbGxlbmdlIGluIEhUVFAg dGhhdCBjYW5ub3QgYmUgc2F0aXNmaWVkIGF0IHRoZSBIVFRQIGxheWVyLiBUaGlzIGJyZWFrcyB0 aGUgcHJvdG9jb2wgbGF5ZXJpbmcsIGFuZCBjYXVzZXMgdGhlIHR5cGVzIG9mIGhhcmQtdG8tbWFu YWdlIGRlcGVuZGVuY2llcyBsaXN0ZWQgYWJvdmUuDQoNCkV2ZW4gaWYgaHR0cGJpcy1jYW50IGFu ZCB0bHMtY2FyZSBib3RoIGJlY29tZSBSRkNzLCBhbmQgZ2V0IGNvbW1vbmx5IGltcGxlbWVudGVk LCBhbmQgZ2V0IHdpZGVseSBkZXBsb3llZCwgSSBiZWxpZXZlIHRoYXQgdGhlIHJlbW92YWwgb2Yg cmVuZWdvdGlhdGlvbiBmcm9tIFRMUyAxLjMgY3JlYXRlcyBtb3JlIHByb2JsZW1zIHRoYW4gaXQg c29sdmVzLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21d IA0KU2VudDogTW9uZGF5LCBKdW5lIDksIDIwMTQgMjoyOCBQTQ0KVG86IEFuZHJlaSBQb3Bvdg0K Q2M6IE5pa29zIE1hdnJvZ2lhbm5vcG91bG9zOyB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb VExTXSBQcm9wb3NlZCB0ZXh0IGZvciByZW1vdmluZyByZW5lZ290aWF0aW9uDQoNCk9uIDkgSnVu ZSAyMDE0IDExOjQ5LCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPiB3 cm90ZToNCj4+IFRoZSBmb3JtZXIgd2UgaGF2ZSBkZWNpZGVkIHRvIHNvbHZlIGluIEhUVFAuDQo+ DQo+IEFyZSB5b3UgcmVmZXJyaW5nIHRvIHRoZXNlIEktRHM6DQo+IGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXRob21zb24taHR0cGJpcy1jYW50LTAwDQo+IGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXRob21zb24tdGxzLWNhcmUtMDANCj4NCj4gSHR0cGJpcy1jYW50 IHRhbGtzIChyYXRoZXIgdmFndWVseSkgYWJvdXQgdXNpbmcgInJlYWxtIiBvciAib3RoZXIgY2hh bGxlbmdlIHBhcmFtZXRlcnMiIHRvIHNlbGVjdCBhbiBhcHByb3ByaWF0ZSBjbGllbnQgY2VydC4g SSB0aGluayBjbGllbnQgY2VydCBzZWxlY3Rpb24gc2hvdWxkIGJlIGNsZWFybHkgc3BlY2lmaWVk IGJlZm9yZSB3ZSBjYW4gc2F5IHRoYXQgdGhlIG1pZC1zZXNzaW9uIGNsaWVudCBhdXRoIHByb2Js ZW0gaGFzIGJlZW4gc29sdmVkLCBhbmQgcmVtb3ZlIHJlbmVnb3RpYXRpb24gZnJvbSBUTFMgMS4z Lg0KDQpUaGUgc2VsZWN0aW9uIHByb2JsZW0gaXMsIGFzIHdlIGRpc2N1c3NlZCBpbiBEZW52ZXIs IHdvcnRoIGFkZHJlc3NpbmcuDQpUaGUgc2hvcnQgdGVybSBmaXggaW4gSFRUUC8yIHdpbGwgYWN0 dWFsbHkgYmUgdG8gZm9yY2UgdGhlc2UgdXNlcnMgZG93biB0byBIVFRQLzEuMS4gIFRoYXQncyBz dWJvcHRpbWFsLCBjZXJ0YWlubHksIGJ1dCBpdCBkb2VzIGZpeCB0aGUgaW1tZWRpYXRlIHByb2Js ZW0uDQoNCkFzIGZhciBhcyB0aGUgLWNhbnQgZHJhZnQgZ29lcywgSSBzaW1wbHkgaGF2ZW4ndCB1 cGxvYWRlZCBhbiB1cGRhdGVkIHZlcnNpb24gYWZ0ZXIgb3VyIGRpc2N1c3Npb24gaW4gRGVudmVy LiAgVGhlcmUncyBhIHdvcmsgaW4gcHJvZ3Jlc3MgdmVyc2lvbiBvbiBnaXRodWI6DQpodHRwOi8v bWFydGludGhvbXNvbi5naXRodWIuaW8vZHJhZnRzL2RyYWZ0LXRob21zb24taHR0cGJpcy1jYW50 Lmh0bWwNCg0KPiBJdCB3b3VsZCBiZSBldmVuIGJldHRlciB0byBzb2x2ZSB0aGlzIHByb2JsZW0g YXQgdGhlIFRMUyBsYXllciwgc28gdGhhdCBlYWNoIGFwcGxpY2F0aW9uIHByb3RvY29sIGRvZXMg bm90IG5lZWQgdG8gY29tZSB1cCB3aXRoIGEgc2VwYXJhdGUgc29sdXRpb24uIEFuZCBhdm9pZGlu ZyB0aGUgcm91bmQtdHJpcHMgaW52b2x2ZWQgaW4gZXN0YWJsaXNoaW5nIGEgVENQIGNvbm5lY3Rp b24gd291bGQgYmUgYXdlc29tZSwgdG9vLiBUaGUgY3VycmVudCBzb2x1dGlvbiB1c2luZyByZW5l Z290aWF0aW9uIGhhcyBib3RoIG9mIHRoZXNlIGRlc2lyYWJsZSBwcm9wZXJ0aWVzLg0KDQpJJ20g c3ltcGF0aGV0aWMgdG8gdGhpcywgYnV0IGlmIEhUVFAgaXMgdGhlIG9ubHkgb25lIHRoYXQgd2Fu dHMgdGhpcyBwYXJ0aWN1bGFyIGZlYXR1cmUsIHRoZW4gd2UgYXJlIGJldHRlciBvZmYgbGVhdmlu ZyB0aGVtIHRvIHdvcmsgYXJvdW5kIHRoaXMuICBBdCBsZWFzdCBpbiBteSBvcGluaW9uLg0K From nobody Wed Jun 11 12:41:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596FF1B289D for ; Wed, 11 Jun 2014 12:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3k0tnjDbKHY for ; Wed, 11 Jun 2014 12:41:55 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD8F1B289B for ; Wed, 11 Jun 2014 12:41:55 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB420.namprd03.prod.outlook.com (10.141.92.25) with Microsoft SMTP Server (TLS) id 15.0.959.24; Wed, 11 Jun 2014 19:41:54 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0954.000; Wed, 11 Jun 2014 19:41:54 +0000 From: Andrei Popov To: Nikos Mavrogiannopoulos , "Salz, Rich" Thread-Topic: [TLS] Proposed text for removing renegotiation Thread-Index: AQHPefQqRTsIIFK8gk6N5dkaAVUiXZtVJ/UAgAEX8YCADnobgIABFBgAgAALywCAApynAIAAs6aAgADrcICAAG31AIAAE8UAgAHOO2A= Date: Wed, 11 Jun 2014 19:41:53 +0000 Message-ID: References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C7130F43560C@USMBX1.msg.corp.akamai.com> <1402416258.11505.7.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: <1402416258.11505.7.camel@dhcp-2-127.brq.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(377454003)(24454002)(199002)(189002)(377424004)(51704005)(13464003)(77096999)(79102001)(50986999)(54356999)(77982001)(76176999)(86612001)(76576001)(46102001)(87936001)(33646001)(2656002)(86362001)(21056001)(4396001)(92566001)(74316001)(81342001)(80022001)(15975445006)(83072002)(19580395003)(81542001)(19580405001)(83322001)(101416001)(99396002)(99286001)(31966008)(20776003)(76482001)(74502001)(74662001)(85852003)(64706001)(93886003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB420; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UEWNMr1k16kDjcAw83jseQGa5K4 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 19:41:57 -0000 In any case, the triple handshake vulnerability has to be fixed, at least i= n TLS1.2 and below. The same fix would likely apply to TLS1.3, so IMHO trip= le handshake does not necessitate the removal of renegotiation from TLS1.3. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Nikos Mavrogiannopoulo= s Sent: Tuesday, June 10, 2014 9:04 AM To: Salz, Rich Cc: tls@ietf.org Subject: Re: [TLS] Proposed text for removing renegotiation On Tue, 2014-06-10 at 10:53 -0400, Salz, Rich wrote: > > Could you please cite these security issues. In the 17 years of the pro= tocol I have only seen one. >=20 > Which one are you omitting -- Marsh's or triple-handshake? The triple handshake identified many issues in TLS but no issue in the rene= gotiation. Renegotiation cannot solve the protocol's vulnerability the trip= le handshake exploits. Nevertheless, you can see the importance of renegotiation in the triple han= dshake attack by checking the preconditions for the attack. The authors on= their website clarify on the vulnerabilities they identified and quoting t= hem for renegotiation: "During renegotiation, both the server and client ce= rtificates can change. This is allowed by TLS (and supported in its main im= plementations) but no definitive guidance is given to applications on how t= o deal with such changes". Mentioning the lack of application level guidance (for applications that ne= ed and make use of it) as a reason to drop renegotiation, is a bit far fetc= hed. regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jun 11 13:01:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C09B1A0273 for ; Wed, 11 Jun 2014 13:01:45 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwDB5WaoWCGE for ; Wed, 11 Jun 2014 13:01:43 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1A91A026D for ; Wed, 11 Jun 2014 13:01:43 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id p10so254104wes.20 for ; Wed, 11 Jun 2014 13:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Axbg98c9q6+cSOS5msl3wohVIpSdTm1gaBTn82b9C4Q=; b=dbXDQDuQxychF9YslWHHUDJz/tZYAPYEeLwQfSrTJjPEYZSrQ90wRkfIGtWKxWLMrU nUoR6xl2Co2RNjrVnKsh1s1elTtDeS1rrilrNQFsJdMQUXf2HkOGAxmMO1Z8r+ilUxKK 3NUapTg0SLL98QOVQTDXxwY2cVVBo6u3DsnDb7V8PpdaGDYZ8e5FHFOdn0PU+CfBcEUC F+mhuGuialKVImIkYLGc/K4SmZ5zH089o2m7vqG6NDX01kEnG2bLX/Z5yN7l6lFunQlt 057NV3h5LAog5bnam3xfFA33dkuMrVC7cHDCYPvEs/nlAyfbYxcVkHsjCTtbwgqtZy6V +8mQ== MIME-Version: 1.0 X-Received: by 10.180.19.233 with SMTP id i9mr144652wie.38.1402516901772; Wed, 11 Jun 2014 13:01:41 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Wed, 11 Jun 2014 13:01:41 -0700 (PDT) In-Reply-To: <319344a622ba450aa60d454fd9f97135@BL2PR03MB419.namprd03.prod.outlook.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <319344a622ba450aa60d454fd9f97135@BL2PR03MB419.namprd03.prod.outlook.com> Date: Wed, 11 Jun 2014 13:01:41 -0700 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PNA1GxH6Sa1Q7W1-FbGLqMIJQCI Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 20:01:45 -0000 To establish a bit more context here: the consensus in HTTPbis is to provide a mechanism whereby servers are able to downgrade to HTTP/1.1 for the purposes of corner cases that are only properly supported by HTTP/1.1. Aside from some interesting legacy scenarios, client authentication was considered a major reason for this feature. We decided not to adopt something like the -cant draft at the current time, since the more generic capability was also needed. On 11 June 2014 12:37, Andrei Popov wrote: > 1. An existing HTTP/1.1 server cannot take advantage of TLS 1.3 if TLS client auth is required. This is because an existing HTTP/1.1 server is not aware of httpbis-cant. Correct. That makes something like -cant a prerequisite of an upgrade to TLS 1.3 for those servers. > 2. An HTTP/2 server requires an updated TLS stack with tls-care support in order to perform TLS client auth. This is because HTTP/2 prohibits renegotiation. This can be worked around. In fact, the proposed text permits renegotiation in TLS 1.2 (there is no "earlier" here because we prohibit the use of earlier versions) prior to starting HTTP/2: https://github.com/http2/http2-spec/pull/514/files#diff-8894168382f6487e5e38c4306e613a88R3430 (This isn't in the main spec due to a dependency issue, that text captures the established consensus from the most recent interim meeting.) > 3. Even with the updated TLS stack in place, an HTTP/2 server cannot negotiate TLS 1.2 and earlier if TLS client auth is required. This is because TLS 1.2 and earlier would send the client cert in the clear, which is bad for client privacy. See above workaround. The cost there is an additional round trip (if you do false start, that is, it's a lot more without). > 4. Without renegotiation, TLS client auth requires additional round-trips to establish a new TCP connection. Correct. From nobody Wed Jun 11 15:49:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0791B28CB for ; Wed, 11 Jun 2014 15:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-BfP0s4GGb1 for ; Wed, 11 Jun 2014 15:49:55 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB63E1A02EE for ; Wed, 11 Jun 2014 15:49:54 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id i17so723501qcy.8 for ; Wed, 11 Jun 2014 15:49:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JDVD96T7XY/Hq5C2wjHgxcvub6GuqdLAhZu7G9bDuNU=; b=LysCXpGVlYlkuHPl8Z3NRhR6E9z5er5sYkBu+QBa4Y6IxqMq8e/vsQQzOVHjpAkvaT eFXv2H9SZHBBeDM0MoxdN/YR/R8XdyokuEp2YcUyp94EZDpSOg92e8/0oxE7rF92DzXT tjjaS7lIDk5JJ0FOJOla65vK1hwUp4dvZyG5wwJjbhqGHTuO4tbZqBT8jDnOmRK4nRkP SPKOfZRBcngUnsQUXBhy1n9k+JZph+cjf+jm4175cy6YZjOjAkBudGIAeZmVaAvJBqp6 WCKdu5JmZQP8qr7y2EXIh4dmm3VAZDOlKdeFOW6D6eQmDREZEcCdTrnIVl5nYqG7ttl1 PySA== X-Gm-Message-State: ALoCoQlkm75xVTRy/K8a/ppPtFC5iJ1ExX9y7AnOtt6OPhZq+rXjY5JbjvEmQk3JXbi9SRu04CRB MIME-Version: 1.0 X-Received: by 10.140.89.202 with SMTP id v68mr17959599qgd.71.1402526993931; Wed, 11 Jun 2014 15:49:53 -0700 (PDT) Received: by 10.224.212.3 with HTTP; Wed, 11 Jun 2014 15:49:53 -0700 (PDT) In-Reply-To: <5390CA45.1050504@nthpermutation.com> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <5390B1D6.5010105@nthpermutation.com> <5390CA45.1050504@nthpermutation.com> Date: Wed, 11 Jun 2014 15:49:53 -0700 Message-ID: From: Brian Smith To: Michael StJohns Content-Type: multipart/alternative; boundary=001a11c1182e432a3804fb9743dc Archived-At: http://mailarchive.ietf.org/arch/msg/tls/V55-l1-7vv8VT8h90ZS6KU3RuaU Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 22:49:58 -0000 --001a11c1182e432a3804fb9743dc Content-Type: text/plain; charset=UTF-8 On Thu, Jun 5, 2014 at 12:51 PM, Michael StJohns wrote: > On 6/5/2014 3:12 PM, Brian Smith wrote: > >> Is it really significantly easier for CAs to add new certificate policies >> compared to adding new certificate extensions? I could see how that could >> be the case, but I think it would be good to hear from CAs about this. >> > > Mostly the "put a policy object in the ca certificate" reduces to > "configure the text string of the OIDs you want to include". > https://www.openssl.org/docs/apps/x509v3_config.html#Certificate_Policies_ > for example. > > The certificate policy extension is pretty well formed, which means that > its pretty easy to specify in configuration language (e.g. xml, > label=value) what you want to be included rather than having to go back and > add new ASN1 encode/decode/translate to and from string logic. Things like > Dogtag and EJBCA support it via a gui I have researched some of the pros and cons of Michael's policy-based approach. I also implemented it in a private copy of mozilla::pkix and Firefox. In particular, I made it so: * When the extension is present in the end-entity certificate, that a valid "Good" OCSP response must be provided in the TLS handshake, * There will never be any fallback to OCSP fetching or CRLs or cache lookups when the end-entity certificate has the must-staple policy. However, additional certificate trust information (blacklists/CRLSet) are still consulted. * The modified mozilla::pkix will never build a path from an end-entity certificate or sub-CA to a higher-level CA certificate where the higher-level CA certificate has the Must-Staple policy but the end-entity or lower-level sub-CA certificate doesn't have the Must-staple policy. * My modified mozilla::pkix enforces a maximum OCSP response lifetime of 2 days + slop (1 day) = 3 days if Must-Staple is present, instead of 10 days. The good news: * In mozilla::pkix and Firefox, it is just as easy to implement Machael's policy-based approach as it would be to implement the approach outlined in the draft. * As Michael said, most if not all CA software already supports custom certificate policies, so there is *no* new code required on the CA side for Machael's approach. This is a significant advantage, especially because there are a lot of companies that have purchased sub-CA certificates that chain to publicly-trusted CAs, which use closed-source software (e.g. Microsoft's). Basically, with Michael's approach, everybody would be able to use Must-Staple straight away, if they want to, without writing code. The bad news: * TLS intercepting proxies cause trouble. In particular, some (if not all) versions of Microsoft Threat Management Gateway forge their fake certificates by copying the certificate policies from the original certificate that they are trying to impersonate. Yet, Microsoft TMG does not support OCSP stapling or in fact any kind of OCSP. Consequently, it will copy the Must-Staple policy into the forged certificate but it won't staple a response. I imagine other TLS intercepting proxies will do the same. * It is unclear what TLS intercepting proxies do with certificate extensions that they don't understand. I would guess that some copy those extensions into their forged certificates and others do not. The OK news: * From what I've found, Microsoft TMG forges certificates that are very short lived (24hrs). Thus, if we make an exception that short-lived certificates (<= 48 hours) with the Must-Staple feature do not need to have a stapled OCSP response even with Must-Staple, we can probably avoid a lot of the issues with TLS intercepting proxies, regardless of how the Must-Staple feature is encoded in the certificate. Thus, for ease-of-deployment reasons, I prefer Michael's policy-based approach + the short-lived certificate exception over the approach in the draft that uses a new extension. Regardless of which of those two approaches is taken, we'll need to do a lot of interop testing with various kinds of TLS intercepting proxies. Cheers, Brian --001a11c1182e432a3804fb9743dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 5, 2014 at 12:51 PM, Michael StJohns <msj@nthpermutation.com= > wrote:
On 6/5/2014 3:12 PM, Brian S= mith wrote:
Is it really significantly easier for CAs to add new certificate policies c= ompared to adding new certificate extensions? I could see how that could be= the case, but I think it would be good to hear from CAs about this.

Mostly the "put a policy object in the ca certificate" reduces to= "configure the text string of the OIDs you want to include". https://www.openssl.org/docs/apps/x509v3_= config.html#Certificate_Policies_ for example.

The certificate policy extension is pretty well formed, which means that it= s pretty easy to specify in configuration language (e.g. xml, label=3Dvalue= ) what you want to be included rather than having to go back and add new AS= N1 encode/decode/translate to and from string logic. =C2=A0Things like Dogt= ag and EJBCA support it via a gui

I have researched some of the pros and con= s of Michael's policy-based approach. I also implemented it in a privat= e copy of mozilla::pkix and Firefox. In particular, I made it so:

* When the extension is present in the end-entity certificate, that a valid= "Good" OCSP response must be provided in the TLS handshake,
<= /div>
* There will never be any fallback to OCSP fetching or CRLs or ca= che lookups when the end-entity certificate has the must-staple policy. How= ever, additional certificate trust information (blacklists/CRLSet) are stil= l consulted.
* The modified mozilla::pkix will never build a path from an end= -entity certificate or sub-CA to a higher-level CA certificate where the hi= gher-level CA certificate has the Must-Staple policy but the end-entity or = lower-level sub-CA certificate doesn't have the Must-staple policy.
* My modified mozilla::pkix enforces a maximum OCSP response lif= etime of 2 days + slop (1 day) =3D 3 days if Must-Staple is present, instea= d of 10 days.

The good news:
* In mozilla::= pkix and Firefox, it is just as easy to implement Machael's policy-base= d approach as it would be to implement the approach outlined in the draft.<= br>
* As Michael said, most if not all CA software already supports = custom certificate policies, so there is *no* new code required on the CA s= ide for Machael's approach. This is a significant advantage, especially= because there are a lot of companies that have purchased sub-CA certificat= es that chain to publicly-trusted CAs, which use closed-source software (e.= g. Microsoft's). Basically, with Michael's approach, everybody woul= d be able to use Must-Staple straight away, if they want to, without writin= g code.

The bad news:
* TLS intercepting proxies cause= trouble. In particular, some (if not all) versions of Microsoft Threat Man= agement Gateway forge their fake certificates by copying the certificate po= licies from the original certificate that they are trying to impersonate. Y= et, Microsoft TMG does not support OCSP stapling or in fact any kind of OCS= P. Consequently, it will copy the Must-Staple policy into the forged certif= icate but it won't staple a response. I imagine other TLS intercepting = proxies will do the same.
* It is unclear what TLS intercepting proxies do with certificat= e extensions that they don't understand. I would guess that some copy t= hose extensions into their forged certificates and others do not.

The OK news:
* From what I've found, Microsoft= TMG forges certificates that are very short lived (24hrs). Thus, if we mak= e an exception that short-lived certificates (<=3D 48 hours) with the Mu= st-Staple feature do not need to have a stapled OCSP response even with Mus= t-Staple, we can probably avoid a lot of the issues with TLS intercepting p= roxies, regardless of how the Must-Staple feature is encoded in the certifi= cate.

Thus, for ease-of-deployment reasons, I prefer Michael's= policy-based approach + the short-lived certificate exception over the app= roach in the draft that uses a new extension. Regardless of which of those = two approaches is taken, we'll need to do a lot of interop testing with= various kinds of TLS intercepting proxies.

Cheers,
Brian

--001a11c1182e432a3804fb9743dc-- From nobody Wed Jun 11 16:10:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35241B28B5 for ; Wed, 11 Jun 2014 16:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mL771pt9Vjhd for ; Wed, 11 Jun 2014 16:10:50 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88011B28D2 for ; Wed, 11 Jun 2014 16:10:49 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id ik5so6914vcb.35 for ; Wed, 11 Jun 2014 16:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JB03FP7xFv/ovtXYdidckGZa2rnswbVhVzkqyxUao7I=; b=ApUJ8vANcoIrIg9wZXYUpN726eK+D8ZlbQ++KOVt4E+E+J8HPTwE268SeTbQ7OvEoK Xp4wOa5R81UBP+bvqYR1dswF+mdPQZo+kGVVi21VxLS2n9kmveDUnFxq9dz8sySnIuQG x+Dwb9T0TdaggiKdumKpdIoiOrOIiQnjIl/oRdmkN+pbpIP5xVRafBHfU8CbJXMBlD9x h+IHXwZc1CF5XXnEI3RgYcCc71s7DZPc7zKFkQ6dxFMJCpZxiU8QdaSNFWuym8BozWmr +Q1HvW4bOWblXBak4fwh+G63vAoHV7dca2gYgvYqTrnovuIsVh1t+9EmCnSt6hCPosWp VCUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JB03FP7xFv/ovtXYdidckGZa2rnswbVhVzkqyxUao7I=; b=KZAG522VoIsLVHe/ei+TSzQoKVfgtIl6M0aWagUbtaXecVrJStfFFnFgiWZlfdBjze 8RoamNrR9ZGkCDm4P5QG4mOX/G/EP68D3IQshP3kvqzmUlpY/gb7SHRjlXGn2oKNjm2q FOxcbjgMqI1wu9gdaCbGBArb9BwkHSmNbvUv8pJbWUvnb9ncUfDIXFOd1V0hjHA2ZGJk orAuHBpNFw/wWmOEag4QMCf2bCrJpWWU9H8mO25dAFeenVTTTSSF2g2d0aWPZ5NpRzn0 1HksE5Ugd8J5WR0dGkmKL5ioeiHjm6N3A7x4Xo2Q55T2V6XHhv8y3cIXvDVSA9up1UuC t9IQ== X-Gm-Message-State: ALoCoQlArTQfWNQeRxbMMc8TNR0giruAWLuOl2Xr/OkVVdH6d3VX5oQW0t07AgAMGmVbsPEBDo+R X-Received: by 10.53.12.229 with SMTP id et5mr5234863vdd.32.1402528247986; Wed, 11 Jun 2014 16:10:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.179.1 with HTTP; Wed, 11 Jun 2014 16:10:26 -0700 (PDT) In-Reply-To: References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <5390B1D6.5010105@nthpermutation.com> <5390CA45.1050504@nthpermutation.com> From: Adam Langley Date: Wed, 11 Jun 2014 16:10:26 -0700 Message-ID: To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JDqthfMVAlzK7rDvaruqnyaV7uQ Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 23:10:51 -0000 On Wed, Jun 11, 2014 at 3:49 PM, Brian Smith wrote: > * TLS intercepting proxies cause trouble. In Chrome (and, I assume, Firefox) there's the concept of a "non-public root" - i.e. a CA root that the user has installed. When one is used on a connection we disable pinning. We could also disable Must Staple. Cheers AGL From nobody Wed Jun 11 17:22:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755DA1B28F2 for ; Wed, 11 Jun 2014 17:22:22 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoY9wrEpEi8l for ; Wed, 11 Jun 2014 17:22:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9232D1B28E0 for ; Wed, 11 Jun 2014 17:22:19 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB417.namprd03.prod.outlook.com (10.141.92.12) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 12 Jun 2014 00:22:17 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0954.000; Thu, 12 Jun 2014 00:22:17 +0000 From: Andrei Popov To: Martin Thomson Thread-Topic: [TLS] Proposed text for removing renegotiation Thread-Index: AQHPefQqRTsIIFK8gk6N5dkaAVUiXZtVJ/UAgAEX8YCADnobgIABFBgAgAALywCAApynAIAAs6aAgAAEdjCAADDigIAC+GgggAAUEoCAAEUNkA== Date: Thu, 12 Jun 2014 00:22:15 +0000 Message-ID: <71550d53435b46c9960e3151eee71180@BL2PR03MB419.namprd03.prod.outlook.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <319344a622ba450aa60d454fd9f97135@BL2PR03MB419.namprd03.prod.outlook.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:ed31::2] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(24454002)(377454003)(13464003)(189002)(199002)(83072002)(85852003)(4396001)(76482001)(64706001)(83322001)(19580395003)(33646001)(77982001)(92566001)(46102001)(20776003)(80022001)(19580405001)(81342001)(79102001)(74662001)(74502001)(31966008)(81542001)(15975445006)(99396002)(2656002)(87936001)(99286001)(101416001)(50986999)(54356999)(86362001)(21056001)(76176999)(77096999)(74316001)(76576001)(93886003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB417; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EskcrfZ9tfRW4k4W5jsnmaLnZoo Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 00:22:22 -0000 PiB0aGUgY29uc2Vuc3VzIGluIEhUVFBiaXMgaXMgdG8gcHJvdmlkZSBhIG1lY2hhbmlzbSB3aGVy ZWJ5IHNlcnZlcnMgYXJlIGFibGUgdG8gZG93bmdyYWRlIHRvIEhUVFAvMS4xIGZvciB0aGUgcHVy cG9zZXMgb2YgY29ybmVyIGNhc2VzIHRoYXQgYXJlIG9ubHkgcHJvcGVybHkgc3VwcG9ydGVkIGJ5 IEhUVFAvMS4xLg0KSSBjYW4ndCBoZWxwIG5vdGljaW5nIHRoYXQgdGhpcyBzZWVtcyB0byBkaXJl Y3RseSBjb250cmFkaWN0IHRoZSAjMSBpdGVtIG9uIHRoZSBIVFRQYmlzIFdHIGNoYXJ0ZXI6DQoi IFRoZSBXb3JraW5nIEdyb3VwJ3Mgc3BlY2lmaWNhdGlvbiBkZWxpdmVyYWJsZXMgYXJlOg0KICog QSBkb2N1bWVudCAob3Igc2V0IG9mIGRvY3VtZW50cykgdGhhdCBpcyBTVUlUQUJMRSBUTyBTVVBF UkNFREUgUkZDIDI2MTYgYXMNCiB0aGUgZGVmaW5pdGlvbiBvZiBIVFRQLzEuMSBhbmQgbW92ZSBS RkMgMjgxNyB0byBIaXN0b3JpYyBzdGF0dXMiDQpCdXQgSSBndWVzcyB0aGlzIGlzIHVwIHRvIHRo ZSBIVFRQYmlzIFdHIHRvIGRpc2N1c3M6KQ0KDQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9odHRwMi9o dHRwMi1zcGVjL3B1bGwvNTE0L2ZpbGVzI2RpZmYtODg5NDE2ODM4MmY2NDg3ZTVlMzhjNDMwNmU2 MTNhODhSMzQzMCANClRoZXJlIGFyZSBhdCBsZWFzdCB0d28gcHJvdG9jb2wgbGF5ZXJpbmcgdmlv bGF0aW9ucyBpbiB0aGlzIHRleHQsIHdoaWNoIEkgdGhpbmsgd2lsbCBjYXVzZSBwcm9ibGVtczoN CjEpIFByZXZlbnRpbmcgdGhlIHVzZSBvZiByZW5lZ290aWF0aW9uIGluIHJlc3BvbnNlIHRvIGEg cmVxdWVzdCBmb3IgYSBzcGVjaWZpYyBwcm90ZWN0ZWQgcmVzb3VyY2UsIGFuZA0KMikgQ29uc3Ry YWluaW5nIHRoZSBUTFMgY2lwaGVyIHN1aXRlcyB0byBiZSB1c2VkIHdpdGggSFRUUC8yLg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzpt YXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDExLCAyMDE0 IDE6MDIgUE0NClRvOiBBbmRyZWkgUG9wb3YNCkNjOiBOaWtvcyBNYXZyb2dpYW5ub3BvdWxvczsg dGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gUHJvcG9zZWQgdGV4dCBmb3IgcmVtb3Zp bmcgcmVuZWdvdGlhdGlvbg0KDQpUbyBlc3RhYmxpc2ggYSBiaXQgbW9yZSBjb250ZXh0IGhlcmU6 IHRoZSBjb25zZW5zdXMgaW4gSFRUUGJpcyBpcyB0byBwcm92aWRlIGEgbWVjaGFuaXNtIHdoZXJl Ynkgc2VydmVycyBhcmUgYWJsZSB0byBkb3duZ3JhZGUgdG8gSFRUUC8xLjEgZm9yIHRoZSBwdXJw b3NlcyBvZiBjb3JuZXIgY2FzZXMgdGhhdCBhcmUgb25seSBwcm9wZXJseSBzdXBwb3J0ZWQgYnkg SFRUUC8xLjEuDQoNCkFzaWRlIGZyb20gc29tZSBpbnRlcmVzdGluZyBsZWdhY3kgc2NlbmFyaW9z LCBjbGllbnQgYXV0aGVudGljYXRpb24gd2FzIGNvbnNpZGVyZWQgYSBtYWpvciByZWFzb24gZm9y IHRoaXMgZmVhdHVyZS4gIFdlIGRlY2lkZWQgbm90IHRvIGFkb3B0IHNvbWV0aGluZyBsaWtlIHRo ZSAtY2FudCBkcmFmdCBhdCB0aGUgY3VycmVudCB0aW1lLCBzaW5jZSB0aGUgbW9yZSBnZW5lcmlj IGNhcGFiaWxpdHkgd2FzIGFsc28gbmVlZGVkLg0KDQpPbiAxMSBKdW5lIDIwMTQgMTI6MzcsIEFu ZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPiAxLiBBbiBl eGlzdGluZyBIVFRQLzEuMSBzZXJ2ZXIgY2Fubm90IHRha2UgYWR2YW50YWdlIG9mIFRMUyAxLjMg aWYgVExTIGNsaWVudCBhdXRoIGlzIHJlcXVpcmVkLiBUaGlzIGlzIGJlY2F1c2UgYW4gZXhpc3Rp bmcgSFRUUC8xLjEgc2VydmVyIGlzIG5vdCBhd2FyZSBvZiBodHRwYmlzLWNhbnQuDQoNCkNvcnJl Y3QuICBUaGF0IG1ha2VzIHNvbWV0aGluZyBsaWtlIC1jYW50IGEgcHJlcmVxdWlzaXRlIG9mIGFu IHVwZ3JhZGUgdG8gVExTIDEuMyBmb3IgdGhvc2Ugc2VydmVycy4NCg0KPiAyLiBBbiBIVFRQLzIg c2VydmVyIHJlcXVpcmVzIGFuIHVwZGF0ZWQgVExTIHN0YWNrIHdpdGggdGxzLWNhcmUgc3VwcG9y dCBpbiBvcmRlciB0byBwZXJmb3JtIFRMUyBjbGllbnQgYXV0aC4gVGhpcyBpcyBiZWNhdXNlIEhU VFAvMiBwcm9oaWJpdHMgcmVuZWdvdGlhdGlvbi4NCg0KVGhpcyBjYW4gYmUgd29ya2VkIGFyb3Vu ZC4gIEluIGZhY3QsIHRoZSBwcm9wb3NlZCB0ZXh0IHBlcm1pdHMgcmVuZWdvdGlhdGlvbiBpbiBU TFMgMS4yICh0aGVyZSBpcyBubyAiZWFybGllciIgaGVyZSBiZWNhdXNlIHdlIHByb2hpYml0IHRo ZSB1c2Ugb2YgZWFybGllciB2ZXJzaW9ucykgcHJpb3IgdG8gc3RhcnRpbmcgSFRUUC8yOg0KDQpo dHRwczovL2dpdGh1Yi5jb20vaHR0cDIvaHR0cDItc3BlYy9wdWxsLzUxNC9maWxlcyNkaWZmLTg4 OTQxNjgzODJmNjQ4N2U1ZTM4YzQzMDZlNjEzYTg4UjM0MzANCg0KKFRoaXMgaXNuJ3QgaW4gdGhl IG1haW4gc3BlYyBkdWUgdG8gYSBkZXBlbmRlbmN5IGlzc3VlLCB0aGF0IHRleHQgY2FwdHVyZXMg dGhlIGVzdGFibGlzaGVkIGNvbnNlbnN1cyBmcm9tIHRoZSBtb3N0IHJlY2VudCBpbnRlcmltDQpt ZWV0aW5nLikNCg0KPiAzLiBFdmVuIHdpdGggdGhlIHVwZGF0ZWQgVExTIHN0YWNrIGluIHBsYWNl LCBhbiBIVFRQLzIgc2VydmVyIGNhbm5vdCBuZWdvdGlhdGUgVExTIDEuMiBhbmQgZWFybGllciBp ZiBUTFMgY2xpZW50IGF1dGggaXMgcmVxdWlyZWQuIFRoaXMgaXMgYmVjYXVzZSBUTFMgMS4yIGFu ZCBlYXJsaWVyIHdvdWxkIHNlbmQgdGhlIGNsaWVudCBjZXJ0IGluIHRoZSBjbGVhciwgd2hpY2gg aXMgYmFkIGZvciBjbGllbnQgcHJpdmFjeS4NCg0KU2VlIGFib3ZlIHdvcmthcm91bmQuICBUaGUg Y29zdCB0aGVyZSBpcyBhbiBhZGRpdGlvbmFsIHJvdW5kIHRyaXAgKGlmIHlvdSBkbyBmYWxzZSBz dGFydCwgdGhhdCBpcywgaXQncyBhIGxvdCBtb3JlIHdpdGhvdXQpLg0KDQo+IDQuIFdpdGhvdXQg cmVuZWdvdGlhdGlvbiwgVExTIGNsaWVudCBhdXRoIHJlcXVpcmVzIGFkZGl0aW9uYWwgcm91bmQt dHJpcHMgdG8gZXN0YWJsaXNoIGEgbmV3IFRDUCBjb25uZWN0aW9uLg0KDQpDb3JyZWN0Lg0K From nobody Wed Jun 11 18:17:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7A21B2926 for ; Wed, 11 Jun 2014 18:17: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARua0nsoQUCH for ; Wed, 11 Jun 2014 18:17:29 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84551B2924 for ; Wed, 11 Jun 2014 18:17:28 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id q9so493710ykb.23 for ; Wed, 11 Jun 2014 18:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tuQwLO/eDYlTDg3bCZ+FG/57xMX4G/jxG8TaMZg3htU=; b=pHnPQfZrXHZ8TIseTGkLmtnWRZjHNiMxIAsRJMTqPVR7HeAjZnbVbfNmEntSq7FjAc Tm5BdDwB3qZydInhHzVVOeaeUlDzA+E0OBBQt2/afMsYGqDeDqfZgasYx8kYWg0bvkBH TayLFXDvUwU+nGVgnK1pvQsrfrC8cE/rH9JNwLFfan3q3z8YKD2IWa1msYIuW0C7At6d 7+KDHP0C3FXjm4wiNuEPqht6y/wfm9P4tGBawBvJkVQUyw0QcGeicpYtdPax8zs921zA r1Cei1L31DTiMfc/bU44Jwqth7hEvHQropz1w87kIhYvpabZ5mZRPciHcO8re/F0Wdyd 5YnQ== MIME-Version: 1.0 X-Received: by 10.236.89.69 with SMTP id b45mr11136971yhf.16.1402535847964; Wed, 11 Jun 2014 18:17:27 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Wed, 11 Jun 2014 18:17:27 -0700 (PDT) In-Reply-To: <5B1D7E570380A64989D4C069F7D14BC8CB7F66D6@PINTO.missi.ncsc.mil> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <5B1D7E570380A64989D4C069F7D14BC8CB7F66D6@PINTO.missi.ncsc.mil> Date: Wed, 11 Jun 2014 22:17:27 -0300 Message-ID: From: Watson Ladd To: "Kemp, David P." Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZyiUZpQzSU2Wf-q77EPHxB10pLw Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 01:17:30 -0000 On Wed, Jun 11, 2014 at 1:08 PM, Kemp, David P. wro= te: > A decision on the proper place to do access control has nothing to do wit= h the skill of implementers. > > If a web server (or any service provider) doesn't know how to grant acces= s to resources based on authenticated user identity, user attributes, resou= rce attributes and access policy, then a perfect bug-free network stack is = not going to help them. Well, they do know how to grant access based on authenticated user identity. What they don't know how to do is deal with portions of a request being made with one identity, other portions with another. > > If a "certificate changes", then either the application should have reque= sted renegotiation synchronously or it should have asynchronously establish= ed conditions for when the stack renegotiates and registered to be notified= when it happens. The proper response to renegotiation is identical to the= proper response to negotiating the first time. Name one program that actually enforces this, or a TLS implementation that permits it, except by banning renegotiation entirely. > > "We know more than the application layer people" - pure hubris. TLS/IPSE= C practitioners should definitely know more about cryptography, which appli= cation developers should be able to largely ignore as a black box. But acc= ess control to application resources is inherently an application function = for which TLS library coding expertise is no substitute. Yes, but we can make the job of the application much easier by restricting the transformations that can happen. Applications are mostly unaware that responses could be split across authentication levels. That's why we had the renegotiation fix. Things can get even worse: if I want to restrict a resource to some ciphersuites, not others, this can be evaded by renegotiation if the first ciphersuite is broken. The issue is that the state transitions in renegotiation aren't clearly explained or cleanly exposed to applications by most TLS stacks. At this point, given the enormous number of applications using and that should be using TLS, the fact that historically most TLS stacks and applications using TLS have gotten this wrong, I don't see stay the course as a reasonable option. Either we clean up renegotiation to the point where it can be useful, or we throw it out. Sincerely, Watson Ladd > > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Watson Ladd > Sent: Wednesday, June 11, 2014 7:46 AM > To: Nikos Mavrogiannopoulos > Cc: tls@ietf.org > Subject: Re: [TLS] Proposed text for removing renegotiation > > On Wed, Jun 11, 2014 at 5:45 AM, Nikos Mavrogiannopoulos wrote: >> On Tue, 2014-06-10 at 14:04 -0300, Watson Ladd wrote: >> >>> Quick: what is the proper response when the Certificate changes >>> between a negotiation and a renegotiation? >> >> That is on the application protocol to decide. > > Always the wrong answer: we know more then the application layer people d= o about security, just as the networking people know more than we do about = sending packets through the network. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Jun 11 19:27:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F1A1B2977 for ; Wed, 11 Jun 2014 19:27: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D-jxttHQ6lL for ; Wed, 11 Jun 2014 19:27:28 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E4C1A0300 for ; Wed, 11 Jun 2014 19:27:27 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id n15so6143815wiw.10 for ; Wed, 11 Jun 2014 19:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gOxZWHVRuMtaE9tQsnpl1AIyyzp7I8rqrHgmT6A4580=; b=zIE3ZBcy5D20XxCYkK8rDAl8sVTqDzzj9jeGtR25dhsOYyWfgiT0hXkCALa915+FA/ 8kIMbW9SryY7V0ispHxcG8llUvC+Ujwa7S8wfB3vtBvlKybx8PS3LKQILdFH1mehV0jv U6YvZyUkil4Q0rfCufjGTfJVodO020wSwHjC2fUOI+WKG6cc3ajksSnVNzUFwBuTptB/ yQBAr3ZLHj/pnjFZJyULeVBiTjYpkAlnuzgXiwXly8/w3hh3KNbM0GcXeBbrChiMVJFt aovtvna7ius11jDWz4LMDDpolzpHxjIUeCJIaFsl7b4wBJmR1NPAMq3xQvbdK6JwX6DU ZabQ== MIME-Version: 1.0 X-Received: by 10.180.72.176 with SMTP id e16mr2022693wiv.44.1402540046519; Wed, 11 Jun 2014 19:27:26 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Wed, 11 Jun 2014 19:27:26 -0700 (PDT) In-Reply-To: <71550d53435b46c9960e3151eee71180@BL2PR03MB419.namprd03.prod.outlook.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <319344a622ba450aa60d454fd9f97135@BL2PR03MB419.namprd03.prod.outlook.com> <71550d53435b46c9960e3151eee71180@BL2PR03MB419.namprd03.prod.outlook.com> Date: Wed, 11 Jun 2014 19:27:26 -0700 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sPtp4KtxQtAHfz-REXNdbthF3mo Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 02:27:29 -0000 On 11 June 2014 17:22, Andrei Popov wrote: > * A document (or set of documents) that is SUITABLE TO SUPERCEDE RFC 2616 as > the definition of HTTP/1.1 and move RFC 2817 to Historic status" > But I guess this is up to the HTTPbis WG to discuss:) That particular goal has been met with the publication of RFCs 7230 through 7235. >> https://github.com/http2/http2-spec/pull/514/files#diff-8894168382f6487e5e38c4306e613a88R3430 > There are at least two protocol layering violations in this text, which I think will cause problems: > 1) Preventing the use of renegotiation in response to a request for a specific protected resource, and The renegotiation is a blanket ban, not conditional in the manner you describe. Arguably, renegotiation triggered by a request to a specific protected resource is a far worse layering violation. > 2) Constraining the TLS cipher suites to be used with HTTP/2. I can't agree that this is necessarily a layering violation. Though the text recommends a violation, it also describes a method that does not require a layering violation. That is, if you consider the interface to TLS to permit the passage of information about the active cipher suite. From nobody Thu Jun 12 02:02:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA6E1A0460 for ; Thu, 12 Jun 2014 02:02:48 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27jS-8Yg65Yc for ; Thu, 12 Jun 2014 02:02:47 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9255B1A0199 for ; Thu, 12 Jun 2014 02:02:46 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t60so951675wes.0 for ; Thu, 12 Jun 2014 02:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=nBnRFsiGorogVNcGOrYwwGYadfO5V85EiV9HlqYiPeA=; b=TLHTkFr81jJz86YNwirwLXEMLIpX/FfVtjeBKf9bbxewykvb319bThESLbgZ3oG196 HSH5L/cGxr8VZ0/pI1tBgMJKcX7gsny8Yj0ByarvRNSAGVUnoYIuBBBbeO8M74/j8Vep Wy37vbPInlDOW8nem8XoLDA+fpYAZA31ibNGboAr9HmfH79si/yvSeNRHmyLhjw0Kp6s EgGfIdywNFWSQZJQks1yIZYX7p0WhnpQhnVSa5gnTzp8c6FBsExPf+q+J6lPuBHWHooC 2nTENO+pEZk3gyvWqkXZVHlDMPMTfK+TPBcq1tB5xByULV07G/F0Aq1J5EUsDDE2Hi+a y34A== X-Received: by 10.180.9.242 with SMTP id d18mr1085916wib.49.1402563763781; Thu, 12 Jun 2014 02:02:43 -0700 (PDT) Received: from [172.24.249.169] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id ht5sm557687wjb.49.2014.06.12.02.02.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 02:02:43 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_80EF5F42-AE9E-4F1D-ADBC-94884E529748" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: Date: Thu, 12 Jun 2014 12:02:40 +0300 Message-Id: <9E3DB9FD-2691-4CED-90A9-A024D7A4F4BA@gmail.com> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <5390B1D6.5010105@nthpermutation.com> <5390CA45.1050504@nthpermutation.com> To: Brian Smith X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3bIb14CPMrx6Egos6KfFKtr8WC0 Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 09:02:49 -0000 --Apple-Mail=_80EF5F42-AE9E-4F1D-ADBC-94884E529748 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Brian Interesting stuff. Also good to hear that it=92s easy to implement, = although mileages vary. Regarding TLS proxies, I can give my perspective, as I work for one = vendor.=20 Our fake certificates contain the DNs and alternate names from the = original certificate. We don=92t copy over any extensions that we don=92t = understand. The same is also true of TLS - we don=92t copy extensions we = don=92t know. That is what allows our proxy to gracefully downgrade = HTTP/2 or SPDY clients and gateways to HTTP/1. As for dates, these *are* copied from the original certificate, the = reason is that this makes the client behavior similar to whatever it is = with the original certificate. We did consider making the certificates = short-lived, but decided against it.=20 So your proposed heuristic for detecting fake certificates will work = with some proxies, but not all. Adam=92s suggestion should work better, = but best is if the fake certificate doesn=92t promise things the proxy = CA doesn=92t understand. Yoav On Jun 12, 2014, at 1:49 AM, Brian Smith wrote: > On Thu, Jun 5, 2014 at 12:51 PM, Michael StJohns = wrote: > On 6/5/2014 3:12 PM, Brian Smith wrote: > Is it really significantly easier for CAs to add new certificate = policies compared to adding new certificate extensions? I could see how = that could be the case, but I think it would be good to hear from CAs = about this. >=20 > Mostly the "put a policy object in the ca certificate" reduces to = "configure the text string of the OIDs you want to include". = https://www.openssl.org/docs/apps/x509v3_config.html#Certificate_Policies_= for example. >=20 > The certificate policy extension is pretty well formed, which means = that its pretty easy to specify in configuration language (e.g. xml, = label=3Dvalue) what you want to be included rather than having to go = back and add new ASN1 encode/decode/translate to and from string logic. = Things like Dogtag and EJBCA support it via a gui >=20 > I have researched some of the pros and cons of Michael's policy-based = approach. I also implemented it in a private copy of mozilla::pkix and = Firefox. In particular, I made it so: >=20 > * When the extension is present in the end-entity certificate, that a = valid "Good" OCSP response must be provided in the TLS handshake, > * There will never be any fallback to OCSP fetching or CRLs or cache = lookups when the end-entity certificate has the must-staple policy. = However, additional certificate trust information (blacklists/CRLSet) = are still consulted. > * The modified mozilla::pkix will never build a path from an = end-entity certificate or sub-CA to a higher-level CA certificate where = the higher-level CA certificate has the Must-Staple policy but the = end-entity or lower-level sub-CA certificate doesn't have the = Must-staple policy. > * My modified mozilla::pkix enforces a maximum OCSP response lifetime = of 2 days + slop (1 day) =3D 3 days if Must-Staple is present, instead = of 10 days. >=20 > The good news: > * In mozilla::pkix and Firefox, it is just as easy to implement = Machael's policy-based approach as it would be to implement the approach = outlined in the draft. > * As Michael said, most if not all CA software already supports custom = certificate policies, so there is *no* new code required on the CA side = for Machael's approach. This is a significant advantage, especially = because there are a lot of companies that have purchased sub-CA = certificates that chain to publicly-trusted CAs, which use closed-source = software (e.g. Microsoft's). Basically, with Michael's approach, = everybody would be able to use Must-Staple straight away, if they want = to, without writing code. >=20 > The bad news: > * TLS intercepting proxies cause trouble. In particular, some (if not = all) versions of Microsoft Threat Management Gateway forge their fake = certificates by copying the certificate policies from the original = certificate that they are trying to impersonate. Yet, Microsoft TMG does = not support OCSP stapling or in fact any kind of OCSP. Consequently, it = will copy the Must-Staple policy into the forged certificate but it = won't staple a response. I imagine other TLS intercepting proxies will = do the same. > * It is unclear what TLS intercepting proxies do with certificate = extensions that they don't understand. I would guess that some copy = those extensions into their forged certificates and others do not. >=20 > The OK news: > * =46rom what I've found, Microsoft TMG forges certificates that are = very short lived (24hrs). Thus, if we make an exception that short-lived = certificates (<=3D 48 hours) with the Must-Staple feature do not need to = have a stapled OCSP response even with Must-Staple, we can probably = avoid a lot of the issues with TLS intercepting proxies, regardless of = how the Must-Staple feature is encoded in the certificate. >=20 > Thus, for ease-of-deployment reasons, I prefer Michael's policy-based = approach + the short-lived certificate exception over the approach in = the draft that uses a new extension. Regardless of which of those two = approaches is taken, we'll need to do a lot of interop testing with = various kinds of TLS intercepting proxies. >=20 > Cheers, > Brian >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_80EF5F42-AE9E-4F1D-ADBC-94884E529748 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi, = Brian

Interesting stuff. Also good to hear that it=92s = easy to implement, although mileages = vary.

Regarding TLS proxies, I can give my = perspective, as I work for one = vendor. 

<hat type=3D=93vendor=94 = status=3D=93on=94>
Our fake certificates contain the DNs = and alternate names from the original certificate. We don=92t copy over = any extensions that we don=92t understand. The same is also true of TLS = - we don=92t copy extensions we don=92t know. That is what allows our = proxy to gracefully downgrade HTTP/2 or SPDY clients and gateways to = HTTP/1.
As for dates, these *are* copied from the original = certificate, the reason is that this makes the client behavior similar = to whatever it is with the original certificate. We did consider making = the certificates short-lived, but decided against = it. 
</hat>

So your = proposed heuristic for detecting fake certificates will work with some = proxies, but not all. Adam=92s suggestion should work better, but best = is if the fake certificate doesn=92t promise things the proxy CA doesn=92t= understand.

Yoav

On = Jun 12, 2014, at 1:49 AM, Brian Smith <brian@briansmith.org> = wrote:

On Thu, Jun 5, 2014 at 12:51 PM, Michael StJohns = <msj@nthpermutation.com> wrote:
On = 6/5/2014 3:12 PM, Brian Smith wrote:
Is it really significantly easier for CAs to add new certificate = policies compared to adding new certificate extensions? I could see how = that could be the case, but I think it would be good to hear from CAs = about this.

Mostly the "put a policy object in the ca certificate" reduces to = "configure the text string of the OIDs you want to include". https://www.openssl.org/docs/apps/x509v3_config.h= tml#Certificate_Policies_ for example.

The certificate policy extension is pretty well formed, which means that = its pretty easy to specify in configuration language (e.g. xml, = label=3Dvalue) what you want to be included rather than having to go = back and add new ASN1 encode/decode/translate to and from string logic. =  Things like Dogtag and EJBCA support it via a gui

I have researched some of the pros and = cons of Michael's policy-based approach. I also implemented it in a = private copy of mozilla::pkix and Firefox. In particular, I made it = so:

* When the extension is present in the end-entity certificate, that a = valid "Good" OCSP response must be provided in the TLS = handshake,
* There will never be any fallback to OCSP = fetching or CRLs or cache lookups when the end-entity certificate has = the must-staple policy. However, additional certificate trust = information (blacklists/CRLSet) are still consulted.
* The modified mozilla::pkix will never build a path from an = end-entity certificate or sub-CA to a higher-level CA certificate where = the higher-level CA certificate has the Must-Staple policy but the = end-entity or lower-level sub-CA certificate doesn't have the = Must-staple policy.
* My modified mozilla::pkix enforces a maximum OCSP response = lifetime of 2 days + slop (1 day) =3D 3 days if Must-Staple is present, = instead of 10 days.

The good news:
* In = mozilla::pkix and Firefox, it is just as easy to implement Machael's = policy-based approach as it would be to implement the approach outlined = in the draft.
* As Michael said, most if not all CA software already = supports custom certificate policies, so there is *no* new code required = on the CA side for Machael's approach. This is a significant advantage, = especially because there are a lot of companies that have purchased = sub-CA certificates that chain to publicly-trusted CAs, which use = closed-source software (e.g. Microsoft's). Basically, with Michael's = approach, everybody would be able to use Must-Staple straight away, if = they want to, without writing code.

The bad news:
* TLS intercepting proxies = cause trouble. In particular, some (if not all) versions of Microsoft = Threat Management Gateway forge their fake certificates by copying the = certificate policies from the original certificate that they are trying = to impersonate. Yet, Microsoft TMG does not support OCSP stapling or in = fact any kind of OCSP. Consequently, it will copy the Must-Staple policy = into the forged certificate but it won't staple a response. I imagine = other TLS intercepting proxies will do the same.
* It is unclear what TLS intercepting proxies do with = certificate extensions that they don't understand. I would guess that = some copy those extensions into their forged certificates and others do = not.

The OK news:
* =46rom what I've found, = Microsoft TMG forges certificates that are very short lived (24hrs). = Thus, if we make an exception that short-lived certificates (<=3D 48 = hours) with the Must-Staple feature do not need to have a stapled OCSP = response even with Must-Staple, we can probably avoid a lot of the = issues with TLS intercepting proxies, regardless of how the Must-Staple = feature is encoded in the certificate.

Thus, for ease-of-deployment reasons, I prefer Michael's = policy-based approach + the short-lived certificate exception over the = approach in the draft that uses a new extension. Regardless of which of = those two approaches is taken, we'll need to do a lot of interop testing = with various kinds of TLS intercepting proxies.

Cheers,
Brian

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

= --Apple-Mail=_80EF5F42-AE9E-4F1D-ADBC-94884E529748-- From nobody Thu Jun 12 09:12:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD081A0147 for ; Thu, 12 Jun 2014 09:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnKJ23n8qo-V for ; Thu, 12 Jun 2014 09:12:27 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) (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 7F22A1B27A4 for ; Thu, 12 Jun 2014 09:12:26 -0700 (PDT) Received: from Odysseus.missi.ncsc.mil (odysseus.missi.ncsc.mil [144.51.60.172]) by stingray.missi.ncsc.mil with ESMTP id s5CGCPlF056247 for ; Thu, 12 Jun 2014 12:12:25 -0400 (EDT) Received: from PINTO.missi.ncsc.mil ([fe80::60c7:cec6:b35c:deed]) by Odysseus.missi.ncsc.mil ([fe80::a8ee:8532:895b:b420%14]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 12:12:24 -0400 From: "Kemp, David P." To: "tls@ietf.org" Thread-Topic: [TLS] Proposed text for removing renegotiation Thread-Index: AQHPhVGEfA6PTH75QESiVYAkFY18F5tsDc0A///9z+CAAOT0gIAAtUJA Date: Thu, 12 Jun 2014 16:12:24 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC8CB7F8826@PINTO.missi.ncsc.mil> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <5B1D7E570380A64989D4C069F7D14BC8CB7F66D6@PINTO.missi.ncsc.mil> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.60.29] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KsQ43MbefF8CZxzuCdr9SJVSufg Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:12:31 -0000 VGhhdCdzIGEgZ29vZCByYXRpb25hbGUgZm9yIHNheWluZyBUTFMgaW1wbGVtZW50YXRpb25zIFNI QUxMIE5PVCByZW5lZ290aWF0ZSB1bmxlc3MgcmVxdWVzdGVkIG9yIGVuYWJsZWQgYnkgdGhlIGFw cGxpY2F0aW9uLiAgSWYgdGhlIEFQSSBkb2Vzbid0IHByb3ZpZGUgYSB3YXkgdG8gcmVxdWVzdC9l bmFibGUsIHRoZW4gdGhlIHN0YWNrIHNob3VsZG4ndCBkbyBpdCBiZWhpbmQgdGhlIGFwcCdzIGJh Y2suDQoNCj4gRWl0aGVyIHdlIGNsZWFuIHVwIHJlbmVnb3RpYXRpb24gdG8gdGhlIHBvaW50IHdo ZXJlIGl0IGNhbiBiZSB1c2VmdWwsIG9yIHdlIHRocm93IGl0IG91dC4NCg0KKzEuICBUaGF0J3Mg ZGlmZmVyZW50IGZyb20gc2F5aW5nIHRocm93IGl0IG91dCwgcGVyaW9kLg0KDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdhdHNvbiBMYWRkIFttYWlsdG86d2F0c29uYmxh ZGRAZ21haWwuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAxMSwgMjAxNCA5OjE3IFBNDQpU bzogS2VtcCwgRGF2aWQgUC4NCkNjOiB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBQ cm9wb3NlZCB0ZXh0IGZvciByZW1vdmluZyByZW5lZ290aWF0aW9uDQoNCk9uIFdlZCwgSnVuIDEx LCAyMDE0IGF0IDE6MDggUE0sIEtlbXAsIERhdmlkIFAuIDxEUEtlbXBAbWlzc2kubmNzYy5taWw+ IHdyb3RlOg0KPiBBIGRlY2lzaW9uIG9uIHRoZSBwcm9wZXIgcGxhY2UgdG8gZG8gYWNjZXNzIGNv bnRyb2wgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgc2tpbGwgb2YgaW1wbGVtZW50ZXJzLg0K Pg0KPiBJZiBhIHdlYiBzZXJ2ZXIgKG9yIGFueSBzZXJ2aWNlIHByb3ZpZGVyKSBkb2Vzbid0IGtu b3cgaG93IHRvIGdyYW50IGFjY2VzcyB0byByZXNvdXJjZXMgYmFzZWQgb24gYXV0aGVudGljYXRl ZCB1c2VyIGlkZW50aXR5LCB1c2VyIGF0dHJpYnV0ZXMsIHJlc291cmNlIGF0dHJpYnV0ZXMgYW5k IGFjY2VzcyBwb2xpY3ksIHRoZW4gYSBwZXJmZWN0IGJ1Zy1mcmVlIG5ldHdvcmsgc3RhY2sgaXMg bm90IGdvaW5nIHRvIGhlbHAgdGhlbS4NCg0KV2VsbCwgdGhleSBkbyBrbm93IGhvdyB0byBncmFu dCBhY2Nlc3MgYmFzZWQgb24gYXV0aGVudGljYXRlZCB1c2VyIGlkZW50aXR5LiBXaGF0IHRoZXkg ZG9uJ3Qga25vdyBob3cgdG8gZG8gaXMgZGVhbCB3aXRoIHBvcnRpb25zIG9mIGEgcmVxdWVzdCBi ZWluZyBtYWRlIHdpdGggb25lIGlkZW50aXR5LCBvdGhlciBwb3J0aW9ucyB3aXRoIGFub3RoZXIu DQoNCj4NCj4gSWYgYSAiY2VydGlmaWNhdGUgY2hhbmdlcyIsIHRoZW4gZWl0aGVyIHRoZSBhcHBs aWNhdGlvbiBzaG91bGQgaGF2ZSByZXF1ZXN0ZWQgcmVuZWdvdGlhdGlvbiBzeW5jaHJvbm91c2x5 IG9yIGl0IHNob3VsZCBoYXZlIGFzeW5jaHJvbm91c2x5IGVzdGFibGlzaGVkIGNvbmRpdGlvbnMg Zm9yIHdoZW4gdGhlIHN0YWNrIHJlbmVnb3RpYXRlcyBhbmQgcmVnaXN0ZXJlZCB0byBiZSBub3Rp ZmllZCB3aGVuIGl0IGhhcHBlbnMuICBUaGUgcHJvcGVyIHJlc3BvbnNlIHRvIHJlbmVnb3RpYXRp b24gaXMgaWRlbnRpY2FsIHRvIHRoZSBwcm9wZXIgcmVzcG9uc2UgdG8gbmVnb3RpYXRpbmcgdGhl IGZpcnN0IHRpbWUuDQoNCk5hbWUgb25lIHByb2dyYW0gdGhhdCBhY3R1YWxseSBlbmZvcmNlcyB0 aGlzLCBvciBhIFRMUyBpbXBsZW1lbnRhdGlvbiB0aGF0IHBlcm1pdHMgaXQsIGV4Y2VwdCBieSBi YW5uaW5nIHJlbmVnb3RpYXRpb24gZW50aXJlbHkuDQoNCj4NCj4gIldlIGtub3cgbW9yZSB0aGFu IHRoZSBhcHBsaWNhdGlvbiBsYXllciBwZW9wbGUiIC0gcHVyZSBodWJyaXMuICBUTFMvSVBTRUMg cHJhY3RpdGlvbmVycyBzaG91bGQgZGVmaW5pdGVseSBrbm93IG1vcmUgYWJvdXQgY3J5cHRvZ3Jh cGh5LCB3aGljaCBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzIHNob3VsZCBiZSBhYmxlIHRvIGxhcmdl bHkgaWdub3JlIGFzIGEgYmxhY2sgYm94LiAgQnV0IGFjY2VzcyBjb250cm9sIHRvIGFwcGxpY2F0 aW9uIHJlc291cmNlcyBpcyBpbmhlcmVudGx5IGFuIGFwcGxpY2F0aW9uIGZ1bmN0aW9uIGZvciB3 aGljaCBUTFMgbGlicmFyeSBjb2RpbmcgZXhwZXJ0aXNlIGlzIG5vIHN1YnN0aXR1dGUuDQoNClll cywgYnV0IHdlIGNhbiBtYWtlIHRoZSBqb2Igb2YgdGhlIGFwcGxpY2F0aW9uIG11Y2ggZWFzaWVy IGJ5IHJlc3RyaWN0aW5nIHRoZSB0cmFuc2Zvcm1hdGlvbnMgdGhhdCBjYW4gaGFwcGVuLiBBcHBs aWNhdGlvbnMgYXJlIG1vc3RseSB1bmF3YXJlIHRoYXQgcmVzcG9uc2VzIGNvdWxkIGJlIHNwbGl0 IGFjcm9zcyBhdXRoZW50aWNhdGlvbiBsZXZlbHMuIFRoYXQncyB3aHkgd2UgaGFkIHRoZSByZW5l Z290aWF0aW9uIGZpeC4NCg0KVGhpbmdzIGNhbiBnZXQgZXZlbiB3b3JzZTogaWYgSSB3YW50IHRv IHJlc3RyaWN0IGEgcmVzb3VyY2UgdG8gc29tZSBjaXBoZXJzdWl0ZXMsIG5vdCBvdGhlcnMsIHRo aXMgY2FuIGJlIGV2YWRlZCBieSByZW5lZ290aWF0aW9uIGlmIHRoZSBmaXJzdCBjaXBoZXJzdWl0 ZSBpcyBicm9rZW4uDQoNClRoZSBpc3N1ZSBpcyB0aGF0IHRoZSBzdGF0ZSB0cmFuc2l0aW9ucyBp biByZW5lZ290aWF0aW9uIGFyZW4ndCBjbGVhcmx5IGV4cGxhaW5lZCBvciBjbGVhbmx5IGV4cG9z ZWQgdG8gYXBwbGljYXRpb25zIGJ5IG1vc3QgVExTIHN0YWNrcy4gQXQgdGhpcyBwb2ludCwgZ2l2 ZW4gdGhlIGVub3Jtb3VzIG51bWJlciBvZiBhcHBsaWNhdGlvbnMgdXNpbmcgYW5kIHRoYXQgc2hv dWxkIGJlIHVzaW5nIFRMUywgdGhlIGZhY3QgdGhhdCBoaXN0b3JpY2FsbHkgbW9zdCBUTFMgc3Rh Y2tzIGFuZCBhcHBsaWNhdGlvbnMgdXNpbmcgVExTIGhhdmUgZ290dGVuIHRoaXMgd3JvbmcsIEkg ZG9uJ3Qgc2VlIHN0YXkgdGhlIGNvdXJzZSBhcyBhIHJlYXNvbmFibGUgb3B0aW9uLiBFaXRoZXIg d2UgY2xlYW4gdXAgcmVuZWdvdGlhdGlvbiB0byB0aGUgcG9pbnQgd2hlcmUgaXQgY2FuIGJlIHVz ZWZ1bCwgb3Igd2UgdGhyb3cgaXQgb3V0Lg0KDQpTaW5jZXJlbHksDQpXYXRzb24gTGFkZA0KDQo+ DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRMUyBbbWFpbHRvOnRs cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2F0c29uIExhZGQNCj4gU2VudDogV2Vk bmVzZGF5LCBKdW5lIDExLCAyMDE0IDc6NDYgQU0NCj4gVG86IE5pa29zIE1hdnJvZ2lhbm5vcG91 bG9zDQo+IENjOiB0bHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtUTFNdIFByb3Bvc2VkIHRl eHQgZm9yIHJlbW92aW5nIHJlbmVnb3RpYXRpb24NCj4NCj4gT24gV2VkLCBKdW4gMTEsIDIwMTQg YXQgNTo0NSBBTSwgTmlrb3MgTWF2cm9naWFubm9wb3Vsb3MgPG5tYXZAcmVkaGF0LmNvbT4gd3Jv dGU6DQo+PiBPbiBUdWUsIDIwMTQtMDYtMTAgYXQgMTQ6MDQgLTAzMDAsIFdhdHNvbiBMYWRkIHdy b3RlOg0KPj4NCj4+PiBRdWljazogd2hhdCBpcyB0aGUgcHJvcGVyIHJlc3BvbnNlIHdoZW4gdGhl IENlcnRpZmljYXRlIGNoYW5nZXMgDQo+Pj4gYmV0d2VlbiBhIG5lZ290aWF0aW9uIGFuZCBhIHJl bmVnb3RpYXRpb24/DQo+Pg0KPj4gVGhhdCBpcyBvbiB0aGUgYXBwbGljYXRpb24gcHJvdG9jb2wg dG8gZGVjaWRlLg0KPg0KPiBBbHdheXMgdGhlIHdyb25nIGFuc3dlcjogd2Uga25vdyBtb3JlIHRo ZW4gdGhlIGFwcGxpY2F0aW9uIGxheWVyIHBlb3BsZSBkbyBhYm91dCBzZWN1cml0eSwganVzdCBh cyB0aGUgbmV0d29ya2luZyBwZW9wbGUga25vdyBtb3JlIHRoYW4gd2UgZG8gYWJvdXQgc2VuZGlu ZyBwYWNrZXRzIHRocm91Z2ggdGhlIG5ldHdvcmsuDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFRMUyBtYWlsaW5nIGxpc3QNCj4gVExT QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoN Cg0KDQotLQ0KIlRob3NlIHdobyB3b3VsZCBnaXZlIHVwIEVzc2VudGlhbCBMaWJlcnR5IHRvIHB1 cmNoYXNlIGEgbGl0dGxlIFRlbXBvcmFyeSBTYWZldHkgZGVzZXJ2ZSBuZWl0aGVyICBMaWJlcnR5 IG5vciBTYWZldHkuIg0KLS0gQmVuamFtaW4gRnJhbmtsaW4NCg== From nobody Thu Jun 12 09:20:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0431B2A2B for ; Thu, 12 Jun 2014 09:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.652 X-Spam-Level: X-Spam-Status: No, score=-7.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfMVUUJ8xpF9 for ; Thu, 12 Jun 2014 09:20:19 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2881B2AA9 for ; Thu, 12 Jun 2014 09:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1402590019; x=1434126019; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5/0/K0WsoN2De03tOjtWYGUyexayM99CpfTETF9mCq8=; b=hawonlVg7K09bjTF7W1qpfRWFwMxldBoSzyV0LSFMmR6HySpgux3c03Z vLfEUEzLSGjNZZZBrMCqTXjrdDsM3dmZVigKNoX/M1BZXXqNI38zui6q/ QcK76FiS6J1ckcgoF6oF3njvBTJnQAmZ/ReE1sI9A1b8vZUjR5AtRdGrt 4=; X-IronPort-AV: E=Sophos;i="5.01,466,1400025600"; d="scan'208";a="115523189" X-IPAS-Result: AlYFAO/RmVPAqArr/2dsb2JhbABahDipTgEBAQEBAQaZHgGBIHWEBAEBBDorFBACAQgNFRQQMiUCBA4N2mUXhVyITjEHgyuBFgShVY9rgi8 Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 12 Jun 2014 16:20:18 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 09:20:17 -0700 From: David Holmes To: Watson Ladd , "Kemp, David P." Thread-Topic: [TLS] Proposed text for removing renegotiation Thread-Index: AQHPhdwqCg8gt7OZi0qJtRIa8EVlLJtss9iw Date: Thu, 12 Jun 2014 16:20:17 +0000 Deferred-Delivery: Thu, 12 Jun 2014 16:20:00 +0000 Message-ID: <859F43324A6FEC448BFEA30C90405FA90550E0@SEAEMBX02.olympus.F5Net.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <5B1D7E570380A64989D4C069F7D14BC8CB7F66D6@PINTO.missi.ncsc.mil> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G_XCCHimEUpeXxsVHB91gLl35LI Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:20:20 -0000 Some field data here. Our load-balancers/SSL terminators let customers set a time interval for re= negotiation (the default is never).=20 We retain support customers for a period of time and have the ability to gr= ep through customer configurations. Over the previous 90 or 180 days (or whatever our retention period is) ther= e are 33 customers using renegotiation (on 56 hosts). This is approximately= 0.5% of the customers. Of those hosts: * The selected interval values range from 3 seconds (!!!) to 86400 - with a= n average being around 3600 seconds. * Lots of 10-second renegotiation intervals as well. * Seems to be a slight preference to the Financial vertical. I'm not suggesting that this data moves the conversation about renegotiatio= n one way or the other. From nobody Thu Jun 12 09:36:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5017C1A01AA for ; Thu, 12 Jun 2014 09:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haBACcBWy-n3 for ; Thu, 12 Jun 2014 09:35:57 -0700 (PDT) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1151B27B6 for ; Thu, 12 Jun 2014 09:35:57 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t60so1612776wes.14 for ; Thu, 12 Jun 2014 09:35:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=W5HWoIbPtPuRS6FYUfNbup7WvV87VtL738fslvr7b44=; b=SADwqGmJEL1DgNsp6ks9K2z8UGrU6zn35MtTGJMxF9NuiSaQYLo0ZkUyBxnkhCLOqP wcOlYDkRlfFfgWiitLeGbqawtFA7WPit7FokOLYUvz4a2aZGVNu78GrR0vA0SM//zoxP MOSwTasnGP8GlsKkC2qZ1Ox4xiJKuZLlZPdK3OS2xkSRzWHd2w2f1GeSpk/dSa4Ye5Cn 3RWKAPM/s6A9upCp3iiZNLARRgUuOyJNacw3COii28RbI5/kQLE9o2OmqPnPpjLGWT/u 3mBxXIzr4UcpQNPNMed6g8a+qiCqqhIXZghDwE3dGGV3trLkDgqj1hmMKAWTaS63K20d 1Fqg== X-Gm-Message-State: ALoCoQldp9CrnLoWZTRUxLstTg6c0ADxG76p0zTHrwb78QdfNwc7ES/GQn6n44yKB5W4nRXaetnF X-Received: by 10.194.10.130 with SMTP id i2mr17550236wjb.70.1402590955596; Thu, 12 Jun 2014 09:35:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Thu, 12 Jun 2014 09:35:15 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:496:bac1:f2cc:1e8c] In-Reply-To: <859F43324A6FEC448BFEA30C90405FA90550E0@SEAEMBX02.olympus.F5Net.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <5B1D7E570380A64989D4C069F7D14BC8CB7F66D6@PINTO.missi.ncsc.mil> <859F43324A6FEC448BFEA30C90405FA90550E0@SEAEMBX02.olympus.F5Net.com> From: Eric Rescorla Date: Thu, 12 Jun 2014 09:35:15 -0700 Message-ID: To: David Holmes Content-Type: multipart/alternative; boundary=047d7b450586ac8aae04fba6272c Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CDHUBUpx11Bflvsiv8PAT2zfWxg Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:36:02 -0000 --047d7b450586ac8aae04fba6272c Content-Type: text/plain; charset=UTF-8 On Thu, Jun 12, 2014 at 9:20 AM, David Holmes wrote: > Some field data here. > > Our load-balancers/SSL terminators let customers set a time interval for > renegotiation (the default is never). > > We retain support customers for a period of time and have the ability to > grep through customer configurations. > > Over the previous 90 or 180 days (or whatever our retention period is) > there are 33 customers using renegotiation (on 56 hosts). This is > approximately 0.5% of the customers. > > Of those hosts: > * The selected interval values range from 3 seconds (!!!) to 86400 - with > an average being around 3600 seconds. > * Lots of 10-second renegotiation intervals as well. > * Seems to be a slight preference to the Financial vertical. > > I'm not suggesting that this data moves the conversation about > renegotiation one way or the other. Do you have any idea why they want this? -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7b450586ac8aae04fba6272c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 12, 2014 at 9:20 AM, David Holmes <d.holmes@f5.com> wrote:
Some field data here.

Our load-balancers/SSL terminators let customers set a time interval for re= negotiation (the default is never).

We retain support customers for a period of time and have the ability to gr= ep through customer configurations.

Over the previous 90 or 180 days (or whatever our retention period is) ther= e are 33 customers using renegotiation (on 56 hosts). This is approximately= 0.5% of the customers.

Of those hosts:
* The selected interval values range from 3 seconds (!!!) to 86400 - with a= n average being around 3600 seconds.
* Lots of 10-second renegotiation intervals as well.
* Seems to be a slight preference to the Financial vertical.

I'm not suggesting that this data moves the conversation about renegoti= ation one way or the other.

Do you have any= idea why they want this?

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

--047d7b450586ac8aae04fba6272c-- From nobody Thu Jun 12 09:50:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AABA1A0278 for ; Thu, 12 Jun 2014 09:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg7-NgWEK8U3 for ; Thu, 12 Jun 2014 09:50:31 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FDB1A01AE for ; Thu, 12 Jun 2014 09:50:30 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s5CGoQ48030752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Jun 2014 09:50:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: <859F43324A6FEC448BFEA30C90405FA90550E0@SEAEMBX02.olympus.F5Net.com> Date: Thu, 12 Jun 2014 09:50:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <24FB0151-D8AB-464F-AA40-DB1A9EEDB91B@vpnc.org> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <5B1D7E570380A64989D4C069F7D14BC8CB7F66D6@PINTO.missi.ncsc.mil> <859F43324A6FEC448BFEA30C90405FA90550E0@SEAEMBX02.olympus.F5Net.com> To: David Holmes X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QBqgXcEvS7S1nOcoNd0O6zwfUEI Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:50:31 -0000 On Jun 12, 2014, at 9:20 AM, David Holmes wrote: > I'm not suggesting that this data moves the conversation about = renegotiation one way or the other. It certainly is good data that some/many of your customers (who I = believe could be labelled as "typical") have little understanding of = understanding what renegotiation is for. To me, that supports the "scrap = it" argument. --Paul Hoffman= From nobody Thu Jun 12 10:45:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4461A0201 for ; Thu, 12 Jun 2014 10:45:35 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDD6ws4Ie0Ez for ; Thu, 12 Jun 2014 10:45:33 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE0F1A01AB for ; Thu, 12 Jun 2014 10:45:33 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so1655277wes.22 for ; Thu, 12 Jun 2014 10:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=kVXHJXn0RIMpmg2vNAOkKvE9mGpaC0HFk2Of47l1jc0=; b=ot0z+ujS6F+cEkZRy+hUoF3JqKF49O5HhHv+IdqqZLwwKJ//IhZWhpdcB7M5t/5aEl hUdGS0aiUJOYFiOPcrSlJDcqA12BQFUxD4waUCXuXW2cAfV4ckKkddqhUMo3qEPGijO6 RjNNKbWNsqpIL0Eh8NBrhySich2+lZjyQz8s4AFS7/x+HaViOlSEKGFxN8Xys9H8SDhW 7XIM6W0QXkXlOr+kInntamAn8SzgSK83E64h8H6LhbEN+D4yNk6p538111iZ6fkDgF2z ILqcH376kv46w4or3qGLP/9RERk8RJAT8SblEjPHtrBPGRub3KkUMyGGFS3xMsEJVUSH eElg== X-Received: by 10.180.126.97 with SMTP id mx1mr8384096wib.29.1402595131421; Thu, 12 Jun 2014 10:45:31 -0700 (PDT) Received: from [192.168.1.103] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id cj41sm6049667eeb.34.2014.06.12.10.45.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 10:45:30 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2F58E8FC-07EA-432B-80EF-87B5EAE50E0D" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: Date: Thu, 12 Jun 2014 20:45:27 +0300 Message-Id: <39BABE88-00B9-4656-885E-41FCD1AD3861@gmail.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <5B1D7E570380A64989D4C069F7D14BC8CB7F66D6@PINTO.missi.ncsc.mil> <859F43324A6FEC448BFEA30C90405FA90550E0@SEAEMBX02.olympus.F5Net.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6tlUav0G6aX0thQMvC6XjXGR9zE Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:45:35 -0000 --Apple-Mail=_2F58E8FC-07EA-432B-80EF-87B5EAE50E0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 12, 2014, at 7:35 PM, Eric Rescorla wrote: >=20 > Of those hosts: > * The selected interval values range from 3 seconds (!!!) to 86400 - = with an average being around 3600 seconds. > * Lots of 10-second renegotiation intervals as well. > * Seems to be a slight preference to the Financial vertical. >=20 > I'm not suggesting that this data moves the conversation about = renegotiation one way or the other. >=20 > Do you have any idea why they want this? Maybe the Bruce said something about needing to regularly replace keys = in =93Applied Cryptography=94. The financial market also suggests some security consultant recommending = setting the values. 3600 is actually a pretty fine value, as you would for the most part = never see a renegotiation. Of course, configuring this by traffic volume = would be even better. Yoav --Apple-Mail=_2F58E8FC-07EA-432B-80EF-87B5EAE50E0D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 12, 2014, at 7:35 PM, Eric = Rescorla <ekr@rtfm.com> = wrote:

Of those hosts:
* The selected interval values range from 3 seconds (!!!) to 86400 - = with an average being around 3600 seconds.
* Lots of 10-second renegotiation intervals as well.
* Seems to be a slight preference to the Financial vertical.

I'm not suggesting that this data moves the conversation about = renegotiation one way or the other.

Do = you have any idea why they want = this?

Maybe the Bruce = said something about needing to regularly replace keys in =93Applied = Cryptography=94.

The financial market also = suggests some security consultant recommending setting the = values.

3600 is actually a pretty fine value, = as you would for the most part never see a renegotiation. Of course, = configuring this by traffic volume would be even = better.

Yoav

= --Apple-Mail=_2F58E8FC-07EA-432B-80EF-87B5EAE50E0D-- From nobody Thu Jun 12 11:05:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707A31A01F3 for ; Thu, 12 Jun 2014 11:05:43 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9n-p3LNB0na for ; Thu, 12 Jun 2014 11:05:42 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6EAF1A015C for ; Thu, 12 Jun 2014 11:05:41 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id cc10so3477108wib.0 for ; Thu, 12 Jun 2014 11:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xkORp30TlmeCljOIzt7Hgka3rTS0IEUf0GB/zFJ7NTU=; b=DTfDS8yf5p17NYATRcCobOtTjYJQRBi7sW4RJPRGvMGPxDij8KzTCGMLBF1p/5CHd1 E5YojvlkJ8DXz/YOWB1TPg4bm/pulxJCAL8GGPYIVk979nRy7x/ydvUqSubCcbLsi+l1 b5sozRAEaDsKkrZ9tQWQxCH3U89+WStjzaoZefBSpbdRBXwaCFiC0lmNgQx8yyGRNHWG cflvX6OqLZGGc26G/RmOgmV18Xy5BHa8YXKH/BBoOZDlcKvVGT9ozjqOdYLc9ZVOwc7z 5GBvfTNSfp7KtUCw27RJFpK0ZKjlv1KBce4AbTT3FJmHhytoSXSQnfFIOhJR6E+ftTPK Rycw== MIME-Version: 1.0 X-Received: by 10.194.219.70 with SMTP id pm6mr12366344wjc.53.1402596340237; Thu, 12 Jun 2014 11:05:40 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Thu, 12 Jun 2014 11:05:40 -0700 (PDT) In-Reply-To: <39BABE88-00B9-4656-885E-41FCD1AD3861@gmail.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <5B1D7E570380A64989D4C069F7D14BC8CB7F66D6@PINTO.missi.ncsc.mil> <859F43324A6FEC448BFEA30C90405FA90550E0@SEAEMBX02.olympus.F5Net.com> <39BABE88-00B9-4656-885E-41FCD1AD3861@gmail.com> Date: Thu, 12 Jun 2014 11:05:40 -0700 Message-ID: From: Martin Thomson To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fOzIvnpha-Dtic64Dl7DZXZ-cG0 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:05:43 -0000 On 12 June 2014 10:45, Yoav Nir wrote: > Maybe the Bruce said something about needing to regularly replace keys in > =E2=80=9CApplied Cryptography=E2=80=9D. If rekeying is the reason, then the proposal I made should address that adequately. From nobody Thu Jun 12 11:22:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EEC1B27EF for ; Thu, 12 Jun 2014 11:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VB0H6c5D_L2e for ; Thu, 12 Jun 2014 11:21:54 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420761B27BB for ; Thu, 12 Jun 2014 11:21:54 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j7so918528qaq.38 for ; Thu, 12 Jun 2014 11:21:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=O8pqrxwdn9uR/kzU+niNwA8FUF3otJvsVC3/wkEMYbw=; b=XTiVzSI2B7G09Vm7vrzLq9Ze5PqFB7eu1YUoIOCksEAnT4oM3Tv2mspizwOkfOaqzm Rb1JfNyln+fluIHATPo3sPKoqVDlI+MNB/t+nX6yvfRAUiGPz1rL1594e716u5b+YF6m xeCvSiLNACkHIc4eXgW9kwplu5SEblk2oaFnsNaA052J4XWDPNy6JCeYiIsJgHHr+0y8 Jyi/1/bL4bJEpF5HSbS/wn+eVsn8XbYLUenqa2G6ZnVCbHMVvIYAaEYxArVH4uzsZu/2 7OiA4qiuYRsYB6tcUNHawGNLXzO3kuGGrMJRG5mADxPfsyHm7DISoJxDDPKzNCGsGrYl 3pVQ== X-Gm-Message-State: ALoCoQkGbr4gV9Uwr0GR6qVXDvai69HuZAVxBiaYoy2FIO3jfkZ6nC86ure0tb9gKoXPXVLf+kVv MIME-Version: 1.0 X-Received: by 10.224.36.141 with SMTP id t13mr59632384qad.75.1402597313448; Thu, 12 Jun 2014 11:21:53 -0700 (PDT) Received: by 10.224.212.3 with HTTP; Thu, 12 Jun 2014 11:21:53 -0700 (PDT) In-Reply-To: <9E3DB9FD-2691-4CED-90A9-A024D7A4F4BA@gmail.com> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <5390B1D6.5010105@nthpermutation.com> <5390CA45.1050504@nthpermutation.com> <9E3DB9FD-2691-4CED-90A9-A024D7A4F4BA@gmail.com> Date: Thu, 12 Jun 2014 11:21:53 -0700 Message-ID: From: Brian Smith To: Yoav Nir Content-Type: multipart/alternative; boundary=089e0149d0e4a1a3d004fba7a22a Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dvx1IaRmrMMIoO-VD0D6g_e8b9g Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:21:57 -0000 --089e0149d0e4a1a3d004fba7a22a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 12, 2014 at 2:02 AM, Yoav Nir wrote: > Regarding TLS proxies, I can give my perspective, as I work for one > vendor. > > > Our fake certificates contain the DNs and alternate names from the > original certificate. We don=E2=80=99t copy over any extensions that we d= on=E2=80=99t > understand. The same is also true of TLS - we don=E2=80=99t copy extensio= ns we > don=E2=80=99t know. That is what allows our proxy to gracefully downgrade= HTTP/2 or > SPDY clients and gateways to HTTP/1. > As for dates, these *are* copied from the original certificate, the reaso= n > is that this makes the client behavior similar to whatever it is with the > original certificate. We did consider making the certificates short-lived= , > but decided against it. > > > So your proposed heuristic for detecting fake certificates will work with > some proxies, but not all. Adam=E2=80=99s suggestion should work better, = but best > is if the fake certificate doesn=E2=80=99t promise things the proxy CA do= esn=E2=80=99t > understand. > Thanks for sharing that information. Does your product copy all the certificate policies from the original certificate into the forged certificate? If your product doesn't copy certificate policies it doesn't understand, then there wouldn't be an interop issue with your product and the use of certificate policies for Must-Staple, even if your product doesn't generate short-lived certificates. Cheers, Brian --089e0149d0e4a1a3d004fba7a22a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 12, 2014 at 2:02 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
Regardin= g TLS proxies, I can give my perspective, as I work for one vendor.=C2=A0
<hat type=3D=E2=80=9Cvendor=E2=80=9D status=3D=E2=80=9Con=E2= =80=9D>
Our fake certificates contain the DNs and alternate na= mes from the original certificate. We don=E2=80=99t copy over any extension= s that we don=E2=80=99t understand. The same is also true of TLS - we don= =E2=80=99t copy extensions we don=E2=80=99t know. That is what allows our p= roxy to gracefully downgrade HTTP/2 or SPDY clients and gateways to HTTP/1.=
As for dates, these *are* copied from the original certificate, the re= ason is that this makes the client behavior similar to whatever it is with = the original certificate. We did consider making the certificates short-liv= ed, but decided against it.=C2=A0
</hat>

So your proposed heuristic for d= etecting fake certificates will work with some proxies, but not all. Adam= =E2=80=99s suggestion should work better, but best is if the fake certifica= te doesn=E2=80=99t promise things the proxy CA doesn=E2=80=99t understand.<= /div>

Thanks for sharing that information.= Does your product copy all the certificate policies from the original cert= ificate into the forged certificate? If your product doesn't copy certi= ficate policies it doesn't understand, then there wouldn't be an in= terop issue with your product and the use of certificate policies for Must-= Staple, even if your product doesn't generate short-lived certificates.=

Cheers,
Brian
--089e0149d0e4a1a3d004fba7a22a-- From nobody Thu Jun 12 11:22:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B51B1B27F5 for ; Thu, 12 Jun 2014 11:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_VRy1mCz8RL for ; Thu, 12 Jun 2014 11:22:20 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6B51A0213 for ; Thu, 12 Jun 2014 11:22:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208";a="115450278" X-IPAS-Result: AqYEADD7RVPAqArr/2dsb2JhbABZhBiDDsEFGYEedIImAQEBAyMRRRACAQgNAQwCBiACAgIwFRACBA4NsQmjCBeBKY0SMQeCbzWBFASfWY53gis Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 12 Jun 2014 18:22:10 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 11:22:10 -0700 From: David Holmes To: Eric Rescorla Thread-Topic: [TLS] Proposed text for removing renegotiation Thread-Index: AQHPhdwqCg8gt7OZi0qJtRIa8EVlLJtss9iwgAFuW4D//6VhYA== Date: Thu, 12 Jun 2014 18:22:09 +0000 Deferred-Delivery: Thu, 12 Jun 2014 18:21:00 +0000 Message-ID: <859F43324A6FEC448BFEA30C90405FA9055451@SEAEMBX02.olympus.F5Net.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <5B1D7E570380A64989D4C069F7D14BC8CB7F66D6@PINTO.missi.ncsc.mil> <859F43324A6FEC448BFEA30C90405FA90550E0@SEAEMBX02.olympus.F5Net.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.156] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BdiUwS_mwVy4lRJaBuncXHcxjlI Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:22:21 -0000 ZWtyDQoNCuKeoiBEbyB5b3UgaGF2ZSBhbnkgaWRlYSB3aHkgdGhleSB3YW50IHRoaXM/DQoNClRo ZSBkYXRhIHBvaW50cyB3ZSBoYXZlIG9uIOKAnHdoeeKAnSBhcmUgdGhlIGZvbGxvd2luZzoNCg0K MS4gbG93LWJhbmR3aWR0aCBjb25uZWN0aW9ucyBmcm9tIGF1dG9tYXRlZCB0ZWxsZXIgbWFjaGlu ZXMgKEFUTSkgdGhhdCBjYW4gbGFzdCBmb3IgZGF5cyBvciBldmVuIHdlZWtzLg0KMi4gc2l0ZXMg dGhhdCBzdGFydCDigJxvcGVu4oCdIGJ1dCB3aWxsIHJlcXVpcmUgcmVuZWdvdGlhdGlvbiB3LyBj bGllbnQgY2VydCB3aGVuIHlvdSB0cnkgdG8gZW50ZXIgYSBwcm90ZWN0ZWQgYXJlYS4NCjMuIGlu ZnJhc3RydWN0dXJlIHBpZWNlcyB1c2UgaVF1ZXJ5IG92ZXIgVExTIGFuZCB0aGVzZSByZW5lZ290 aWF0ZSBwZXJpb2RpY2FsbHkuDQoNCk9uZSBjb3VsZCBhbHNvIGxvb2sgYXQgdGhlIHByZXZpb3Vz IHN0YXQgbGlrZSB0aGlzOg0KDQo5OS41JSBvZiB0aGUgbG9hZC1iYWxhbmNpbmcgY3VzdG9tZXJz IGRvIG5vdCB1c2UgcmVuZWdvdGlhdGlvbi4NCg0KDQo= From nobody Thu Jun 12 11:34:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF331A0248 for ; Thu, 12 Jun 2014 11:34: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hd05nVdFMG5n for ; Thu, 12 Jun 2014 11:34:25 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13D741B2AE0 for ; Thu, 12 Jun 2014 11:34:24 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so6170596wib.6 for ; Thu, 12 Jun 2014 11:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PfzLeezulpbyBJ9idYS9cCQghIoO1vo7iR77B6Z93uI=; b=DGtDwXXYwvJ5A2+Y4bP7QAJjoJo1Pz04sKd2dSw0uVhkuxz/I2tuENto4Ge6QKWUCj GqRNyljcXlfr3Vc6YWnOakba6xpe0jY2JC/+siviqb6USnTcCzft80hX1a55q6MK2k7T BtfA1ueQmHty6YT21AR1shByVPeLO4T4hti0AoNXVtVIRbasHAlwfrILSoqfCslj9V6p WMDf80T2j6C15snMJ2NNFN7sReO6kpG6HFGXfn/ssk/gL6j0PpCA1YaVU3JbHqJ6JUKO Y8ikzGsR528vwnB6AMWZrIrPaYOkN8tFTatMtav4uAFPOSaN+GHC0MBMoa7kihAtxQqN kGDg== MIME-Version: 1.0 X-Received: by 10.195.18.8 with SMTP id gi8mr64732434wjd.75.1402598063602; Thu, 12 Jun 2014 11:34:23 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Thu, 12 Jun 2014 11:34:23 -0700 (PDT) In-Reply-To: <859F43324A6FEC448BFEA30C90405FA9055451@SEAEMBX02.olympus.F5Net.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <5B1D7E570380A64989D4C069F7D14BC8CB7F66D6@PINTO.missi.ncsc.mil> <859F43324A6FEC448BFEA30C90405FA90550E0@SEAEMBX02.olympus.F5Net.com> <859F43324A6FEC448BFEA30C90405FA9055451@SEAEMBX02.olympus.F5Net.com> Date: Thu, 12 Jun 2014 11:34:23 -0700 Message-ID: From: Martin Thomson To: David Holmes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/K3V2168x57FaYpl5TyIK-ajQ-ko Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:34:27 -0000 On 12 June 2014 11:22, David Holmes wrote: > The data points we have on =E2=80=9Cwhy=E2=80=9D are the following: > > 1. low-bandwidth connections from automated teller machines (ATM) that ca= n last for days or even weeks. > 2. sites that start =E2=80=9Copen=E2=80=9D but will require renegotiation= w/ client cert when you try to enter a protected area. > 3. infrastructure pieces use iQuery over TLS and these renegotiate period= ically. That suggests 1. rekeying 2. client auth'n 3. rekeying (I think) From nobody Thu Jun 12 11:39:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A149C1B2812 for ; Thu, 12 Jun 2014 11:39: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, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eygtcJ6FHLrH for ; Thu, 12 Jun 2014 11:39:42 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4957E1B280F for ; Thu, 12 Jun 2014 11:39:42 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 187981C20D6; Thu, 12 Jun 2014 20:39:40 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 6A92A1FE00FF; Thu, 12 Jun 2014 20:39:38 +0200 (CEST) Date: Thu, 12 Jun 2014 20:39:38 +0200 From: Kurt Roeckx To: Yoav Nir Message-ID: <20140612183938.GA8147@roeckx.be> References: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <5390B1D6.5010105@nthpermutation.com> <5390CA45.1050504@nthpermutation.com> <9E3DB9FD-2691-4CED-90A9-A024D7A4F4BA@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9E3DB9FD-2691-4CED-90A9-A024D7A4F4BA@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TxaGI3niZZLaqGfZ8WEz61zfRk8 Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:39:44 -0000 On Thu, Jun 12, 2014 at 12:02:40PM +0300, Yoav Nir wrote: > Hi, Brian > > Interesting stuff. Also good to hear that it's easy to implement, although mileages vary. > > Regarding TLS proxies, I can give my perspective, as I work for one vendor. > > > Our fake certificates contain the DNs and alternate names from the original certificate. We don't copy over any extensions that we don't understand. The same is also true of TLS - we don't copy extensions we don't know. That is what allows our proxy to gracefully downgrade HTTP/2 or SPDY clients and gateways to HTTP/1. > As for dates, these *are* copied from the original certificate, the reason is that this makes the client behavior similar to whatever it is with the original certificate. We did consider making the certificates short-lived, but decided against it. > I'm wondering if it also strips things it doesn't know but are marked critical. Kurt From nobody Thu Jun 12 11:44:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CCD1B2AF6 for ; Thu, 12 Jun 2014 11:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZwaE-wQaE3j for ; Thu, 12 Jun 2014 11:44:06 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665B51B27C0 for ; Thu, 12 Jun 2014 11:43:57 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id i17so2537647qcy.22 for ; Thu, 12 Jun 2014 11:43:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4VrKCTfMOuWrffNoS9i1UCZWozZ28w5r9ES3F7CtvBE=; b=Whj7uYuNH5pmYI9DklAt/f1jScIbWR4pFygne7rSs+6hssb2SM4HFyESLr3kQpg/X7 CbOWowQWPRJKaXR4qcvavfDayjuMWrE/Fa78DHLkaMrdE3Iba9CPZx/NfLL0+WwZGAWt N5KW77GD+BAf53D9477nARuzjnRRUp3z8FIrUL93jbvuPuzTxfo8Vlm5AARS04ckzMBl Vfl2swpcxjt+Lg9T3P7nb/mR8QTb/0/yLWMcTtbr9I5b1EWJ26wxiPgfmO0Cy5vRY0tc lwZr0WLYsr80Vp2SX+66dojjrENz/9TquxjD9a1iJ1MWCeIRLRw0TLZb62D8QzCFPYK6 bjgg== X-Gm-Message-State: ALoCoQmLB/YOV96tTRlbDPx1PoNCz6zOIYgZGInYiPbrKuG7EtgfC9CifBmGY35DouA4TOfxqPzT MIME-Version: 1.0 X-Received: by 10.224.30.71 with SMTP id t7mr65004505qac.30.1402598636514; Thu, 12 Jun 2014 11:43:56 -0700 (PDT) Received: by 10.224.212.3 with HTTP; Thu, 12 Jun 2014 11:43:56 -0700 (PDT) In-Reply-To: References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <5390B1D6.5010105@nthpermutation.com> <5390CA45.1050504@nthpermutation.com> Date: Thu, 12 Jun 2014 11:43:56 -0700 Message-ID: From: Brian Smith To: Adam Langley Content-Type: multipart/alternative; boundary=047d7bf0e5307e112504fba7f12c Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tjvB_7yzS4qpe6Cv7uadURsgz5s Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:44:13 -0000 --047d7bf0e5307e112504fba7f12c Content-Type: text/plain; charset=UTF-8 On Wed, Jun 11, 2014 at 4:10 PM, Adam Langley wrote: > On Wed, Jun 11, 2014 at 3:49 PM, Brian Smith wrote: > > * TLS intercepting proxies cause trouble. > > In Chrome (and, I assume, Firefox) there's the concept of a > "non-public root" - i.e. a CA root that the user has installed. When > one is used on a connection we disable pinning. We could also disable > Must Staple. > That is one approach that would address the compatibility issues. However, I think it would be better to find an approach that doesn't limit Must-Staple to publicly-trusted root CAs. Otherwise, it will be harder than necessary to make the case stapling + Must-Staple is a complete replacement for OCSP fetching. If my suggestion of making an exception for short-lived certificates isn't good enough to address the compatibility issue (and it probably isn't) then we could require that the Must-Staple extension in the end-entity certificate be ignored unless it is also present in a CA certificate in the chain. This would work as long as TLS intercepting proxies are not forging intermediate CA certificates by copying the contents of the original intermediate CA certificates. The downside is that every CA that would want to use Must-Staple would have to first issue a new Must-Staple-enabled intermediate. It would be more work, but probably it would still be less of a barrier to enabling Must-Staple than waiting for CA management software to add support for a new extension. Cheers, Brian --047d7bf0e5307e112504fba7f12c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 11, 2014 at 4:10 PM, Adam Langley <agl@google.com> wrot= e:
On Wed, Jun 11, 2014 at 3:49 PM, Brian Smith <brian@briansmith.org> wrote:
> * TLS intercepting proxies cause trouble.

In Chrome (and, I assume, Firefox) there's the concept of a
"non-public root" - i.e. a CA root that the user has installed. W= hen
one is used on a connection we disable pinning. We could also disable
Must Staple.

That is one approach that = would address the compatibility issues. However, I think it would be better= to find an approach that doesn't limit Must-Staple to publicly-trusted= root CAs. Otherwise, it will be harder than necessary to make the case sta= pling + Must-Staple is a complete replacement for OCSP fetching.

If my suggestion of making an exception for short-lived certificates is= n't good enough to address the compatibility issue (and it probably isn= 't) then we could require that the Must-Staple extension in the end-ent= ity certificate be ignored unless it is also present in a CA certificate in= the chain. This would work as long as TLS intercepting proxies are not for= ging intermediate CA certificates by copying the contents of the original i= ntermediate CA certificates. The downside is that every CA that would want = to use Must-Staple would have to first issue a new Must-Staple-enabled inte= rmediate. It would be more work, but probably it would still be less of a b= arrier to enabling Must-Staple than waiting for CA management software to a= dd support for a new extension.

Cheers,
Brian
--047d7bf0e5307e112504fba7f12c-- From nobody Thu Jun 12 13:51:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B3F1B2809 for ; Thu, 12 Jun 2014 13:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.652 X-Spam-Level: X-Spam-Status: No, score=-7.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnNwVhtGaiDU for ; Thu, 12 Jun 2014 13:51:30 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A596A1A025E for ; Thu, 12 Jun 2014 13:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1402606291; x=1434142291; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CMOslf8I1kmKHf4Xpznz7eesf6n6F82LX6f0AVQwKqk=; b=LnLdhq7JRBIhYqFM8QTgh+n/MJRc6XPhRaeZ/FV0GggExJ5MmgS0HAxP 3W8ZhymzUjXNdxDgb8bb89calj3s4MNCdAca8y6+naTZUHiB3+Nf7Zi0i rvnOlbmPtfvzcHgHtMmDIXy23dzSVq3Ihc917c1e0qP4X0wKioZYAedIg M=; X-IronPort-AV: E=Sophos;i="5.01,467,1400025600"; d="scan'208";a="115636342" X-IPAS-Result: As4EAM0RmlPAqArr/2dsb2JhbABahDiCbKZmBgaZHgEZgQh1hAMBAQEBAgEjEUUFCwIBCA0NAgYgAgICMBUQAgQODYgysk6gIBeBKoQyiE4xB4J1NoEWBKFVj2yCLw Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 12 Jun 2014 20:51:30 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 13:51:29 -0700 From: David Holmes To: Martin Thomson Thread-Topic: [TLS] Proposed text for removing renegotiation Thread-Index: AQHPhdwqCg8gt7OZi0qJtRIa8EVlLJtss9iwgAFuW4D//6VhYIAAe+mA//+wZQA= Date: Thu, 12 Jun 2014 20:51:28 +0000 Deferred-Delivery: Thu, 12 Jun 2014 20:51:00 +0000 Message-ID: <859F43324A6FEC448BFEA30C90405FA90557F6@SEAEMBX02.olympus.F5Net.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <5B1D7E570380A64989D4C069F7D14BC8CB7F66D6@PINTO.missi.ncsc.mil> <859F43324A6FEC448BFEA30C90405FA90550E0@SEAEMBX02.olympus.F5Net.com> <859F43324A6FEC448BFEA30C90405FA9055451@SEAEMBX02.olympus.F5Net.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.155] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iEpINcjDHHXJ7rfbUY7tmoPSxeg Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 20:51:31 -0000 PiBUaGF0IHN1Z2dlc3RzIDEuIHJla2V5aW5nIDIuIGNsaWVudCBhdXRoJ24gMy4gcmVrZXlpbmcg KEkgdGhpbmspDQoNClllcy4NCg== From nobody Thu Jun 12 14:45:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0961A028D for ; Thu, 12 Jun 2014 14:45:40 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF8sjKwm3Bir for ; Thu, 12 Jun 2014 14:45:39 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90FBF1A0276 for ; Thu, 12 Jun 2014 14:45:38 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so1916717wgg.32 for ; Thu, 12 Jun 2014 14:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=kDIEsghWsntwiaz5nuDn2HbGB1Q8sujuWIHiO5UDulM=; b=VqFKBJUwMP39zBxgQBu/zkcmvOHQ4Mg0SWPB9t5m0cSlN7KCeKIo2mZQ+hExBJX4pz p18TcFoMCJmKt7aAOZMJfIoeCJwnkDH8A1y/N2OdCCF+MTrUL4N+VS85N4wE7vYqpn16 Rp275T3Id04PoBbVNh4vH8Z+gZiP+4Gj4sUcLCCekb0789mlgSj4eBSg5MAvbfwj8CMv wnGdbk6Wz3+RKdZ/Lg1VdxAtz45J7AFU5L6gEvezJM9PjCitCjdNFjh39ukcZLSVD34T itlYaqzbG0+Jx6wd9HAbZUAzhP6ZGEyXJjfRzH3ZRkf+l3LV9ms/z5hqTyamfNz0ksyg 37eg== X-Received: by 10.181.13.106 with SMTP id ex10mr10003614wid.30.1402609537185; Thu, 12 Jun 2014 14:45:37 -0700 (PDT) Received: from [192.168.1.101] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id f45sm7313255eem.15.2014.06.12.14.45.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 14:45:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CE114B1C-0C19-4977-94CB-B1DBEB25FB27" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: Date: Fri, 13 Jun 2014 00:45:32 +0300 Message-Id: <49B8F9EA-40C6-442D-9E7E-2B09E42CDCC1@gmail.com> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <5390B1D6.5010105@nthpermutation.com> <5390CA45.1050504@nthpermutation.com> <9E3DB9FD-2691-4CED-90A9-A024D7A4F4BA@gmail.com> To: Brian Smith X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RAr6G9T9LT7yAv_cYNNyyRpZg4o Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 21:45:40 -0000 --Apple-Mail=_CE114B1C-0C19-4977-94CB-B1DBEB25FB27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 12, 2014, at 9:21 PM, Brian Smith wrote: > On Thu, Jun 12, 2014 at 2:02 AM, Yoav Nir wrote: > Regarding TLS proxies, I can give my perspective, as I work for one = vendor.=20 >=20 > > Our fake certificates contain the DNs and alternate names from the = original certificate. We don=92t copy over any extensions that we don=92t = understand. The same is also true of TLS - we don=92t copy extensions we = don=92t know. That is what allows our proxy to gracefully downgrade = HTTP/2 or SPDY clients and gateways to HTTP/1. > As for dates, these *are* copied from the original certificate, the = reason is that this makes the client behavior similar to whatever it is = with the original certificate. We did consider making the certificates = short-lived, but decided against it.=20 > >=20 > So your proposed heuristic for detecting fake certificates will work = with some proxies, but not all. Adam=92s suggestion should work better, = but best is if the fake certificate doesn=92t promise things the proxy = CA doesn=92t understand. >=20 > Thanks for sharing that information. Does your product copy all the = certificate policies from the original certificate into the forged = certificate? If your product doesn't copy certificate policies it = doesn't understand, then there wouldn't be an interop issue with your = product and the use of certificate policies for Must-Staple, even if = your product doesn't generate short-lived certificates. IIRC we don=92t copy certificate policies at all, but I could be wrong.=20= The thing is, a browser like Mozilla has to work with many different = interceptors around, so there might be one that does copy all = extensions, but doesn=92t make short-lived certificates. Yoav --Apple-Mail=_CE114B1C-0C19-4977-94CB-B1DBEB25FB27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 12, 2014, at 9:21 PM, Brian = Smith <brian@briansmith.org> = wrote:

On Thu, Jun 12, 2014 at 2:02 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
Regarding TLS proxies, I can give my = perspective, as I work for one vendor. 

<hat type=3D=93vendor=94 status=3D=93on=94>
Our= fake certificates contain the DNs and alternate names from the original = certificate. We don=92t copy over any extensions that we don=92t = understand. The same is also true of TLS - we don=92t copy extensions we = don=92t know. That is what allows our proxy to gracefully downgrade = HTTP/2 or SPDY clients and gateways to HTTP/1.
As for dates, these *are* copied from the original certificate, the = reason is that this makes the client behavior similar to whatever it is = with the original certificate. We did consider making the certificates = short-lived, but decided against it. 
</hat>

So your proposed heuristic = for detecting fake certificates will work with some proxies, but not = all. Adam=92s suggestion should work better, but best is if the fake = certificate doesn=92t promise things the proxy CA doesn=92t = understand.

Thanks for sharing that = information. Does your product copy all the certificate policies from = the original certificate into the forged certificate? If your product = doesn't copy certificate policies it doesn't understand, then there = wouldn't be an interop issue with your product and the use of = certificate policies for Must-Staple, even if your product doesn't = generate short-lived = certificates.

IIRC = we don=92t copy certificate policies at all, but I could be = wrong. 

The thing is, a browser like = Mozilla has to work with many different interceptors around, so there = might be one that does copy all extensions, but doesn=92t make = short-lived = certificates.

Yoav


= --Apple-Mail=_CE114B1C-0C19-4977-94CB-B1DBEB25FB27-- From nobody Thu Jun 12 14:48:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7841A0276 for ; Thu, 12 Jun 2014 14:48: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7T-PvxXl6csD for ; Thu, 12 Jun 2014 14:48:49 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669B11A0282 for ; Thu, 12 Jun 2014 14:48:48 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id r20so2367283wiv.10 for ; Thu, 12 Jun 2014 14:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zzGvwPINri2d3NNJCMn3z8QZYvbArDWHcEe9DPJZjBo=; b=ZCtOwVd21wRx0Z+eMn38N7975Z2FPaHTm6bH60NZuE/xHNWbIzMXUVrAabdZ3vfUWw 5FHezA/NkDdCsuXj9EMV4Ks6fY1VddBF3I5DZor0IjE2uD1EeIg+yFyA60MDKt9ViPqm Gr/Y5Nhkq13m/zYBl1mmcVT6EXm4aDntrmlSDi6tKDdAm9cuTKD37Eu3RtLI+dB3BfLY 5WN8YWp6gLeKESw17kZeWYukV0jKbk/QCO4D7nkkh2O6vLRvnJRy8ccsTdAXsRSrDf5L YLCcxfuMDS+bVexRY85DEBnQLDMMTyRiZM27ZqExm4Kb/v/ehP5a7twjjh1qX1IKRfGe +9rg== X-Received: by 10.180.14.65 with SMTP id n1mr3018727wic.4.1402609726776; Thu, 12 Jun 2014 14:48:46 -0700 (PDT) Received: from [192.168.1.101] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id l45sm7318333eep.25.2014.06.12.14.48.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 14:48:46 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: <20140612183938.GA8147@roeckx.be> Date: Fri, 13 Jun 2014 00:48:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <66BD07EC-1CCC-49DC-99F5-02102230157D@gmail.com> References: <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <5390B1D6.5010105@nthpermutation.com> <5390CA45.1050504@nthpermutation.com> <9E3DB9FD-2691-4CED-90A9-A024D7A4F4BA@gmail.com> <20140612183938.GA8147@roeckx.be> To: Kurt Roeckx X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/n4kdaapaWusFAm7ebq1pOMv4RHs Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 21:48:53 -0000 On Jun 12, 2014, at 9:39 PM, Kurt Roeckx wrote: > On Thu, Jun 12, 2014 at 12:02:40PM +0300, Yoav Nir wrote: >> Hi, Brian >>=20 >> Interesting stuff. Also good to hear that it's easy to implement, = although mileages vary. >>=20 >> Regarding TLS proxies, I can give my perspective, as I work for one = vendor.=20 >>=20 >> >> Our fake certificates contain the DNs and alternate names from the = original certificate. We don't copy over any extensions that we don't = understand. The same is also true of TLS - we don't copy extensions we = don't know. That is what allows our proxy to gracefully downgrade HTTP/2 = or SPDY clients and gateways to HTTP/1. >> As for dates, these *are* copied from the original certificate, the = reason is that this makes the client behavior similar to whatever it is = with the original certificate. We did consider making the certificates = short-lived, but decided against it.=20 >> >=20 > I'm wondering if it also strips things it doesn't know but are > marked critical. For the server-side half of the connection, a proxy acts as a client, or = in certificate terminology, a relying party. If there=92s a critical = extension it doesn=92t understand, it rejects the certificate, and never = even gets to the stage of creating a fake certificate. So there=92s the big set of certificate extension, a proper subset of = this that are the extensions that the product understands, and a proper = subset of that, which are the extensions that it copies.=20 Yoav From nobody Thu Jun 12 16:44:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9266A1A02EF for ; Thu, 12 Jun 2014 16:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ke4oyY6mzsO for ; Thu, 12 Jun 2014 16:44:29 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423AC1A02ED for ; Thu, 12 Jun 2014 16:44:29 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id w7so3160009qcr.16 for ; Thu, 12 Jun 2014 16:44:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jjznSraPgxE0Si4JXrT5hkmz5nyImuqPunkABJU6WzI=; b=J62KWkV3GUmtxxj/m10SYTVEAhO3G1+gjgFMwN0AU+1qLJdkwfQgn/+fAE/Kjll4nd ux9PI1DyPZJWGeN+EDFwCDp+Q+2+BpejEQEP4MDs3n5e7hZp5uOoQM1ndssQVY83T4hI SVrPTxpEQbnL8qYbXRzX34SnkZvPWydWVKJ/FGRUMH6/E2v+M8kHwRAn5m+7drNGz+Cl uxlKNm4ffJArYozGLM07jXDsepgIsy2wTq0iAqH3izWo3O8iDYiylHRuqtrkFtRhINmO +E5um0OejylOmQ9URW9Pv/z574s/yL928LZgY64JJ82yCvKPpRzRmOQcJumayyDa8P9M JM2Q== X-Gm-Message-State: ALoCoQkJckGgO/udoUypunNJbmBB4S9aeGQWFHT+1s/P+CIGNHy4w+I+q6sAQu4weocy2l4a4FTr MIME-Version: 1.0 X-Received: by 10.224.55.130 with SMTP id u2mr65891994qag.67.1402616668372; Thu, 12 Jun 2014 16:44:28 -0700 (PDT) Received: by 10.224.212.3 with HTTP; Thu, 12 Jun 2014 16:44:28 -0700 (PDT) In-Reply-To: <49B8F9EA-40C6-442D-9E7E-2B09E42CDCC1@gmail.com> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <5390B1D6.5010105@nthpermutation.com> <5390CA45.1050504@nthpermutation.com> <9E3DB9FD-2691-4CED-90A9-A024D7A4F4BA@gmail.com> <49B8F9EA-40C6-442D-9E7E-2B09E42CDCC1@gmail.com> Date: Thu, 12 Jun 2014 16:44:28 -0700 Message-ID: From: Brian Smith To: Yoav Nir Content-Type: multipart/alternative; boundary=047d7bdc878446796604fbac2404 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QRY3XoXZRsU4OJVaEhOmiW1Epbw Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 23:44:31 -0000 --047d7bdc878446796604fbac2404 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 12, 2014 at 2:45 PM, Yoav Nir wrote: > > On Jun 12, 2014, at 9:21 PM, Brian Smith wrote: > > Thanks for sharing that information. Does your product copy all the > certificate policies from the original certificate into the forged > certificate? If your product doesn't copy certificate policies it doesn't > understand, then there wouldn't be an interop issue with your product and > the use of certificate policies for Must-Staple, even if your product > doesn't generate short-lived certificates. > > IIRC we don=E2=80=99t copy certificate policies at all, but I could be wr= ong. > It would be great to get a more definitive confirmation of that, not just from you, but from other vendors of similar products. The thing is, a browser like Mozilla has to work with many different > interceptors around, so there might be one that does copy all extensions, > but doesn=E2=80=99t make short-lived certificates. > I agree there probably is one that is especially problematic like that. But, it seems like we should actually find such a problematic one deployed before we start limiting the usefulness of the feature to accommodate it. Cheers, Brian --047d7bdc878446796604fbac2404 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 12, 2014 at 2:45 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:

On Jun 12, 2014, at 9:21 PM, Brian Smith <<= a href=3D"mailto:brian@briansmith.org" target=3D"_blank">brian@briansmith.o= rg> wrote:
Thanks for sharing that information. Does your p= roduct copy all the certificate policies from the original certificate into= the forged certificate? If your product doesn't copy certificate polic= ies it doesn't understand, then there wouldn't be an interop issue = with your product and the use of certificate policies for Must-Staple, even= if your product doesn't generate short-lived certificates.
IIRC we don=E2= =80=99t copy certificate policies at all, but I could be wrong.=C2=A0
=

=C2=A0It would be great to get a mor= e definitive confirmation of that, not just from you, but from other vendor= s of similar products.

The thing is, a browser like Mozilla has to work with man= y different interceptors around, so there might be one that does copy all e= xtensions, but doesn=E2=80=99t make short-lived certificates.

I agree there probably is one that i= s especially problematic like that. But, it seems like we should actually f= ind such a problematic one deployed before we start limiting the usefulness= of the feature to accommodate it.

Cheers,
Brian
--047d7bdc878446796604fbac2404-- From nobody Thu Jun 12 21:52:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC4D1B28A8 for ; Thu, 12 Jun 2014 21:52: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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToM7VhRUKl3Y for ; Thu, 12 Jun 2014 21:52:53 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638821B28AB for ; Thu, 12 Jun 2014 21:52:53 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so200284wib.6 for ; Thu, 12 Jun 2014 21:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=CTyh2O9e0CBmg4PWSWm1fUl+XQrXxPulm7+OkmrpgKw=; b=mrmBYSzp1taBHX40u2tjSucR48R3/Z1T57R6JDWo4CdgO7ys/acsY1JCr/VLMmCG+P TZvSYTaBwbO2hASKjIE+wVvCO5I+yNnpRN6NNym6eckVN3EuUm2ZnbyE6iOq+Tjma8C3 gS73Ue8IxpIMkcemroLtG5f+gxBfNL8bbwZBGnML7fPGb3sr6/nKzpZu4BrebcBNLm8Z 3Wv34LCoNKyIIN9+/80xSPhh5Elox1V0CKlyUYnfRUhxfVRJAubjllmLzlfs7mI1OZJY 7Cfb1kYxMhvECcUSbtDGI8oH2+cj3uGQOLN29HY4fgQOXoOQxcEe6mItzxOIEtY+LN6D B57A== X-Received: by 10.194.6.166 with SMTP id c6mr511912wja.64.1402635170778; Thu, 12 Jun 2014 21:52:50 -0700 (PDT) Received: from [192.168.1.101] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id l41sm9245272eew.8.2014.06.12.21.52.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 21:52:49 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B2AD33A8-C601-4DD6-952C-DFC33F5496A1" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: Date: Fri, 13 Jun 2014 07:52:47 +0300 Message-Id: <6407EEB5-E138-4B50-83D1-D68E1DC8E5EE@gmail.com> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <5390B1D6.5010105@nthpermutation.com> <5390CA45.1050504@nthpermutation.com> <9E3DB9FD-2691-4CED-90A9-A024D7A4F4BA@gmail.com> <49B8F9EA-40C6-442D-9E7E-2B09E42CDCC1@gmail.com> To: Brian Smith X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YhlXqEGvm-6gRfxkOFXR7SObRbI Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 04:52:55 -0000 --Apple-Mail=_B2AD33A8-C601-4DD6-952C-DFC33F5496A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 13, 2014, at 2:44 AM, Brian Smith wrote: > On Thu, Jun 12, 2014 at 2:45 PM, Yoav Nir wrote: >=20 > On Jun 12, 2014, at 9:21 PM, Brian Smith wrote: >> Thanks for sharing that information. Does your product copy all the = certificate policies from the original certificate into the forged = certificate? If your product doesn't copy certificate policies it = doesn't understand, then there wouldn't be an interop issue with your = product and the use of certificate policies for Must-Staple, even if = your product doesn't generate short-lived certificates. >=20 > IIRC we don=92t copy certificate policies at all, but I could be = wrong.=20 >=20 > It would be great to get a more definitive confirmation of that, not = just from you, but from other vendors of similar products. The weekend for us is Friday+Saturday, so I=92ll only be able to check = this only on Sunday. > The thing is, a browser like Mozilla has to work with many different = interceptors around, so there might be one that does copy all = extensions, but doesn=92t make short-lived certificates. >=20 > I agree there probably is one that is especially problematic like = that. But, it seems like we should actually find such a problematic one = deployed before we start limiting the usefulness of the feature to = accommodate it. A TLS proxy acts as both CA and server for the client. If it emits a = certificate that says it must staple and then doesn=92t staple, then the = proxy is the one with the bug, the =93last one who changed=94 doctrine = notwithstanding. OCSP stapling has privacy benefits. I don=92t think it=92s warranted to = disable that feature because of somebody else=92s implementation bug.=20 Yoav --Apple-Mail=_B2AD33A8-C601-4DD6-952C-DFC33F5496A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 13, 2014, at 2:44 AM, Brian = Smith <brian@briansmith.org> = wrote:

On Thu, Jun 12, 2014 at 2:45 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:

On Jun 12, = 2014, at 9:21 PM, Brian Smith <brian@briansmith.org> wrote:
Thanks for sharing that information. Does your = product copy all the certificate policies from the original certificate = into the forged certificate? If your product doesn't copy certificate = policies it doesn't understand, then there wouldn't be an interop issue = with your product and the use of certificate policies for Must-Staple, = even if your product doesn't generate short-lived certificates.
IIRC we don=92t copy = certificate policies at all, but I could be = wrong. 

 It would = be great to get a more definitive confirmation of that, not just from = you, but from other vendors of similar = products.

The = weekend for us is Friday+Saturday, so I=92ll only be able to check this = only on Sunday.

The thing is, a browser = like Mozilla has to work with many different interceptors around, so = there might be one that does copy all extensions, but doesn=92t make = short-lived certificates.

I agree there probably is one = that is especially problematic like that. But, it seems like we should = actually find such a problematic one deployed before we start limiting = the usefulness of the feature to accommodate = it.

A TLS = proxy acts as both CA and server for the client. If it emits a = certificate that says it must staple and then doesn=92t staple, then the = proxy is the one with the bug, the =93last one who changed=94 doctrine = notwithstanding.

OCSP stapling has privacy benefits. = I don=92t think it=92s warranted to disable that feature because of = somebody else=92s implementation = bug. 

Yoav

= --Apple-Mail=_B2AD33A8-C601-4DD6-952C-DFC33F5496A1-- From nobody Fri Jun 13 01:43:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474721A0312 for ; Fri, 13 Jun 2014 01:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAvrwKy3nlxW for ; Fri, 13 Jun 2014 01:43:02 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 78E0F1A030E for ; Fri, 13 Jun 2014 01:43:02 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5D8h0br031000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Jun 2014 04:43:00 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5D8gwZp007417 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2014 04:42:59 -0400 Message-ID: <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Watson Ladd Date: Fri, 13 Jun 2014 10:42:57 +0200 In-Reply-To: References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GDAYVnU6wEBnR5m5IZwDZZ_FbD8 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 08:43:05 -0000 On Wed, 2014-06-11 at 08:45 -0300, Watson Ladd wrote: > >> Quick: what is the proper response when the Certificate changes > >> between a negotiation and a renegotiation? > > > > That is on the application protocol to decide. > Always the wrong answer: we know more then the application layer > people do about security, just as the networking people know more than > we do about sending packets through the network. Sorry, but I don't believe you understand the issue. Authentication is to the application layer to decide. The secure transport protocol cannot know or guess when and if authentication is desired by the upper protocols. TLS should determine the algorithms and the methods, but the upper protocols should set the timing and the allowed combinations. It may be very legitimate to switch my user-certificate to access a different web page; that cannot be mandated by TLS. > >> What is the relation between the two connections? Can there ever be > >> sensible semantics for this? > >> Renegotiation makes reads block on writes, a problem for all > >> event-based systems. Exposing renegotiation to application level code > >> is hard. > > It has been done already, and not only once. Could you provide evidence > > of this hardness that you claim? > Where has this been done? I'd suggest you to check existing TLS implementations, or read the discussion in the triple handshake paper (section II). > As for the hardness, most applications expect a stream of bytes. > Renegotation is OOB data. What is the issue with that? > >> Show me a formalization of renegotiation semantics, and I might be > >> convinced otherwise. > > I think it is up to the one proposing the change to provide evidence of > > the contrary and there has been none so far. Otherwise we do things like > > prove me TLS secure combination or we drop it completely. Formal models > > lag behind protocols. > You guessed what the next email from me when EKR posted his draft was > going to say. Since miTLS finished up this has been a reasonable > position: TLS 1.2 has fairly well understood security, so TLS 1.3 > should be better, not worse. Or do you think that three attacks in > three years is acceptable? I don't think anyone would disagree with what you say here. But you are avoiding to reply to the point. Was the new proposal you endorse proven secure, or do we replace the old method, -that you claim is insecure- with yet another method that will be proven insecure in few years? > Where is the usecase that needs renegotiation in TLS 1.3? I've not > seen it: we've provided alternatives for all of them. I don't buy the we have provided alternatives for all of them, because you fail to show the issue that is so grave that requires throwing out renegotiation, and re-inventing it. > Why do you care > what we do to provide an easy protocol to analyze? If there is a case > for keeping renegotation, make it: Sorry, protocol design doesn't work like that. If you want to change or remove something, you need to make a case for that, and it is up to you to make solid arguments. Making a change an basing it on arguments like, (1) everyone knows that, (2) this paper supports my opinion -but it doesn't-, doesn't give any credibility to your proposal. Maybe you are right, but unless you make your case with solid arguments, you haven't convinced me. > >> But to say that it is > >> "not complex" belies the experience of implementors, theorists, and > >> the past 17 years of security > > It's good to know that you are representing them. Could you share your > > experience with implementing or modeling TLS? Or at least cite some > > document that backs up the claims that you make. > Let's see: there's the discussion in the Triple Handshake paper of how > applications respond to these changes, Which changes do you refer to, and which discussion. The paper as I read it, makes no claims that renegotiation is overly complex or cannot be modeled. On the contrary, it is mentioned that it is already modeled in mitls. > the previous renegotiation bug, It was addressed long time ago. > virtually every paper on the TLS handshake until miTLS, etc. Can you > point to someone providing an adequate explanation of what > renegotation does? This is not a citation, you could replace it with "everyone knows that". If you really have a point, because it is not of your own experience, please cite it properly. regards, Nikos From nobody Fri Jun 13 03:32:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8471B27FF for ; Fri, 13 Jun 2014 03:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgyPivHVuaQs for ; Fri, 13 Jun 2014 03:32:38 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (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 ACC521A854B for ; Fri, 13 Jun 2014 03:32:36 -0700 (PDT) Received: (qmail 3251 invoked by uid 1000); 13 Jun 2014 10:32:34 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 13 Jun 2014 11:32:34 +0100 Message-ID: <539AD342.3090401@comodo.com> Date: Fri, 13 Jun 2014 11:32:34 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian Smith , Yoav Nir References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <5390B1D6.5010105@nthpermutation.com> <5390CA45.1050504@nthpermutation.com> <9E3DB9FD-2691-4CED-90A9-A024D7A4F4BA@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tPE7B8fGdxF8XNN6H45bAH5yHdk Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 10:32:40 -0000 On 12/06/14 19:21, Brian Smith wrote: > On Thu, Jun 12, 2014 at 2:02 AM, Yoav Nir wrote: > So your proposed heuristic for detecting fake certificates will work > with some proxies, but not all. Adams suggestion should work > better, but best is if the fake certificate doesnt promise things > the proxy CA doesnt understand. > > Thanks for sharing that information. Does your product copy all the > certificate policies from the original certificate into the forged > certificate? If your product doesn't copy certificate policies it > doesn't understand, then there wouldn't be an interop issue with your > product and the use of certificate policies for Must-Staple, even if > your product doesn't generate short-lived certificates. So far we've been discussing two options for how to encode the Must Staple indicator: - As a new Certificate Extension. - As a Certificate Policy. Here's a third option... - Put it in the Authority Information Access extension. RFC5280 says that the AIA extension... "indicates how to access information and services...(which) may include on-line validation services and CA policy data." The AIA extension's id-ad-ocsp "accessMethod" specifies "how to access" the origin OCSP Responder directly. Now, compare id-ad-ocsp to OCSP Stapling and Must Staple... - "information and services": identical. For all three, what we want is an OCSP Response. - "how to access": id-ad-ocsp: SHOULD get the OCSP Response from the OCSP Responder. OCSP Stapling: SHOULD get the OCSP Response from the TLS handshake. Must Staple: MUST get the OCSP Response from the TLS handshake. We could... 1. Use the existing id-ad-ocsp "accessMethod", and define a new "accessLocation" that uses a type other than a GeneralName->uniformResourceIdentifier and has the meaning "the location is the CertificateStatus TLS extension sent by the Server". ...or... 2. Define a new "accessMethod" that has that meaning. (Not sure what we'd put in the "accessLocation" though). Would this approach be any more or less likely to work with proxies? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Jun 13 04:34:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D4B1B283F for ; Fri, 13 Jun 2014 04:34:32 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WY3lD-i130wK for ; Fri, 13 Jun 2014 04:34:30 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FDBF1A0340 for ; Fri, 13 Jun 2014 04:34:30 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id 10so1906172ykt.8 for ; Fri, 13 Jun 2014 04:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z3IzV+yN4IU/Ha+HEywh3anp8a5FsgaB3r0FHx1r3l8=; b=qVXJiPINOwj/Xum0mnHdUG1zyDcIZCrNa+kj10fATmky7c5C9bFJjwF5cghJ81Vj8w rOkh9XZv4vR7qvabBeyRyqVm+iQ2bMG9kGonqkfHREOqFUwBkOE11ZdraynwXre6UEPn zhT9u6tJ639a8Zuxof25Xqg7KP6vWGxoiEEtQH+grGscOelhJEIUQhV75YUAxVVh26xY VX/m6Anmb5uvbx+FWVuLb8jhFRMmxboAXkSj8e9EJ59mnvjA+PKfA25sooW7PS3X1j12 8wzDSV/BBHb4+CDMrQHH6edt39ok2w6IlmjbSVvt9ACV/GBIXChdFSRL2agR3I2oKcRh 03vg== MIME-Version: 1.0 X-Received: by 10.236.15.133 with SMTP id f5mr3383863yhf.63.1402659269277; Fri, 13 Jun 2014 04:34:29 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Fri, 13 Jun 2014 04:34:29 -0700 (PDT) In-Reply-To: <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> Date: Fri, 13 Jun 2014 08:34:29 -0300 Message-ID: From: Watson Ladd To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/figx0KV83cdlbqLLCvebhoF0GA0 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 11:34:32 -0000 On Fri, Jun 13, 2014 at 5:42 AM, Nikos Mavrogiannopoulos wrote: > On Wed, 2014-06-11 at 08:45 -0300, Watson Ladd wrote: >> >> Quick: what is the proper response when the Certificate changes >> >> between a negotiation and a renegotiation? >> > >> > That is on the application protocol to decide. >> Always the wrong answer: we know more then the application layer >> people do about security, just as the networking people know more than >> we do about sending packets through the network. > > Sorry, but I don't believe you understand the issue. Authentication is > to the application layer to decide. The secure transport protocol cannot > know or guess when and if authentication is desired by the upper > protocols. TLS should determine the algorithms and the methods, but the > upper protocols should set the timing and the allowed combinations. It > may be very legitimate to switch my user-certificate to access a > different web page; that cannot be mandated by TLS. Sure, but then we should make clear that the upper-level protocol should control when renegotiation happens. Right now it's a free-for-all: you can change the authentication state repeatedly in the course of reading a request. As a result, when the application checks what the authentication state is there is a TOCTOU problem. The renegotiation fix kind of solves this problem: it takes data from the first connection and links it to the second. > >> >> What is the relation between the two connections? Can there ever be >> >> sensible semantics for this? >> >> Renegotiation makes reads block on writes, a problem for all >> >> event-based systems. Exposing renegotiation to application level code >> >> is hard. >> > It has been done already, and not only once. Could you provide evidence >> > of this hardness that you claim? >> Where has this been done? > > I'd suggest you to check existing TLS implementations, or read the > discussion in the triple handshake paper (section II). > >> As for the hardness, most applications expect a stream of bytes. >> Renegotation is OOB data. > > What is the issue with that? The issue is the following: most applications do something like this parse_request(conn) check_if_request_authorized(conn) This assumes that the authentication state doesn't change in between the two lines, or midway through the parse. With renegotiation it can. Furthermore, renegotiation makes writes block on reads. That can cause pain for event based systems. > >> >> Show me a formalization of renegotiation semantics, and I might be >> >> convinced otherwise. >> > I think it is up to the one proposing the change to provide evidence of >> > the contrary and there has been none so far. Otherwise we do things like >> > prove me TLS secure combination or we drop it completely. Formal models >> > lag behind protocols. >> You guessed what the next email from me when EKR posted his draft was >> going to say. Since miTLS finished up this has been a reasonable >> position: TLS 1.2 has fairly well understood security, so TLS 1.3 >> should be better, not worse. Or do you think that three attacks in >> three years is acceptable? > > I don't think anyone would disagree with what you say here. But you are > avoiding to reply to the point. Was the new proposal you endorse proven > secure, or do we replace the old method, -that you claim is insecure- > with yet another method that will be proven insecure in few years? What new proposal have I endorsed? No, you do the work to show your protocol is secure. Up until now, we haven't, and users have paid the price. (If we eliminate renegotation, clearly this cannot be less secure. If we add key rotation, assuming we do it sanely, there is fairly clearly not a problem.) > >> Where is the usecase that needs renegotiation in TLS 1.3? I've not >> seen it: we've provided alternatives for all of them. > > I don't buy the we have provided alternatives for all of them, because > you fail to show the issue that is so grave that requires throwing out > renegotiation, and re-inventing it. > >> Why do you care >> what we do to provide an easy protocol to analyze? If there is a case >> for keeping renegotation, make it: > > Sorry, protocol design doesn't work like that. If you want to change or > remove something, you need to make a case for that, and it is up to you > to make solid arguments. Making a change an basing it on arguments like, > (1) everyone knows that, (2) this paper supports my opinion -but it > doesn't-, doesn't give any credibility to your proposal. > > Maybe you are right, but unless you make your case with solid arguments, > you haven't convinced me. > >> >> But to say that it is >> >> "not complex" belies the experience of implementors, theorists, and >> >> the past 17 years of security >> > It's good to know that you are representing them. Could you share your >> > experience with implementing or modeling TLS? Or at least cite some >> > document that backs up the claims that you make. >> Let's see: there's the discussion in the Triple Handshake paper of how >> applications respond to these changes, > > Which changes do you refer to, and which discussion. The paper as I read > it, makes no claims that renegotiation is overly complex or cannot be > modeled. On the contrary, it is mentioned that it is already modeled in > mitls. > >> the previous renegotiation bug, > > It was addressed long time ago. I don't think you understand the point I'm trying to make: it's not that I can sit down and make an attack taking advantage of renegotation. It's that renegotation is so complex that applications don't understand how to use it, and so it's very difficult to ensure that we've provided the right semantics, and hard to determine how implementations should deal with it. With the Finished message it's a different issue: analyzing with Finished is a pain, because the master-secret gets used as is. With the core handshake it's a third issue: the standard key agreement semantics have never been provided, and they should be. I don't care too much about renegotiation: the handshake fixes, maintaining the security of the new handshakes, and fixing the finished message are more important. > >> virtually every paper on the TLS handshake until miTLS, etc. Can you >> point to someone providing an adequate explanation of what >> renegotation does? > > This is not a citation, you could replace it with "everyone knows that". > If you really have a point, because it is not of your own experience, > please cite it properly. Go to eprint.iacr.org. Search TLS: http://eprint.iacr.org/2013/339.pdf "we do not model renegotation/resumption" http://eprint.iacr.org/2012/630.pdf Analyzes the renegotation fix, a full 3 years after the fix was proposed and adopted, and TLS does not meet strongest security model. http://eprint.iacr.org/2014/020.pdf Renegotation isn't mentioned. I did skip over a few papers but the message is clear: renegotiation is not currently amenable to analysis. Sincerely, Watson Ladd > > regards, > Nikos > > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Jun 13 10:44:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11F81B2992 for ; Fri, 13 Jun 2014 10:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNwMZ69URYW5 for ; Fri, 13 Jun 2014 10:44:14 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BCF1B2957 for ; Fri, 13 Jun 2014 10:44:13 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id im17so2552148vcb.25 for ; Fri, 13 Jun 2014 10:44:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=SyLIRMgRlXvBrur1soOasQrEMnXl3S1Zejqe5cvlcyU=; b=NJUFI3uqGBD5BMy3phHmNTZ7FJeKhbM2lmVfl4/4F9c8yU3OdAyE9qnWPrwLVggMbg w5M0TsFnu3S0DecYPyjVlQflhFWPIw0haIZVFF2/0AwnSYmXsMO2eYpz1vCAY4GVQY59 EB4CB8NF4IPAxDtCt8MoxZ4OPnKG2PVkYtSRl1YEqHl4NposeKfD5MIR6OIPIwShuP1O bDpi1Qa0b7zyADkGfpwo6b2xEq4tBTdhEcJj9HmnxfoWTZ2vs2NY9augXpTY3Q1H+sfz POTxZDDYfLjD7FVZs72jn+bWlVgJfP+g3Hxvc5bSG+gh/Bz2rgcrA1oZsziJ44nOIfKn gKKg== X-Gm-Message-State: ALoCoQl/D6h75XIhjYw1m2YVSE7ByUSY6MlTmMsdwmN1XxOdoRDEEie+7JZjCA+Iu59gCV6Hr0b3 MIME-Version: 1.0 X-Received: by 10.58.210.68 with SMTP id ms4mr2729034vec.6.1402681451952; Fri, 13 Jun 2014 10:44:11 -0700 (PDT) Received: by 10.52.249.79 with HTTP; Fri, 13 Jun 2014 10:44:11 -0700 (PDT) X-Originating-IP: [132.162.120.50] In-Reply-To: References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> Date: Fri, 13 Jun 2014 13:44:11 -0400 Message-ID: From: Steve Checkoway To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bd6ad42ad54e204fbbb39d8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/t2t4aOPVtjvIGMftHFtZnraO2nE Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 17:44:17 -0000 --047d7bd6ad42ad54e204fbbb39d8 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 13, 2014 at 7:34 AM, Watson Ladd wrote: > The issue is the following: most applications do something like this > parse_request(conn) > check_if_request_authorized(conn) > > This assumes that the authentication state doesn't change in between > the two lines, or midway through the parse. > With renegotiation it can. Although I'm leaning toward removing renegotiation (and potentially adding rekeying or authentication), I'm not sure your example demonstrates an issue. Regardless of the authentication state during parse_request, the relevant issue is is the other side authorized at the point of the check_if_request_authorized. Where do you see a TOCTTOU violation? -- Steve Checkoway --047d7bd6ad42ad54e204fbbb39d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 13, 2014 at 7:34 AM, Watson Ladd <watsonbladd@gmail.com>= ; wrote:
=C2=A0
The issue is the following:= most applications do something like this
parse_request(conn)
check_if_request_authorized(conn)

This assumes that the authentication state doesn't change in between the two lines, or midway through the parse.
With renegotiation it can.

Although I'm= leaning toward removing renegotiation (and potentially adding rekeying or = authentication), I'm not sure your example demonstrates an issue. Regar= dless of the authentication state during parse_request, the relevant issue = is is the other side authorized at the point of the check_if_request_author= ized.

Where do you see a TOCTTOU violation?

=C2=A0--=C2=A0
Steve Checkoway

--047d7bd6ad42ad54e204fbbb39d8-- From nobody Fri Jun 13 11:10:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9F81B293F for ; Fri, 13 Jun 2014 11:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffAE2D007S88 for ; Fri, 13 Jun 2014 11:10:00 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 043881A01E7 for ; Fri, 13 Jun 2014 11:10:00 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BE003165694; Fri, 13 Jun 2014 18:09:58 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id B309C165690; Fri, 13 Jun 2014 18:09:58 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 8608C1E045; Fri, 13 Jun 2014 18:09:58 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Fri, 13 Jun 2014 14:09:58 -0400 From: "Salz, Rich" To: Steve Checkoway , "tls@ietf.org" Date: Fri, 13 Jun 2014 14:09:57 -0400 Thread-Topic: [TLS] Proposed text for removing renegotiation Thread-Index: Ac+HLyHgIZBWn4+uTBi1EEggjKJnXgAAnjaw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7181DE20AFB@USMBX1.msg.corp.akamai.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7181DE20AFBUSMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WyBbck537CQ0LqDjbBX4R0Lye5c Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 18:10:01 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7181DE20AFBUSMBX1msgcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIFdoZXJlIGRvIHlvdSBzZWUgYSBUT0NUVE9VIHZpb2xhdGlvbj8NCg0KSSBkb27igJl0IHRo aW5rIGl04oCZcyBndWFyYW50ZWVkIHRoYXQgdGhlcmXigJlzIGEgdmlvbGF0aW9uLCBidXQgaXQg aXMgdmVyeSBoYXJkIHRvIGdldCB0aGlzIHJpZ2h0LiBDb21wYXJlZCB0bywgc2F5LCBmaWxlc3lz dGVtIG9wZXJhdGlvbnMgb24gYSBsb2NhbCBvcGVyYXRpbmcgc3lzdGVtLCB0aGluZ3MgYXJlIHNl cXVlbnRpYWwgYW5kIGF0b21pYzsgYSBwcm9jZXNzIGNhbuKAmXQgZG8gc2V0dWlkKCkgd2hpbGUg b3BlbigpIGlzIGNoZWNraW5nIHRvIHNlZSBpZiB0aGUgcHJvY2VzcyBoYXMgdGhlIHJlcXVpcmVk IHBlcm1pc3Npb24uIEFuZCBhbHNvIHRoZSBrZXJuZWwgQUxXQVlTIGtub3dzIHRoZSBpZGVudGl0 eSBvZiB0aGUgcHJvZ3JhbS4gVGhpcyBpcyBkaWZmZXJlbnQgZnJvbSBuZXR3b3JrL3dlYiBhcHBs aWNhdGlvbnMsIHdoaWNoIGFyZSBvZnRlbiBub3QgZXhwZWN0aW5nIGlkZW50aXR5IGNoZWNrcywg YW5kIHdoZXJlIHRoZSDigJxmcmFtZXdvcmsgcnVudGltZeKAnSBpcyBkb2luZyB0aGluZ3Mgd2hp bGUgdGhlIGJ1c2luZXNzIGxvZ2ljIGlzIHByb2Nlc3NpbmcgYSByZXF1ZXN0LCBvZnRlbiBpbiB0 aGUgbmFtZSBvZiBzcGVlZFhYWFhYIGJldHRlciB1c2VyIGV4cGVyaWVuY2UuDQoNCiAgICAgICAg ICAgICAgICAvciQNCg0KLS0NClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcg0KQWthbWFpIFRl Y2hub2xvZ2llcywgQ2FtYnJpZGdlLCBNQQ0KSU06IHJzYWx6QGphYmJlci5tZTxtYWlsdG86cnNh bHpAamFiYmVyLm1lPjsgVHdpdHRlcjogUmljaFNhbHoNCg0K --_000_2A0EFB9C05D0164E98F19BB0AF3708C7181DE20AFBUSMBX1msgcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMDg3NzI1NTYxOw0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxODc4ODE3OTIwIDE2Nzg1NDYzMzQgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxi b2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0 aW9uMT48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseTpXaW5nZGluZ3MnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPsOY PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyA8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+V2hlcmUgZG8geW91IHNlZSBhIFRPQ1RUT1UgdmlvbGF0 aW9uPzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5JIGRvbuKAmXQgdGhpbmsgaXTigJlzIGd1YXJhbnRlZWQgdGhhdCB0 aGVyZeKAmXMgYSB2aW9sYXRpb24sIGJ1dCBpdCBpcyB2ZXJ5IGhhcmQgdG8gZ2V0IHRoaXMgcmln aHQuIENvbXBhcmVkIHRvLCBzYXksIGZpbGVzeXN0ZW0gb3BlcmF0aW9ucyBvbiBhIGxvY2FsIG9w ZXJhdGluZyBzeXN0ZW0sIHRoaW5ncyBhcmUgc2VxdWVudGlhbCBhbmQgYXRvbWljOyBhIHByb2Nl c3MgY2Fu4oCZdCBkbyBzZXR1aWQoKSB3aGlsZSBvcGVuKCkgaXMgY2hlY2tpbmcgdG8gc2VlIGlm IHRoZSBwcm9jZXNzIGhhcyB0aGUgcmVxdWlyZWQgcGVybWlzc2lvbi4gQW5kIGFsc28gdGhlIGtl cm5lbCBBTFdBWVMga25vd3MgdGhlIGlkZW50aXR5IG9mIHRoZSBwcm9ncmFtLiBUaGlzIGlzIGRp ZmZlcmVudCBmcm9tIG5ldHdvcmsvd2ViIGFwcGxpY2F0aW9ucywgd2hpY2ggYXJlIG9mdGVuIG5v dCBleHBlY3RpbmcgaWRlbnRpdHkgY2hlY2tzLCBhbmQgd2hlcmUgdGhlIOKAnGZyYW1ld29yayBy dW50aW1l4oCdIGlzIGRvaW5nIHRoaW5ncyB3aGlsZSB0aGUgYnVzaW5lc3MgbG9naWMgaXMgcHJv Y2Vzc2luZyBhIHJlcXVlc3QsIG9mdGVuIGluIHRoZSBuYW1lIG9mIHNwZWVkWFhYWFggYmV0dGVy IHVzZXIgZXhwZXJpZW5jZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCAvciQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0twqAgPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlByaW5jaXBhbCBT ZWN1cml0eSBFbmdpbmVlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ba2FtYWkgVGVjaG5vbG9naWVzLCBDYW1icmlkZ2UsIE1B PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPklNOiA8YSBocmVmPSJtYWlsdG86cnNhbHpAamFiYmVyLm1lIj48c3BhbiBzdHlsZT0n Y29sb3I6Ymx1ZSc+cnNhbHpAamFiYmVyLm1lPC9zcGFuPjwvYT47IFR3aXR0ZXI6IFJpY2hTYWx6 PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_2A0EFB9C05D0164E98F19BB0AF3708C7181DE20AFBUSMBX1msgcorp_-- From nobody Fri Jun 13 11:12:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6421B2917 for ; Fri, 13 Jun 2014 11:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBcqIP6UEh8v for ; Fri, 13 Jun 2014 11:12:34 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE4E1B2879 for ; Fri, 13 Jun 2014 11:12:34 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 015FA165696; Fri, 13 Jun 2014 18:12:34 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id EAACF165695; Fri, 13 Jun 2014 18:12:33 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id BDD339803D; Fri, 13 Jun 2014 18:12:33 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Fri, 13 Jun 2014 14:12:33 -0400 From: "Salz, Rich" To: "Salz, Rich" , Steve Checkoway , "tls@ietf.org" Date: Fri, 13 Jun 2014 14:12:32 -0400 Thread-Topic: [TLS] Proposed text for removing renegotiation Thread-Index: Ac+HLyHgIZBWn4+uTBi1EEggjKJnXgAAnjawAABXufA= Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7181DE20B02@USMBX1.msg.corp.akamai.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C7181DE20AFB@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7181DE20AFB@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7181DE20B02USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cT0E281J4Q8rug7FYLNYL_intcM Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 18:12:36 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7181DE20B02USMBX1msgcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXJnLiAgQXJlIOKAnG9mdGVuIG5vdCBleHBlY3RpbmcgaWRlbnRpdHkgQ0hBTkdFUyzigJ0NCg0K LS0NClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcg0KQWthbWFpIFRlY2hub2xvZ2llcywgQ2Ft YnJpZGdlLCBNQQ0KSU06IHJzYWx6QGphYmJlci5tZTxtYWlsdG86cnNhbHpAamFiYmVyLm1lPjsg VHdpdHRlcjogUmljaFNhbHoNCg0KRnJvbTogU2FseiwgUmljaCBbbWFpbHRvOnJzYWx6QGFrYW1h aS5jb21dDQpTZW50OiBGcmlkYXksIEp1bmUgMTMsIDIwMTQgMjoxMCBQTQ0KVG86IFN0ZXZlIENo ZWNrb3dheTsgdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gUHJvcG9zZWQgdGV4dCBm b3IgcmVtb3ZpbmcgcmVuZWdvdGlhdGlvbg0KDQoNCsOYICBXaGVyZSBkbyB5b3Ugc2VlIGEgVE9D VFRPVSB2aW9sYXRpb24/DQoNCkkgZG9u4oCZdCB0aGluayBpdOKAmXMgZ3VhcmFudGVlZCB0aGF0 IHRoZXJl4oCZcyBhIHZpb2xhdGlvbiwgYnV0IGl0IGlzIHZlcnkgaGFyZCB0byBnZXQgdGhpcyBy aWdodC4gQ29tcGFyZWQgdG8sIHNheSwgZmlsZXN5c3RlbSBvcGVyYXRpb25zIG9uIGEgbG9jYWwg b3BlcmF0aW5nIHN5c3RlbSwgdGhpbmdzIGFyZSBzZXF1ZW50aWFsIGFuZCBhdG9taWM7IGEgcHJv Y2VzcyBjYW7igJl0IGRvIHNldHVpZCgpIHdoaWxlIG9wZW4oKSBpcyBjaGVja2luZyB0byBzZWUg aWYgdGhlIHByb2Nlc3MgaGFzIHRoZSByZXF1aXJlZCBwZXJtaXNzaW9uLiBBbmQgYWxzbyB0aGUg a2VybmVsIEFMV0FZUyBrbm93cyB0aGUgaWRlbnRpdHkgb2YgdGhlIHByb2dyYW0uIFRoaXMgaXMg ZGlmZmVyZW50IGZyb20gbmV0d29yay93ZWIgYXBwbGljYXRpb25zLCB3aGljaCBhcmUgb2Z0ZW4g bm90IGV4cGVjdGluZyBpZGVudGl0eSBjaGVja3MsIGFuZCB3aGVyZSB0aGUg4oCcZnJhbWV3b3Jr IHJ1bnRpbWXigJ0gaXMgZG9pbmcgdGhpbmdzIHdoaWxlIHRoZSBidXNpbmVzcyBsb2dpYyBpcyBw cm9jZXNzaW5nIGEgcmVxdWVzdCwgb2Z0ZW4gaW4gdGhlIG5hbWUgb2Ygc3BlZWRYWFhYWCBiZXR0 ZXIgdXNlciBleHBlcmllbmNlLg0KDQogICAgICAgICAgICAgICAgL3IkDQoNCi0tDQpQcmluY2lw YWwgU2VjdXJpdHkgRW5naW5lZXINCkFrYW1haSBUZWNobm9sb2dpZXMsIENhbWJyaWRnZSwgTUEN CklNOiByc2FsekBqYWJiZXIubWU8bWFpbHRvOnJzYWx6QGphYmJlci5tZT47IFR3aXR0ZXI6IFJp Y2hTYWx6DQoNCg== --_000_2A0EFB9C05D0164E98F19BB0AF3708C7181DE20B02USMBX1msgcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MjA4NzcyNTU2MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MTg3ODgxNzkyMCAxNjc4NTQ2MzM0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxp bms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QXJnLsKgIEFyZSDigJxvZnRlbiBub3QgZXhw ZWN0aW5nIGlkZW50aXR5IENIQU5HRVMs4oCdPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0twqAg PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPlByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ba2FtYWkgVGVjaG5vbG9n aWVzLCBDYW1icmlkZ2UsIE1BPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklNOiA8YSBocmVmPSJtYWlsdG86cnNhbHpAamFiYmVy Lm1lIj48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+cnNhbHpAamFiYmVyLm1lPC9zcGFuPjwvYT47 IFR3aXR0ZXI6IFJpY2hTYWx6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gU2FseiwgUmljaCBbbWFpbHRvOnJzYWx6QGFr YW1haS5jb21dIDxicj48Yj5TZW50OjwvYj4gRnJpZGF5LCBKdW5lIDEzLCAyMDE0IDI6MTAgUE08 YnI+PGI+VG86PC9iPiBTdGV2ZSBDaGVja293YXk7IHRsc0BpZXRmLm9yZzxicj48Yj5TdWJqZWN0 OjwvYj4gUmU6IFtUTFNdIFByb3Bvc2VkIHRleHQgZm9yIHJlbW92aW5nIHJlbmVnb3RpYXRpb248 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OldpbmdkaW5ncyc+PHNwYW4gc3R5bGU9J21zby1saXN0 Oklnbm9yZSc+w5g8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5i c3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5XaGVyZSBkbyB5b3Ugc2VlIGEgVE9D VFRPVSB2aW9sYXRpb24/PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgZG9u4oCZdCB0aGluayBpdOKAmXMgZ3VhcmFu dGVlZCB0aGF0IHRoZXJl4oCZcyBhIHZpb2xhdGlvbiwgYnV0IGl0IGlzIHZlcnkgaGFyZCB0byBn ZXQgdGhpcyByaWdodC4gQ29tcGFyZWQgdG8sIHNheSwgZmlsZXN5c3RlbSBvcGVyYXRpb25zIG9u IGEgbG9jYWwgb3BlcmF0aW5nIHN5c3RlbSwgdGhpbmdzIGFyZSBzZXF1ZW50aWFsIGFuZCBhdG9t aWM7IGEgcHJvY2VzcyBjYW7igJl0IGRvIHNldHVpZCgpIHdoaWxlIG9wZW4oKSBpcyBjaGVja2lu ZyB0byBzZWUgaWYgdGhlIHByb2Nlc3MgaGFzIHRoZSByZXF1aXJlZCBwZXJtaXNzaW9uLiBBbmQg YWxzbyB0aGUga2VybmVsIEFMV0FZUyBrbm93cyB0aGUgaWRlbnRpdHkgb2YgdGhlIHByb2dyYW0u IFRoaXMgaXMgZGlmZmVyZW50IGZyb20gbmV0d29yay93ZWIgYXBwbGljYXRpb25zLCB3aGljaCBh cmUgb2Z0ZW4gbm90IGV4cGVjdGluZyBpZGVudGl0eSBjaGVja3MsIGFuZCB3aGVyZSB0aGUg4oCc ZnJhbWV3b3JrIHJ1bnRpbWXigJ0gaXMgZG9pbmcgdGhpbmdzIHdoaWxlIHRoZSBidXNpbmVzcyBs b2dpYyBpcyBwcm9jZXNzaW5nIGEgcmVxdWVzdCwgb2Z0ZW4gaW4gdGhlIG5hbWUgb2Ygc3BlZWRY WFhYWCBiZXR0ZXIgdXNlciBleHBlcmllbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC9yJDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS0mbmJzcDsg PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPlByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ba2FtYWkgVGVjaG5vbG9n aWVzLCBDYW1icmlkZ2UsIE1BPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklNOiA8YSBocmVmPSJtYWlsdG86cnNhbHpAamFiYmVy Lm1lIj5yc2FsekBqYWJiZXIubWU8L2E+OyBUd2l0dGVyOiBSaWNoU2FsejxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7181DE20B02USMBX1msgcorp_-- From nobody Fri Jun 13 14:30:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65391B2A5D for ; Fri, 13 Jun 2014 14:30:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-XbQsXKksHY for ; Fri, 13 Jun 2014 14:30:48 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDCF91B2A59 for ; Fri, 13 Jun 2014 14:30:47 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f10so2600371yha.38 for ; Fri, 13 Jun 2014 14:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GTZu3n6B12hl4TwzHbudfxhL5z70Izr+s9bK0Bg10XY=; b=D36V2DBAjsq16DW1bjL3PZYfT67GLA+zr26LVdEuF55Nt4eDoHugzpt4wlxs7kywWg GvnW0NkYOCKS5mH6qqlleQ6Whefm+Dc6mnXubjZ5T/Cbk87hZc2p4eVVLM9MVXOdLzPm hxrI041SDD9co2EqD2c+t+0HxvuVtwItlHc1u2W+CZf287qgqYia/bhJg+wwh+P6nNfE adiovAvxnIwS0pUfDU0V8N1MQ/b6OTJvaHlC8GgjofY7qsDDxlgn8XjzEcDHS0cysHi5 daOhUQzwwWmxZvait0EijpnsnXkpJz+sCHk47Fk17EMqxMC8Jrmrl0SAnC2BRYz+NFwo p2rw== MIME-Version: 1.0 X-Received: by 10.236.74.33 with SMTP id w21mr8056075yhd.87.1402695047179; Fri, 13 Jun 2014 14:30:47 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Fri, 13 Jun 2014 14:30:46 -0700 (PDT) Date: Fri, 13 Jun 2014 18:30:46 -0300 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_r7C6QZumy85LRfmZ3NWFVAnwHw Subject: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 21:30:48 -0000 Dear all, TLS with ECC computes the premaster secret as H(abg) where g is the generator of the group, and a and b are the ephemeral exponents. Because of protocol weaknesses, this premaster secret must be "contributory": neither side can be allowed to dictate it. Curve25519 has order 8*q, where q is some prime. All encoded public keys lie on this or a twist with order 4*q'. (I might be wrong in the details, but it's right enough). In particular there is a point of order 2. A malicious server can provide a point of order 2, and with 50% probability get a dictated premaster secret. The solution is to follow the advice on contributory behaviour and disallow a fixed list of public keys, namely those of small order. Alternatively we can compute the premaster secret as the hash of H(ag | bg | abg): I have not yet confirmed that this solves the problem. For TLS 1.3 we should ensure contributory behaviour is not required to avoid these issues. Sincerely, Watson Ladd From nobody Fri Jun 13 14:37:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38B31B2A59 for ; Fri, 13 Jun 2014 14:37:35 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bqt3Fi6DM_aS for ; Fri, 13 Jun 2014 14:37:34 -0700 (PDT) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C7C1A025A for ; Fri, 13 Jun 2014 14:37:33 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id ft15so2479508pdb.25 for ; Fri, 13 Jun 2014 14:37:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QZhG+gq8D9oGIajVBtTgZHHQGc8IzaW7/sHMlD4ZVyY=; b=gxq86YU3ysmDUyTgrDEiY065qHcHmXxYVuUX5bNM3TlvXE47JZWSwH9Sbk17mGRlA6 4AHdsFE2pqrXVAYEG6R9kcor2C4fz0DBPuak0fNvN4SMr5dIcH7cXkl6u6umeQLN7Vbh pLMka7lRkIcTtXSza/O3mofC/pxArDKOeVLR9cVLJ7sGYO8nxuu8jS1OCBaGo0BPngnw CSY17qaASoX5xK4H+GRuB8SnAuBf3ghJaf3tb3uwtwKH+vje7zEup+HIV9xdOlHNPH57 nSnAIgj/WnRq5dSqSRbaDtNWcdMkOuIFdEeHrVNC2nWBHFst6I0bFxQNOxajGK414kOo PK5A== X-Gm-Message-State: ALoCoQka+oGSW7ezbOr6T+xmTg45YGSS5v1JQgZUAjL8UYhUm3yHfb7/hwv/BxRG6ssGldCo0Xmt X-Received: by 10.68.213.198 with SMTP id nu6mr6260227pbc.21.1402695453641; Fri, 13 Jun 2014 14:37:33 -0700 (PDT) Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id nf5sm5307853pbc.77.2014.06.13.14.37.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 14:37:32 -0700 (PDT) From: Andy Lutomirski X-Google-Original-From: Andy Lutomirski Message-ID: <539B6F1B.4030407@mit.edu> Date: Fri, 13 Jun 2014 14:37:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Watson Ladd , "tls@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RApJYE2IfC1JDjzAyBV9BsdyaVI Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 21:37:35 -0000 On 06/13/2014 02:30 PM, Watson Ladd wrote: > For TLS 1.3 we should ensure contributory behaviour is not required to > avoid these issues. What needs to change for this to be the case? It would be even nicer if the result were provably correct in some reasonable model. --Andy > > Sincerely, > Watson Ladd > From nobody Fri Jun 13 14:59:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F17A1B2A79 for ; Fri, 13 Jun 2014 14:59:46 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk2mhCbkmxnD for ; Fri, 13 Jun 2014 14:59:40 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD341B2A7A for ; Fri, 13 Jun 2014 14:59:40 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id 200so2524199ykr.2 for ; Fri, 13 Jun 2014 14:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e50aRdxZ9vi5ApAx6ACgAG75EqkhygCnKT2vPGBmmzk=; b=qgci8EBVaY9d+8VgkvBI86EfrDj9fQlLamK/VbczY6TgA1p+DqFS1IaQv2Nt/TDfN+ OfUH8CMAx5toLS7g8dhVI3B1hyiQsCWdmDa8/YjQeX8LZVCLZMdtsZydgABLV0zwiQNH OB0C0qGms3XtJKO5wX//JRLfJ8oe2sTj4vPg00rltzzrOA2mpfy/XEH95y1Hjw7oajaj hNcnpd7GSitgKd7TqW3gbyN0iDGFFrldsRGIP+okY+b29OtbCt1TxWRmg0L3+sSubXw2 0tlWjmWf7i7cQSLp1IMcwoobyjj8E/N22XZERzQ89QbM204kTP/LpvhBlZgzR+/XwvER g+5w== MIME-Version: 1.0 X-Received: by 10.236.1.229 with SMTP id 65mr8319807yhd.107.1402696779974; Fri, 13 Jun 2014 14:59:39 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Fri, 13 Jun 2014 14:59:39 -0700 (PDT) In-Reply-To: <539B6F1B.4030407@mit.edu> References: <539B6F1B.4030407@mit.edu> Date: Fri, 13 Jun 2014 18:59:39 -0300 Message-ID: From: Watson Ladd To: Andy Lutomirski Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dshpT8hGjCyb1a-Q1Sj87M-CJAY Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 21:59:47 -0000 On Fri, Jun 13, 2014 at 6:37 PM, Andy Lutomirski wrote: > On 06/13/2014 02:30 PM, Watson Ladd wrote: >> For TLS 1.3 we should ensure contributory behaviour is not required to >> avoid these issues. > > What needs to change for this to be the case? It would be even nicer if > the result were provably correct in some reasonable model. Hash the entire exchange into the generated key, so that a key made by someone cheating is only shared with them. I still don't understand why this isn't done already: it's needed for the finished message, so nothing is saved by not doing it. This is what the triple handshake fix is supposed to do, but it does a strange variant that reuses the oddball finished message. (And use a strong hash function: apparently the reason we haven't finished fixing Triple Handshake is that some people want to use SHA-1. On their heads be it!) If the protocol is simple enough CryptoVerif can do the proofs with some prodding: proving shouldn't really be the issue. Hashing helps here by enabling the formation of a concept of "matching exchange", and thus significantly constraining an attacker. Sincerely, Watson Ladd From nobody Fri Jun 13 16:02:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A271A025A for ; Fri, 13 Jun 2014 16:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oZeyDHm0ZA6 for ; Fri, 13 Jun 2014 16:02:45 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A711B2A8B for ; Fri, 13 Jun 2014 16:02:44 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so3365915wgh.35 for ; Fri, 13 Jun 2014 16:02:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RBvK5/xqAyOzKFZTGpj87NrMDVr6JxhrLp8to6EEwi0=; b=bmfOJ/IZKU9WXoTV3hBEmFT341zZD5bqMv2uGo8WJUWU5ZDncWXuwf7k3CgsSAEzRL mZ9ByOcHdLZf+y/YfsnGK01kbkHAFtt+wuErfPFt9AlxbJELQDzTjedMiKqD5e6niHMM d3IFDnd8w9XurIFVb7uEx4uKvdHEin55sYC+w/92X8rHtpNOQOSjAjz23Z2NnIXId+Sh U7JSE65WyZ6s2CPlmLkjXRL5mfbqJ/N/niPZozicWDzftVDmchJbY+vbR7mswlS6h4Ys wUgpj5YKsglXv+fBWlJQd/FhLqOtuMSBSBtSz719GhOyD9XJkhSBB2mWisIn7w7p/Pza KlBw== X-Gm-Message-State: ALoCoQm9hmvFBKTllV2XylA1lKfeeUSvEmcfQzjxMjPNn068PJeGrO63F4LwUa48GTWxYgAkN2r3 X-Received: by 10.180.99.71 with SMTP id eo7mr7844681wib.49.1402700562922; Fri, 13 Jun 2014 16:02:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Fri, 13 Jun 2014 16:02:02 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:74a6:4746:3f43:9e51] In-Reply-To: References: <539B6F1B.4030407@mit.edu> From: Eric Rescorla Date: Fri, 13 Jun 2014 16:02:02 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=f46d044283a8c7b88a04fbbfac68 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LD83pPSuijWgDZUb_GyOQ_Wdx_o Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 23:02:46 -0000 --f46d044283a8c7b88a04fbbfac68 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 13, 2014 at 2:59 PM, Watson Ladd wrote: > On Fri, Jun 13, 2014 at 6:37 PM, Andy Lutomirski > wrote: > > On 06/13/2014 02:30 PM, Watson Ladd wrote: > >> For TLS 1.3 we should ensure contributory behaviour is not required to > >> avoid these issues. > > > > What needs to change for this to be the case? It would be even nicer if > > the result were provably correct in some reasonable model. > > Hash the entire exchange into the generated key, so that a key made by > someone cheating is only shared with them. I still don't understand > why this isn't done already: it's needed for the finished message, so > nothing is saved by not doing it. This is what the triple handshake > fix is supposed to do, but it does a strange variant that reuses the > oddball finished message. > > (And use a strong hash function: apparently the reason we haven't > finished fixing Triple Handshake is that some people want to use > SHA-1. On their heads be it!) > Hmm... I don't believe that this isn't done strictly because of SHA-1. Looking back at what I wrote a while ago: http://www.ietf.org/mail-archive/web/tls/current/msg12574.html I believe the question is whether it is acceptable to have a *hash* of the handshake hashed into the generated key as opposed to having the handshake itself hashed into the generated key and whether it's acceptable to have that hash be the combined MD5/SHA1 variant in TLS < 1.2 and if not what recommendation we should make for those versions. -Ekr > If the protocol is simple enough CryptoVerif can do the proofs with > some prodding: proving shouldn't really be the issue. Hashing helps > here by enabling the formation of a concept of "matching exchange", > and thus significantly constraining an attacker. > > Sincerely, > Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d044283a8c7b88a04fbbfac68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 13, 2014 at 2:59 PM, Watson Ladd <= watsonbladd@gmai= l.com> wrote:
On Fri, Jun 13, 2014 at 6:37 PM, Andy Lutomirski <= luto@amacapital.ne= t> wrote:
> On 06/13/2014 02:30 PM, Watson Ladd wrote:
>> For TLS 1.3 we should ensure contributory behaviour is not require= d to
>> avoid these issues.
>
> What needs to change for this to be the case? =C2=A0It would be even n= icer if
> the result were provably correct in some reasonable model.

Hash the entire exchange into the generated key, so that a key made b= y
someone cheating is only shared with them. I still don't understand
why this isn't done already: it's needed for the finished message, = so
nothing is saved by not doing it. This is what the triple handshake
fix is supposed to do, but it does a strange variant that reuses the
oddball finished message.

(And use a strong hash function: apparently the reason we haven't
finished fixing Triple Handshake is that some people want to use
SHA-1. On their heads be it!)

Hmm... I = don't believe that this isn't done strictly because of SHA-1.
=
Looking back at what I wrote a while ago:


I believe the question is whether it is acceptabl= e to have a *hash* of
the handshake hashed into the generated key= as opposed to having
the handshake itself hashed into the genera= ted key and whether it's
acceptable to have that hash be the combined MD5/SHA1 variant
in TLS < 1.2 and if not what recommendation we should make for
those versions.

-Ekr
=C2=A0
If the protocol is simple enough CryptoVerif can do the proofs with
some prodding: proving shouldn't really be the issue. Hashing helps
here by enabling the formation of a concept of "matching exchange"= ;,
and thus significantly constraining an attacker.

Sincerely,
Watson Ladd

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

--f46d044283a8c7b88a04fbbfac68-- From nobody Fri Jun 13 16:11:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB101B29BE for ; Fri, 13 Jun 2014 16:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCDj6xrM8sDy for ; Fri, 13 Jun 2014 16:11:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147781B29B6 for ; Fri, 13 Jun 2014 16:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=526; q=dns/txt; s=iport; t=1402701110; x=1403910710; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=SM5RpUR2Yf6POSWyCa6Q+MCV3pLnuVHyEO52wU3VOOY=; b=ma0z/3o3OiRi92cbqbuD7mToqFtCl6RaCkDF/R1Fsxx7xiN4ETCbK7f4 KxukH3uMlLOqI3zQX5syEPjIQTOY2UD3weUGACNoLpGrvoaVv1geECb+c 7qUKkKbqD2jnT8mF/xjv/0xO9iNM+mfqNXNImSi7DAwU7xKHd+H8hPueY 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoHAFeEm1OtJA2M/2dsb2JhbABagw2BK6lfAQEBAQEBBQGaKBZ1hAo6UQE+QicEiFWhPq40F4VdjDSBFgSaN5NXgz6CMA X-IronPort-AV: E=Sophos;i="5.01,474,1400025600"; d="scan'208";a="332988032" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP; 13 Jun 2014 23:11:49 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5DNBnYU011853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 13 Jun 2014 23:11:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.225]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 18:11:49 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Consensus Call on Removing GMT from the Handshake Thread-Index: AQHPh1zaFeX5WSCqdU6kY8JoPt9I4w== Date: Fri, 13 Jun 2014 23:11:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.112] Content-Type: text/plain; charset="us-ascii" Content-ID: <514B370FE62689478574ED040C627EE5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TiJiTMp_QoaqPUd5M1tE0LJHu6A Subject: [TLS] Consensus Call on Removing GMT from the Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 23:11:56 -0000 There appears to be significant support for the removal of GMT from the cli= ent and server random values in TLS. The chairs would like to ask two questions= : - Should we remove the GMT values from the client and server values in TLS = 1.3? - Should we remove the GMT fields from the current versions of TLS and adop= t draft-mathewson-no-gmtunixtime-00 or something similar? If you have an opinion on this topic, please reply to the TLS list with you= r reasons by Friday, June 20 Joe (for the chairs)= From nobody Fri Jun 13 16:49:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5A91B2AA4 for ; Fri, 13 Jun 2014 16:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEDbQeQ2JCwh for ; Fri, 13 Jun 2014 16:49:52 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2ADF1B2AA3 for ; Fri, 13 Jun 2014 16:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2604; q=dns/txt; s=iport; t=1402703392; x=1403912992; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6W8HC2vdWrJ7z8bPtJgXktfaVDuk1dw0OpzgBs7z5CQ=; b=leXZR8Ia9cNI6cBaAlVpmZqB6byxTc9DDvBSnw46nJU8D7qAAlOYkkG6 Z7w0bkFb6QK8zdhZjqXuF5TEJqnZ8q10+zWQ1jRYJyl8YZ8se7Oz6cK0Y CXq6q/iifVh2sM5wMTWnWGG0S48CnacET72KSrUZiNhKWBU7EgPwUckEG c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FAISNm1OtJA2E/2dsb2JhbABRCYMNUlmpYgEBAQEBB5Flhz0BgQUWdYQDAQEBAwEBAQE3NBALAgEIGB4QJwslAgQTiDoIDc9oEwSFXYVkgkMoOoMrgRYEmjeTV4M+gjA X-IronPort-AV: E=Sophos;i="5.01,474,1400025600"; d="scan'208";a="333048391" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP; 13 Jun 2014 23:49:51 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5DNnoYv003774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 13 Jun 2014 23:49:50 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.225]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 18:49:50 -0500 From: "Joseph Salowey (jsalowey)" To: "tls@ietf.org" Thread-Topic: [TLS] AUTH48 [AR]: RFC 7250 changes Thread-Index: AQHPedB3r/5JHL+RFEieWpJdLbQeBg== Date: Fri, 13 Jun 2014 23:49:50 +0000 Message-ID: <8686EA69-5E48-413C-9AC6-3BE2AFB2379D@cisco.com> References: <201405201629.s4KGTtoU021704@new.toad.com> <790AE3A2-37B2-4124-8093-69812232052C@cisco.com> <20140527181017.GN27883@mournblade.imrryr.org> In-Reply-To: <20140527181017.GN27883@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.112] Content-Type: text/plain; charset="us-ascii" Content-ID: <8991A499C81D7E4B9ABD12F03945BE7B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_QPK_fzE3lFlLtQC62CPFbkO1ss Subject: Re: [TLS] AUTH48 [AR]: RFC 7250 changes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 23:49:53 -0000 On May 27, 2014, at 11:10 AM, Viktor Dukhovni wr= ote: > On Tue, May 27, 2014 at 05:24:09PM +0000, Joseph Salowey (jsalowey) wrote= : >=20 >>> Section 4.3: >>>=20 >>> OLD: >>> Authentication of the TLS client to the TLS server is supported only >>> through authentication of the received client SubjectPublicKeyInfo >>> via an out-of-band method. >>>=20 >>> NEW: >>>=20 >>> When the TLS server has specified RawPublicKey as the >>> client_certificate_type, authentication of the TLS client to the >>> TLS server is supported only through authentication of the received >>> client SubjectPublicKeyInfo via an out-of-band method. >>>=20 >>> [...] >>>=20 >>> Add Section 4.4. Server Authentication >>>=20 >>> NEW: >>> When the TLS server has specified RawPublicKey as the >>> server_certificate_type, authentication of the TLS server to the >>> TLS client is supported only through authentication of the received >>> client SubjectPublicKeyInfo via an out-of-band method. >=20 > Some (as I did briefly, though I think I have finally figured out > what is meant) might find "authentication" here a bit confusing. >=20 > There are two parts to the traditional use of a public key in TLS for > authentication: >=20 > * The public key is used to sign the key exchange or decrypt > key transport. This proves that the counter-party possesses > the corresponding private key. >=20 > * The public key is delivered in the form of a certificate that > attests to a binding between the public key and some identity. >=20 > When I first read the quoted text out of context, I though it was > saying that both parts were out of band, which is surely not the > case. Rather it is merely the identity mapping that is out of > band, each side still verifies possession via appropriate signatures. >=20 [Joe] This is the correct interpretation. =20 > Is the use of raw public keys to sign the relevant bits of the > handshake that would otherwise have been signed by the public key > embedded in the certificate too obvious to have to state explicitly? >=20 [Joe] I think so, this is core to TLS operation. I'm not confident that I = can come up with text that would be less confusing. Do you have any sugge= sted modifications? I think we will probably leave the text as is, but I c= an pass on a suggestion if you have one. =20 > --=20 > Viktor. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Jun 13 17:16:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FD81B2AAB for ; Fri, 13 Jun 2014 17:16:56 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeeEhvh65Bin for ; Fri, 13 Jun 2014 17:16:55 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BE871B2AA2 for ; Fri, 13 Jun 2014 17:16:55 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q58so3502206wes.30 for ; Fri, 13 Jun 2014 17:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LGd4zKj/taFy2wP3hWaxQ1DCxP5AmvOZ+ipUctqb0fM=; b=yiUWt5IZadc9KwyjRrxVI4Kgd3h7SOIIBYMCYUUa+Hb2hzmya1bnFMmO2jWkEXOuML PQAS7IDFl387BSNRnWltTRaSg9a8ioMibC1/iwupQzWbaZY32JSv9me3SlzVCkNqMkYB FpzPMPTEZEEjWfzd+zVb267wBaC5+ORlNCQ/sPSuQDYhy9fohqyEQYr1GU1Sugb8z0Bw EP9A1eVFb37LV4NcrG9/Cc1Kj/piE+Aqm1Bmv7dfOqkJLJoL+YjVyYvVwB2YxVZv/mR1 9phVr1D2YnHrKQgYaJkBPPzI45/iuGFr/LMQB9cVWBRQ/Yhgi9MzIzRuGpMowBXN4wLj Ewog== MIME-Version: 1.0 X-Received: by 10.180.72.176 with SMTP id e16mr8820329wiv.44.1402705013613; Fri, 13 Jun 2014 17:16:53 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Fri, 13 Jun 2014 17:16:53 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Jun 2014 17:16:53 -0700 Message-ID: From: Martin Thomson To: "Joseph Salowey (jsalowey)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1l1kIv5dDcxn-ZNZJAZJiW3t3Bk Cc: "" Subject: Re: [TLS] Consensus Call on Removing GMT from the Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 00:16:56 -0000 On 13 June 2014 16:11, Joseph Salowey (jsalowey) wrote: > - Should we remove the GMT values from the client and server values in TLS 1.3? I'd prefer to see it removed. > - Should we remove the GMT fields from the current versions of TLS and adopt > draft-mathewson-no-gmtunixtime-00 or something similar? I think that this statement: ... TLS implementors MUST by default set the entire value the ClientHello.Random and ServerHello.Random fields, including gmt_unix_time, to a cryptographically random sequence. Is enough. The rationale is a little overblown. That should help expose more of the RNG state ;) From nobody Fri Jun 13 17:28:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0251B2AB8 for ; Fri, 13 Jun 2014 17:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec0MiPFQNr6O for ; Fri, 13 Jun 2014 17:28:54 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6E01A02ED for ; Fri, 13 Jun 2014 17:28:54 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id 10so809554lbg.29 for ; Fri, 13 Jun 2014 17:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mEboL37/kJ1GA7pIoGVCe7vZVBaiFxyHoy6s/eljsjg=; b=c2R9nzBTryboAQxgOMCDV2X6IOhFl9eSLOWvNFyNP2z0TcTQA5AZmeGzEl14Woeq7J zZ97n11p+eVF1coqqLA30oYquoR2J+hB0x5tqG3a/nVmMXlqdAw6idsuU0mKY2v+olt5 fg749z8rNsnuo33gUp1eSRzlhkOXmXnhxIa8ksczfz3cbKeZQ2TZALKvsZvWHhnnengi nSp34Cz7uAgil8lzU5ypAJBiModvR3rS1WKEDkX+0pu1aDuE1ZvqZyCtnPiZVMqp41qe 18emNXElUvAFUkwmeY6fsvKwRNMzpYyID4GTQ4NEFd0U7q32w5pJVbo9Je8RtbOQB4Oh S03A== MIME-Version: 1.0 X-Received: by 10.112.129.202 with SMTP id ny10mr3680638lbb.14.1402705732778; Fri, 13 Jun 2014 17:28:52 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.5.68 with HTTP; Fri, 13 Jun 2014 17:28:52 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Jun 2014 17:28:52 -0700 X-Google-Sender-Auth: 4yrRU1XBEli31n_2cyp-yj7E9uU Message-ID: From: Adam Langley To: "Joseph Salowey (jsalowey)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gVifzctu2yGNQIwpNcfwLGO0iYE Cc: "" Subject: Re: [TLS] Consensus Call on Removing GMT from the Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 00:28:56 -0000 On Fri, Jun 13, 2014 at 4:11 PM, Joseph Salowey (jsalowey) wrote: > - Should we remove the GMT values from the client and server values in TLS 1.3? Yes, in the same way as below... > - Should we remove the GMT fields from the current versions of TLS and adopt > draft-mathewson-no-gmtunixtime-00 or something similar? Yes, at the SHOULD level. For servers we have some clients that take a clock-sync signal from the GMT time and we wouldn't immediately want to break them. For clients, there is basically no value and it leaks a fingerprint. Additionally, this would be reflecting reality because implementations are already doing this. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Fri Jun 13 19:06:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723631B2B11 for ; Fri, 13 Jun 2014 19:05: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_TffrwLgUiU for ; Fri, 13 Jun 2014 19:05:58 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70E71B2B0A for ; Fri, 13 Jun 2014 19:05:57 -0700 (PDT) Received: by mail-yk0-f175.google.com with SMTP id 9so2635430ykp.6 for ; Fri, 13 Jun 2014 19:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xXMHmQChqjll2Pv0PXnQyyZu3PiSDha8dVWHpgb1L64=; b=e6HrmkoHzxMOz5MFvtPdXQ53Ppvqg1OhkOTXGhb0aCqQCGpK6dfd0gwHGTaCmGiLYT ou0RNg/yp6L21vBAQ5c96N2YRRWMPYjcVs6weLKNJ1LXPS0ER45UOh5NirnammJqjmQJ BLw1XFIq7RI6ClzAod2bXoT931sKDQKybsIRG1YgOP8w8/o3pZHSQidhyeKczOTWuvsv iQu005qXU7Sv7HioOeN0TRaM55/w7xRJitssKMngy5QSL67gyxSygeRJMR1stqfekRZB x+ggu/IN0mFDSdQlt5GCNsHViZ8iHXGqjLJJv6dOW541f1H4CDTwO/tidXeuLZYtrPdU QIsQ== MIME-Version: 1.0 X-Received: by 10.236.192.73 with SMTP id h49mr10070505yhn.6.1402711557160; Fri, 13 Jun 2014 19:05:57 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Fri, 13 Jun 2014 19:05:57 -0700 (PDT) In-Reply-To: References: <539B6F1B.4030407@mit.edu> Date: Fri, 13 Jun 2014 23:05:57 -0300 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Qi7A26Ybmh0m8053mE2q6bg3cC4 Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 02:05:59 -0000 On Fri, Jun 13, 2014 at 8:02 PM, Eric Rescorla wrote: > > > > On Fri, Jun 13, 2014 at 2:59 PM, Watson Ladd wrote: >> >> On Fri, Jun 13, 2014 at 6:37 PM, Andy Lutomirski >> wrote: >> > On 06/13/2014 02:30 PM, Watson Ladd wrote: >> >> For TLS 1.3 we should ensure contributory behaviour is not required to >> >> avoid these issues. >> > >> > What needs to change for this to be the case? It would be even nicer if >> > the result were provably correct in some reasonable model. >> >> Hash the entire exchange into the generated key, so that a key made by >> someone cheating is only shared with them. I still don't understand >> why this isn't done already: it's needed for the finished message, so >> nothing is saved by not doing it. This is what the triple handshake >> fix is supposed to do, but it does a strange variant that reuses the >> oddball finished message. >> >> (And use a strong hash function: apparently the reason we haven't >> finished fixing Triple Handshake is that some people want to use >> SHA-1. On their heads be it!) > > > Hmm... I don't believe that this isn't done strictly because of SHA-1. > Looking back at what I wrote a while ago: > > http://www.ietf.org/mail-archive/web/tls/current/msg12574.html > > I believe the question is whether it is acceptable to have a *hash* of > the handshake hashed into the generated key as opposed to having > the handshake itself hashed into the generated key and whether it's > acceptable to have that hash be the combined MD5/SHA1 variant > in TLS < 1.2 and if not what recommendation we should make for > those versions. Why wouldn't it be? If H(m)=H(m'), that's just as much a collision as if H(m || stuff)=H(m' || stuff). The MD5/SHA1 combination is only as strong as SHA1 against collisions. In versions before TLS 1.2 this is unavoidable. If that isn't good enough, the only recommendation I can offer is don't use SHA1, but SHA2. > > -Ekr > >> >> If the protocol is simple enough CryptoVerif can do the proofs with >> some prodding: proving shouldn't really be the issue. Hashing helps >> here by enabling the formation of a concept of "matching exchange", >> and thus significantly constraining an attacker. >> >> Sincerely, >> Watson Ladd >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Jun 13 23:59:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9731B2B89 for ; Fri, 13 Jun 2014 23:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pv-oy4DUsbH2 for ; Fri, 13 Jun 2014 23:59:07 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F7B1B2B88 for ; Fri, 13 Jun 2014 23:59:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,476,1400018400"; d="asc'?scan'208,217";a="80023657" Received: from 18.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.18]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 14 Jun 2014 08:59:04 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_35EF1BF8-39B3-4D46-A26B-FC2FDA361FA2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Sat, 14 Jun 2014 08:59:03 +0200 Message-Id: References: To: Watson Ladd X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cho0Vvo508asNtdSkccuJnPz8Mg Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 06:59:09 -0000 --Apple-Mail=_35EF1BF8-39B3-4D46-A26B-FC2FDA361FA2 Content-Type: multipart/alternative; boundary="Apple-Mail=_5BD4C15D-3ED4-49DC-AFE8-B9139876978A" --Apple-Mail=_5BD4C15D-3ED4-49DC-AFE8-B9139876978A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes, we considered Curve25519 for Triple Handshake too. One immediate protection that the crypto library could provide=20 is to check that the received public key is not one of the 8 = =93degenerate=94=20 points listed at http://cr.yp.to/ecdh.html More generally, I agree that using a session hash would protect this = exchange too. Best, Karthik On 13 Jun 2014, at 23:30, Watson Ladd wrote: > Dear all, >=20 > TLS with ECC computes the premaster secret as H(abg) where g is the > generator of the group, and a and b are the ephemeral exponents. > Because of protocol weaknesses, this premaster secret must be > "contributory": neither side can be allowed to dictate it. >=20 > Curve25519 has order 8*q, where q is some prime. All encoded public > keys lie on this or a twist with order 4*q'. (I might be wrong in the > details, but it's right enough). In particular there is a point of > order 2. >=20 > A malicious server can provide a point of order 2, and with 50% > probability get a dictated premaster secret. >=20 > The solution is to follow the advice on contributory behaviour and > disallow a fixed list of public keys, namely those of small order. > Alternatively we can compute the premaster secret as the hash of H(ag > | bg | abg): I have not yet confirmed that this solves the problem. >=20 > For TLS 1.3 we should ensure contributory behaviour is not required to > avoid these issues. >=20 > Sincerely, > Watson Ladd >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_5BD4C15D-3ED4-49DC-AFE8-B9139876978A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yes, = we considered Curve25519 for Triple Handshake too.
One immediate = protection that the crypto library could provide 
is to = check that the received public key is not one of the 8 = =93degenerate=94 
points listed at http://cr.yp.to/ecdh.html

More generally, I agree that using a session hash would = protect this exchange = too.

Best,
Karthik

=


On 13 Jun 2014, at 23:30, Watson = Ladd <watsonbladd@gmail.com> = wrote:

Dear all,

TLS with ECC computes the premaster = secret as H(abg) where g is the
generator of the group, and a and b = are the ephemeral exponents.
Because of protocol weaknesses, this = premaster secret must be
"contributory": neither side can be allowed = to dictate it.

Curve25519 has order 8*q, where q is some prime. = All encoded public
keys lie on this or a twist with order 4*q'. (I = might be wrong in the
details, but it's right enough). In particular = there is a point of
order 2.

A malicious server can provide a = point of order 2, and with 50%
probability get a dictated premaster = secret.

The solution is to follow the advice on contributory = behaviour and
disallow a fixed list of public keys, namely those of = small order.
Alternatively we can compute the premaster secret as the = hash of H(ag
| bg | abg): I have not yet confirmed that this solves = the problem.

For TLS 1.3 we should ensure contributory behaviour = is not required to
avoid these issues.

Sincerely,
Watson = Ladd

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

= --Apple-Mail=_5BD4C15D-3ED4-49DC-AFE8-B9139876978A-- --Apple-Mail=_35EF1BF8-39B3-4D46-A26B-FC2FDA361FA2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTm/K4AAoJEB/WSo9veuUKt5oIAJnfXf0OvSvlA0/Dnlmaee0Y QWC40+xCxs3qejLsGlsmaf/+vCJEgp2jEzhFBdGgNyFhWtTZNlcFkmLlqATbB0I+ k3Hdb3hRouUS37ElL1pQn2Nt1xPEIYx2htmWQ9/aebANQZlTRnrCEt75L//pcsbb I1P9ODSvtdOe35n9GL6pvN5Fmngg08xS5+gVFTsR2nxT4Scn6emlKZK/+XHq+R/U VOCGNgC6EnLfR0CwjoPIGlFCiL70zbl33tqzDOnU/EmCclaGW0OlIosXijmvAQmm lRyR7pCbypRiHRExGRboOhPS8jEyzePmjx37Ja7J6fKKei1KkPAMTKcwwQ4rwSU= =VSSP -----END PGP SIGNATURE----- --Apple-Mail=_35EF1BF8-39B3-4D46-A26B-FC2FDA361FA2-- From nobody Sat Jun 14 00:39:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458A81B2BB4 for ; Sat, 14 Jun 2014 00:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_VxEY4MoBJ9 for ; Sat, 14 Jun 2014 00:39:27 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5F21B2BB2 for ; Sat, 14 Jun 2014 00:39:27 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 48A8A2AB26D; Sat, 14 Jun 2014 07:39:25 +0000 (UTC) Date: Sat, 14 Jun 2014 07:39:25 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140614073925.GY8358@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WXZIkBYhJIkPJ4O9EExnOZgiRwQ Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 07:39:29 -0000 On Fri, Jun 13, 2014 at 06:30:46PM -0300, Watson Ladd wrote: > TLS with ECC computes the premaster secret as H(abg) where g is the > generator of the group, and a and b are the ephemeral exponents. > Because of protocol weaknesses, this premaster secret must be > "contributory": neither side can be allowed to dictate it. > > Curve25519 has order 8*q, where q is some prime. All encoded public > keys lie on this or a twist with order 4*q'. (I might be wrong in the > details, but it's right enough). In particular there is a point of > order 2. As far as I can tell, this is not the case with Diffie-Hellman over Curve 25519, because the base-point (namely 9) has order 8, and the cyclic sub-group it generates has prime order. All private keys are multiples of 8, so an attacker M who chooses a low order element must send a public key m of order 1, 2, 4 or 8, which since Alice's private exponent is a multiple of 8 means that g^{am} is the identity. See the "Small-subgroup attacks" section of DJB's paper. Since key agreement with Curve25519 is presumably Diffie-Hellman with (9) as the base point and the recommended constraints on private exponents, there should be no problem. > A malicious server can provide a point of order 2, and with 50% > probability get a dictated premaster secret. Not useful when Alice's (or Bob's depending on whom Mallory is trying to fool) private exponent is a multiple of 8, the only check required is that the final shared secret is not the identity (IIRC the point at infinity is represented by "0" in Curve 25519 so the check is then just to make sure that the DH shared secret is not 32 zero octets). Corrections/elaboration from folks more familiar with 25519 welcome. -- Viktor. From nobody Sat Jun 14 05:36:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF251B2C28 for ; Sat, 14 Jun 2014 05:36:34 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7O1t-k4W7T3e for ; Sat, 14 Jun 2014 05:36:32 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598281B2C27 for ; Sat, 14 Jun 2014 05:36:32 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id f73so2979174yha.22 for ; Sat, 14 Jun 2014 05:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Ax6U0+ztnSh6wxwTuzQExsm0CX/dyQxsaGQ0q3jo1+k=; b=I/MBN+OapPxdU80uT8i6nut3cYtPc3DjgTKROyo1IgYg1uC/92A82AnbX4Vc3TkbJm e6UCq8MElOvDOeSKVWqAOb6BtVpgCqkrcSWwyRRG+00qQTYOyn/ObM4wQtV7mThYugO2 nAxSnSsensdoLVppg+8Y1fYfLY5V54BxUNVWV1AB+r9CCiDebmtDA6cYfsoJXKV6LohE M3CGAq/1flcfXNLvdHdACY7ySyrAF9u5ulVzUravtY2GMq1LTnEs+flPD0qheJ0aUerF +nRhChQpsE855J7UNxnmc9irIOtdk/7WV3Zbbj2hj5gN+9QLCM+pwFom1p1Lsc3RO8w5 78qw== MIME-Version: 1.0 X-Received: by 10.236.134.169 with SMTP id s29mr14158722yhi.4.1402749391659; Sat, 14 Jun 2014 05:36:31 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Sat, 14 Jun 2014 05:36:31 -0700 (PDT) In-Reply-To: <20140614073925.GY8358@mournblade.imrryr.org> References: <20140614073925.GY8358@mournblade.imrryr.org> Date: Sat, 14 Jun 2014 09:36:31 -0300 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ovieGF_ScAo9FzR_rsQtrVLXA8w Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 12:36:34 -0000 On Sat, Jun 14, 2014 at 4:39 AM, Viktor Dukhovni wrote: > On Fri, Jun 13, 2014 at 06:30:46PM -0300, Watson Ladd wrote: > >> TLS with ECC computes the premaster secret as H(abg) where g is the >> generator of the group, and a and b are the ephemeral exponents. >> Because of protocol weaknesses, this premaster secret must be >> "contributory": neither side can be allowed to dictate it. >> >> Curve25519 has order 8*q, where q is some prime. All encoded public >> keys lie on this or a twist with order 4*q'. (I might be wrong in the >> details, but it's right enough). In particular there is a point of >> order 2. > > As far as I can tell, this is not the case with Diffie-Hellman over > Curve 25519, because the base-point (namely 9) has order 8, and > the cyclic sub-group it generates has prime order. All private > keys are multiples of 8, so an attacker M who chooses a low order > element must send a public key m of order 1, 2, 4 or 8, which since > Alice's private exponent is a multiple of 8 means that g^{am} is > the identity. Yes, the only key that results is the identity. So the attack is 100%, not 50%, effective. > > See the "Small-subgroup attacks" section of DJB's paper. Since > key agreement with Curve25519 is presumably Diffie-Hellman with > (9) as the base point and the recommended constraints on private > exponents, there should be no problem. Read http://cr.yp.to/ecdh.html, the portion after "contributory behavior". This is not an attack that recovers the exponent: it's an attack that involves predicting the premaster secret ahead of time. > >> A malicious server can provide a point of order 2, and with 50% >> probability get a dictated premaster secret. > > Not useful when Alice's (or Bob's depending on whom Mallory is > trying to fool) private exponent is a multiple of 8, the only check > required is that the final shared secret is not the identity (IIRC > the point at infinity is represented by "0" in Curve 25519 so the > check is then just to make sure that the DH shared secret is not > 32 zero octets). Yes, but this check isn't specified in the johnsson-tls-curve25519 draft. It needs to be. Section 2.1 states Parties exchange their public keys (see Section 2.3) and compute a shared secret as x_S = Curve25519(d, x_peer). This shared secret is used directly as the premaster secret, which is always exactly 32 bytes when ECDHE with Curve25519 is used. That implies there is no check on the value of the shared secret. Sincerely, Watson Ladd > > Corrections/elaboration from folks more familiar with 25519 welcome. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sat Jun 14 06:31:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44481B2B4B for ; Sat, 14 Jun 2014 06:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qr7taZ7YIwqO for ; Sat, 14 Jun 2014 06:31:17 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FCC1B283E for ; Sat, 14 Jun 2014 06:31:16 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id s7so1895042lbd.2 for ; Sat, 14 Jun 2014 06:31:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sVjYf+sjyT0bCxIVYbuyH41AWo3Mi6HGDGs+a7zj2Iw=; b=e1jMfYaWiOGBTTb6ot4S4EM+lDXhksIAPPU80kxp8Wnus5c9vkLmHAnTEmmR9sBYXl 5EIPBxtwyT8c93iDXGzapYDLri+fPYx0v8mi5iPiui+EMtcBchudFARBN1SGWe829B8v kJzXl2oQ+/zdwHdoxVwYJZ5entbFRr/TXhAV/65hnnHOanS9ht8C1znG5t0f6nph3FbH oV1Vo8Y+eVIHX2dIJuHH2z5A4ZzhATqNPtK2ckOaPbFAZirwAiNKWk55UoLZm0qIg97T Y1gFULVUxlVLJV+rjCIitblPT3HhY8iibXJ69vGdIlOCd9cNFxVNTx1S0CHiKu0C15EE 8/Vg== X-Gm-Message-State: ALoCoQnOIEP5+X7Bo4QPZpuLKBBhjLiy0yRJx/JKDpQa5aZZOZUPVBD8m4LcvPAGmV08r/jmsJEP MIME-Version: 1.0 X-Received: by 10.112.12.103 with SMTP id x7mr5615237lbb.36.1402752674728; Sat, 14 Jun 2014 06:31:14 -0700 (PDT) Received: by 10.152.114.227 with HTTP; Sat, 14 Jun 2014 06:31:14 -0700 (PDT) X-Originating-IP: [89.207.132.76] In-Reply-To: References: Date: Sat, 14 Jun 2014 13:31:14 +0000 Message-ID: From: Jacob Appelbaum To: "Joseph Salowey (jsalowey)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/g6GTZH8y9aldc8153R10rQzhpb4 Cc: "" Subject: Re: [TLS] Consensus Call on Removing GMT from the Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 13:31:18 -0000 On 6/13/14, Joseph Salowey (jsalowey) wrote: > There appears to be significant support for the removal of GMT from the > client > and server random values in TLS. The chairs would like to ask two > questions: > > - Should we remove the GMT values from the client and server values in TLS > 1.3? > I would request that the language in 1.3 be MUST for clients to avoid client fingerprinting by a passive or active adversary. For servers, I would request that they servers SHOULD make it random. I would also request that for 1.3 that it isn't a requirement (MUST) to make it random. > - Should we remove the GMT fields from the current versions of TLS and > adopt > draft-mathewson-no-gmtunixtime-00 or something similar? Yes. I would request that the language be SHOULD for servers and MUST for clients. As a general comment, I also think it makes sense to hash the output with something cryptographically secure such as SHA-256. I think it is a bad sign to expose random bytes from the RNG to the wire. This kind of exposure is (partially) what allows exploitation of the DUAL_EC_DRBG backdoor. We probably want to stop that kind of information leakage as a matter of defense in depth. > > If you have an opinion on this topic, please reply to the TLS list with your > reasons by Friday, June 20 > The above will help users of various software such as tlsdate to transition. All the best, Jacob From nobody Sat Jun 14 13:54:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D29C1B29F1 for ; Sat, 14 Jun 2014 13:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MSGID_MULTIPLE_AT=1, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFbL9iAKNxoy for ; Sat, 14 Jun 2014 13:53:57 -0700 (PDT) Received: from mail.webolution.de (mail.webolution.de [80.152.246.40]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1A31B29EF for ; Sat, 14 Jun 2014 13:53:56 -0700 (PDT) Received: from staubermann.webolution.de ([192.168.168.32] helo=StaubermannPC) by mail.webolution.de with esmtp (Exim 4.69) (envelope-from ) id 1WvuxO-0005Uw-JT; Sat, 14 Jun 2014 22:53:48 +0200 From: "Michael Staubermann" To: "'Jacob Appelbaum'" , "'Joseph Salowey \(jsalowey\)'" References: In-Reply-To: Date: Sat, 14 Jun 2014 22:54:04 +0200 Message-ID: <028b01cf8812$ca0a5f60$5e1f1e20$@Staubermann@webolution.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+H1PuKYTo2JZVWTly9nVomqPBKPAAPVPSg Content-Language: de X-SA-Exim-Connect-IP: 192.168.168.32 X-SA-Exim-Mail-From: Michael.Staubermann@webolution.de X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on mail.webolution.de) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/awHq79GD8mcfPAhYEYiagjO6nPk Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call on Removing GMT from the Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 20:53:58 -0000 My +1 for all requests. -mst > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Jacob Appelbaum > Sent: Saturday, June 14, 2014 3:31 PM > To: Joseph Salowey (jsalowey) > Cc: > Subject: Re: [TLS] Consensus Call on Removing GMT from the Handshake > > On 6/13/14, Joseph Salowey (jsalowey) wrote: > > There appears to be significant support for the removal of GMT from > > the client and server random values in TLS. The chairs would like to > > ask two > > questions: > > > > - Should we remove the GMT values from the client and server values > in > > TLS 1.3? > > > > I would request that the language in 1.3 be MUST for clients to avoid > client fingerprinting by a passive or active adversary. For servers, I > would request that they servers SHOULD make it random. I would also > request that for 1.3 that it isn't a requirement (MUST) to make it > random. > > > - Should we remove the GMT fields from the current versions of TLS > and > > adopt draft-mathewson-no-gmtunixtime-00 or something similar? > > Yes. I would request that the language be SHOULD for servers and MUST > for clients. > > > As a general comment, I also think it makes sense to hash the output > with something cryptographically secure such as SHA-256. I think it is > a bad sign to expose random bytes from the RNG to the wire. This kind > of exposure is (partially) what allows exploitation of the DUAL_EC_DRBG > backdoor. We probably want to stop that kind of information leakage as > a matter of defense in depth. > > > > > If you have an opinion on this topic, please reply to the TLS list > > with your reasons by Friday, June 20 > > > > The above will help users of various software such as tlsdate to > transition. > > All the best, > Jacob > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Jun 14 20:01:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBEC1B29F6 for ; Sat, 14 Jun 2014 20:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emvJiJcogKfj for ; Sat, 14 Jun 2014 20:01:38 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D821B2886 for ; Sat, 14 Jun 2014 20:01:35 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D6C7C2AB26D; Sun, 15 Jun 2014 03:01:31 +0000 (UTC) Date: Sun, 15 Jun 2014 03:01:31 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140615030131.GK8358@mournblade.imrryr.org> References: <20140614073925.GY8358@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/O53YgjT0NTW_cCT7mcAv66awBOc Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 03:01:40 -0000 On Sat, Jun 14, 2014 at 09:36:31AM -0300, Watson Ladd wrote: > > As far as I can tell, this is not the case with Diffie-Hellman over > > Curve 25519, because the base-point (namely 9) has order 8, Sorry, typo, not order 8, rather prime order, it is an 8th power... > > and > > the cyclic sub-group it generates has prime order. All private > > keys are multiples of 8, so an attacker M who chooses a low order > > element must send a public key m of order 1, 2, 4 or 8, which since > > Alice's private exponent is a multiple of 8 means that g^{am} is > > the identity. > > Yes, the only key that results is the identity. So the attack is 100%, > not 50%, effective. Well, it is not much of an attack, provided the appropriate care is taken to avoid a public key that represents the group identity (all zero if I am not mistaken, but this is the result of a cursory read). > Yes, but this check isn't specified in the johnsson-tls-curve25519 > draft. It needs to be. Yes. The shared secret is either a single trivial value or strong, so the sole trivial value needs to be avoided. > Parties exchange their public keys (see Section 2.3) and compute a > shared secret as x_S = Curve25519(d, x_peer). This shared secret is > used directly as the premaster secret, which is always exactly > 32 bytes when ECDHE with Curve25519 is used. > > That implies there is no check on the value of the shared secret. Unless the function Curve25519 is defined to fail rather than produce the trivial result. So sure, the (simple) check needs to be somewhere. -- Viktor. From nobody Sun Jun 15 01:12:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F071B2BA6 for ; Sun, 15 Jun 2014 01:12:20 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs6tsW_uDVQP for ; Sun, 15 Jun 2014 01:12:18 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9B11B2B8C for ; Sun, 15 Jun 2014 01:12:18 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id x13so4242524wgg.15 for ; Sun, 15 Jun 2014 01:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=XbDwNMzRqkfLRHcQ7GSXEgR0y1efot6eiIubTEDETUE=; b=d4ItR7DLZ0bhXLF9YwWUaRrmvJp5bQ0ydcNT/Usrs3Z8/UPoXuqY2bWcxrJQ8zfMw/ fclPzJB+VI4PF2jmzN9+xqfeUF9o7pwxYSMEtvzqMLSZVjFI+rOck9HZEtTdV4IZCeO5 knHnsoHI+ct3fx6pGd9rj6SmUc6VsDi8hTfS8OvYD01skYh7jtr/Ck8bvq32shmfvdC7 +aQGO4pK4JtCqBrRTSFQjGC5jUpM8NVfivFw0ypmGR6VeAJZZBZE4tACPQ4E6fwzxGb2 B/bejtThyGq+vjlbO/p3AG8goutIWg2cP/eTrr12OHkQYSjFsGrK5FDRjo8hm2a7U9Ud E0Ug== X-Received: by 10.194.240.129 with SMTP id wa1mr18246611wjc.11.1402819936730; Sun, 15 Jun 2014 01:12:16 -0700 (PDT) Received: from [172.24.249.169] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id ej2sm13278114wjd.21.2014.06.15.01.12.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Jun 2014 01:12:15 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5D7B71FB-3082-4291-943F-AAE6748BD773" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: <6407EEB5-E138-4B50-83D1-D68E1DC8E5EE@gmail.com> Date: Sun, 15 Jun 2014 11:12:11 +0300 Message-Id: <6E86C545-58F9-4741-9563-7E2E7C8E0DA8@gmail.com> References: <20140528184735.GA20602@roeckx.be> <097101cf7aa7$17f960a0$47ec21e0$@digicert.com> <4AA8E7B7-A19D-4E65-AF18-C4D02A513652@ieca.com> <538EF79B.3000506@cs.tcd.ie> <539069CC.5010304@cs.tcd.ie> <5390B1D6.5010105@nthpermutation.com> <5390CA45.1050504@nthpermutation.com> <9E3DB9FD-2691-4CED-90A9-A024D7A4F4BA@gmail.com> <49B8F9EA-40C6-442D-9E7E-2B09E42CDCC1@gmail.com> <6407EEB5-E138-4B50-83D1-D68E1DC8E5EE@gmail.com> To: Brian Smith X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mSN2hvYIF-SbsAEglXn1f0TZlPw Cc: "" Subject: Re: [TLS] OCSP must staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 08:12:20 -0000 --Apple-Mail=_5D7B71FB-3082-4291-943F-AAE6748BD773 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 13, 2014, at 7:52 AM, Yoav Nir wrote: >=20 > On Jun 13, 2014, at 2:44 AM, Brian Smith wrote: >=20 >> On Thu, Jun 12, 2014 at 2:45 PM, Yoav Nir = wrote: >>=20 >> On Jun 12, 2014, at 9:21 PM, Brian Smith = wrote: >>> Thanks for sharing that information. Does your product copy all the = certificate policies from the original certificate into the forged = certificate? If your product doesn't copy certificate policies it = doesn't understand, then there wouldn't be an interop issue with your = product and the use of certificate policies for Must-Staple, even if = your product doesn't generate short-lived certificates. >>=20 >> IIRC we don=92t copy certificate policies at all, but I could be = wrong.=20 >>=20 >> It would be great to get a more definitive confirmation of that, not = just from you, but from other vendors of similar products. >=20 > The weekend for us is Friday+Saturday, so I=92ll only be able to check = this only on Sunday. OK. Now I=92ve had a chance to check this, and we don=92t copy any of = the policy extensions. We copy BasicConstraints, KU EKU and = SubjectAltNames. That=92s it. Other vendors may be doing other things. Yoav --Apple-Mail=_5D7B71FB-3082-4291-943F-AAE6748BD773 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 13, 2014, at 7:52 AM, Yoav Nir = <ynir.ietf@gmail.com> = wrote:


On Jun 13, 2014, at 2:44 AM, Brian = Smith <brian@briansmith.org> = wrote:

On Thu, Jun 12, 2014 at 2:45 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:

On Jun 12, = 2014, at 9:21 PM, Brian Smith <brian@briansmith.org> wrote:
Thanks for sharing that information. Does your = product copy all the certificate policies from the original certificate = into the forged certificate? If your product doesn't copy certificate = policies it doesn't understand, then there wouldn't be an interop issue = with your product and the use of certificate policies for Must-Staple, = even if your product doesn't generate short-lived certificates.
IIRC we don=92t copy = certificate policies at all, but I could be = wrong. 

 It would = be great to get a more definitive confirmation of that, not just from = you, but from other vendors of similar = products.

The = weekend for us is Friday+Saturday, so I=92ll only be able to check this = only on Sunday.

OK. Now = I=92ve had a chance to check this, and we don=92t copy any of the policy = extensions. We copy BasicConstraints, KU EKU and SubjectAltNames. That=92s= it.

Other vendors may be doing other = things.

Yoav

= --Apple-Mail=_5D7B71FB-3082-4291-943F-AAE6748BD773-- From nobody Sun Jun 15 07:46:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826BA1B285A for ; Sun, 15 Jun 2014 07:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHiSj6v34fU0 for ; Sun, 15 Jun 2014 07:46:19 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB6D1B2854 for ; Sun, 15 Jun 2014 07:46:19 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id B9920F2C0C3; Sun, 15 Jun 2014 10:46:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id hs44gwLsDfY7; Sun, 15 Jun 2014 10:45:48 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-144-77.washdc.fios.verizon.net [96.255.144.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id F05C1F2C0B6; Sun, 15 Jun 2014 10:45:47 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Sun, 15 Jun 2014 10:45:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <80B0EEB3-AC9C-4E3E-B5F9-32789C39E42F@vigilsec.com> References: To: "Joseph Salowey (jsalowey)" X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RKDX1KlsEU9AaA1CSAvtbjGv_pc Cc: "" Subject: Re: [TLS] Consensus Call on Removing GMT from the Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 14:46:20 -0000 > - Should we remove the GMT values from the client and server values in = TLS 1.3? Yes, these should be allowed to be any values, so that GMT values are = still allowed. > - Should we remove the GMT fields from the current versions of TLS and = adopt > draft-mathewson-no-gmtunixtime-00 or something similar? Yes, as above. Russ From nobody Sun Jun 15 17:52:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EDA1B2990 for ; Sun, 15 Jun 2014 17:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8g0j9KHXCZwn for ; Sun, 15 Jun 2014 17:52:35 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7E11B298C for ; Sun, 15 Jun 2014 17:52:35 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 871B1A888132; Sun, 15 Jun 2014 17:52:34 -0700 (PDT) Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 15 Jun 2014 17:52:34 -0700 (PDT) Message-ID: <914e7a8836ad1efd761f7d867c5cb881.squirrel@www.trepanning.net> In-Reply-To: References: Date: Sun, 15 Jun 2014 17:52:34 -0700 (PDT) From: "Dan Harkins" To: "Jacob Appelbaum" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0zpI50AQyH3KD4v2P8xQkSgzMa8 Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call on Removing GMT from the Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 00:52:36 -0000 On Sat, June 14, 2014 6:31 am, Jacob Appelbaum wrote: > On 6/13/14, Joseph Salowey (jsalowey) wrote: >> There appears to be significant support for the removal of GMT from the >> client >> and server random values in TLS. The chairs would like to ask two >> questions: >> >> - Should we remove the GMT values from the client and server values in >> TLS >> 1.3? >> > > I would request that the language in 1.3 be MUST for clients to avoid > client fingerprinting by a passive or active adversary. For servers, I > would request that they servers SHOULD make it random. I would also > request that for 1.3 that it isn't a requirement (MUST) to make it > random. I see no value in retaining the GMT value in the server random. Making it optional requires some justification. Care to share it? Dan. From nobody Sun Jun 15 18:53:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457ED1B29C2 for ; Sun, 15 Jun 2014 18:53:00 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v1tFMcL6NG8 for ; Sun, 15 Jun 2014 18:52:58 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA41D1B29BD for ; Sun, 15 Jun 2014 18:52:58 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id q200so3670133ykb.4 for ; Sun, 15 Jun 2014 18:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z5TzJED8n0dPk0CHSZDO055XqzkzbIKClMpPFgOC41Y=; b=QTG3dGXvKt9oJqdv0IEBcnkAvJoKGccmmb/sHoWcgf1qxFuaPMP9dp5BzWr3psz3Kp OtLcLrNwsH4FMqUM9ju9xrhydaQii8cpTwsB6AQjcwSle2IULs72hm5kDyNEje0G2UQT VNqVyWyV3frTnKxHbh/jiypwFnvwpje/fX6km+lQDkj0QwrhLndw4HmnG6DAbEkN62kP v0CuY1rvgH0PCTeJKZZzHuSK85mj5Pbm7y0wyrOxhYBkGgzOgHpC8KWWXZRSEsHh4vAT oUcuAS2lgJyiocY7HsMZfOc888ZXd1lRiSxKZREASpTx6Qar7h6IJyEqpjCn8EZfw5s6 +LWw== MIME-Version: 1.0 X-Received: by 10.236.53.69 with SMTP id f45mr29416093yhc.53.1402883578095; Sun, 15 Jun 2014 18:52:58 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Sun, 15 Jun 2014 18:52:58 -0700 (PDT) In-Reply-To: <914e7a8836ad1efd761f7d867c5cb881.squirrel@www.trepanning.net> References: <914e7a8836ad1efd761f7d867c5cb881.squirrel@www.trepanning.net> Date: Sun, 15 Jun 2014 22:52:58 -0300 Message-ID: From: Watson Ladd To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/x0b0H5wCU6Ib3j2cGdx4Z9xrnuM Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on Removing GMT from the Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 01:53:00 -0000 On Sun, Jun 15, 2014 at 9:52 PM, Dan Harkins wrote: > > On Sat, June 14, 2014 6:31 am, Jacob Appelbaum wrote: >> On 6/13/14, Joseph Salowey (jsalowey) wrote: >>> There appears to be significant support for the removal of GMT from the >>> client >>> and server random values in TLS. The chairs would like to ask two >>> questions: >>> >>> - Should we remove the GMT values from the client and server values in >>> TLS >>> 1.3? >>> >> >> I would request that the language in 1.3 be MUST for clients to avoid >> client fingerprinting by a passive or active adversary. For servers, I >> would request that they servers SHOULD make it random. I would also >> request that for 1.3 that it isn't a requirement (MUST) to make it >> random. > > I see no value in retaining the GMT value in the server random. Making > it optional requires some justification. Care to share it? Tails currently uses the gmt time from servers to figure out what time it is. Making it optional lets them ween off. Sincerely, Watson Ladd > > Dan. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Jun 16 00:50:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA90C1B28B8 for ; Mon, 16 Jun 2014 00:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCse3GyFhu62 for ; Mon, 16 Jun 2014 00:50:41 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6573A1B282F for ; Mon, 16 Jun 2014 00:50:41 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A9603A888132; Mon, 16 Jun 2014 00:50:40 -0700 (PDT) Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 16 Jun 2014 00:50:40 -0700 (PDT) Message-ID: <44dfb2038035a40e77c717052f7627ee.squirrel@www.trepanning.net> In-Reply-To: References: <914e7a8836ad1efd761f7d867c5cb881.squirrel@www.trepanning.net> Date: Mon, 16 Jun 2014 00:50:40 -0700 (PDT) From: "Dan Harkins" To: "Watson Ladd" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UgY989TSRB2ilhMatxuufU3CsCk Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on Removing GMT from the Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 07:50:42 -0000 On Sun, June 15, 2014 6:52 pm, Watson Ladd wrote: > On Sun, Jun 15, 2014 at 9:52 PM, Dan Harkins wrote: >> >> On Sat, June 14, 2014 6:31 am, Jacob Appelbaum wrote: >>> On 6/13/14, Joseph Salowey (jsalowey) wrote: >>>> There appears to be significant support for the removal of GMT from >>>> the >>>> client >>>> and server random values in TLS. The chairs would like to ask two >>>> questions: >>>> >>>> - Should we remove the GMT values from the client and server values in >>>> TLS >>>> 1.3? >>>> >>> >>> I would request that the language in 1.3 be MUST for clients to avoid >>> client fingerprinting by a passive or active adversary. For servers, I >>> would request that they servers SHOULD make it random. I would also >>> request that for 1.3 that it isn't a requirement (MUST) to make it >>> random. >> >> I see no value in retaining the GMT value in the server random. Making >> it optional requires some justification. Care to share it? > > Tails currently uses the gmt time from servers to figure out what time > it is. Making it optional lets them ween off. I don't know what "Tails" is but deciding what time it is based on the value of a field that you have no guarantee that you'll find in a received packet sounds like a really bad idea. And since this is a consensus call for removing the GMT value from random in a new version of TLS then "Tails" can figure out some other way to determine time when it negotiates this new version.There is no weening possible or needed. Dan. From nobody Mon Jun 16 01:28:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFD31B2B9F for ; Mon, 16 Jun 2014 01:28:31 -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, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-iSPE27gcXG for ; Mon, 16 Jun 2014 01:28:30 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58E31B2B9E for ; Mon, 16 Jun 2014 01:28:29 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id cm18so7022978qab.14 for ; Mon, 16 Jun 2014 01:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4Uwp7Qj2TIQrQEP1Sk3PLfu5vCpeTmG0PeL+seKGL1M=; b=ALp8M7QobSE4c5+mmHxIg1LhtYPd+90HxF9ZlS/FKhwZ4kXgpcWk3QkdoHcXpB/Jql GEz5tKUPudy6ISThazY7sQmDR56avrRU9bVwBRxGAldKhCfPbKfuht+n8cjzGJM0LrxQ 04P9eyBfu5hMkpaIjVC8Lbe5Fh5149qWOOkdAYCPUDzQzJ1DgXvOuD4dldP7f3zdTZn7 9KpNMYxEovP+aFdzubCeb+9I26W+XnsOzWoJDtSxgPiBhSxffKGvSCJWPHEwJHG2qbmL elMY35IPKtWV/qdZzNwdxLMWIL7lKviBA0YQNKBVX8rnNMAwgfK8XBqnknBT5QgzHbld qS+g== MIME-Version: 1.0 X-Received: by 10.224.111.196 with SMTP id t4mr23920062qap.63.1402907308947; Mon, 16 Jun 2014 01:28:28 -0700 (PDT) Received: by 10.140.98.233 with HTTP; Mon, 16 Jun 2014 01:28:28 -0700 (PDT) In-Reply-To: <44dfb2038035a40e77c717052f7627ee.squirrel@www.trepanning.net> References: <914e7a8836ad1efd761f7d867c5cb881.squirrel@www.trepanning.net> <44dfb2038035a40e77c717052f7627ee.squirrel@www.trepanning.net> Date: Mon, 16 Jun 2014 01:28:28 -0700 Message-ID: From: Robert Ransom To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/X4_vdhHlgjJv0bJKX-ThJQnwZyo Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on Removing GMT from the Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 08:28:31 -0000 On 6/16/14, Dan Harkins wrote: > > On Sun, June 15, 2014 6:52 pm, Watson Ladd wrote: >> On Sun, Jun 15, 2014 at 9:52 PM, Dan Harkins wrote= : >>> >>> On Sat, June 14, 2014 6:31 am, Jacob Appelbaum wrote: >>>> On 6/13/14, Joseph Salowey (jsalowey) wrote: >>>>> There appears to be significant support for the removal of GMT from >>>>> the >>>>> client >>>>> and server random values in TLS. The chairs would like to ask two >>>>> questions: >>>>> >>>>> - Should we remove the GMT values from the client and server values i= n >>>>> TLS >>>>> 1.3? >>>>> >>>> >>>> I would request that the language in 1.3 be MUST for clients to avoid >>>> client fingerprinting by a passive or active adversary. For servers, I >>>> would request that they servers SHOULD make it random. I would also >>>> request that for 1.3 that it isn't a requirement (MUST) to make it >>>> random. >>> >>> I see no value in retaining the GMT value in the server random. Makin= g >>> it optional requires some justification. Care to share it? >> >> Tails currently uses the gmt time from servers to figure out what time >> it is. Making it optional lets them ween off. > > I don't know what "Tails" is but deciding what time it is based on the > value of a field that you have no guarantee that you'll find in a receive= d > packet sounds like a really bad idea. And since this is a consensus call > for removing the GMT value from random in a new version of TLS then > "Tails" can figure out some other way to determine time when it > negotiates this new version.There is no weening possible or needed. =E2=80=98Tails=E2=80=99 () is a live CD which, rou= ghly, routes all of a user's traffic through Tor. I don't remember whether it still uses =E2=80=98tlsdate=E2=80=99 (they put considerable effort into = switching to learning the system time from Tor's directory documents), but it used a small set of servers for tlsdate and it did enough sanity checking on tlsdate's results that it wouldn't have been confused by random values in that protocol field. The more important (widely deployed) use of tlsdate is in Google's ChromeOS, which is probably why Adam Langley wants to not immediately turn off that timestamp field on Google's servers. Since Google controls both the client software and the servers used for tlsdate in ChromeOS, their use of tlsdate should be completely safe. Robert Ransom From nobody Mon Jun 16 07:01:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB751A0034; Mon, 16 Jun 2014 07:00:38 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAYrIuVJwdur; Mon, 16 Jun 2014 07:00:30 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289641A003A; Mon, 16 Jun 2014 07:00:24 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s5GE0LA6006306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Jun 2014 09:00:23 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s5GE0L1h022215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Jun 2014 16:00:21 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.240]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 16 Jun 2014 16:00:21 +0200 From: "FOSSATI, Thomas (Thomas)" To: "saag@ietf.org" Thread-Topic: New Version Notification for draft-fossati-dtls-over-gsm-sms-00.txt Thread-Index: AQHPiWOM4hux6nsRm0SbWD3JXkPFcA== Date: Mon, 16 Jun 2014 14:00:20 +0000 Message-ID: References: <20140616130407.11150.52339.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2254E5C2A22F98409DCB62311C88E581@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TvLoFIjkByDmtDoeFxxmalb5IQo Cc: "dtls-iot@ietf.org" , "tls@ietf.org" Subject: [TLS] Fwd: New Version Notification for draft-fossati-dtls-over-gsm-sms-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 14:00:40 -0000 Hi all, I=92ve just uploaded this new I-D about layering DTLS on top of an SMS bear= er. (Its main use-case is in the OMA Lightweight M2M spec.) Any feedback from you sec folks would be very welcome. TLS and DICE mailing lists have been copied in as well as this may (or may = not) be relevant to those working groups, but I=92d rather let SAAG be the = main collector for comments. Thanks very much, Thomas. Begin forwarded message: > From: > Subject: New Version Notification for draft-fossati-dtls-over-gsm-sms-00.= txt > Date: 16 June 2014 14:04:07 BST > To: Thomas Fossati >=20 >=20 > A new version of I-D, draft-fossati-dtls-over-gsm-sms-00.txt > has been successfully submitted by Thomas Fossati and posted to the > IETF repository. >=20 > Name: draft-fossati-dtls-over-gsm-sms > Revision: 00 > Title: Datagram Transport Layer Security (DTLS) over Global System for M= obile Communications (GSM) Short Message Service (SMS) > Document date: 2014-06-16 > Group: Individual Submission > Pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-fossati-dtls-ov= er-gsm-sms-00.txt > Status: https://datatracker.ietf.org/doc/draft-fossati-dtls-over-= gsm-sms/ > Htmlized: http://tools.ietf.org/html/draft-fossati-dtls-over-gsm-sm= s-00 >=20 >=20 > Abstract: > This document specifies the use of Datagram Transport Layer Security > (DTLS) over the Global System for Mobile Communications (GSM) Short > Message Service (SMS). >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat From nobody Mon Jun 16 07:25:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191261A002B for ; Mon, 16 Jun 2014 07:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6vcA0gjDHRA for ; Mon, 16 Jun 2014 07:25:18 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85F21A0058 for ; Mon, 16 Jun 2014 07:25:17 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id mc6so2749928lab.38 for ; Mon, 16 Jun 2014 07:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=5nvkiUjlb5pbiYrWuB8Qx8PxuqooL+XzKnq+UymsvQQ=; b=ppxKgzgoQdpqJVWh2ONtRB4hWN1Bd6ItlZfjd0vxbg5NJyUi8SixGb18KLriSNbQPV ubtoRDTZk941TcG18cSDCUSI0NVaTcTkXOoRJUFuMQxSs81pYKXaDPX7H8+8Spowqw0R W9mRQ0N+EXxq86vrmJjG/XXSYC0y9kW7lNI+CdWxKcRMTmk0It/CcgFA9IgaCnWEMmrF 1GMyI+CrVppUNzD1+wiQPcv6R2B6ZLWssQpVYZ/8M0db8zfifpHBoILh7M/H36jlgknR sbHUj4b9yoyCfAl43YSfm2ZDDCcw3+DnisrVxsebtzTgg5k820Ob4G+4xmeqdl8Mh++W qNlg== MIME-Version: 1.0 X-Received: by 10.112.154.74 with SMTP id vm10mr2230640lbb.47.1402928716118; Mon, 16 Jun 2014 07:25:16 -0700 (PDT) Sender: nick.a.mathewson@gmail.com Received: by 10.112.139.234 with HTTP; Mon, 16 Jun 2014 07:25:16 -0700 (PDT) In-Reply-To: References: <914e7a8836ad1efd761f7d867c5cb881.squirrel@www.trepanning.net> <44dfb2038035a40e77c717052f7627ee.squirrel@www.trepanning.net> Date: Mon, 16 Jun 2014 10:25:16 -0400 X-Google-Sender-Auth: zml297OzYGImVjJTg8DdMOfLHiY Message-ID: From: Nick Mathewson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LVfW3OOiqhcWLUB1qXmMBX6N3UM Subject: Re: [TLS] Consensus Call on Removing GMT from the Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 14:25:19 -0000 On Mon, Jun 16, 2014 at 4:28 AM, Robert Ransom wrote: [...] > The more important (widely deployed) use of tlsdate is in Google's > ChromeOS, which is probably why Adam Langley wants to not immediately > turn off that timestamp field on Google's servers. Since Google > controls both the client software and the servers used for tlsdate in > ChromeOS, their use of tlsdate should be completely safe. For what it's worth, I believe that recent versions of tlsdate also support learning the current time from an HTTPS "Date:" header, so there's a plausible upgrade path there. (Anybody who is interested in security and time should have a look over at the NTP working group. If I'm not mistaken, they've been discussing an open draft that tries to improve the state of security in NTP.) cheers, -- Nick Mathewson From nobody Mon Jun 16 08:35:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1A61A007C; Mon, 16 Jun 2014 08:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juIHhwWizBd8; Mon, 16 Jun 2014 08:35:01 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3273F1A007B; Mon, 16 Jun 2014 08:35:01 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s5GFYtOX007500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Jun 2014 17:34:55 +0200 (MEST) In-Reply-To: To: Hugo Krawczyk Date: Mon, 16 Jun 2014 17:34:55 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140616153455.977B21AD52@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ghy-Sy7qFZ7dPYBI720HmzxruPE Cc: "ietf\\@ietf.org" , TLS Mailing List Subject: Re: [TLS] Last Call: (Encrypt-then-MAC for TLS and DTLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 15:35:03 -0000 Hugo Krawczyk wrote: > > The technical results in my 2001 paper are correct but the conclusion > regarding SSL/TLS is wrong. I assumed that TLS was using fresh IVs and that > the MAC was computed on the encoded plaintext, i.e. Encode-Mac-Encrypt > while TLS is doing Mac-Encode-Encrypt which is exactly what my theoretical > example shows is insecure. The later padding attacks showed that the > theoretical example of insecurity had a very practical instantiation in > TLS. While the paper shows correctly that MAC-then-Encrypt can be secure > with both CBC and stream ciphers, it also shows that it requires a LOT of > care about encoding - it turned out that TLS/SSL was not doing that. So if > you want to keep Mac-then-Encrypt then you must change the encoding as well > as how you apply the MAC. Changing to Encrypt-then-MAC is a much safer > solution. I agree with you that your paper demonstrates problem with mac-extend-encrypt schemes. And that it fails to notice that TLS applies CBC padding after computing the MAC and before encryption, and is therefore an mac-extend-encrypt scheme that can be susceptible to decryption oracles. But I strongly disagree to the assertion that "Encrypt-then-MAC" would be a much safer scheme than *TRUE* MAC-then-Encrypt _withou_ any extension inserted before the encryption such as CBC-padding. In fact, the pad-mac-encrypt scheme for TLS-CBC-ciphersuites, as suggested by Serge Vaudenay, is provably safer than the currently favoured encrypt-then-MAC scheme. -Martin From nobody Mon Jun 16 12:10:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B79B1A0172 for ; Mon, 16 Jun 2014 12:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1V4dcR5bg0YL for ; Mon, 16 Jun 2014 12:10:46 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A05A41A015E for ; Mon, 16 Jun 2014 12:10:46 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 00B85A888132; Mon, 16 Jun 2014 12:10:45 -0700 (PDT) Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 16 Jun 2014 12:10:46 -0700 (PDT) Message-ID: In-Reply-To: References: <914e7a8836ad1efd761f7d867c5cb881.squirrel@www.trepanning.net> <44dfb2038035a40e77c717052f7627ee.squirrel@www.trepanning.net> Date: Mon, 16 Jun 2014 12:10:46 -0700 (PDT) From: "Dan Harkins" To: "Robert Ransom" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tls/S34UMVzH-NpFFg_pmdsiy_bufJs Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on Removing GMT from the Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 19:10:51 -0000 On Mon, June 16, 2014 1:28 am, Robert Ransom wrote: > On 6/16/14, Dan Harkins wrote: >> >> On Sun, June 15, 2014 6:52 pm, Watson Ladd wrote: >>> On Sun, Jun 15, 2014 at 9:52 PM, Dan Harkins >>> wrote: >>>> >>>> On Sat, June 14, 2014 6:31 am, Jacob Appelbaum wrote: >>>>> On 6/13/14, Joseph Salowey (jsalowey) wrote: >>>>>> There appears to be significant support for the removal of GMT from >>>>>> the >>>>>> client >>>>>> and server random values in TLS. The chairs would like to ask two >>>>>> questions: >>>>>> >>>>>> - Should we remove the GMT values from the client and server values >>>>>> in >>>>>> TLS >>>>>> 1.3? >>>>>> >>>>> >>>>> I would request that the language in 1.3 be MUST for clients to avoid >>>>> client fingerprinting by a passive or active adversary. For servers, >>>>> I >>>>> would request that they servers SHOULD make it random. I would also >>>>> request that for 1.3 that it isn't a requirement (MUST) to make it >>>>> random. >>>> >>>> I see no value in retaining the GMT value in the server random. >>>> Making >>>> it optional requires some justification. Care to share it? >>> >>> Tails currently uses the gmt time from servers to figure out what time >>> it is. Making it optional lets them ween off. >> >> I don't know what "Tails" is but deciding what time it is based on the >> value of a field that you have no guarantee that you'll find in a >> received >> packet sounds like a really bad idea. And since this is a consensus call >> for removing the GMT value from random in a new version of TLS then >> "Tails" can figure out some other way to determine time when it >> negotiates this new version.There is no weening possible or needed. > > 'Tails' () is a live CD which, roughly, > routes all of a user's traffic through Tor. I don't remember whether > it still uses 'tlsdate' (they put considerable effort into switching > to learning the system time from Tor's directory documents), but it > used a small set of servers for tlsdate and it did enough sanity > checking on tlsdate's results that it wouldn't have been confused by > random values in that protocol field. Very cool! > The more important (widely deployed) use of tlsdate is in Google's > ChromeOS, which is probably why Adam Langley wants to not immediately > turn off that timestamp field on Google's servers. Since Google > controls both the client software and the servers used for tlsdate in > ChromeOS, their use of tlsdate should be completely safe. In both of these cases, the client seems to know when it's talking to a like instance of TLS-- either a Tails client connecting to a Tor server or a ChromeOS client connecting to a Google server-- so this can be supported proprietarily. Think of "random" as a covert channel and tlsdate as the data to transfer through it. Neither of these are a really justification for making it optional in the standard to include GMT in the server random. Dan. From nobody Mon Jun 16 16:30:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152021A02C5 for ; Mon, 16 Jun 2014 16:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lctAEsraX3p0 for ; Mon, 16 Jun 2014 16:30:31 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E885B1A02B8 for ; Mon, 16 Jun 2014 16:30:30 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id dc16so8410587qab.15 for ; Mon, 16 Jun 2014 16:30:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3UGclpa4jLKZL9APxrluMRj+hwMke508ghgBRH6lds0=; b=FjAA8xfsQrPqRxP39/LlpFpl4vX+xE/LlBQ/zAneqavxkv6CRNYdGoCNQcuGTu+yEg HrV7hX6CHNH15I9KxOJFtDpvZpfLf2XNcxkRiFRYqIvQYLpkplMQmQ64TWgDSeO8f7hT 4d9LnAQujFmJ2MrtNxQehse5ZFfviWRtsm3xQOuuWFtxGeKvYvgxYmyq6RsZaM40jAOa wif4Nq4g1O4N7ShvJDi/s5xFQOjp1uPVp3h02VlNDDHAqeJUwPURgKRVX5w91Oc+IB3i tZbjX35AYg7zPspt8Fh4lJLJ0g/l5bTGSxiISYR0klZVbYgSIZGRJojEyeiqEgmZZrf8 l5Ow== X-Gm-Message-State: ALoCoQkR7K8M6GAQHlys6DWZzeQo6O0hxE2OddY6v9RVoRqXLyUu5YJ97fLxWySiYwIe7KJorch1 MIME-Version: 1.0 X-Received: by 10.140.102.79 with SMTP id v73mr21245775qge.8.1402961428974; Mon, 16 Jun 2014 16:30:28 -0700 (PDT) Received: by 10.140.87.55 with HTTP; Mon, 16 Jun 2014 16:30:28 -0700 (PDT) X-Originating-IP: [77.247.181.163] In-Reply-To: References: <914e7a8836ad1efd761f7d867c5cb881.squirrel@www.trepanning.net> <44dfb2038035a40e77c717052f7627ee.squirrel@www.trepanning.net> Date: Mon, 16 Jun 2014 23:30:28 +0000 Message-ID: From: Jacob Appelbaum To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QXiRVV9PDljap5jbHTGeisbqLlw Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on Removing GMT from the Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 23:30:33 -0000 On 6/16/14, Dan Harkins wrote: > > On Mon, June 16, 2014 1:28 am, Robert Ransom wrote: >> On 6/16/14, Dan Harkins wrote: >>> >>> On Sun, June 15, 2014 6:52 pm, Watson Ladd wrote: >>>> On Sun, Jun 15, 2014 at 9:52 PM, Dan Harkins >>>> wrote: >>>>> >>>>> On Sat, June 14, 2014 6:31 am, Jacob Appelbaum wrote: >>>>>> On 6/13/14, Joseph Salowey (jsalowey) wrote: >>>>>>> There appears to be significant support for the removal of GMT from >>>>>>> the >>>>>>> client >>>>>>> and server random values in TLS. The chairs would like to ask two >>>>>>> questions: >>>>>>> >>>>>>> - Should we remove the GMT values from the client and server values >>>>>>> in >>>>>>> TLS >>>>>>> 1.3? >>>>>>> >>>>>> >>>>>> I would request that the language in 1.3 be MUST for clients to avoid >>>>>> client fingerprinting by a passive or active adversary. For servers, >>>>>> I >>>>>> would request that they servers SHOULD make it random. I would also >>>>>> request that for 1.3 that it isn't a requirement (MUST) to make it >>>>>> random. >>>>> >>>>> I see no value in retaining the GMT value in the server random. >>>>> Making >>>>> it optional requires some justification. Care to share it? >>>> >>>> Tails currently uses the gmt time from servers to figure out what time >>>> it is. Making it optional lets them ween off. >>> >>> I don't know what "Tails" is but deciding what time it is based on the >>> value of a field that you have no guarantee that you'll find in a >>> received >>> packet sounds like a really bad idea. And since this is a consensus call >>> for removing the GMT value from random in a new version of TLS then >>> "Tails" can figure out some other way to determine time when it >>> negotiates this new version.There is no weening possible or needed. >> >> 'Tails' () is a live CD which, roughly, >> routes all of a user's traffic through Tor. I don't remember whether >> it still uses 'tlsdate' (they put considerable effort into switching >> to learning the system time from Tor's directory documents), but it >> used a small set of servers for tlsdate and it did enough sanity >> checking on tlsdate's results that it wouldn't have been confused by >> random values in that protocol field. > > Very cool! > >> The more important (widely deployed) use of tlsdate is in Google's >> ChromeOS, which is probably why Adam Langley wants to not immediately >> turn off that timestamp field on Google's servers. Since Google >> controls both the client software and the servers used for tlsdate in >> ChromeOS, their use of tlsdate should be completely safe. > > In both of these cases, the client seems to know when it's talking to > a like instance of TLS-- either a Tails client connecting to a Tor server > or a ChromeOS client connecting to a Google server-- so this can be > supported proprietarily. Think of "random" as a covert channel and > tlsdate as the data to transfer through it. Previously, it was a standard way to securely fetch time - downgrading it to something that is far from a covert channel seems less than ideal. :) > > Neither of these are a really justification for making it optional in > the standard to include GMT in the server random. > The reason to make it optional is that it impacts clients in the wild who depend on this detail in the specification. These are just a few examples of who uses it. Such a change will affect (tens? of) millions of users in the case of ChromeOS alone. It makes sense to allow time to transition. All the best, Jacob From nobody Mon Jun 16 16:31:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E6F1A02C9 for ; Mon, 16 Jun 2014 16:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yp3h_4jW23tQ for ; Mon, 16 Jun 2014 16:31:23 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E80AF1A02C8 for ; Mon, 16 Jun 2014 16:31:22 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id w7so8934171qcr.2 for ; Mon, 16 Jun 2014 16:31:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8lYoPlXuKfXx2dnR8cL/nB3lY/yrUcs/Isl3b4lF/uU=; b=Hn4xi3bvfLz2w3kWm6hKxZjj494ZTYI04saGMNUJAhcFd3OF39KCHQ045a8BArXVuc N0f/Yw5L2/tvv7ynMHSKpYcxhFqW3jTaRyPCQ3SqEjZJ3v9aSlXTIUZVL/16hWwxjR1b 8NFrfkX0LVWAhYO5yYWBhtqhK20WvU4NdAM72BdnLgnM6HK2he/d13ijWNq6MhsIdG0V LjwS48bICUvd9Uk7ee30v59h73dWI9+bu8b9ZJac6SFD0ASr6aG80/bB+v0GTmwjmezZ fcNgzruCQ3qSfXOJKDAR/QY+1l71IJ50Nh8M3GMfQD5+EJ/vK4qTtOik/dRNRH5SK/LV /GVw== X-Gm-Message-State: ALoCoQk9FJsbfP8wH5z7aQpJLU3DTjPo5lzTbyPAB1sSXT819jmeuXTJPOwDlA3PGHwDHZP5xRfs MIME-Version: 1.0 X-Received: by 10.224.63.145 with SMTP id b17mr30389547qai.38.1402961482186; Mon, 16 Jun 2014 16:31:22 -0700 (PDT) Received: by 10.140.87.55 with HTTP; Mon, 16 Jun 2014 16:31:22 -0700 (PDT) X-Originating-IP: [77.247.181.163] In-Reply-To: References: <914e7a8836ad1efd761f7d867c5cb881.squirrel@www.trepanning.net> <44dfb2038035a40e77c717052f7627ee.squirrel@www.trepanning.net> Date: Mon, 16 Jun 2014 23:31:22 +0000 Message-ID: From: Jacob Appelbaum To: Nick Mathewson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/u4EADT-0RcO6URi4v2iY9yDGriI Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call on Removing GMT from the Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 23:31:24 -0000 On 6/16/14, Nick Mathewson wrote: > On Mon, Jun 16, 2014 at 4:28 AM, Robert Ransom > wrote: > [...] >> The more important (widely deployed) use of tlsdate is in Google's >> ChromeOS, which is probably why Adam Langley wants to not immediately >> turn off that timestamp field on Google's servers. Since Google >> controls both the client software and the servers used for tlsdate in >> ChromeOS, their use of tlsdate should be completely safe. > > For what it's worth, I believe that recent versions of tlsdate also > support learning the current time from an HTTPS "Date:" header, so > there's a plausible upgrade path there. Yes, that is exactly correct - it isn't clear to me if Google has switched to this specific method of using tlsdate. Thanks again for the patch! > > (Anybody who is interested in security and time should have a look > over at the NTP working group. If I'm not mistaken, they've been > discussing an open draft that tries to improve the state of security > in NTP.) That sounds great - thanks for the heads up. All the best, Jacob From nobody Tue Jun 17 00:36:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D616B1A0272 for ; Tue, 17 Jun 2014 00:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 968SC6CbiuRd for ; Tue, 17 Jun 2014 00:36:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 455981A005C for ; Tue, 17 Jun 2014 00:36:41 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5H7adJf028665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 17 Jun 2014 03:36:39 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5H7ab0C029506 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 17 Jun 2014 03:36:38 -0400 Message-ID: <1402990596.2335.18.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Watson Ladd Date: Tue, 17 Jun 2014 09:36:36 +0200 In-Reply-To: References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yjpFq3pvzwl-3kudV3dWtP1BMW0 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 07:36:44 -0000 On Fri, 2014-06-13 at 08:34 -0300, Watson Ladd wrote: > The issue is the following: most applications do something like this > parse_request(conn) > check_if_request_authorized(conn) > > This assumes that the authentication state doesn't change in between > the two lines, or midway through the parse. > With renegotiation it can. Indeed, but this is an easily unsolvable issue. That can be easily avoided on the implementation side (and gnutls is does not allow that). I have numerous times asked to clarify and better specify this part on the past. > Furthermore, renegotiation makes writes block on reads. That can cause > pain for event based systems. I don't understand what do you make by makes writes block on reads. Renegotiation is the same a negotiation in TLS. The same issues that exist in the TLS handshake will exist in the rehandshake. Nevertheless, I've used many even-based systems with TLS with no issue. > > I don't think anyone would disagree with what you say here. But you are > > avoiding to reply to the point. Was the new proposal you endorse proven > > secure, or do we replace the old method, -that you claim is insecure- > > with yet another method that will be proven insecure in few years? > What new proposal have I endorsed? The whole thread is about dropping renegotiation _and_ replacing with a mechanism proposed by Martin Thompson. > No, you do the work to show your > protocol is secure. > Up until now, we haven't, and users have paid the price. [...] > >> virtually every paper on the TLS handshake until miTLS, etc. Can you > >> point to someone providing an adequate explanation of what > >> renegotation does? > > This is not a citation, you could replace it with "everyone knows that". > > If you really have a point, because it is not of your own experience, > > please cite it properly. > Go to eprint.iacr.org. Search TLS: > http://eprint.iacr.org/2013/339.pdf "we do not model renegotation/resumption" > http://eprint.iacr.org/2012/630.pdf Analyzes the renegotation fix, a > full 3 years after the fix was proposed and adopted, and TLS does not > meet strongest security model. > http://eprint.iacr.org/2014/020.pdf Renegotation isn't mentioned. > I did skip over a few papers but the message is clear: renegotiation > is not currently amenable to analysis. Interesting observation. However, the fact that renegotiation has not been modeled in some papers doesn't reveal much except that the formal protocol verification lags behind protocol design. If you check the papers that you reference you'll notice that it is not only renegotiation that they don't model. The first one doesn't even model ciphersuite negotiation which is the basis of the protocol. The second does mention that renegotiation can be modified to avoid a stronger adversary, i.e., an adversary that can learn the previous session keys. That's an interesting paper, but whether we really need to protect against this adversary is really up to discussion. Most often in academic papers (with the exception of mitls work) they simply model a single ciphersuite and prove it secure; then in the next month you see an new attack on the same ciphersuite that was proven secure, because the majority of the protocol interactions were ignored. That does not show that we need to drop all the protocol options and only allow for RSA-AES-CBC for example (which was proven secure numerous times prior it was broken). If we had followed that path and dropped ciphersuite negotiation, renegotiation, and session resumption, only to allow the "proven" secure options, now TLS would be broken and we wouldn't have a way to fix it. regards, Nikos From nobody Tue Jun 17 13:03:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920A71A0174 for ; Tue, 17 Jun 2014 13:03:50 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_F9kV_sDgnk for ; Tue, 17 Jun 2014 13:03:39 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7C51A0168 for ; Tue, 17 Jun 2014 13:03:24 -0700 (PDT) Received: from [10.70.10.68] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id C258EF984; Tue, 17 Jun 2014 16:03:20 -0400 (EDT) Message-ID: <53A09EFE.5090509@fifthhorseman.net> Date: Tue, 17 Jun 2014 16:03:10 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: Eric Rescorla References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F4F@USMBX1.msg.corp.akamai.com> <5398995F.2080106@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ekTj9D1smwS7jcvwvQsgMjXm94IDqLO3n" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xZBJY9PAWQlb4fkUu6G_EaxCyqA Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Pre-IETF meeting? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:03:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ekTj9D1smwS7jcvwvQsgMjXm94IDqLO3n Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/11/2014 02:14 PM, Eric Rescorla wrote: > We'll be discussing this on the chair's call tomorrow. We need to figur= e > out what the other constraints are. Expect an update tomorrow PM Did this update happen? If so, i think i missed it, and i don't see it in the archives [0]. Were any decisions made? --dkg [0] https://www.ietf.org/mail-archive/web/tls/current/maillist.html --ekTj9D1smwS7jcvwvQsgMjXm94IDqLO3n Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJToJ7+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcXzYQALUpCqyssYS1MIRV63w0C4ok H0z9urLpgXt6Q6IfmrmUCzkHluoAaVPm2Idgfwi65VF22lQRgCIZPD+idcgcG14Q k3ufT49/20t3U+++m2ig174gvZgiaCiRkhf8bKuLT9LmkFmmzKTKVbME63KB3ryJ i4XctADk6yfiRSK5sLL0cse/pKpFhjvUwNPzZV9NRwkP5uNoF25yjoxxrX0yZvlz lXkFknmVnw4wiWsz2CzlB8fEJXtfl68SLsFGuY41D8l0q9Q6q4daSUVCTdIZ5t7h okm+qsvXLCob246Cykxm5NOyNRjbibb1oGIC2Z6lnLbtxcVBB4M8pEf69FR5kb6z DoMLdjyctcwFXy8yza6Dfv4+rndEz9xACD8t29qwkz3ol8trRIRwenKelBS7YLNa dDWcfqjENdpiHHPslgXVUos2xx0WwbVERCkubZXDdJCJjNtLAIcNvg2j11pd0AOi GbpfBdh3mZdgJFz/pZqQB0Fycv2vEUuR3O1fWxANPcFCKoan+0SP1MtvPAiO0UAf DLqlKd+tgTph4ASSIDgUNoJ/1A9t9mDVuJJXjKtwcbnvWOmk3ROvzgCzWzMKYCG0 fXJcrM/8FPXfdQZVVkbYjH4MmqUXAJPMddp0+Ww8beDnua3PKbhCpzeEQeyH12qr gtQoFxJhqYxDiARqIM47 =yOho -----END PGP SIGNATURE----- --ekTj9D1smwS7jcvwvQsgMjXm94IDqLO3n-- From nobody Tue Jun 17 13:56:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF5F1A0168 for ; Tue, 17 Jun 2014 13:56:51 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QikXsDfsDgAV for ; Tue, 17 Jun 2014 13:56:49 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 78E221A0154 for ; Tue, 17 Jun 2014 13:56:49 -0700 (PDT) Received: from [10.70.10.68] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id E6FDDF984; Tue, 17 Jun 2014 16:56:43 -0400 (EDT) Message-ID: <53A0AB7E.4050706@fifthhorseman.net> Date: Tue, 17 Jun 2014 16:56:30 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos , Watson Ladd References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> <1402990596.2335.18.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: <1402990596.2335.18.camel@dhcp-2-127.brq.redhat.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="76GctuBcn9eD0q0UO5LDmT2f6SSjmiaF7" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6FeNZB8MtUt5noo686zfweDIPZE Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:56:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --76GctuBcn9eD0q0UO5LDmT2f6SSjmiaF7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/17/2014 03:36 AM, Nikos Mavrogiannopoulos wrote: > On Fri, 2014-06-13 at 08:34 -0300, Watson Ladd wrote: >=20 >> The issue is the following: most applications do something like this >> parse_request(conn) >> check_if_request_authorized(conn) >> >> This assumes that the authentication state doesn't change in between >> the two lines, or midway through the parse. >> With renegotiation it can. >=20 > Indeed, but this is an easily unsolvable issue.=20 Do you mean "easily solvable" here? > That can be easily > avoided on the implementation side (and gnutls is does not allow that).= > I have numerous times asked to clarify and better specify this part on > the past. Do you have a suggestion for how we could clarify and better specify this part? Maybe it's worth crafting that into a counterproposal that could be weighed against the current "remove renegotiation" proposal. I realize that we frequently claim we "don't do API" here, and the issue of how well application developers actually deal with connection property changes comes close to the API of any given TLS implementation. But I suspect most application developers who use TLS don't understand that the authentication state or cryptographic protections of the connection may change mid-stream. Of the minority that does understand that this state may change, i suspect that many of them don't actually handle the situation well (if at all). if we want to avoid this on the implementation side, do we need more guidance to implementers of TLS stacks? or guidance for application-layer users of those stacks? or both? --dkg --76GctuBcn9eD0q0UO5LDmT2f6SSjmiaF7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJToKt+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcQncP/3EwsKHKhZg3ylh9yOfcf+s3 rChrnaSVXPsjeb+QB3KF5KgoWV8omNdIybLAJy4n0f4/a0YncRqAhrHINePO8jnm maihNTI9vgV//LDAHevQtGkFVeXm+j6a+jejR6JTKsG6sPSYz3pYaeJVXMoMMXCW KCvI9wbeAgwoYvw53+WnilDuPV4bLCNApeoSsO77XVhBlKqPXfzSZ1PZQRdDabUF bAI3Ou8IcXrsw2VX7vgAogfFpgn1Bgzscdz9IMxM5dyne2SeC07aejGZGt+g5uMc wn7Lc4XEWtsDirdR94Knzl7TS28WPNMvDYsQD4rdLZ9cN63cwqwQ44dnUDVzYPwU 3dLgd9yk7HA4L3QaQXCnJTai/iqLp0qLEpu8J/z1lD4or7UdlvHn0fV3N1PXh3qi EYAJqex9fCjsMQjOloq04UUKl4jZQiOSjiqO0532Do5vE6e3//Mh9S/rJlK/wveX gJ8MZZjHQtEA6oEY8quaJWlp23L69hek43hcZS5smsOzp5tCvmKxTBRywOJf0AYU OPGaa7fPHnqsWcLYA9O40/Z++FtWyrVDp7oUvKHIBBboC0F2fC34Snz/gjXeTBro pE6157rndcyEOMc7UqCKCCf6Yb4xBgN/dX8xls5QSTO4YXbnVA/bQAC+yK2JzQJa wjFgkfYPQGEwg6yVJ9E/ =n3vU -----END PGP SIGNATURE----- --76GctuBcn9eD0q0UO5LDmT2f6SSjmiaF7-- From nobody Wed Jun 18 12:03:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBA51A0115 for ; Wed, 18 Jun 2014 12:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9czQRDoiUBI for ; Wed, 18 Jun 2014 12:02:57 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 217AF1A00E1 for ; Wed, 18 Jun 2014 12:02:56 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 641F6F984 for ; Wed, 18 Jun 2014 15:02:53 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 747FE203E5; Wed, 18 Jun 2014 15:02:54 -0400 (EDT) From: Daniel Kahn Gillmor To: tls@ietf.org Date: Wed, 18 Jun 2014 15:02:54 -0400 Message-Id: <1403118174-13024-1-git-send-email-dkg@fifthhorseman.net> X-Mailer: git-send-email 2.0.0 In-Reply-To: References: Archived-At: http://mailarchive.ietf.org/arch/msg/tls/e5K3gtAJkyhtppbPtyE83Wl0n-s Subject: [TLS] [PATCH] Clean up removal of all non-AEAD modes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 19:03:01 -0000 The draft was in a sort of halfway state between whether TLSCiphertext has a fragment that is a selection or just embedding the AEAD elements directly. This should normalize it to the embedded view without the extra GenericAEADCipher struct definition. (i don't think this changes the logic of the draft at all) --- draft-ietf-tls-tls13.md | 25 +++++-------------------- 1 file changed, 5 insertions(+), 20 deletions(-) This is https://github.com/tlswg/tls13-spec/pull/45 diff --git a/draft-ietf-tls-tls13.md b/draft-ietf-tls-tls13.md index 2c21189..2a7f244 100644 --- a/draft-ietf-tls-tls13.md +++ b/draft-ietf-tls-tls13.md @@ -985,7 +985,7 @@ of {{RFC5116}}. The key is either the client_write_key or the server_write_key. opaque nonce_explicit[SecurityParameters.record_iv_length]; aead-ciphered struct { opaque content[TLSPlaintext.length]; - }; + } fragment; } TLSCiphertext; type @@ -1000,19 +1000,10 @@ length fragment : The AEAD encrypted form of TLSPlaintext.fragment. -{:br } - - struct { - opaque nonce_explicit[SecurityParameters.record_iv_length]; - aead-ciphered struct { - opaque content[TLSPlaintext.length]; - }; - } GenericAEADCipher; - Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD operation is constructed, and what is the length of the -GenericAEADCipher.nonce_explicit part. In many cases, it is appropriate to use +TLSCiphertext.nonce_explicit part. In many cases, it is appropriate to use the partially implicit nonce technique described in Section 3.2.1 of {{RFC5116}}; with record_iv_length being the length of the explicit part. In this case, the implicit part SHOULD be derived from key_block as @@ -2731,18 +2722,12 @@ This section describes protocol types and constants. ContentType type; ProtocolVersion version; uint16 length; - select (SecurityParameters.cipher_type) { - case aead: GenericAEADCipher; + opaque nonce_explicit[SecurityParameters.record_iv_length]; + aead-ciphered struct { + opaque content[TLSPlaintext.length]; } fragment; } TLSCiphertext; - struct { - opaque nonce_explicit[SecurityParameters.record_iv_length]; - aead-ciphered struct { - opaque content[TLSPlaintext.length]; - }; - } GenericAEADCipher; - ## Change Cipher Specs Message struct { -- 2.0.0 From nobody Wed Jun 18 12:07:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B331A0261 for ; Wed, 18 Jun 2014 12:07: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uf6ZlT1eN8Um for ; Wed, 18 Jun 2014 12:07:34 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17AA1A0125 for ; Wed, 18 Jun 2014 12:07:24 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w62so1309807wes.24 for ; Wed, 18 Jun 2014 12:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k2pK8aKkZAJykIMz9sHk1fjumwPWEWr48NOR8cW2NRs=; b=CneJ1VL1mluh4h9aX5H3IQwvsDwCauomCqdNfBMB/WJYzcVCapTwKlps47vb3BHgad GLHiQamfdxvzxqEAmm2TNIcIZUrqEKYQsBipmm3PdXEa6m+euGoirSpYJxYNKyk3Y1qp e+20b8WChnxIkJ/mNepZMUQwDoGqkWAkcrYmrhW9YIqaFIzRJJeW5OFL7/9Jwo98DN3r AMTrKXpxG1chVkHQV7EaLew5ISMy/rWwmm1gLXw0PWEeSPiFEGbc7nSyss/BD2PqYkjj em0pSmqhRt68tOJ6ekSZC512jepDy4D3F19HuWyAKMe4cpfDWNuP/dwQ8J8ATLCZyUHr KcHQ== MIME-Version: 1.0 X-Received: by 10.194.2.244 with SMTP id 20mr151489wjx.26.1403118443249; Wed, 18 Jun 2014 12:07:23 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Wed, 18 Jun 2014 12:07:23 -0700 (PDT) In-Reply-To: <1403118174-13024-1-git-send-email-dkg@fifthhorseman.net> References: <1403118174-13024-1-git-send-email-dkg@fifthhorseman.net> Date: Wed, 18 Jun 2014 12:07:23 -0700 Message-ID: From: Martin Thomson To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6Ux9-_PXQGBHL6HHEYFBbpcK19k Cc: "tls@ietf.org" Subject: Re: [TLS] [PATCH] Clean up removal of all non-AEAD modes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 19:07:36 -0000 On 18 June 2014 12:02, Daniel Kahn Gillmor wrote: > This is https://github.com/tlswg/tls13-spec/pull/45 It looks like a good change to me. But it's probably not the sort of thing we need to discuss that much, it's purely editorial. From nobody Wed Jun 18 12:18:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708C01A0111 for ; Wed, 18 Jun 2014 12:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6whrLvAYFhB for ; Wed, 18 Jun 2014 12:17:57 -0700 (PDT) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3441A002F for ; Wed, 18 Jun 2014 12:17:56 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x48so1359921wes.11 for ; Wed, 18 Jun 2014 12:17:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IT1BPYz861EpkVriUvr+aLkiTparens0hKsxTbk27Z4=; b=R+xNQWTF1PuMozmvDZsvisxZyUhlt3hmDpDkSCLmJBj9tCBFG7u10GrRM2/U7LSVyz OKCeF6eNjNAvwB380zq9GE3mKDe2HGPjaZ0P5/uVirQ6P4d105oWWgz8BD0hclkeFBJE gmAVtNFQP3RJtyFl8PnjtYu02yvB27uqsDAE0w4pZOSV17L/WqAubEMPv59nFd8BYn6/ ad26dhGEr5PpKHsdrSb2wjnuJhgRxmPzVkRWYnDTKKEyXWlBzsjCH7q+c/tj0ehNiCMm lMyjh7f7xdCqOrUEZAmtXhP/UzEJSVILkxp9E+hUuN5vilYTLqdmodaAUz0vs1p08+2o SSAQ== X-Gm-Message-State: ALoCoQkMHlnowklRIRYLd3/rMdHYgA1oW83FbcWdfxteLx6jitxpGn1MjR9g7ELtKsHhcAQhDkKQ X-Received: by 10.180.198.44 with SMTP id iz12mr7471422wic.49.1403119075739; Wed, 18 Jun 2014 12:17:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 18 Jun 2014 12:17:15 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:874:5003:5c89:162b] In-Reply-To: References: <1403118174-13024-1-git-send-email-dkg@fifthhorseman.net> From: Eric Rescorla Date: Wed, 18 Jun 2014 12:17:15 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b624dfe16673604fc211ea8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZBer-hMhDoYDOG6fvA6mEdqRY6Y Cc: "tls@ietf.org" Subject: Re: [TLS] [PATCH] Clean up removal of all non-AEAD modes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 19:17:59 -0000 --047d7b624dfe16673604fc211ea8 Content-Type: text/plain; charset=UTF-8 This looks basically sound to me. I'll give it a once-over on github and assuming it still looks ok, merge it in. -Ekr On Wed, Jun 18, 2014 at 12:07 PM, Martin Thomson wrote: > On 18 June 2014 12:02, Daniel Kahn Gillmor wrote: > > This is https://github.com/tlswg/tls13-spec/pull/45 > > It looks like a good change to me. But it's probably not the sort of > thing we need to discuss that much, it's purely editorial. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7b624dfe16673604fc211ea8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This looks basically sound to me. I'll give it a once-= over on github and assuming
it still looks ok, merge it in.
<= br>
-Ekr


On Wed, Jun 18, 2014 at 12:07 PM, Martin Tho= mson <martin.thomson@gmail.com> wrote:
On 18 June 2014 12:02, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> This is https://github.com/tlswg/tls13-spec/pull/45

It looks like a good change to me. =C2=A0But it's probably not the sort= of
thing we need to discuss that much, it's purely editorial.

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

--047d7b624dfe16673604fc211ea8-- From nobody Wed Jun 18 12:20:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116AA1A0261 for ; Wed, 18 Jun 2014 12:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.143 X-Spam-Level: * X-Spam-Status: No, score=1.143 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHdcsf9GKV1s for ; Wed, 18 Jun 2014 12:20:12 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.16.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE62F1A0125 for ; Wed, 18 Jun 2014 12:20:11 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 23152A2A40A4E; Wed, 18 Jun 2014 14:19:50 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway04.websitewelcome.com (Postfix) with ESMTP id C92EBA2A4081B for ; Wed, 18 Jun 2014 14:19:49 -0500 (CDT) Received: from [96.231.225.192] (port=60919 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WxLOe-0005rx-Ce for tls@ietf.org; Wed, 18 Jun 2014 14:19:48 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <89E6060A-9756-4186-8375-372B406CAA8F@ieca.com> Date: Wed, 18 Jun 2014 15:19:46 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1WxLOe-0005rx-Ce X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:60919 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/snuLL-Z12Po708uLTEkhH5sTjwU Subject: [TLS] doodle for interim TLS WG meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 19:20:13 -0000 WG members, At the interim meeting in Denver we discussed having another interim around the time of the regularly scheduled IETF meeting in July; either Sunday the 20th of July or Saturday the 26th of July are the dates on offer this time. The meeting venue is still TBD but it will be in the Toronto metropolitan area (tentatively in the Mozilla offices). The meeting will start at 10am and conclude at 4pm. Please complete the doodle poll (http://doodle.com/nmt6itede9czrtdt) by Friday the 20th of June to indicate your preference for either Saturday or Sunday. spt for the chairs From nobody Wed Jun 18 12:21:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65BE11A0289 for ; Wed, 18 Jun 2014 12:20:59 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzZFeoOttlsa for ; Wed, 18 Jun 2014 12:20:57 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CAB291A02C5 for ; Wed, 18 Jun 2014 12:20:57 -0700 (PDT) Received: from [10.70.10.68] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id E687EF984; Wed, 18 Jun 2014 15:20:55 -0400 (EDT) Message-ID: <53A1E68A.9060004@fifthhorseman.net> Date: Wed, 18 Jun 2014 15:20:42 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: Martin Thomson References: <1403118174-13024-1-git-send-email-dkg@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wAAeVkHe9tQOaQoJ2vh4bcp0UEpwSTuLa" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4hPnxTC6pT3KqrFADWdRRvU-SJA Cc: "tls@ietf.org" Subject: Re: [TLS] [PATCH] Clean up removal of all non-AEAD modes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 19:20:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wAAeVkHe9tQOaQoJ2vh4bcp0UEpwSTuLa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/18/2014 03:07 PM, Martin Thomson wrote: > On 18 June 2014 12:02, Daniel Kahn Gillmor wrot= e: >> This is https://github.com/tlswg/tls13-spec/pull/45 >=20 > It looks like a good change to me. But it's probably not the sort of > thing we need to discuss that much, it's purely editorial. I agree this shouldn't need much discussion. i posted it to the list here because there was no feedback in 6 days after submitting the initial pull request. --dkg --wAAeVkHe9tQOaQoJ2vh4bcp0UEpwSTuLa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJToeaKXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcjjYP/j0d+peiinggMJ6Di5GddPFP XDoHATYCrRubzAShkma0D4Cr9fSI3UBHYBHxqDPt/u8YSKPfhB2pF2HSEJ9xdkcE b61dnHG8zSEKEuVV6yKXDp/p5+QWwE7si/M9Iq51sboX45KyDvKFDNBZYOkieRwT h2wd3GSDAgQ8IXWrOPRJU4Vb3X2KiMeuKtlSs55Cvf5s/HVQTfe9kcN98Q175FU0 eZEXBZWXyxN7sR2BaPeI2iMF61RpeCn73PjEy2OLhR/vFIfXHMXt9qOQo5iNgMt8 Qp6dZ1OxBjD5+ky59BornhNUyAkdropQDtqbgSEhNyyIzj25DLVMXjDhMJMZ06Lw x1zPUhN2nPDt8g8RAO/GkXwUQwgoKw+pUVIERRz7Ks0d7x15Jf36SueQZVXsBsAq GMhCrUX/AsZDZrc7eefY1h86gjEUJ8Lv6G9hFgm8yl9au/xug1Fv8He4BvQ7tZm6 rkpKVUFXtvnI+OWD3S1CjheMNzk9wXIbmegJqw2Zgc7lDj6KOMCUFwtYOSfyMvG+ fQ3IIFNzCQEnPmS7r0sf73OORIVfeEikAZpVBxRAAaGn3pPXwFaO+yGAaFQ5+41O ILs20+9b/6sPwFFY2tXWvIFCaFi18qAWgeS1528GGJu/eiZ8qU1azXVuSilLFa+w adirochpyQcMjLsNisdl =n7g/ -----END PGP SIGNATURE----- --wAAeVkHe9tQOaQoJ2vh4bcp0UEpwSTuLa-- From nobody Wed Jun 18 12:27:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740341A0289 for ; Wed, 18 Jun 2014 12:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Beb9Zg3ihEBK for ; Wed, 18 Jun 2014 12:26:57 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DAB31A0261 for ; Wed, 18 Jun 2014 12:26:57 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so9017508wib.2 for ; Wed, 18 Jun 2014 12:26:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2irD75FoNz+vM/KOvJj4Hb6pX61S6rSESlpmRvIJSVc=; b=UHhBcJ56eAQYwOz7Iq1H/0VHXQUg9jzWcipJBNQm1anmQlkOCFqk1FmXAv4+6LEI+o vgoRUBfUyxgq1VScQ6Pm1uK/Q4rPxEy+r8DBauxpbKdGd42W+u90FvIT4X8kghfDgSZm aNvWXk8lzUpi3KI5+2VjdaLZxgou9qEDs8hgCtBJQfxiGtV1e8lbkSAjUjEiTDEiHCZo 6kTXAiRZ2txhur8bfxFXh5eoyn6C5hkkgeWkTwxsGxtG6xuARxRv4Wl+z1qN27iP3zMn eOwtX0YpBw0LzBP8QehXE7O4JlyLxjxORVslYOKsr585kb2JXgqAyLHr8L+qMBtWYJsJ mqJQ== X-Gm-Message-State: ALoCoQng5BIFkzzBb8fWY5+cbSlrueVVvpZ31pM72lh+AZRGYF30THKvNZnwN9m5wAeRjNjyaPKq X-Received: by 10.194.243.10 with SMTP id wu10mr235967wjc.44.1403119615889; Wed, 18 Jun 2014 12:26:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 18 Jun 2014 12:26:15 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:874:5003:5c89:162b] In-Reply-To: <53A1E68A.9060004@fifthhorseman.net> References: <1403118174-13024-1-git-send-email-dkg@fifthhorseman.net> <53A1E68A.9060004@fifthhorseman.net> From: Eric Rescorla Date: Wed, 18 Jun 2014 12:26:15 -0700 Message-ID: To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=089e0141a2024871ca04fc213e51 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2iw_adFrG4m5_rNPPWP9RbNKi30 Cc: "tls@ietf.org" Subject: Re: [TLS] [PATCH] Clean up removal of all non-AEAD modes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 19:27:02 -0000 --089e0141a2024871ca04fc213e51 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 18, 2014 at 12:20 PM, Daniel Kahn Gillmor wrote: > On 06/18/2014 03:07 PM, Martin Thomson wrote: > > On 18 June 2014 12:02, Daniel Kahn Gillmor > wrote: > >> This is https://github.com/tlswg/tls13-spec/pull/45 > > > > It looks like a good change to me. But it's probably not the sort of > > thing we need to discuss that much, it's purely editorial. > > I agree this shouldn't need much discussion. i posted it to the list > here because there was no feedback in 6 days after submitting the > initial pull request. That was just me doing batch processing :) -Ekr > > --dkg > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e0141a2024871ca04fc213e51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 18, 2014 at 12:20 PM, Daniel Kahn Gillmor <dkg@fifthho= rseman.net> wrote:
On 06/18/2014 03:07 PM, Mart= in Thomson wrote:
> On 18 June 2014 12:02, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
>> This is https://github.com/tlswg/tls13-spec/pull/45
>
> It looks like a good change to me. =C2=A0But it's probably not the= sort of
> thing we need to discuss that much, it's purely editorial.

I agree this shouldn't need much discussion. =C2=A0i posted it to= the list
here because there was no feedback in 6 days after submitting the
initial pull request.

That was just me doin= g batch processing :)

-Ekr
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 --dkg


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


--089e0141a2024871ca04fc213e51-- From nobody Wed Jun 18 12:33:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1625D1A02BF for ; Wed, 18 Jun 2014 12:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGraZoCzBR-B for ; Wed, 18 Jun 2014 12:33:52 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.93.35.6]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 454B81A029F for ; Wed, 18 Jun 2014 12:33:52 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 78ED69C6963A; Wed, 18 Jun 2014 14:33:50 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway13.websitewelcome.com (Postfix) with ESMTP id ABD4F9C6890E for ; Wed, 18 Jun 2014 14:33:47 -0500 (CDT) Received: from [96.231.225.192] (port=61110 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WxLc4-0001Ru-84; Wed, 18 Jun 2014 14:33:40 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sean Turner In-Reply-To: <53A09EFE.5090509@fifthhorseman.net> Date: Wed, 18 Jun 2014 15:33:37 -0400 Content-Transfer-Encoding: 7bit Message-Id: <7AD622BD-893F-4F1B-8F78-7C4739416B93@ieca.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434F4F@USMBX1.msg.corp.akamai.com> <5398995F.2080106@fifthhorseman.net> <53A09EFE.5090509@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.1878.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1WxLc4-0001Ru-84 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:61110 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 8 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2BDYTd3QAhGcWctu_cIAi7GtKbU Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Pre-IETF meeting? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 19:33:53 -0000 On Jun 17, 2014, at 16:03, Daniel Kahn Gillmor wrote: > On 06/11/2014 02:14 PM, Eric Rescorla wrote: >> We'll be discussing this on the chair's call tomorrow. We need to figure >> out what the other constraints are. Expect an update tomorrow PM > > Did this update happen? If so, i think i missed it, and i don't see it > in the archives [0]. Were any decisions made? > > --dkg > > [0] https://www.ietf.org/mail-archive/web/tls/current/maillist.html This was my bad. Polls out now. spt From nobody Thu Jun 19 03:26:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22551A011E for ; Thu, 19 Jun 2014 03:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOxa4FcK8TzK for ; Thu, 19 Jun 2014 03:26:54 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.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 40F421A0114 for ; Thu, 19 Jun 2014 03:26:54 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5JAQpOC029740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Jun 2014 06:26:51 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5JAQm68006547 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 19 Jun 2014 06:26:50 -0400 Message-ID: <1403173608.5825.6.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Daniel Kahn Gillmor Date: Thu, 19 Jun 2014 12:26:48 +0200 In-Reply-To: <53A0AB7E.4050706@fifthhorseman.net> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> <1402990596.2335.18.camel@dhcp-2-127.brq.redhat.com> <53A0AB7E.4050706@fifthhorseman.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_HqoYQhGY4geAFTumvhO8OLfZo0 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 10:26:56 -0000 On Tue, 2014-06-17 at 16:56 -0400, Daniel Kahn Gillmor wrote: > On 06/17/2014 03:36 AM, Nikos Mavrogiannopoulos wrote: > > On Fri, 2014-06-13 at 08:34 -0300, Watson Ladd wrote: > > > >> The issue is the following: most applications do something like this > >> parse_request(conn) > >> check_if_request_authorized(conn) > >> > >> This assumes that the authentication state doesn't change in between > >> the two lines, or midway through the parse. > >> With renegotiation it can. > > > > Indeed, but this is an easily unsolvable issue. > Do you mean "easily solvable" here? Yes. > > That can be easily > > avoided on the implementation side (and gnutls is does not allow that). > > I have numerous times asked to clarify and better specify this part on > > the past. > Do you have a suggestion for how we could clarify and better specify > this part? Maybe it's worth crafting that into a counterproposal that > could be weighed against the current "remove renegotiation" proposal. My counter-proposal would be: 1. Removing the Note "If a rehandshake occurs while data is flowing on a connection, the communicating parties may continue to send data using the old CipherSpec." 2. Adding the text: "During the handshake process implementations SHALL NOT allow application protocol data exchange. Implementations SHALL terminate the session if application protocol data is received." (in DTLS that data may arrive due to network errors so they should be quietly discarded. 3. Adding the text "Since the authentication credentials may change during a renegotiation the upper layers must be notified of either the new negotiation process or any identity change." That would make renegotiation a strictly inband process, and applications would be able to distinguish traffic before and after a new negotiation. regards, Nikos From nobody Thu Jun 19 08:28:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C2F1A026F for ; Thu, 19 Jun 2014 08:28:23 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qIfNdAwMg0l for ; Thu, 19 Jun 2014 08:28:21 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931801A026E for ; Thu, 19 Jun 2014 08:28:21 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so2426999wgg.21 for ; Thu, 19 Jun 2014 08:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=47ab3z24/LYqyuH8oZ3PmoR2KwkI0KpX7vfZ5Mhj2kI=; b=vJNkPEXPERQx7rWyU0HQH0UHavkJTFhgGgKUQSLwPZVFVwH8vWv2Ns3UziKys//LOE H0MDSpvACip/UtNdHjK6RKR3vSDmPRivRTSV2iv+mcq9dhGwwbKfkfusciPUIl1F+n60 KXL5XZxZKNXRhb9tBvA4+XZzvxXgDZ74Lp+s2wa5+zybWG/csHl9TEpS5pUUhxBrxRvL a0dNCmGdvBTRERxZos3ZnjudrOeOY8/io8rH7EbdReNDuVbfsxRakPneH0gwmFwRSRfi KWfFu4ogJEXm9JnJr2m3WAkS2JgEmpW+o1vr3DsCyIfv0RdjgjBjoHNjOqRXI/H3VEEy gOQQ== MIME-Version: 1.0 X-Received: by 10.180.96.6 with SMTP id do6mr7562897wib.44.1403191700264; Thu, 19 Jun 2014 08:28:20 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Thu, 19 Jun 2014 08:28:20 -0700 (PDT) In-Reply-To: <1403173608.5825.6.camel@dhcp-2-127.brq.redhat.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> <1402990596.2335.18.camel@dhcp-2-127.brq.redhat.com> <53A0AB7E.4050706@fifthhorseman.net> <1403173608.5825.6.camel@dhcp-2-127.brq.redhat.com> Date: Thu, 19 Jun 2014 08:28:20 -0700 Message-ID: From: Martin Thomson To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/K4LkyMrfTeG9qlzbQYxJKNYqfa4 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 15:28:23 -0000 On 19 June 2014 03:26, Nikos Mavrogiannopoulos wrote: > My counter-proposal would be: > 1. Removing the Note "If a rehandshake occurs while data is flowing on a > connection, the communicating parties may continue to send data using > the old CipherSpec." > > 2. Adding the text: "During the handshake process implementations SHALL > NOT allow application protocol data exchange. Implementations SHALL > terminate the session if application protocol data is received." (in > DTLS that data may arrive due to network errors so they should be > quietly discarded. > > 3. Adding the text "Since the authentication credentials may change > during a renegotiation the upper layers must be notified of either the > new negotiation process or any identity change." > > That would make renegotiation a strictly inband process, and > applications would be able to distinguish traffic before and after a new > negotiation. That sounds strictly worse than what we have today. Points 1&2 render the connection unusable, something that many applications can't have. In many respects - other than TCP congestion window warmup perhaps - this is equivalent to Brian's proposal to remove renegotiation and replace it with nothing, forcing people to make new connections. And the main point, which is that it's not the lack of a notification API for renegotiation that causes the issue, it's the fact that it can happen at all. From nobody Thu Jun 19 15:06:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5701A044F for ; Thu, 19 Jun 2014 15:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OR8Z9kTL4LW for ; Thu, 19 Jun 2014 15:06:21 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) (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 C3DAB1A03F4 for ; Thu, 19 Jun 2014 15:06:20 -0700 (PDT) Received: from Mustang.missi.ncsc.mil (mustang.missi.ncsc.mil [144.51.60.149]) by stingray.missi.ncsc.mil with ESMTP id s5JM6JpY032642 for ; Thu, 19 Jun 2014 18:06:19 -0400 (EDT) Received: from ODYSSEUS.missi.ncsc.mil ([fe80::a8ee:8532:895b:b420]) by Mustang.missi.ncsc.mil ([fe80::dd64:e457:4553:e1ff%14]) with mapi id 14.03.0181.006; Thu, 19 Jun 2014 18:06:18 -0400 From: "Kemp, David P." To: "tls@ietf.org" Thread-Topic: [TLS] Proposed text for removing renegotiation Thread-Index: AQHPi6kHx49fY5M8bUK7yZHZkjJ7zZt40e8A///nX3A= Date: Thu, 19 Jun 2014 22:06:17 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC8CB7FDC30@Odysseus.missi.ncsc.mil> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> <1402990596.2335.18.camel@dhcp-2-127.brq.redhat.com> <53A0AB7E.4050706@fifthhorseman.net> <1403173608.5825.6.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.60.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BFVHLDPEXUef9JvnDt8EDO8cxTI Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 22:06:24 -0000 > And the main point, which is that it's not the lack of a > notification API for renegotiation that causes the issue, > it's the fact that it can happen at all. If there is not general agreement on what "the issue" is, there won't be ag= reement on how to solve it. If "the issue" is "we don't like renegotiation= ", then of course no solution other than eliminating renegotiation will sol= ve it. But if the issue is that applications on each side of a TLS connection don'= t have a common understanding of what parameters have been negotiated and w= hen they become effective, then an API that supports data semantics identic= al to "Close and Open TCP" without actually negotiating a new TCP connectio= n is a valid solution. An application must be guaranteed that all data sent or received prior to r= enegotiation uses the old set of parameters and all data sent or received a= fter uses the new set. The TLS library should arrange for that to happen s= uch that the data flowing in one direction (written on the initiating side)= flows continuously over the wire, slowed only by the TLS handshake bytes t= ransmitted in that direction. Data in the other direction is delayed as ne= cessary to sync with the transition. Note 2 may be overly restrictive if "handshake process" is interpreted to i= nclude any round trips. It should include only messages that trigger the u= se of new parameters; there is no reason to block data while sending setup = messages that have not yet taken effect. >> That would make renegotiation a strictly inband process, and=20 >> applications would be able to distinguish traffic before and after a=20 >> new negotiation ---> becomes effective <---. That is the requirement. Dave -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Thursday, June 19, 2014 11:28 AM To: Nikos Mavrogiannopoulos Cc: tls@ietf.org Subject: Re: [TLS] Proposed text for removing renegotiation On 19 June 2014 03:26, Nikos Mavrogiannopoulos wrote: > My counter-proposal would be: > 1. Removing the Note "If a rehandshake occurs while data is flowing on=20 > a connection, the communicating parties may continue to send data=20 > using the old CipherSpec." > > 2. Adding the text: "During the handshake process implementations=20 > SHALL NOT allow application protocol data exchange. Implementations=20 > SHALL terminate the session if application protocol data is received."=20 > (in DTLS that data may arrive due to network errors so they should be=20 > quietly discarded. > > 3. Adding the text "Since the authentication credentials may change=20 > during a renegotiation the upper layers must be notified of either the=20 > new negotiation process or any identity change." > > That would make renegotiation a strictly inband process, and=20 > applications would be able to distinguish traffic before and after a=20 > new negotiation. That sounds strictly worse than what we have today. Points 1&2 render the connection unusable, something that many applications= can't have. In many respects - other than TCP congestion window warmup pe= rhaps - this is equivalent to Brian's proposal to remove renegotiation and = replace it with nothing, forcing people to make new connections. And the main point, which is that it's not the lack of a notification API f= or renegotiation that causes the issue, it's the fact that it can happen at= all. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Jun 19 15:44:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6149B1A0183 for ; Thu, 19 Jun 2014 15:44:11 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S64O42kciWAa for ; Thu, 19 Jun 2014 15:44:09 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C97C1A0320 for ; Thu, 19 Jun 2014 15:44:09 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so2910629wes.8 for ; Thu, 19 Jun 2014 15:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=41dYVIDxbFl6bEby61E1sUHM6ZErPM9lZJj8+KNZ5wc=; b=z9qOkBzqp2L1qAATkerZxehacY2OPxX5cOvjsc5Bz8lG4ObZu6+/izr5Y8B9SZC58r pq6V42A+EHo3URNgeLetsY+JazWcnuHQvjlLzXYcWVww5yA1N70QosysPOvZ+j7JGc98 zyRW10pruRITALUF9mZPax6OghV8kWaAFSBXlQq9XkUeF2KuYXrTQ9WOOyPzkAp/7OEB 37kX/r9dR+yqbC/2rV8hLSJblxr/lkGdKFO/cl0AHRD9bFfMbgM53aljWFms6os0am7/ RR6HhwYu/B/m7GDVBmBV0kaYKRLnAnkAZNYhPNFGsc5570O/TpJuC4lmgDc2jn0JHN/l Xe6w== MIME-Version: 1.0 X-Received: by 10.195.17.164 with SMTP id gf4mr727340wjd.45.1403217848078; Thu, 19 Jun 2014 15:44:08 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Thu, 19 Jun 2014 15:44:08 -0700 (PDT) Date: Thu, 19 Jun 2014 15:44:08 -0700 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-d8tuhw0d_yNuHl2VsCHc-TeTV0 Subject: [TLS] Renegotiation: trying to summarize X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 22:44:11 -0000 It's been a long thread, I think a recap is in order. Here's the options I've seen thus far: 1. Remove renegotiation entirely Brian Smith proposed this. Arguments for are its beautiful simplicity and the fact that it ensures that you limit the time that a single session (and the corresponding keys) live. Arguments against are that it doesn't allow for long-lived connections; and we've evidence (thanks David) that suggests that rekeying on very short timescales is interesting to some TLS users, misguided or not. 2. Remove renegotiation and replace it with a key refresh This is what I've proposed, though the details could easily be different (e.g., you could do a new DH exchange for maximal PFS, or you could invent a new message type). The advantage over #1 is that you can have a much longer connection lifetime. That could equally be considered a disadvantage. 3. End TLS and use the same L4 for a new session Here we effectively end TLS, but keep the TCP connection (or equivalent) around for use in a new TLS session. In some versions, this has an "end TLS" message that signals the end of the old session. In others, starting a new handshake terminates the old session implicitly. Some have suggested that it be phrased in API terms as a new connection, that the application needs to request a new connection to get the handshake to happen. In others, this is just a different spin on renegotiation, with a little dead air while everything is changed out. In the latter case, I don't see how this is any different to retaining renegotiation. The former seems like an optimization of #1. 4. It ain't broke, don't fix it The general thread here is that any problems are either fictional, or the result of problems in the TLS API or the application that uses it. In short, I think that #1 and #2 suggest that there is a potential problem if session properties can change; #3 and #4 reject that thesis. You could treat the 1&2 vs. 3&4 as the high order bit. Then, you either choose to limit the lifetime of sessions (#1) or go long (#2). Alternatively, you decide whether to break sessions apart (#3) or keep the old renegotiation scheme (#4). On the other hand, 3 could looks a lot like an optimization of #1, though it might suggest the potential to get things wrong. From nobody Thu Jun 19 16:19:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CED1A04C8 for ; Thu, 19 Jun 2014 16:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zbR8k15Xnn6 for ; Thu, 19 Jun 2014 16:19:32 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B271A0496 for ; Thu, 19 Jun 2014 16:19:32 -0700 (PDT) Received: from BY2PR03MB427.namprd03.prod.outlook.com (10.141.141.146) by BY2PR03MB428.namprd03.prod.outlook.com (10.141.141.151) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 19 Jun 2014 23:19:31 +0000 Received: from BY2PR03MB427.namprd03.prod.outlook.com ([10.141.141.146]) by BY2PR03MB427.namprd03.prod.outlook.com ([10.141.141.146]) with mapi id 15.00.0954.000; Thu, 19 Jun 2014 23:19:30 +0000 From: Andrei Popov To: Martin Thomson , "tls@ietf.org" Thread-Topic: [TLS] Renegotiation: trying to summarize Thread-Index: AQHPjBAD3pQReO/HX0e0rijhNJZiipt5DTYA Date: Thu, 19 Jun 2014 23:19:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(51444003)(377454003)(199002)(189002)(101416001)(81542001)(31966008)(99286002)(2656002)(105586002)(83072002)(85306003)(106116001)(85852003)(76576001)(15975445006)(79102001)(95666004)(74662001)(80022001)(74502001)(64706001)(87936001)(20776003)(21056001)(86362001)(33646001)(4396001)(92566001)(76482001)(77982001)(46102001)(19580395003)(19580405001)(99396002)(83322001)(81342001)(50986999)(76176999)(54356999)(74316001)(24736002)(106276001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB428; H:BY2PR03MB427.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ji0Tx0CUFieVM1G_jCwkZpEFeOY Subject: Re: [TLS] Renegotiation: trying to summarize X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 23:19:37 -0000 This is a good summary, thanks Martin. It also seems that #1 and #2 break (= or significantly complicate) existing TLS client auth scenarios, while #3 a= nd #4 allow these client auth scenarios. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Thursday, June 19, 2014 3:44 PM To: tls@ietf.org Subject: [TLS] Renegotiation: trying to summarize It's been a long thread, I think a recap is in order. Here's the options I= 've seen thus far: 1. Remove renegotiation entirely Brian Smith proposed this. Arguments for are its beautiful simplicity and = the fact that it ensures that you limit the time that a single session (and= the corresponding keys) live. Arguments against are that it doesn't allow= for long-lived connections; and we've evidence (thanks David) that suggest= s that rekeying on very short timescales is interesting to some TLS users, = misguided or not. 2. Remove renegotiation and replace it with a key refresh This is what I've proposed, though the details could easily be different (e= .g., you could do a new DH exchange for maximal PFS, or you could invent a = new message type). The advantage over #1 is that you can have a much longe= r connection lifetime. That could equally be considered a disadvantage. 3. End TLS and use the same L4 for a new session Here we effectively end TLS, but keep the TCP connection (or equivalent) around for use in a new TLS session. In some versions, this ha= s an "end TLS" message that signals the end of the old session. In others, starting a new handshake terminates the old session implicitly. Some have suggested that it be phrased in API terms as a new connection, th= at the application needs to request a new connection to get the handshake t= o happen. In others, this is just a different spin on renegotiation, with = a little dead air while everything is changed out. In the latter case, I d= on't see how this is any different to retaining renegotiation. The former = seems like an optimization of #1. 4. It ain't broke, don't fix it The general thread here is that any problems are either fictional, or the r= esult of problems in the TLS API or the application that uses it. In short, I think that #1 and #2 suggest that there is a potential problem = if session properties can change; #3 and #4 reject that thesis. You could treat the 1&2 vs. 3&4 as the high order bit. Then, you either ch= oose to limit the lifetime of sessions (#1) or go long (#2). Alternatively, you decide whether to break sessions apart (#3) or keep the = old renegotiation scheme (#4). On the other hand, 3 could looks a lot like= an optimization of #1, though it might suggest the potential to get things= wrong. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Jun 19 16:23:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF871A0183 for ; Thu, 19 Jun 2014 16:23: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uB406IlBSQor for ; Thu, 19 Jun 2014 16:23:21 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CE61A00F2 for ; Thu, 19 Jun 2014 16:23:20 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id x48so2952080wes.23 for ; Thu, 19 Jun 2014 16:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ImroUCfaiqD0uSet7QZOCvn/8GD8o8N8wH4H9rl9H0Y=; b=j3d9PNye9hvWx/MhMBnVAI710Avu2P5OMxfUyTS/GOpwJBGLN1xeY8I+lKDjjvP0Yd TKoksSZlSauu4GVWw5Fev+kajrK/cEWYsgd5I6F23bGBq+mplno45E+N5BmzQg6M45NU 8gkaE8RNRQGyP5IhFA6GhEcKLUMoJddiqi8hcrIx3y2TmCV319Qd1Ah5tfNdD7/XUZhF g8vIoIniwK8oe5AHpX17u+UkcqB6YQNYtykuvqGdN/ulyRBmmqqDvvH79AVJCdzIPGgv qa4zdcUryCPS7tSKje26svP0HEhsz7ze4fGdEAiwQVpdMTDkUxX739SIKJNgKI6kPnEt XJdg== MIME-Version: 1.0 X-Received: by 10.195.11.132 with SMTP id ei4mr8292931wjd.95.1403220199460; Thu, 19 Jun 2014 16:23:19 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Thu, 19 Jun 2014 16:23:19 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Jun 2014 16:23:19 -0700 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uFA8_GaJMa3gjXRHDS7I3LVAUJ4 Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation: trying to summarize X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 23:23:22 -0000 On 19 June 2014 16:19, Andrei Popov wrote: > It also seems that #1 and #2 break (or significantly complicate) existing TLS client auth scenarios, while #3 and #4 allow these client auth scenarios. Indeed. This is perhaps the biggest drawback to making session properties immutable. We know that people use this feature. Personally, I think that we can find a better solution for that. I've proposed one option that relies on changes in the application protocol; others have suggested that we could provide a facility within TLS to support this use case. Depending on what you think of those options, it might reduce the severity of losing the feature. From nobody Thu Jun 19 16:43:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665B81A02E0 for ; Thu, 19 Jun 2014 16:43:27 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfxWLPIjJ9yX for ; Thu, 19 Jun 2014 16:43:25 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90BBB1A00F2 for ; Thu, 19 Jun 2014 16:43:25 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 0698133D1BD; Thu, 19 Jun 2014 23:43:24 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Andrei Popov References: From: Geoffrey Keating Date: 19 Jun 2014 16:43:24 -0700 In-Reply-To: Message-ID: Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NETuf93ye8QlSJkQTIkVeiWDukA Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation: trying to summarize X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 23:43:27 -0000 Andrei Popov writes: > This is a good summary, thanks Martin. It also seems that #1 and #2 > break (or significantly complicate) existing TLS client auth > scenarios, while #3 and #4 allow these client auth scenarios. I believe there was also a proposal to allow client auth at any point during the session, but not renegotiate: no new ciphers, no new keys, just send CertificateRequest and get back Client Certificate and CertificateVerify. This does prevent use of client certificates with encryption-only algorithms, but it seems such a thing should be used from the start of the connection anyway. Compared to renegotiation this allows many simplifications: - It can't affect the confidentiality of the session - The server's identity cannot change - The authentication is of the whole handshake from the start, so there's no possibility of some earlier unauthenticated state affecting the rest of the session - You can request multiple authentications and all of them apply to the entire session so far including previous authentications (a property that current TLS is vague about) - No random numbers are needed (at least for RSA certificates) From nobody Thu Jun 19 19:25:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3511F1A04B7 for ; Thu, 19 Jun 2014 19:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTe6ekQvXYD2 for ; Thu, 19 Jun 2014 19:25:26 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id B52111A04A2 for ; Thu, 19 Jun 2014 19:25:26 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F3BB028506; Fri, 20 Jun 2014 02:25:25 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id DEFD02812D; Fri, 20 Jun 2014 02:25:25 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id DA7B12049; Fri, 20 Jun 2014 02:25:25 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Thu, 19 Jun 2014 22:25:25 -0400 From: "Salz, Rich" To: Martin Thomson , "tls@ietf.org" Date: Thu, 19 Jun 2014 22:25:23 -0400 Thread-Topic: [TLS] Renegotiation: trying to summarize Thread-Index: Ac+MEAI6yDRu5Dr6Rba9mUQS0c6wmgAHZQoQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7181E9EA8A8@USMBX1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/am6r2Ro6B1F_eZfwLqBukRjIz6E Subject: Re: [TLS] Renegotiation: trying to summarize X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 02:25:28 -0000 Nice summary. One quibble: > In short, I think that #1 and #2 suggest that there is a potential proble= m if session properties can change; #3 and #4 reject that thesis. I don't see how #3 "rejects that thesis." Actually, looking at your note I= would disagree with all of your characterization. To me, #3 says that cha= nge is a problem, so explicitly start a new session if you want to change t= hings. =20 > Some have suggested that it be phrased in API terms as a new connection, = that the application needs to request a new connection to get the handshake= to happen. In others, this is just a different spin on renegotiation, wit= h a little dead air while everything is changed out. In the latter case, I= don't see how this is any different to retaining renegotiation. The forme= r seems like an optimization of #1. I was thinking that since the TCP(whatever) connecdtion was open, both clie= nt and server would already "know" who was on the other side, and if the re= started connection ended up with different identities (on either side), it = could signal an error to the application. Or, either side MAY send an aler= t if the identity is "unexpected" or different. Maybe that's a SHOULD or ev= en a MUST. Also, for I'd expect that the client could now use the 0RT since= it has the server's DH key. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Thu Jun 19 20:24:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178B11A01A5 for ; Thu, 19 Jun 2014 20:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_56=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fzu9FYHQAtmu for ; Thu, 19 Jun 2014 20:24:54 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E628D1A017F for ; Thu, 19 Jun 2014 20:24:53 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id j17so6616392oag.39 for ; Thu, 19 Jun 2014 20:24:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=2xJcjBgUtBVB4jkE94djYqRWN5kwpLVyTatVppmJ5zw=; b=X2LDgrRyVJ08zb5Ht1PYj1W2kYxRxXnx+xW6JFAuhovJmb3Z3vPlcGMJEu7qbBfSz9 c+WCxO2szxiW+dimVak+ifaRt646x09tlXPI8xbmN+BXabv4o6n/F7kEJYXDUOd95+Nm UXU0iHlD9ugPTlDl0SzuYa7qizgl/v96FxqtxfRqfcrToXHcvX99u/LhJCHcTc+FfFfg BiFhUA5UH+1gFaF3B0aHyrBnlh9jltwmXDrhdH+dTZZAJ2JSR5w8pHn+rcijAyuPsVZk Gg25Bv75weL+FQDg38uG11dUeNZjVCtvyz+kx2E7fCjCbnaVpRSv+p7lVInrle81LcBI kM0g== X-Gm-Message-State: ALoCoQnzvbRlEccjvFuOQPnrnE28pD7WHTwDaCe4JuimS6egugLSwXbxV3J1qaytPXNHn7tAsDb3 MIME-Version: 1.0 X-Received: by 10.60.70.200 with SMTP id o8mr567371oeu.55.1403234693241; Thu, 19 Jun 2014 20:24:53 -0700 (PDT) Sender: colm@allcosts.net Received: by 10.76.20.164 with HTTP; Thu, 19 Jun 2014 20:24:53 -0700 (PDT) Date: Thu, 19 Jun 2014 20:24:53 -0700 X-Google-Sender-Auth: 897zbTZNWgNKAhx2CSkCg0EeFTI Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/A4iVm_yyzrIxcM84YEi3gCV0XSY Subject: [TLS] Short notes on TLS RFCs ... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 03:24:55 -0000 I've recently spent some time reading various TLS RFCs in detail. During the process I found a few points of confusion, or inconsistency with what I could find in general implementations. As I'm new to this, I may be duplicating reports, and I may also be in error. Apologies if so, but it seemed worth sending a note all the same. 1. I don't think RFC5246 actually specifies how DH parameters should be signed. In section 7.4.3 signed_params is defined as "a signature over the server's key exchange parameters" and appendix F (which is non-normative?) described that the parameters are hashed with the hello.random values, but does not say how. RFC4346 does contain a description; but it was not clear to me what should be done in TLS1.2 without reverse engineering it from existing implementations. Again, my apologies if I've missed it - but I can't find a clear instruction on how to sign the parameters in the RFC. I think a future RFC could benefit from a small repair work here and I'd be happy to contribute if that's appropriate. 2. The handling of alert messages is somewhat ambiguous. I think a strict reading of the sections on the record layer imply that alert messages may be fragmented across more than one record, and also that several alerts (and also maybe a partial alert) may be coelesced into a single record. Some experiments with implementations show me that this is inconsistently handled. Because alert messages specify the AlertLevel before the alert code, there is a possibility for ambiguity with the intent of section 7.2. Suppose that a peer send the first byte of an alert message, and that that byte is "2". As the recipient, I know that I have a fatal alert. Should I shut the connection down immediately? Or is the alert message considered incomplete until the entire message is received? If the subsequent record, with the second byte of the alert message also contains other alert messages - what status should I give those? where a peer chooses to indicate several alerts in one record, should it be clear that a fatal alert truncates the alert stream? Is there a reason to support fragmentation/coalescing for alerts at all? 3. The purpose of heartbeat message seems to be a form of path MTU discovery, but they also seem ill-suited to MTU discovery. In particular, Heartbeat messages seem to me capable of only discovering the lowest-MTU supported in both directions of transmission; rather than the actual MTU of the network paths; which can be (and sometimes are) asymmetrical. This may seem very esoteric, but as WANs and transit providers deploy jumbo-frames inconsistently, asymmetrical MTUs are becoming more common. Though hopefully that day will pass. Again, apologies if my notes are duplicative, but figured it was better to report a dupe than to miss something. -- Colm From nobody Thu Jun 19 20:32:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294191A01BA for ; Thu, 19 Jun 2014 20:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_56=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDyXgQurLqn6 for ; Thu, 19 Jun 2014 20:32:46 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1FD1A00B5 for ; Thu, 19 Jun 2014 20:32:46 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id uy5so456700obc.31 for ; Thu, 19 Jun 2014 20:32:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=2xJcjBgUtBVB4jkE94djYqRWN5kwpLVyTatVppmJ5zw=; b=aj+EAuOJ8PV/Z4d1mO5pDRu2XxBdkCRA9A6XbADdjq7Z3Rq1FpeMCpXkckkmPD9JVO wDaoMEt0T69Q0nn3HQYGgqwFYkQS1Ko9Q7/3SAzjpasBfW4M/oxIquX8Lpbo6yPD+QeK 8sWi/wIxFjh450zJZpCWD731g15eKVLykl7t5/8XRXzzuuNtdw90A+xcLt8ZFNpfFj7/ m5YAFgIeVgcAzV8T7/LYcy6Z3Sk50dDyHk4snrMwJtFTGyCUgWb1nt8xol0ZtHv4sMFn EQzYGEnZAQOWdiXRleSmoZ8jMFsEK1yh/u7PlK57QgobH2uJjUCSK/kCGkKSYUD2VkDF +fOw== X-Gm-Message-State: ALoCoQlLF+7OdiXSR6c+ZtUIpcQxl1ruVmFzPytM3mOj10mi6WzVxp6eWg6/jLDhgTmUcMAcFJga MIME-Version: 1.0 X-Received: by 10.60.101.170 with SMTP id fh10mr602878oeb.39.1403235165489; Thu, 19 Jun 2014 20:32:45 -0700 (PDT) Received: by 10.76.20.164 with HTTP; Thu, 19 Jun 2014 20:32:45 -0700 (PDT) Date: Thu, 19 Jun 2014 20:32:45 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WrtthL6ThscMoU99iBwARASMArc Subject: [TLS] Short notes on TLS RFCs ... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 03:32:47 -0000 I've recently spent some time reading various TLS RFCs in detail. During the process I found a few points of confusion, or inconsistency with what I could find in general implementations. As I'm new to this, I may be duplicating reports, and I may also be in error. Apologies if so, but it seemed worth sending a note all the same. 1. I don't think RFC5246 actually specifies how DH parameters should be signed. In section 7.4.3 signed_params is defined as "a signature over the server's key exchange parameters" and appendix F (which is non-normative?) described that the parameters are hashed with the hello.random values, but does not say how. RFC4346 does contain a description; but it was not clear to me what should be done in TLS1.2 without reverse engineering it from existing implementations. Again, my apologies if I've missed it - but I can't find a clear instruction on how to sign the parameters in the RFC. I think a future RFC could benefit from a small repair work here and I'd be happy to contribute if that's appropriate. 2. The handling of alert messages is somewhat ambiguous. I think a strict reading of the sections on the record layer imply that alert messages may be fragmented across more than one record, and also that several alerts (and also maybe a partial alert) may be coelesced into a single record. Some experiments with implementations show me that this is inconsistently handled. Because alert messages specify the AlertLevel before the alert code, there is a possibility for ambiguity with the intent of section 7.2. Suppose that a peer send the first byte of an alert message, and that that byte is "2". As the recipient, I know that I have a fatal alert. Should I shut the connection down immediately? Or is the alert message considered incomplete until the entire message is received? If the subsequent record, with the second byte of the alert message also contains other alert messages - what status should I give those? where a peer chooses to indicate several alerts in one record, should it be clear that a fatal alert truncates the alert stream? Is there a reason to support fragmentation/coalescing for alerts at all? 3. The purpose of heartbeat message seems to be a form of path MTU discovery, but they also seem ill-suited to MTU discovery. In particular, Heartbeat messages seem to me capable of only discovering the lowest-MTU supported in both directions of transmission; rather than the actual MTU of the network paths; which can be (and sometimes are) asymmetrical. This may seem very esoteric, but as WANs and transit providers deploy jumbo-frames inconsistently, asymmetrical MTUs are becoming more common. Though hopefully that day will pass. Again, apologies if my notes are duplicative, but figured it was better to report a dupe than to miss something. -- Colm From nobody Fri Jun 20 00:32:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545D01A00CF for ; Fri, 20 Jun 2014 00:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y30e8M_-cAp for ; Fri, 20 Jun 2014 00:32:14 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.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 B472A1A0065 for ; Fri, 20 Jun 2014 00:32:14 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5K7WB6O007003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Jun 2014 03:32:11 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5K7W8gd016067 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2014 03:32:09 -0400 Message-ID: <1403249527.30440.11.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Martin Thomson Date: Fri, 20 Jun 2014 09:32:07 +0200 In-Reply-To: References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> <1402990596.2335.18.camel@dhcp-2-127.brq.redhat.com> <53A0AB7E.4050706@fifthhorseman.net> <1403173608.5825.6.camel@dhcp-2-127.brq.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lgYhMQ-PDhxDBZPEQs2PLF0nfEs Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 07:32:16 -0000 On Thu, 2014-06-19 at 08:28 -0700, Martin Thomson wrote: > On 19 June 2014 03:26, Nikos Mavrogiannopoulos wrote: > > My counter-proposal would be: > > 1. Removing the Note "If a rehandshake occurs while data is flowing on a > > connection, the communicating parties may continue to send data using > > the old CipherSpec." > > > > 2. Adding the text: "During the handshake process implementations SHALL > > NOT allow application protocol data exchange. Implementations SHALL > > terminate the session if application protocol data is received." (in > > DTLS that data may arrive due to network errors so they should be > > quietly discarded. > > > > 3. Adding the text "Since the authentication credentials may change > > during a renegotiation the upper layers must be notified of either the > > new negotiation process or any identity change." > > > > That would make renegotiation a strictly inband process, and > > applications would be able to distinguish traffic before and after a new > > negotiation. > > That sounds strictly worse than what we have today. > > Points 1&2 render the connection unusable, something that many > applications can't have. Could you elaborate on the applications that will be affected by such change? I've never seen any such applications, and in fact for the 99% of the renegotiation uses (e.g., the web) the renegotiation operation would be identical before and after my proposed change. The only applications that could potentially interleave TLS application and handshake data are TLS-based VPNs, and there aren't any that do that (and they could if they are required to, that's why there is a SHALL NOT there instead of must). The other advantage is the symmetricity of TLS handshake and re-handshake. By allowing application data during the re-handshake one opens the door for allowing application data during the handshake, if an implementer doesn't distinguish the two perfectly symmetric options. > In many respects - other than TCP congestion > window warmup perhaps - this is equivalent to Brian's proposal to > remove renegotiation and replace it with nothing, forcing people to > make new connections. I disagree with this evaluation, as there is no data to back that up. regards, Nikos From nobody Fri Jun 20 04:50:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF01A1B2799 for ; Fri, 20 Jun 2014 04:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.551 X-Spam-Level: X-Spam-Status: No, score=-4.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_b_KFC2TuOc for ; Fri, 20 Jun 2014 04:50:34 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 333D81A0286 for ; Fri, 20 Jun 2014 04:50:34 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 53959285DE; Fri, 20 Jun 2014 11:50:33 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 4C0DE2852B; Fri, 20 Jun 2014 11:50:31 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 4639C80059; Fri, 20 Jun 2014 11:50:31 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Fri, 20 Jun 2014 07:50:30 -0400 From: "Salz, Rich" To: =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= , "tls@ietf.org" Date: Fri, 20 Jun 2014 07:50:29 -0400 Thread-Topic: [TLS] Short notes on TLS RFCs ... Thread-Index: Ac+MOFHa7w1D1jkbSbew71d8J3YxmAAQfTvw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7181E9EA8DF@USMBX1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vZdlLBTEBys5Osa0lCDQxnDAJtM Subject: Re: [TLS] Short notes on TLS RFCs ... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 11:50:36 -0000 Thanks; it is always useful to have a fresh pair of eyes! > I think a future RFC could benefit from a small repair work here and I'd= be happy to contribute if that's appropriate. Yes, particularly if you have suggested wording. > Is there a reason to support fragmentation/coalescing for alerts at all? Not supporting it adds a special case, no? Clarification around multiple alerts at once would be useful. But a fatal a= lert should be the last thing sent. Whether or not you read the whole messa= ge is a quality of implementation issue, I'd think. Heartbeat is dead. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Fri Jun 20 05:15:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448C21A064E for ; Fri, 20 Jun 2014 05:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_56=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RC-JLra0r_P for ; Fri, 20 Jun 2014 05:15:38 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED6EF1A0401 for ; Fri, 20 Jun 2014 05:15:37 -0700 (PDT) Received: from [192.168.1.200] (p508F221E.dip0.t-ipconnect.de [80.143.34.30]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id DDF951C104938; Fri, 20 Jun 2014 14:15:34 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Tuexen In-Reply-To: Date: Fri, 20 Jun 2014 14:15:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5772B9EF-EDD0-4B3E-A85E-43CCEA199D01@lurchi.franken.de> References: To: =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/meuakOI0ui3LukpyCmg-7YsRRiM Cc: "tls@ietf.org" Subject: Re: [TLS] Short notes on TLS RFCs ... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 12:15:40 -0000 On 20 Jun 2014, at 05:32, Colm MacC=E1rthaigh wrote: > I've recently spent some time reading various TLS RFCs in detail. > During the process I found a few points of confusion, or inconsistency > with what I could find in general implementations. As I'm new to this, > I may be duplicating reports, and I may also be in error. Apologies if > so, but it seemed worth sending a note all the same. >=20 > 1. I don't think RFC5246 actually specifies how DH parameters should > be signed. In section 7.4.3 signed_params is defined as "a signature > over the server's key exchange parameters" and appendix F (which is > non-normative?) described that the parameters are hashed with the > hello.random values, but does not say how. >=20 > RFC4346 does contain a description; but it was not clear to me what > should be done in TLS1.2 without reverse engineering it from existing > implementations. >=20 > Again, my apologies if I've missed it - but I can't find a clear > instruction on how to sign the parameters in the RFC. >=20 > I think a future RFC could benefit from a small repair work here and > I'd be happy to contribute if that's appropriate. >=20 > 2. The handling of alert messages is somewhat ambiguous. I think a > strict reading of the sections on the record layer imply that alert > messages may be fragmented across more than one record, and also that > several alerts (and also maybe a partial alert) may be coelesced into > a single record. Some experiments with implementations show me that > this is inconsistently handled. >=20 > Because alert messages specify the AlertLevel before the alert code, > there is a possibility for ambiguity with the intent of section 7.2. > Suppose that a peer send the first byte of an alert message, and that > that byte is "2". As the recipient, I know that I have a fatal alert. > Should I shut the connection down immediately? Or is the alert message > considered incomplete until the entire message is received? If the > subsequent record, with the second byte of the alert message also > contains other alert messages - what status should I give those? where > a peer chooses to indicate several alerts in one record, should it be > clear that a fatal alert truncates the alert stream? >=20 > Is there a reason to support fragmentation/coalescing for alerts at = all? >=20 > 3. The purpose of heartbeat message seems to be a form of path MTU > discovery, but they also seem ill-suited to MTU discovery. In > particular, Heartbeat messages seem to me capable of only discovering > the lowest-MTU supported in both directions of transmission; rather > than the actual MTU of the network paths; which can be (and sometimes > are) asymmetrical. This may seem very esoteric, but as WANs and > transit providers deploy jumbo-frames inconsistently, asymmetrical > MTUs are becoming more common. Though hopefully that day will pass. No, heartbeat messages contain a payload being reflected and a padding being discarded. Therefore you can send your (large) probe packet containing a relatively small payload and a padding to get it to the size you want to test, and just get back a small answer containing the payload (and a small padding). So the padding is there especially for dealing with asymmetric paths. Best regards Michael >=20 > Again, apologies if my notes are duplicative, but figured it was > better to report a dupe than to miss something. >=20 > --=20 > Colm >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Fri Jun 20 05:31:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5EE1B27B0 for ; Fri, 20 Jun 2014 05:31:47 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clnu0inHY76i for ; Fri, 20 Jun 2014 05:31:46 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84251B27A3 for ; Fri, 20 Jun 2014 05:31:45 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id a41so2755937yho.11 for ; Fri, 20 Jun 2014 05:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RxyVTUIhFiKojD+mu+Pi4OmXxZfHstEEccybFrFktf8=; b=zaD9A7OqDXv+tS+ZZ+iFa1PXxgy0R8JucZf73jwxf3H17PxQMUAtvVYxV5Emf4nXNA dRmYsTGQ2LgU20TkPLqXYZ34QsL0xUpIgTmbJ1Yn8qudQslaBZBomKq1Y346GGQxG40y rb3ZdR8FVhuC5WbT7KjgbQ9cqv9+B2zCRXSlPB9EEI+XMPBV1xdDRIEt5feJz7D1mMlN skuoavnGSJwRjOr6M4vLMnaViIvAvRVIXxMijSrfFHFYnzT5SSEUDOyC4W7YMcOPzPMK PqYCQFLyy5FP1DjyoUJ07f6198vc9iabfAZdDxdyiLiCpSndPnyRwXYdCncQIZ4skNtk 2RyQ== MIME-Version: 1.0 X-Received: by 10.236.25.234 with SMTP id z70mr4958126yhz.107.1403267505237; Fri, 20 Jun 2014 05:31:45 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Fri, 20 Jun 2014 05:31:45 -0700 (PDT) In-Reply-To: <5772B9EF-EDD0-4B3E-A85E-43CCEA199D01@lurchi.franken.de> References: <5772B9EF-EDD0-4B3E-A85E-43CCEA199D01@lurchi.franken.de> Date: Fri, 20 Jun 2014 09:31:45 -0300 Message-ID: From: Watson Ladd To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/evfeXSvYJzp-ZPtt30qp9IKE7fs Cc: "tls@ietf.org" Subject: Re: [TLS] Short notes on TLS RFCs ... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 12:31:47 -0000 On Fri, Jun 20, 2014 at 9:15 AM, Michael Tuexen wrote: > On 20 Jun 2014, at 05:32, Colm MacC=C3=A1rthaigh wrot= e: > >> >> 3. The purpose of heartbeat message seems to be a form of path MTU >> discovery, but they also seem ill-suited to MTU discovery. In >> particular, Heartbeat messages seem to me capable of only discovering >> the lowest-MTU supported in both directions of transmission; rather >> than the actual MTU of the network paths; which can be (and sometimes >> are) asymmetrical. This may seem very esoteric, but as WANs and >> transit providers deploy jumbo-frames inconsistently, asymmetrical >> MTUs are becoming more common. Though hopefully that day will pass. > No, heartbeat messages contain a payload being reflected and a padding > being discarded. Therefore you can send your (large) probe packet > containing a relatively small payload and a padding to get it to > the size you want to test, and just get back a small answer containing > the payload (and a small padding). So the padding is there especially > for dealing with asymmetric paths. So Heartbleed is a feature: send a small packet and get a large response for the direction you want to test. Sincerely, Watson Ladd > > Best regards > Michael >> >> Again, apologies if my notes are duplicative, but figured it was >> better to report a dupe than to miss something. >> >> -- >> Colm >> >> _______________________________________________ >> 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 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Jun 20 06:07:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3E71B27D6 for ; Fri, 20 Jun 2014 06:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgTMqAiM9FWB for ; Fri, 20 Jun 2014 06:07:27 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9701D1B27BF for ; Fri, 20 Jun 2014 06:07:10 -0700 (PDT) Received: from [192.168.1.200] (p508F221E.dip0.t-ipconnect.de [80.143.34.30]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 98EF71C104938; Fri, 20 Jun 2014 15:07:07 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Tuexen In-Reply-To: Date: Fri, 20 Jun 2014 15:07:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5772B9EF-EDD0-4B3E-A85E-43CCEA199D01@lurchi.franken.de> To: Watson Ladd X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CHsfQbXb0NlDPDBMAiB9_m2g5hQ Cc: "tls@ietf.org" Subject: Re: [TLS] Short notes on TLS RFCs ... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 13:07:33 -0000 On 20 Jun 2014, at 14:31, Watson Ladd wrote: > On Fri, Jun 20, 2014 at 9:15 AM, Michael Tuexen > wrote: >> On 20 Jun 2014, at 05:32, Colm MacC=E1rthaigh = wrote: >>=20 >>>=20 >>> 3. The purpose of heartbeat message seems to be a form of path MTU >>> discovery, but they also seem ill-suited to MTU discovery. In >>> particular, Heartbeat messages seem to me capable of only = discovering >>> the lowest-MTU supported in both directions of transmission; rather >>> than the actual MTU of the network paths; which can be (and = sometimes >>> are) asymmetrical. This may seem very esoteric, but as WANs and >>> transit providers deploy jumbo-frames inconsistently, asymmetrical >>> MTUs are becoming more common. Though hopefully that day will pass. >> No, heartbeat messages contain a payload being reflected and a = padding >> being discarded. Therefore you can send your (large) probe packet >> containing a relatively small payload and a padding to get it to >> the size you want to test, and just get back a small answer = containing >> the payload (and a small padding). So the padding is there especially >> for dealing with asymmetric paths. >=20 > So Heartbleed is a feature: send a small packet and get a large > response for the direction you want to test. No... You send a large packet (mostly containing padding) and get back a small one (mostly containing the reflected payload)... Best regards Michael >=20 > Sincerely, > Watson Ladd >>=20 >> Best regards >> Michael >>>=20 >>> Again, apologies if my notes are duplicative, but figured it was >>> better to report a dupe than to miss something. >>>=20 >>> -- >>> Colm >>>=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 >=20 >=20 >=20 > --=20 > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin >=20 From nobody Fri Jun 20 06:10:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE351B27DA for ; Fri, 20 Jun 2014 06:10:43 -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, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3a2YDFSjsmu for ; Fri, 20 Jun 2014 06:10:37 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123CA1B27DE for ; Fri, 20 Jun 2014 06:10:23 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id v10so3065186qac.4 for ; Fri, 20 Jun 2014 06:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=aERNWFT4tFqI/B9zDXAn3g7YxM98LCij3ICwBnjB10c=; b=zpNXuhsUayhNjk9rh8uaN4XsQncB9Qex473Pem6UTiQ2XBeBqZof4xHsVEaEujo/5C n/+XkFy11UzrON9KYRLBMmEhoRbslsv1BfRfrg3PjhH037E29QZXsx8u4XviPib4U0Wu qgz45+pc/KJjPs6Qb4tsp8pX+1Rd+RkP9KwXiBD9OqO1aAoKnokOu8SP4MJzSZgM/kQK L0eB1vsoEnfaz1OwzwZ4Kxk7J4nHvnSdKk34nJ8ZXwF7UHtworMFgKVJKbTMy7aNTsER JP76ZIcFHKkV7nQ/2jGiE4mY1q7KkdRWiZO1jO+Nb6SZhidaPqmjnTjarMlLYctvE62z Tc9Q== MIME-Version: 1.0 X-Received: by 10.140.88.241 with SMTP id t104mr4458113qgd.29.1403269823249; Fri, 20 Jun 2014 06:10:23 -0700 (PDT) Received: by 10.140.98.233 with HTTP; Fri, 20 Jun 2014 06:10:23 -0700 (PDT) In-Reply-To: References: <5772B9EF-EDD0-4B3E-A85E-43CCEA199D01@lurchi.franken.de> Date: Fri, 20 Jun 2014 06:10:23 -0700 Message-ID: From: Robert Ransom To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bQC-HLGr0-Y6e51BEK1u0fW9ZQw Cc: "tls@ietf.org" Subject: Re: [TLS] Short notes on TLS RFCs ... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 13:10:43 -0000 On 6/20/14, Michael Tuexen wrote: > On 20 Jun 2014, at 14:31, Watson Ladd wrote: > >> On Fri, Jun 20, 2014 at 9:15 AM, Michael Tuexen >> wrote: >>> On 20 Jun 2014, at 05:32, Colm MacC=C3=A1rthaigh wr= ote: >>> >>>> >>>> 3. The purpose of heartbeat message seems to be a form of path MTU >>>> discovery, but they also seem ill-suited to MTU discovery. In >>>> particular, Heartbeat messages seem to me capable of only discovering >>>> the lowest-MTU supported in both directions of transmission; rather >>>> than the actual MTU of the network paths; which can be (and sometimes >>>> are) asymmetrical. This may seem very esoteric, but as WANs and >>>> transit providers deploy jumbo-frames inconsistently, asymmetrical >>>> MTUs are becoming more common. Though hopefully that day will pass. >>> No, heartbeat messages contain a payload being reflected and a padding >>> being discarded. Therefore you can send your (large) probe packet >>> containing a relatively small payload and a padding to get it to >>> the size you want to test, and just get back a small answer containing >>> the payload (and a small padding). So the padding is there especially >>> for dealing with asymmetric paths. >> >> So Heartbleed is a feature: send a small packet and get a large >> response for the direction you want to test. > No... You send a large packet (mostly containing padding) and get > back a small one (mostly containing the reflected payload)... =E2=80=98Heartbleed=E2=80=99 allowed a party to send a small packet and rec= eive a large reply. Robert Ransom From nobody Fri Jun 20 08:01:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1191B281C for ; Fri, 20 Jun 2014 08:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cc3D2g9_QlMW for ; Fri, 20 Jun 2014 08:01:37 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7516D1B281A for ; Fri, 20 Jun 2014 08:01:37 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id eb12so7376522oac.13 for ; Fri, 20 Jun 2014 08:01:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TM6ZGNv+DLEcX+pwb5eAhSK7TudDY03QA4fqPd0D5sM=; b=ZN1DA3AsnZPNiAaF7/LbMrJe8N4MV0atx5XgZXXTLhVgGdDqDQ3va5V+vrW4WiNNM7 8LtjbLO0cvhh5zMUyHfeoa4MIgkeISh8OKVZpmYEdhoj1k5Rl5Uc8GjDMhfVH73hwn8m 99uG9Kn0wJvjU7iHhj2plugQMF9LwAAlJ516NQLw8z5gNRNnINrCVH/5vHE6L1h9JR2n PgfmzF8Xazh5ZhMaa4Wf7YVsUtT4YZSQH4SjVB0OjZvpaEu2TSJ7nJKEizw3tKH+7D8L YYVn6xZEenHDkZ3zjmLgjxtUe5j9prIgjrgUL6qwKR91dZjfXMtliCW2q8UuyGLww6Lv eCyQ== X-Gm-Message-State: ALoCoQnEkY4HFpJkgFXILDBatyXjNDk5+kFjVnCEMQp+Drxg8Suk4Wp6mWU78KC4atfN6SbO3+eR MIME-Version: 1.0 X-Received: by 10.182.213.100 with SMTP id nr4mr671590obc.39.1403276496896; Fri, 20 Jun 2014 08:01:36 -0700 (PDT) Received: by 10.76.20.164 with HTTP; Fri, 20 Jun 2014 08:01:36 -0700 (PDT) In-Reply-To: References: <5772B9EF-EDD0-4B3E-A85E-43CCEA199D01@lurchi.franken.de> Date: Fri, 20 Jun 2014 08:01:36 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/okwR7aWx17L6Wr_xHmagD-j694E Cc: "tls@ietf.org" Subject: Re: [TLS] Short notes on TLS RFCs ... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 15:01:38 -0000 On Fri, Jun 20, 2014 at 6:07 AM, Michael Tuexen wrote: >> So Heartbleed is a feature: send a small packet and get a large >> response for the direction you want to test. > No... You send a large packet (mostly containing padding) and get > back a small one (mostly containing the reflected payload)... aha, thanks for the correction, that makes more sense. -- Colm From nobody Fri Jun 20 08:53:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4921A03C7 for ; Fri, 20 Jun 2014 08:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fucSgZiglNre for ; Fri, 20 Jun 2014 08:53:02 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28791A038B for ; Fri, 20 Jun 2014 08:53:02 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id eb12so7455652oac.13 for ; Fri, 20 Jun 2014 08:53:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=F4S6ta9HiiNqXkDkxYSx3Wj21qIWj4AoR2QqvMa14A4=; b=h8gT+6imzS23s/H3rm0KRn1pXB/aZ6WwP5vz5Dn+vEUmGX3TLu7pNUyTFuPhlH02kB dUS7fegsK4tg8uqD0RR+qZq16V87V25TmXT29sJph+LsACyloC2Q0gep6TSYhvJrIeDx SmtN+DTFr9sgnT09QzCKQe6uXRIR6ru+Gi7a41rX5shL7FpjJNr/znPBdy94mqlYX//W ze05Tg+ckOtjYhfT6pckIQa10oI5wRNgxveuskrkxpgjlT6AlYX6GtDG+5LfHJu2sR+S AghthSK/g2am6ZXkjtUvW2L2cIeKrSuQe9L64gYv2xvK7bT1ZST8A0CTxjSFasITMdNF 3SwQ== X-Gm-Message-State: ALoCoQlUBhQHBGhCpuBlXIi0qw39kDY3NwLteCQMqGZ7+0E6ffQlUBCtTwBqllXmHXqjW6qfJN1A MIME-Version: 1.0 X-Received: by 10.182.121.170 with SMTP id ll10mr4382386obb.58.1403279582122; Fri, 20 Jun 2014 08:53:02 -0700 (PDT) Received: by 10.76.20.164 with HTTP; Fri, 20 Jun 2014 08:53:02 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7181E9EA8DF@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7181E9EA8DF@USMBX1.msg.corp.akamai.com> Date: Fri, 20 Jun 2014 08:53:02 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/N2KGw4TH0Gfo4ljEMo94ulUgZWw Cc: "tls@ietf.org" Subject: Re: [TLS] Short notes on TLS RFCs ... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 15:53:03 -0000 On Fri, Jun 20, 2014 at 4:50 AM, Salz, Rich wrote: > Thanks; it is always useful to have a fresh pair of eyes! > >> I think a future RFC could benefit from a small repair work here and I'd be happy to contribute if that's appropriate. > > Yes, particularly if you have suggested wording. Thanks for the encouragement, I have made the following suggested change via a pull request; https://github.com/tlswg/tls13-spec/pull/46 Hopefully it can be considered an editorial change and non-controversial. -- Colm From nobody Fri Jun 20 09:21:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08AE1B2860 for ; Fri, 20 Jun 2014 09:21: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-mbcQGYN6_T for ; Fri, 20 Jun 2014 09:21:40 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D425C1B2858 for ; Fri, 20 Jun 2014 09:21:39 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so1112224wib.7 for ; Fri, 20 Jun 2014 09:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dF99EpO0aL/h94ce3NSnwV+qJ/tCwnF2O/4qLOELpeo=; b=PiUT4r4USmDIVdKcJgWes04MeWYJZ4r9ez9QFdoKu4BZ07XovetqmQ9I2eoR9/WFDI 83uNFVCzrrWa0aZpj0tbwcYdmWO+Ac9Jzg4IubnKeA/9mCx6OLqzAgzZ8HFIb2wG/mAm 1GMe50vBkJMJq2XFS+Ac8MpjsFm0zbGVjiGRdiXM13ptN4Ie9wk6DuuJpbv+Cs3bHvpy /ub6Ygy0WpOVkuXzSyWenMPwv2zlOQt9pAHJkE/aRqVrSuUGH6roy9a4ZWs6OKlxzgtT Dvf0CDUI9o+Ano3N6tDYsXdyecRQt5Auubhx9o0v6yF7oCSVYE124jB5Op/AAwvOXPpW 2gkA== MIME-Version: 1.0 X-Received: by 10.180.19.233 with SMTP id i9mr5440559wie.38.1403281298348; Fri, 20 Jun 2014 09:21:38 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Fri, 20 Jun 2014 09:21:38 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7181E9EA8A8@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7181E9EA8A8@USMBX1.msg.corp.akamai.com> Date: Fri, 20 Jun 2014 09:21:38 -0700 Message-ID: From: Martin Thomson To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5R5WdDg_sVw7i81LBzD8MmPx20Q Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation: trying to summarize X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 16:21:41 -0000 On 19 June 2014 19:25, Salz, Rich wrote: > I don't see how #3 "rejects that thesis." Actually, looking at your note= I would disagree with all of your characterization. To me, #3 says that c= hange is a problem, so explicitly start a new session if you want to change= things. > >> Some have suggested that it be phrased in API terms as a new connection,= that the application needs to request a new connection to get the handshak= e to happen. In others, this is just a different spin on renegotiation, wi= th a little dead air while everything is changed out. In the latter case, = I don't see how this is any different to retaining renegotiation. The form= er seems like an optimization of #1. > > I was thinking that since the TCP(whatever) connecdtion was open, both cl= ient and server would already "know" who was on the other side, and if the = restarted connection ended up with different identities (on either side), i= t could signal an error to the application. Or, either side MAY send an al= ert if the identity is "unexpected" or different. Maybe that's a SHOULD or = even a MUST. Also, for I'd expect that the client could now use the 0RT sin= ce it has the server's DH key. That's detail that wasn't clear. So the idea is that only some properties would be effectively immutable, and that immutability is enforced by the stack. Identity seems like an obvious candidate for immutability, but that would prevent the spontaneous client authentication use case. We'd need careful rules around what can change, what requires an alert, and what causes the connection to abort. I'll note that 0RTT could reduce the amount of dead air, but not entirely eliminate it. Server initiated restarts (as opposed to renegotiation) would lose time if they had to stop sending at that point. And for clients, we currently have a limitation with the 0RTT handshake in that the first flight of data needs to be entirely contained in the encrypted ClientHello extension. You can't trickle data out without risking an explosion from non-1.3 servers. Obviously, you know that the server talks 1.3, so maybe we can have different logic here to allow for regular data to flow... You see where I'm going? From nobody Fri Jun 20 09:43:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9387B1A0298 for ; Fri, 20 Jun 2014 09:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boWc1sXKrYXh for ; Fri, 20 Jun 2014 09:43:40 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0C11A03D6 for ; Fri, 20 Jun 2014 09:43:40 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id cc10so1141206wib.12 for ; Fri, 20 Jun 2014 09:43:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MyGXcYKyb2vqVJUtq4SJN/khWINCtUmP+ot26iqh8qQ=; b=kAuzGrlOsdwwX4Rb14cDalAO4DeAtFba2KHOh29TW619jDIhNgKnGOmnhhgxoZJvsP wsgxUXXXlU5uLnHj+8pxI2K1pxGe2z/SiyjUPHs7zpE5Iv0NwY2WGfhr1xxFRjew2lsj xpJ4RIiFQBXFaheeRkKpPHkkr5pWuiH6HEEy7nozmJ02iWDyG8kHHXgyP2LfaPBy4J18 gfpW6go8D8i9rzQpPgn5NH5Q9SE/cTcKP2m8AhF50nxlz244h5EZvb2Ip0HJfZUIhpSV FiIdQK4LgEIbRo/DZz+2Y8CTCg1A/VH1zh8O57eYCRW05YFabrZ0IlBkTuqMJplLaB/u hJ3w== X-Gm-Message-State: ALoCoQmy714E7RwBZXGIqgmz4s8UrsFIFPzqVtdELCZyMzwZHkzG3pdGEeR+KOrLyL2emShLoDKn X-Received: by 10.194.110.10 with SMTP id hw10mr5871509wjb.81.1403282619024; Fri, 20 Jun 2014 09:43:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Fri, 20 Jun 2014 09:42:58 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:7437:1051:6a18:da2] In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7181E9EA8DF@USMBX1.msg.corp.akamai.com> From: Eric Rescorla Date: Fri, 20 Jun 2014 09:42:58 -0700 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: multipart/alternative; boundary=089e010d870c06e72c04fc4732e4 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_IrA4_dtq5zMyNnQilbxd-X408o Cc: "tls@ietf.org" Subject: Re: [TLS] Short notes on TLS RFCs ... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 16:43:41 -0000 --089e010d870c06e72c04fc4732e4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The draft has been updated. Thanks! -Ekr On Fri, Jun 20, 2014 at 8:53 AM, Colm MacC=C3=A1rthaigh wrote: > On Fri, Jun 20, 2014 at 4:50 AM, Salz, Rich wrote: > > Thanks; it is always useful to have a fresh pair of eyes! > > > >> I think a future RFC could benefit from a small repair work here and > I'd be happy to contribute if that's appropriate. > > > > Yes, particularly if you have suggested wording. > > Thanks for the encouragement, I have made the following suggested > change via a pull request; > > https://github.com/tlswg/tls13-spec/pull/46 > > Hopefully it can be considered an editorial change and non-controversial. > > -- > Colm > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e010d870c06e72c04fc4732e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The draft has been updated.

Thanks!
=

-Ekr



On Fri, Jun 20, 2014 at 8:53 AM= , Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
On Fri, Jun 20, 2014 at 4:50= AM, Salz, Rich <rsalz@akamai.com> wrote:
> Thanks; it is always useful to have a fresh pair of eyes!
>
>> =C2=A0I think a future RFC could benefit from a small repair work = here and I'd be happy to contribute if that's appropriate.
>
> Yes, particularly if you have suggested wording.

Thanks for the encouragement, I have made the following suggested
change via a pull request;

h= ttps://github.com/tlswg/tls13-spec/pull/46

Hopefully it can be considered an editorial change and non-controversial.
--
Colm

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

--089e010d870c06e72c04fc4732e4-- From nobody Fri Jun 20 09:50:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764C91A03DF for ; Fri, 20 Jun 2014 09:50: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BA8dXpuY706 for ; Fri, 20 Jun 2014 09:50:39 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D553B1A03E1 for ; Fri, 20 Jun 2014 09:50:38 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so3995978wes.21 for ; Fri, 20 Jun 2014 09:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9ffDZpFIxN5gQ1In7+MHnj3HRj4bzA+pryty93QBbmM=; b=FCdUm0r/jxn0QcUE8MNbmaP9jAWTdPPGXqWaZuo9RXmVvHV1yFSF3q0M3F23bmpMc/ V9rkVSNWa+AysjjIc+ApKaYJLSysljqnVWGFBHTP6y4uU35be07jKp4xYE1xsTGukmhW kRU/HSAeNs4wD37cbi7dnBxz7ju2ue7M5INfIEfFFRScESpoL1Y/EHrdF3ETFezciOeS wBlNMU44kLwv+TxaG0gdI75j5AMS9o0zwMbDB5NeLQziyTgcdg445Ht2315HNiNF6wAA Rt4e9iOHnk+p01yqgzpSt+kLvXBx8oNf1JgvQKdJvAVrSythzluzOIH3KZz2bITMFlwD aCNw== MIME-Version: 1.0 X-Received: by 10.180.74.131 with SMTP id t3mr5497481wiv.23.1403283037460; Fri, 20 Jun 2014 09:50:37 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Fri, 20 Jun 2014 09:50:37 -0700 (PDT) In-Reply-To: <1403249527.30440.11.camel@dhcp-2-127.brq.redhat.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> <1402990596.2335.18.camel@dhcp-2-127.brq.redhat.com> <53A0AB7E.4050706@fifthhorseman.net> <1403173608.5825.6.camel@dhcp-2-127.brq.redhat.com> <1403249527.30440.11.camel@dhcp-2-127.brq.redhat.com> Date: Fri, 20 Jun 2014 09:50:37 -0700 Message-ID: From: Martin Thomson To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Xk2Jen7I-uIeTTgZVrYIFOjxPI4 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 16:50:40 -0000 On 20 June 2014 00:32, Nikos Mavrogiannopoulos wrote: > Could you elaborate on the applications that will be affected by such > change? I've never seen any such applications, and in fact for the 99% > of the renegotiation uses (e.g., the web) the renegotiation operation > would be identical before and after my proposed change. I'm concerned about applications that rely on renegotiation for rekeying purposes, not the web scenarios. For instance, those small number of F5 users that have set a renegotiation timer (see David's email earlier in the thread). From nobody Fri Jun 20 11:12:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F191B289B for ; Fri, 20 Jun 2014 11:12:28 -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_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h97psPezjX3I for ; Fri, 20 Jun 2014 11:12:25 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 793E11A02B2 for ; Fri, 20 Jun 2014 11:12:14 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id DC617F984 for ; Fri, 20 Jun 2014 14:12:11 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 7C96F1FF69; Fri, 20 Jun 2014 14:12:02 -0400 (EDT) From: Daniel Kahn Gillmor To: IETF TLS Working Group User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Fri, 20 Jun 2014 14:11:58 -0400 Message-ID: <87k38bzc0h.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XLmFWE3dOdnvM1oZ2AxIUsS3OrU Subject: [TLS] On the possibility of AEAD modes that require padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 18:12:28 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable hi IETF folks-- If an AEAD mode is ever defined that must pad its input to a blocksize before encrypting, the current spec seems like it will break. This is a currently-theoretical concern, since (fixed authentication tag notwithstanding) GCM does not pad its input, and OCB and chacha20-poly1305 (and other AEAD modes i could find data on) also don't pad their input. (note that this question is independent of the various proposals for explicitly introducing padding into TLS, which i don't go into here) The 1.3 draft currently says: > The additional authenticated data, which we denote as additional_data, is > defined as follows: >=20 > additional_data =3D seq_num + TLSPlaintext.type + > TLSPlaintext.version + TLSPlaintext.length; >=20 > where "+" denotes concatenation. >=20 > The aead_output consists of the ciphertext output by the AEAD encryption > operation. The length will generally be larger than TLSPlaintext.length, = but > by an amount that varies with the AEAD cipher. Since the ciphers might > incorporate padding, the amount of overhead could vary with different > TLSPlaintext.length values. Each AEAD cipher MUST NOT produce an expansio= n of > greater than 1024 bytes. It goes on to define AEAD-Decrypt this way: > TLSPlaintext.fragment =3D AEAD-Decrypt(write_key, nonce, > AEADEncrypted, > additional_data) Consider the decryption step. The decryptor knows: * the AEAD mode (including the taglength) * the nonce * the write key * the sequence number * the record type * the TLS version * the ciphertext (including its length) To create additional_data, it must be able to derive TLSPlaintext.length From=20the above information. All the AEAD modes i know about have a ciphertext expansion of a fixed-length tag. so: TLSPlaintext.length =3D TLSCiphertext.length - AEADmode.taglength But if an AEAD mode were to additionally pad its input ("Since the ciphers might incorporate padding, the amount of overhead could vary with different TLSPlaintext.length values"), there would be no clear way to derive additional_data because the length of the plaintext is unknown before doing the decryption. So i think the fix is to specify that additional_data should be derived From=20the padded length of the TLSPlaintext.fragment, not from TLSPlaintext.length. For GCM (and other AEAD modes i know of) these values are of course identical. Making this explicit seems like it would require a bit of gymnastics in the spec, all for the sake of holding open the door for future modes with variable-length ciphertext expansion. I can try to make a patch for this change, but i want to know if we think it's necessary. Alternately, we could decide that we won't accept modes that require this kind of padding (maybe stripping out the sentence about "might incorporate padding"). Have i missed an obvious solution or misunderstood the situation? What do people think we should do here? --dkg --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJTpHluXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc9mkQAMeptWS90naj2rK9QU2ulU5g nSYE8BIdtVrZ02yCSpxgiYL+MlzNJ78oEpm6DRWqRKf035LJje0zmPAI7hW0kYSd 1asbIfdLzqypUT2dwQMfeglRwMMt2N6ip+1sIhHyIN1qF49tJ3MxpntQYVxcx93S lrRnKo6mjFWfRuQNlco2D25zt13E090FFSrZsDrm1csAWRO/LVCWuoyIuol0GAdc M1jNJXjJLzjlIYc6QLQa3tWGVwXaUNQzUrM2MQ/7VhWWnM646dBDA9ahDdR9Dfex Grv2/fKOPca6NtV1ECW0LsJ8Miay3EAGo9KgzUCy8noUADSWXD44dDO1wNLCCGbv pQl1HT/vjF/VdBBFceQ6X/3vo16fuP/N6QCJsapxRx8EDaV+PzD1K1bi1BOC5fej jDvxXUb8kZSj1ZSrbFMzMg3FCMhBp5kAou4WamHQTut2y78sZnz1+3LaY5bsNXzC sl0liEgyJs3b3azzdUomz4VGFpAfe/oDTwZaF2u4p7HUZg1BjEgAg0yOyTI5h98k vBv7Aq5j7ULumScLhWX1bxtHtI4jy+SHCcj48oSuwWf3bel4+O3IJXhRVT+y8Ddl +B13nest0X/t46DZBzOyKQlwZCjQvTH4o9gjClqIohtH3PqTmiNHzeUeG5jaR38G FSnD9S40RJLSODng5D1t =5Zd3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 20 11:24:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520831B28C9 for ; Fri, 20 Jun 2014 11:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsvTTd4fTy4M for ; Fri, 20 Jun 2014 11:24:36 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59691B28C2 for ; Fri, 20 Jun 2014 11:23:40 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id s7so2623342lbd.32 for ; Fri, 20 Jun 2014 11:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UkQLBsm6m1U8NemTplOScqYGUc5pNDism8eQ55H0/2g=; b=ZHZPOlWrOPsqWsbqcaGfbC71ST483HAzfesk0DD8/kUvRXGbSurXoD/oJNoq+HrxVX 5w2oOTZlVT/10Hjt7tnx3Qpe2VDjatJKOJlUIJAWK0L95czFviIpFdfVg/VY1GXRPaj0 6Kyk97l8A4GTHHCRlQohqv9FQHJ6aXgco3sI6/Zp4cP0YnZmNcl4yXiC3gEnEgO74yiK MDA0EHJoIJsR/XGIzrjCoX/fY1yXe7mrqHSfg3J94gF9IjDhs7wuuZE3BBfxwmamJ6W/ wwiFDZXXWcxKWjf6UYiEjZIwGBmi7AvDSu2DQgpcJ1vm8DvddoWbasurDBoYiSyz39dd tD1Q== MIME-Version: 1.0 X-Received: by 10.112.142.33 with SMTP id rt1mr3443051lbb.45.1403288618753; Fri, 20 Jun 2014 11:23:38 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.5.68 with HTTP; Fri, 20 Jun 2014 11:23:38 -0700 (PDT) In-Reply-To: <87k38bzc0h.fsf@alice.fifthhorseman.net> References: <87k38bzc0h.fsf@alice.fifthhorseman.net> Date: Fri, 20 Jun 2014 11:23:38 -0700 X-Google-Sender-Auth: TR-PwbeUhHY8diIIueg48zy5W84 Message-ID: From: Adam Langley To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JrwtTU3xwgcjfK2QCczgMliTHps Cc: IETF TLS Working Group Subject: Re: [TLS] On the possibility of AEAD modes that require padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 18:24:37 -0000 On Fri, Jun 20, 2014 at 11:11 AM, Daniel Kahn Gillmor wrote: > So i think the fix is to specify that additional_data should be derived > From the padded length of the TLSPlaintext.fragment, not from > TLSPlaintext.length. For GCM (and other AEAD modes i know of) these > values are of course identical. This would mean that padding would, conceptually, be done outside of the AEAD, right? Otherwise the AEAD interface suffers: the caller would have to be able to query the "padded length" of a plaintext length in order to update the AD. Neither is very attractive. I would suggest that, if a padded AEAD is added to TLS, then the length bytes in the AD be set to zero. That seems to be the least bad option to me. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Fri Jun 20 11:25:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB9F1B28E7 for ; Fri, 20 Jun 2014 11:25:23 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TswS99YxfusZ for ; Fri, 20 Jun 2014 11:25:18 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E0A1B28CF for ; Fri, 20 Jun 2014 11:23:59 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id i57so3184878yha.1 for ; Fri, 20 Jun 2014 11:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PGTIUyH+LGyCIhZ29++pmHSNkqlvZBNdgehU1WnmkL8=; b=puLuXPYL9ELcZy1EWsYKsFFym1MRDa7xVSlEI3+xN6Jd7TXBM4xPNjGd1vJUWNtHY5 SP4wcgPUAyzpiZZ0o2WhW7+ftMR2rw2+PQ/WxnE3c7T1pP6K98lDjN1Da69W9Z8aqyu9 fyqGoYi9+ofLOo5yw/i8jFYwLN7oTh1u9nDhymHA/Ia3nFUqefRya/lkeawFEbwZpW+v SIMPxq6LOI5ntOeNSyo59B2wFNSopdopvYcZy4BPXtdyNc3f9EwEw6X5njOhnsv9XEtY xql81OBuDdfPIPLNyVvT9H5vNdoVZg8oUJlQkzdVwSIBYavyWa4aXB4H5hAyiSNuH3PC MIiA== MIME-Version: 1.0 X-Received: by 10.236.15.133 with SMTP id f5mr7676085yhf.63.1403288638363; Fri, 20 Jun 2014 11:23:58 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Fri, 20 Jun 2014 11:23:58 -0700 (PDT) In-Reply-To: <87k38bzc0h.fsf@alice.fifthhorseman.net> References: <87k38bzc0h.fsf@alice.fifthhorseman.net> Date: Fri, 20 Jun 2014 15:23:58 -0300 Message-ID: From: Watson Ladd To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pZmJaSJbKDozDSRCs-kbiwOd_B4 Cc: IETF TLS Working Group Subject: Re: [TLS] On the possibility of AEAD modes that require padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 18:25:23 -0000 On Fri, Jun 20, 2014 at 3:11 PM, Daniel Kahn Gillmor wrote: > hi IETF folks-- > > If an AEAD mode is ever defined that must pad its input to a blocksize > before encrypting, the current spec seems like it will break. > > This is a currently-theoretical concern, since (fixed authentication tag > notwithstanding) GCM does not pad its input, and OCB and > chacha20-poly1305 (and other AEAD modes i could find data on) also don't > pad their input. > > (note that this question is independent of the various proposals for > explicitly introducing padding into TLS, which i don't go into here) > > The 1.3 draft currently says: > >> The additional authenticated data, which we denote as additional_data, is >> defined as follows: >> >> additional_data = seq_num + TLSPlaintext.type + >> TLSPlaintext.version + TLSPlaintext.length; >> >> where "+" denotes concatenation. >> >> The aead_output consists of the ciphertext output by the AEAD encryption >> operation. The length will generally be larger than TLSPlaintext.length, but >> by an amount that varies with the AEAD cipher. Since the ciphers might >> incorporate padding, the amount of overhead could vary with different >> TLSPlaintext.length values. Each AEAD cipher MUST NOT produce an expansion of >> greater than 1024 bytes. > > It goes on to define AEAD-Decrypt this way: > >> TLSPlaintext.fragment = AEAD-Decrypt(write_key, nonce, >> AEADEncrypted, >> additional_data) > > Consider the decryption step. The decryptor knows: > > * the AEAD mode (including the taglength) > * the nonce > * the write key > * the sequence number > * the record type > * the TLS version > * the ciphertext (including its length) > > To create additional_data, it must be able to derive TLSPlaintext.length > From the above information. > > All the AEAD modes i know about have a ciphertext expansion of a > fixed-length tag. so: > > TLSPlaintext.length = TLSCiphertext.length - AEADmode.taglength > > But if an AEAD mode were to additionally pad its input ("Since the > ciphers might incorporate padding, the amount of overhead could vary > with different TLSPlaintext.length values"), there would be no clear way > to derive additional_data because the length of the plaintext is unknown > before doing the decryption. This is just a straight-up mistake: AEAD modes already protect the plaintext length without explicitly supplying it in the form of AAD. Omitting it solves the problem. > > So i think the fix is to specify that additional_data should be derived > From the padded length of the TLSPlaintext.fragment, not from > TLSPlaintext.length. For GCM (and other AEAD modes i know of) these > values are of course identical. > > Making this explicit seems like it would require a bit of gymnastics in > the spec, all for the sake of holding open the door for future modes > with variable-length ciphertext expansion. I can try to make a patch > for this change, but i want to know if we think it's necessary. > > Alternately, we could decide that we won't accept modes that require > this kind of padding (maybe stripping out the sentence about "might > incorporate padding"). > > Have i missed an obvious solution or misunderstood the situation? What > do people think we should do here? > > --dkg > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Jun 20 11:30:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0FC1B28A3 for ; Fri, 20 Jun 2014 11:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-jeRoAKraSc for ; Fri, 20 Jun 2014 11:30:28 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B27B1B28A6 for ; Fri, 20 Jun 2014 11:30:27 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so1276309wiv.2 for ; Fri, 20 Jun 2014 11:30:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SlF5hfNtBsOZYJzes9QlXji9Akx2KhUUyO6YSkFiQH0=; b=SYFuYo9udz9YQlFodhPEsuRhXvPlxsKI+pqgKkK1n+xB2sdKAYn6Ws7MFEesGYNGgo pI360XPO1OhlTKHlx+J9CTPrhLh7Jd3T16sNLA0D6Yiplb5gxh9wY6cJo4Yi/Zue9MRP wnHAoA1St1fXQkwTlu+Lyi6HwSAJTsG0UX7EvKE+umcXi5lpIZCwyZvv3QGUKpxd7rw+ BNL+bWyeaO9lZludwI6EufHvaRy1WYY33Gii7WhTGDemGp5l8gPlJn/M1Ur0p8MYfhe1 JU6RLTeE+yyYdmXDSo1Qg8b8jC2kl3AZrDVrI6XBHjaisNz8ZYaDvxrIKmzhahXIa80L s2gw== X-Gm-Message-State: ALoCoQmJccSVhxeCm0X0AslvwSzJxBxSyA/8hkWEcOkZowBlfAgaMS8f/RyhrPqBUqx24Kb37Hah X-Received: by 10.194.87.200 with SMTP id ba8mr6551241wjb.28.1403289025962; Fri, 20 Jun 2014 11:30:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Fri, 20 Jun 2014 11:29:45 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:682a:acf8:fd1d:56ee] In-Reply-To: <87k38bzc0h.fsf@alice.fifthhorseman.net> References: <87k38bzc0h.fsf@alice.fifthhorseman.net> From: Eric Rescorla Date: Fri, 20 Jun 2014 11:29:45 -0700 Message-ID: To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=089e010d8afee90f4404fc48af76 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gAe2QTnQvSVP9PDc7rY7QG-ilvw Cc: IETF TLS Working Group Subject: Re: [TLS] On the possibility of AEAD modes that require padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 18:30:35 -0000 --089e010d8afee90f4404fc48af76 Content-Type: text/plain; charset=UTF-8 Daniel, Thanks for your post: You're right that this is an issue (which has been raised by several people in the past). The two solutions seem to be: - As you propose, compute the integrity tag over the padded length. - Simply remove the length field from the additional_data on the theory that the AEAD mode itself must verify the length (or as AGL proposed a few minutes ago, set it to 0 for any modes which pad) If we decide to take the second direction, we might remove the length for any AEAD algorithms which take padding in TLS 1.2 and then remove the length for all AEAD algorithms in TLS 1.3. I have created a github issue to track this: https://github.com/tlswg/tls13-spec/issues/47 -Ekr On Fri, Jun 20, 2014 at 11:11 AM, Daniel Kahn Gillmor wrote: > hi IETF folks-- > > If an AEAD mode is ever defined that must pad its input to a blocksize > before encrypting, the current spec seems like it will break. > > This is a currently-theoretical concern, since (fixed authentication tag > notwithstanding) GCM does not pad its input, and OCB and > chacha20-poly1305 (and other AEAD modes i could find data on) also don't > pad their input. > > (note that this question is independent of the various proposals for > explicitly introducing padding into TLS, which i don't go into here) > > The 1.3 draft currently says: > > > The additional authenticated data, which we denote as additional_data, is > > defined as follows: > > > > additional_data = seq_num + TLSPlaintext.type + > > TLSPlaintext.version + TLSPlaintext.length; > > > > where "+" denotes concatenation. > > > > The aead_output consists of the ciphertext output by the AEAD encryption > > operation. The length will generally be larger than TLSPlaintext.length, > but > > by an amount that varies with the AEAD cipher. Since the ciphers might > > incorporate padding, the amount of overhead could vary with different > > TLSPlaintext.length values. Each AEAD cipher MUST NOT produce an > expansion of > > greater than 1024 bytes. > > It goes on to define AEAD-Decrypt this way: > > > TLSPlaintext.fragment = AEAD-Decrypt(write_key, nonce, > > AEADEncrypted, > > additional_data) > > Consider the decryption step. The decryptor knows: > > * the AEAD mode (including the taglength) > * the nonce > * the write key > * the sequence number > * the record type > * the TLS version > * the ciphertext (including its length) > > To create additional_data, it must be able to derive TLSPlaintext.length > From the above information. > > All the AEAD modes i know about have a ciphertext expansion of a > fixed-length tag. so: > > TLSPlaintext.length = TLSCiphertext.length - AEADmode.taglength > > But if an AEAD mode were to additionally pad its input ("Since the > ciphers might incorporate padding, the amount of overhead could vary > with different TLSPlaintext.length values"), there would be no clear way > to derive additional_data because the length of the plaintext is unknown > before doing the decryption. > > So i think the fix is to specify that additional_data should be derived > From the padded length of the TLSPlaintext.fragment, not from > TLSPlaintext.length. For GCM (and other AEAD modes i know of) these > values are of course identical. > > Making this explicit seems like it would require a bit of gymnastics in > the spec, all for the sake of holding open the door for future modes > with variable-length ciphertext expansion. I can try to make a patch > for this change, but i want to know if we think it's necessary. > > Alternately, we could decide that we won't accept modes that require > this kind of padding (maybe stripping out the sentence about "might > incorporate padding"). > > Have i missed an obvious solution or misunderstood the situation? What > do people think we should do here? > > --dkg > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e010d8afee90f4404fc48af76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Daniel,

Thanks for your post:

You're right that this is an issue (which has been rais= ed by several people
in the past). The two solutions seem to be:<= /div>

- As you propose, compute the integrity tag over the padded length.

- Simply remove the length field from the additional= _data on the theory
that the AEAD mode itself must verify the len= gth (or as AGL proposed
a few minutes ago, set it to 0 for any modes which pad)

=
If we decide to take the second direction, we might remove the l= ength
for any AEAD algorithms which take padding in TLS 1.2 and t= hen remove
the length for all AEAD algorithms in TLS 1.3.

I have created a github issue to track this:

-Ekr


On Fri, Jun 20, 2014 at 11:11 AM= , Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
hi IETF folks--

If an AEAD mode is ever defined that must pad its input to a blocksize
before encrypting, the current spec seems like it will break.

This is a currently-theoretical concern, since (fixed authentication tag notwithstanding) GCM does not pad its input, and OCB and
chacha20-poly1305 (and other AEAD modes i could find data on) also don'= t
pad their input.

(note that this question is independent of the various proposals for
explicitly introducing padding into TLS, which i don't go into here)
The 1.3 draft currently says:

> The additional authenticated data, which we denote as additional_data,= is
> defined as follows:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0additional_data =3D seq_num + TLSPlaintext.= type +
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0TLSPlaintext.version + TLSPlaintext.length;
>
> where "+" denotes concatenation.
>
> The aead_output consists of the ciphertext output by the AEAD encrypti= on
> operation. The length will generally be larger than TLSPlaintext.lengt= h, but
> by an amount that varies with the AEAD cipher. Since the ciphers might=
> incorporate padding, the amount of overhead could vary with different<= br> > TLSPlaintext.length values. Each AEAD cipher MUST NOT produce an expan= sion of
> greater than 1024 bytes.

It goes on to define AEAD-Decrypt this way:

> =C2=A0 =C2=A0 =C2=A0 TLSPlaintext.fragment =3D AEAD-Decrypt(write_key,= nonce,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0AEADEncrypted,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0additional_data)

Consider the decryption step. =C2=A0The decryptor knows:

=C2=A0* the AEAD mode (including the taglength)
=C2=A0* the nonce
=C2=A0* the write key
=C2=A0* the sequence number
=C2=A0* the record type
=C2=A0* the TLS version
=C2=A0* the ciphertext (including its length)

To create additional_data, it must be able to derive TLSPlaintext.length >From the above information.

All the AEAD modes i know about have a ciphertext expansion of a
fixed-length tag. =C2=A0so:

=C2=A0TLSPlaintext.length =3D TLSCiphertext.length - AEADmode.taglength

But if an AEAD mode were to additionally pad its input ("Since the
ciphers might incorporate padding, the amount of overhead could vary
with different TLSPlaintext.length values"), there would be no clear w= ay
to derive additional_data because the length of the plaintext is unknown before doing the decryption.

So i think the fix is to specify that additional_data should be derived
>From the padded length of the TLSPlaintext.fragment, not from
TLSPlaintext.length. =C2=A0For GCM (and other AEAD modes i know of) these values are of course identical.

Making this explicit seems like it would require a bit of gymnastics in
the spec, all for the sake of holding open the door for future modes
with variable-length ciphertext expansion. =C2=A0I can try to make a patch<= br> for this change, but i want to know if we think it's necessary.

Alternately, we could decide that we won't accept modes that require this kind of padding (maybe stripping out the sentence about "might incorporate padding").

Have i missed an obvious solution or misunderstood the situation? =C2=A0Wha= t
do people think we should do here?

=C2=A0 =C2=A0 =C2=A0--dkg

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


--089e010d8afee90f4404fc48af76-- From nobody Fri Jun 20 11:57:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080891B28BA for ; Fri, 20 Jun 2014 11:57: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhMaphz6abyw for ; Fri, 20 Jun 2014 11:57:01 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3535D1B28B9 for ; Fri, 20 Jun 2014 11:57:01 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 8BB51F984 for ; Fri, 20 Jun 2014 14:56:58 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id E58BC201CF; Fri, 20 Jun 2014 14:56:49 -0400 (EDT) From: Daniel Kahn Gillmor To: IETF TLS Working Group In-Reply-To: References: <87k38bzc0h.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Fri, 20 Jun 2014 14:56:49 -0400 Message-ID: <87egyjz9xq.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-pNn0rRdtE55dF3TEiVXrevtHE4 Subject: Re: [TLS] On the possibility of AEAD modes that require padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 18:57:03 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri 2014-06-20 14:29:45 -0400, Eric Rescorla wrote: > - Simply remove the length field from the additional_data on the theory > that the AEAD mode itself must verify the length Does anyone object to this approach for TLS 1.3? An AEAD that does not verify the length seems like it would be problematic in other ways, and this seems like a nice simplifying approach. diff --git a/draft-ietf-tls-tls13.md b/draft-ietf-tls-tls13.md index d9ace55..cda3dbf 100644 =2D-- a/draft-ietf-tls-tls13.md +++ b/draft-ietf-tls-tls13.md @@ -1016,7 +1016,7 @@ The additional authenticated data, which we denote as= additional_data, is defined as follows: =20 additional_data =3D seq_num + TLSPlaintext.type + =2D TLSPlaintext.version + TLSPlaintext.length; + TLSPlaintext.version; =20 where "+" denotes concatenation. =20 I don't know whether folks think this warrants an entry in the "Major Differences from TLS 1.2" section. It's a small change, but it would be a significant one for implementers who missed it. I don't know that we even need to bother with it for TLS 1.2, unless someone wants to add a new padded AEAD mode to TLS 1.2 separately. --dkg --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJTpIPxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcItAP/i0L0xBNUWv2oHMWbhytxHa0 KOkaOBjuSqGWsy7GPTkTq8xOVR82aPYo3rc+opuIVVdUY1L9e5RaabrFi9pczvKr ehKFRPk5mDB6NvBwXIbYMcJ2iY6DLrwG+5wZ2wTTf240zYeaaq54ujQlAlr4tVtE GO4jAWMsMDBxBGnvbpNYFdC9XgFwxRcsNG/NRW9kgRWobl1ZTsBhtUtvo5NOkaDi MyxGpKH0H5HrHjg9TIPHBLxvkjY9MtBbbeTd1dfI6s52y9AkaciFLsDITDikTRCt ulMVYu72kanspmSmaGoyTNVesb9XgSyZr96ig8Kwx3uWVsnyGR/yw6dYrwHIe8Ma 0wPw38z5PmEUBUrGrTz/NTHLN0y+qse8JdiVuy/XtQFGqpbXTVk9OCUifVob8sDx +8LPFgU9G3bRIrorm9gW8orG7+voHLd8S2ed/NO6dz7zvtxDUUhWZBeaaMrUcKMM A5jFldEgRUwukAaPcwMuEEoYTkvzX3/bT+G8AQljaPcBt2E8NN/dETlt5vRggPNY wB28MTDGypknP9brZBFNoL6NkI+Hvg/9azBbz6Cokuv/bDY3n2/CQA84AWIindvw LHbRKmMf9PZmQJx8LWcg76u9tF7m9D4JWIGiEcZ7pQ9gUB9L5FVEC47/PYB+TvpZ PYcC9v5ho7j+yHkGLLBI =eKVg -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 20 13:25:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4B01B290F for ; Fri, 20 Jun 2014 13:25: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTDt7hSjiiPn for ; Fri, 20 Jun 2014 13:25:31 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282A31B290D for ; Fri, 20 Jun 2014 13:25:29 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so1378784wib.12 for ; Fri, 20 Jun 2014 13:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wKrAnoUNG3kVSAqC/JDzh/YUu0kMQ4WYllxF0mDoAW4=; b=N6Lf0S2X/AKfz6ESdjvzuMS6/xon3VR7X2F+u4hjfjYP8gkZKKniMv0MSIO7ryPZkW 3wwkIMnFuJFyBt6O/rTXxbIIFgWWrDXHC+tMBESEyX7jAZb08fLdSE2G9NGqekufqICr gMxf8GsENXlKXwGsSRiNpqUxFNjCQptyJbovGR9qWJU0dlWI3PYact9tZz8v2cQT31bp mFJWXYoUCkT9VnFFvCIwwTKMSftBKbsGBpUA95o0MTir8OghLmf76kZv7QbU0Yjel0if fVuypuXlclLPRfqmZDuMlgvmzlwW/E4W7r6RsJFiv2Zb99XDJ3ggVwkai6HwzI/hH0GG fNYw== X-Received: by 10.180.99.99 with SMTP id ep3mr6742624wib.42.1403295927723; Fri, 20 Jun 2014 13:25:27 -0700 (PDT) Received: from [192.168.1.101] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id am10sm17701599wjc.45.2014.06.20.13.25.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Jun 2014 13:25:27 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: <87k38bzc0h.fsf@alice.fifthhorseman.net> Date: Fri, 20 Jun 2014 23:25:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3422AC27-DC99-49AC-87EC-EFFC9F883D98@gmail.com> References: <87k38bzc0h.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hGZkiCsYOBBNKUgRW9SIuY5IM4M Cc: IETF TLS Working Group Subject: Re: [TLS] On the possibility of AEAD modes that require padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 20:25:33 -0000 On Jun 20, 2014, at 9:11 PM, Daniel Kahn Gillmor = wrote: > hi IETF folks-- >=20 > If an AEAD mode is ever defined that must pad its input to a blocksize > before encrypting, the current spec seems like it will break. >=20 > This is a currently-theoretical concern, since (fixed authentication = tag > notwithstanding) GCM does not pad its input, and OCB and > chacha20-poly1305 (and other AEAD modes i could find data on) also = don't > pad their input. While this hasn=92t been proposed directly to the TLS working group = there is the CBC-HMAC AEAD in draft-mcgrew-aead-aes-cbc-hmac-sha2. That=92s CBC so there is padding as described in section 2.1. Yoav From nobody Fri Jun 20 17:16:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE121A041F for ; Fri, 20 Jun 2014 17:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QZ5_zZqiS76 for ; Fri, 20 Jun 2014 17:16:25 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DDD81A0319 for ; Fri, 20 Jun 2014 17:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1403309785; x=1434845785; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ip37oi5q6KG0hLNFJXM0OEUM11UjZSq/RAT0WtQzdso=; b=OsC55gXfYJHVehT3vDvkl2wgBiDtDNj/eVwd4a9S2y4LySRPT4Lh/+Ff KrxtOWQtRsdrmsKCrKz4KB38znXrgsblZZs72Q+0Uqse0ZWNXJYgkTKfM kBQu1gZUf0m1swlamnAdZR+n6u1zMSrqt5eB7gNLwToL4r3H/4mt3Lf5w A=; X-IronPort-AV: E=Sophos;i="5.01,518,1399982400"; d="scan'208";a="259752363" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Jun 2014 12:16:21 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sat, 21 Jun 2014 12:16:20 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Renegotiation: trying to summarize Thread-Index: Ac+M5gaFSKrCCIhTRdiucEnoVPu4XA== Date: Sat, 21 Jun 2014 00:16:19 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DECC45F@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0b0S_Vp2rDJf4kQrQNdaUs01Dto Subject: Re: [TLS] Renegotiation: trying to summarize X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 00:16:27 -0000 Martin Thomson writes:=0A= =0A= >1. Remove renegotiation entirely=0A= >=0A= >Brian Smith proposed this. Arguments for are its beautiful simplicity and= =0A= >the fact that it ensures that you limit the time that a single session (an= d=0A= >the corresponding keys) live.=0A= =0A= Another argument strongly in favour of removing it is that in all the=0A= applications where I've seen a requirement for renegotiation (e.g. in indus= try=0A= standards that use TLS), in approximately, oh, 100% of them it was due to s= ome=0A= misguided perception that it'd do... well, no-one could really explain it, = but=0A= the capability was there so we may as well add a clause requiring it.=0A= =0A= In some cases the requirement was so clearly ridiculous (infrequent reporti= ng=0A= from SCADA systems where you'd need to renegotiate on each message) that=0A= implementers chose to ignore it, but in other cases it wasn't easy to convi= nce=0A= people that it was pointless, particularly when some standards committee ha= d=0A= decided that you had to do it.=0A= =0A= I'm strongly in favour of removing it, it's mostly pointless, it's been the= =0A= cause of the first real flaw in the SSL/TLS protocol design (rather than an= =0A= implementation issue), and it really messes things up when other standards= =0A= groups decide they need to mandate it without knowing why.=0A= =0A= Peter.= From nobody Fri Jun 20 21:30:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1885B1A04CD for ; Fri, 20 Jun 2014 21:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bqyOpDPPWzd for ; Fri, 20 Jun 2014 21:30:04 -0700 (PDT) Received: from xsmtp11.mail2web.com (xsmtp11.mail2web.com [168.144.250.181]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8491A0248 for ; Fri, 20 Jun 2014 21:30:03 -0700 (PDT) Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1WyCwE-0001bA-En for tls@ietf.org; Sat, 21 Jun 2014 00:30:02 -0400 Received: (qmail 1133 invoked from network); 21 Jun 2014 04:30:01 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Jun 2014 04:30:01 -0000 From: "Christian Huitema" To: "'Robert Ransom'" , "'Michael Tuexen'" References: <5772B9EF-EDD0-4B3E-A85E-43CCEA199D01@lurchi.franken.de> In-Reply-To: Date: Fri, 20 Jun 2014 21:29:59 -0700 Message-ID: <02af01cf8d09$77b0eee0$6712cca0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJXg8qdelqDXI3T9Tole9+VST4PUgFlDyGBAdrKTXwB82QLWAGu6fJEmjP5a9A= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7EuffoY7woZ7yXcyAjt6lmeQwT0 Cc: tls@ietf.org Subject: Re: [TLS] Short notes on TLS RFCs ... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 04:30:06 -0000 >> No... You send a large packet (mostly containing padding) and get >> back a small one (mostly containing the reflected payload)... > > =E2=80=98Heartbleed=E2=80=99 allowed a party to send a small packet = and receive a large reply. The coding error in Open SSL allowed for that. The specification, on the = other hand, specified that the reflected payload could not be larger = than the incoming message. If the code had actually implemented the = spec, there would be no bug. -- Christian Huitema From nobody Sun Jun 22 17:05:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2D41B2796 for ; Sun, 22 Jun 2014 17:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMi5B_a-p8rP for ; Sun, 22 Jun 2014 17:05:13 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B691F1A083D for ; Sun, 22 Jun 2014 17:05:13 -0700 (PDT) Received: by mail-yk0-f175.google.com with SMTP id 9so4252519ykp.6 for ; Sun, 22 Jun 2014 17:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tIlExNE4sCmEAYobxN95SX/Oo3CR8xDVXXPvyfibUwE=; b=kvpgwsUnSx0VqhVaSwfPfEgQfmKwfU6g0HukaM4i6nPd+rOadHNtkcnL5OyhDb+zjK EJnFoqJzQ8tTgIYMKXidaZqmG0Ona1OWW/hqGM4J2hyw8FvygIN+giNobbw04RGnpT+W YBqTzB03YeHXVcGqzdo8P4DoiYpYF+xE559voiZhXAJJ2voiIo6qo/UgYyhz+ms8+baG c9MZLp+mNb493y8G/kMSqqkperAXPPRWpb0BBJ0+H0BQ9jW4+KivcVL7qBFXYrAv0b5p 6GIlDNdgVyCRMn0IxFMHZHd2wLc7HjcSW9efQSRs+uggXF0f0RAKKYxsBuaI+ycH7kaN 1m1g== MIME-Version: 1.0 X-Received: by 10.236.207.33 with SMTP id m21mr29424957yho.71.1403481912963; Sun, 22 Jun 2014 17:05:12 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Sun, 22 Jun 2014 17:05:12 -0700 (PDT) Date: Sun, 22 Jun 2014 17:05:12 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-7Kts_iX452Dy593BoMF5XoXKMI Subject: [TLS] A (somewhat) comprehensive proposal for the handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 00:05:16 -0000 Dear all, I'm writing this to put forward a (somewhat) comprehensive view of how we can deliver on the promises in the charter, while making sure we don't have the sort of security problems as before, and making it easy to support TLS 1.3 in clients and servers that already support TLS 1.2. My view is the best way forward is to have TLS 1.3 consist of two extensions to TLS 1.2: one signalling a change to the key derivation and Finished Messages, the second signaling a guess as to the ciphersuite and curve to be negotiated, along with the ClientKeyExchange. The guess is conceptually easier to describe: it contains the ciphersuite, the curve that will be picked, and a "point on the curve" (aka DH value). If the server accepts the guess it sends back this extension, if it doesn't accept the guess (because it wants a different ciphersuite or curve) it doesn't send back the extension. The changes signalled by the first extension are as follows: The ciphersuite contains a PRF I will call H. At each message we have H(script), a hash of the transcript of sent messages. We set the master key at the earliest possible point, namely after the DH values have been exchanged to H( hlen || H(script) || hlen || H(g^a, g^b, g^ab) || opt_in_len || opt_in). (Server random and client random are in the script, opt_in is optional data for channel binding purposes like renegotation_info or handshake obfuscation). (Yes, I would have prefered going from {{0,1}*}*->{0,1}^n) H(script) is used to salt the server signature of its group element. If we want to protect against clients with bad random number generators from being fooled we might need to add server_random also. >From this channel keys are derived as usual. (This might go badly with resumption: maybe this needs to be rethought) The Finished message contains a confirmation key H( master_key_len || master_key || "client confirm") for the client or "server confirm" for the server. It's not sent encrypted: the ChangeCipherSpec comes immediately afterwards. (Yes, you can have a half-encrypted channel at some stages during the handshake) Why is this secure? Go to the ROM, and we see that the key derived from the handshake is a function of the handshake values that is injective. With a bit more work we see active intervention earns the attacker nothing, so what is left reduces to DH security. Assume server_random is unique, and you get anti-replay. I've not formalized this intuition. Client authentication has to come after the finished message, but this is easy: sign a value extracted from the master_secret. Resumption tickets need to be set in a message after the key is derived. This proposal is orthogonal to handshake obfuscation. For the ZRT transport I have no idea. Sincerely, Watson Ladd From nobody Sun Jun 22 17:57:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF8F1B27DB for ; Sun, 22 Jun 2014 17:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe4z1Lw5oJ_I for ; Sun, 22 Jun 2014 17:57:09 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1015D1B27DA for ; Sun, 22 Jun 2014 17:57:08 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id bs8so3259212wib.9 for ; Sun, 22 Jun 2014 17:57:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vNWS0mQFTKAb7Mj36xGK/z4BIl82OM4OAWbNx8JFYys=; b=NzxwXn34psXu+IuNsfTMaUvj8ESa3/dsS5lo8mrfLPFAKT3M0EifBZs+VE/7Ij6Y15 XNfwv3gCKF+z0ItipcnDoKz0UW8Lb92CNnB9M3xXtpPonhaVutMZUOuVYNxMQoZWhjaY l45l8OR2A11rxlpLClR2K/tIbl99PN0ajwg339dD70nCJILcdFmwRl9Z48RSqTQcQR69 EKZ/eplCTcAyzaUlYL2KHu6O+chJZDdKZZ7RLKJpnx1f6yyi2AszEyzFOENDET1oSQyc plHnP3eDRGlQPFDMZFcLsDvwRhf5XM8zlkX2+DYM/KcwxT/+6AWqX4C9EbPPEbe4k10u 3VHA== X-Gm-Message-State: ALoCoQmpdVaaJORZCg8O1FVBFHEPd2DD1bqkDhwvIQbMgq8i0pKZMtjEyrYGgS7UuvVE+TetboiV X-Received: by 10.180.186.97 with SMTP id fj1mr21633129wic.18.1403485027610; Sun, 22 Jun 2014 17:57:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sun, 22 Jun 2014 17:56:27 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <539B6F1B.4030407@mit.edu> From: Eric Rescorla Date: Sun, 22 Jun 2014 17:56:27 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11c2584e84cf7c04fc7652df Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9ifkfgchYhQ2ljAfeq5K5S5JM0k Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 00:57:12 -0000 --001a11c2584e84cf7c04fc7652df Content-Type: text/plain; charset=UTF-8 On Fri, Jun 13, 2014 at 7:05 PM, Watson Ladd wrote: > On Fri, Jun 13, 2014 at 8:02 PM, Eric Rescorla wrote: > > > > > > > > On Fri, Jun 13, 2014 at 2:59 PM, Watson Ladd > wrote: > >> > >> On Fri, Jun 13, 2014 at 6:37 PM, Andy Lutomirski > >> wrote: > >> > On 06/13/2014 02:30 PM, Watson Ladd wrote: > >> >> For TLS 1.3 we should ensure contributory behaviour is not required > to > >> >> avoid these issues. > >> > > >> > What needs to change for this to be the case? It would be even nicer > if > >> > the result were provably correct in some reasonable model. > >> > >> Hash the entire exchange into the generated key, so that a key made by > >> someone cheating is only shared with them. I still don't understand > >> why this isn't done already: it's needed for the finished message, so > >> nothing is saved by not doing it. This is what the triple handshake > >> fix is supposed to do, but it does a strange variant that reuses the > >> oddball finished message. > >> > >> (And use a strong hash function: apparently the reason we haven't > >> finished fixing Triple Handshake is that some people want to use > >> SHA-1. On their heads be it!) > > > > > > Hmm... I don't believe that this isn't done strictly because of SHA-1. > > Looking back at what I wrote a while ago: > > > > http://www.ietf.org/mail-archive/web/tls/current/msg12574.html > > > > I believe the question is whether it is acceptable to have a *hash* of > > the handshake hashed into the generated key as opposed to having > > the handshake itself hashed into the generated key and whether it's > > acceptable to have that hash be the combined MD5/SHA1 variant > > in TLS < 1.2 and if not what recommendation we should make for > > those versions. > > Why wouldn't it be? If H(m)=H(m'), that's just as much a collision as > if H(m || stuff)=H(m' || stuff). > Well, this isn't quite the two cases we are considering, since we are computing either: HMAC(Key, stuff) or: HMAC(Key, H(stuff)) with: - stuff being under partial control of the attacker and - the Key being subject to the issue you raise in the message that started this thread. It may well be that these are equally secure, and if you have an analysis that demonstrates that, then it would be useful in assessing how to move forward with this draft. Thanks -Ekr --001a11c2584e84cf7c04fc7652df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 13, 2014 at 7:05 PM, Watson Ladd <= watsonbladd@gmai= l.com> wrote:
On Fri, Jun 13, 2014 at 8:02 PM, E= ric Rescorla <ekr@rtfm= .com> wrote:
>
>
>
> On Fri, Jun 13, 2014 at 2:59 PM, Watson Ladd <watsonbladd@gmail.com> wrote:<= br> >>
>> On Fri, Jun 13, 2014 at 6:37 PM, Andy Lutomirski <luto@amacapital.net>
>> wrote:
>> > On 06/13/2014 02:30 PM, Watson Ladd wrote:
>> >> For TLS 1.3 we should ensure contributory behaviour is no= t required to
>> >> avoid these issues.
>> >
>> > What needs to change for this to be the case? =C2=A0It would = be even nicer if
>> > the result were provably correct in some reasonable model. >>
>> Hash the entire exchange into the generated key, so that a key mad= e by
>> someone cheating is only shared with them. I still don't under= stand
>> why this isn't done already: it's needed for the finished = message, so
>> nothing is saved by not doing it. This is what the triple handshak= e
>> fix is supposed to do, but it does a strange variant that reuses t= he
>> oddball finished message.
>>
>> (And use a strong hash function: apparently the reason we haven= 9;t
>> finished fixing Triple Handshake is that some people want to use >> SHA-1. On their heads be it!)
>
>
> Hmm... I don't believe that this isn't done strictly because o= f SHA-1.
> Looking back at what I wrote a while ago:
>
> http://www.ietf.org/mail-archive/web/tls/current/msg= 12574.html
>
> I believe the question is whether it is acceptable to have a *hash* of=
> the handshake hashed into the generated key as opposed to having
> the handshake itself hashed into the generated key and whether it'= s
> acceptable to have that hash be the combined MD5/SHA1 variant
> in TLS < 1.2 and if not what recommendation we should make for
> those versions.

Why wouldn't it be? If H(m)=3DH(m'), that's just as= much a collision as
if H(m || stuff)=3DH(m' || stuff).

= Well, this isn't quite the two cases we are considering, since we are
computing either:

HMAC(Key, stuff)

or:

HMAC(Key, H(stuff))
<= div>
with:
- stuff being under partial control of t= he attacker and
- the Key being subject to the issue you raise in= the message=C2=A0
that started this thread.

It may well be that= these are equally secure, and if you have an analysis
that demon= strates that, then it would be useful in assessing how to
move fo= rward with this draft.

Thanks
-Ekr

<= /div> --001a11c2584e84cf7c04fc7652df-- From nobody Sun Jun 22 18:24:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E3E1B27FC for ; Sun, 22 Jun 2014 18:24: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5yAsoUQCD48 for ; Sun, 22 Jun 2014 18:24:21 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9C31B27FB for ; Sun, 22 Jun 2014 18:24:21 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id t59so4591900yho.9 for ; Sun, 22 Jun 2014 18:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FStjqwHPj0JwL/M3rEiaKkDUMd35NTdT0RomS3ewfEk=; b=kIG162UfEZx5tPwKcJDs9IWWevxXdNRwpe1mWZpJij0ty5w+fz6sFX9PSisWgqKIHg i2DrNkiAsP90csMT0RbX/QGBiY5vrlb1Wj5LCxzzbeCZHDzD5liMcCNDGXkNmapP8ROy QaCWwtv8ysJrrqJQA1UaITUhpb8SdG96n1Oa48xSZdvJEUEPuGgqs5MnCRqX9+dB6Lsg YXDboRpGrRkoYmGBKzP8wpxLkVsmNhK2BWdiW/ZbECcJp0mHHpqMuOOI72NEsV+6LDjq kTZIgMxQ0m3Om0cWuRozRJLYbGtHt7cFHcTvZWRYJdewO2BahvZAGPYCkIZHFTh/2rrX gxkw== MIME-Version: 1.0 X-Received: by 10.236.28.133 with SMTP id g5mr31150847yha.46.1403486660664; Sun, 22 Jun 2014 18:24:20 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Sun, 22 Jun 2014 18:24:20 -0700 (PDT) In-Reply-To: References: <539B6F1B.4030407@mit.edu> Date: Sun, 22 Jun 2014 18:24:20 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OVGxSAJ4JX-IrXoxdPk5-BxI0xg Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 01:24:23 -0000 On Sun, Jun 22, 2014 at 5:56 PM, Eric Rescorla wrote: > > > > On Fri, Jun 13, 2014 at 7:05 PM, Watson Ladd wrote: >> >> On Fri, Jun 13, 2014 at 8:02 PM, Eric Rescorla wrote: >> > >> > >> > >> > On Fri, Jun 13, 2014 at 2:59 PM, Watson Ladd >> > wrote: >> >> >> >> On Fri, Jun 13, 2014 at 6:37 PM, Andy Lutomirski >> >> wrote: >> >> > On 06/13/2014 02:30 PM, Watson Ladd wrote: >> >> >> For TLS 1.3 we should ensure contributory behaviour is not required >> >> >> to >> >> >> avoid these issues. >> >> > >> >> > What needs to change for this to be the case? It would be even nicer >> >> > if >> >> > the result were provably correct in some reasonable model. >> >> >> >> Hash the entire exchange into the generated key, so that a key made by >> >> someone cheating is only shared with them. I still don't understand >> >> why this isn't done already: it's needed for the finished message, so >> >> nothing is saved by not doing it. This is what the triple handshake >> >> fix is supposed to do, but it does a strange variant that reuses the >> >> oddball finished message. >> >> >> >> (And use a strong hash function: apparently the reason we haven't >> >> finished fixing Triple Handshake is that some people want to use >> >> SHA-1. On their heads be it!) >> > >> > >> > Hmm... I don't believe that this isn't done strictly because of SHA-1. >> > Looking back at what I wrote a while ago: >> > >> > http://www.ietf.org/mail-archive/web/tls/current/msg12574.html >> > >> > I believe the question is whether it is acceptable to have a *hash* of >> > the handshake hashed into the generated key as opposed to having >> > the handshake itself hashed into the generated key and whether it's >> > acceptable to have that hash be the combined MD5/SHA1 variant >> > in TLS < 1.2 and if not what recommendation we should make for >> > those versions. >> >> Why wouldn't it be? If H(m)=H(m'), that's just as much a collision as >> if H(m || stuff)=H(m' || stuff). > > > Well, this isn't quite the two cases we are considering, since we are > computing either: > > HMAC(Key, stuff) > > or: > > HMAC(Key, H(stuff)) > > with: > - stuff being under partial control of the attacker and > - the Key being subject to the issue you raise in the message > that started this thread. HMAC is H(key || H(stuff)) right? So it turns into H(key || H(stuff)) vs H(key || H(H(stuff))). (Yes, there is padding: that's an injective function, so doesn't matter for this analysis). Once again a collision means stuff equals stuff both ways. Of course, this presumes resistance to collisions. But if we don't have that, there is a lot more going wrong. Sincerely, Watson Ladd From nobody Sun Jun 22 18:43:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037331B281A for ; Sun, 22 Jun 2014 18:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNfNt7Kqltsr for ; Sun, 22 Jun 2014 18:43:31 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68CF11B2816 for ; Sun, 22 Jun 2014 18:43:31 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id r20so3286893wiv.14 for ; Sun, 22 Jun 2014 18:43:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5Tnx3rDd4BUVY0YETvCrNov+vdC8NFBN/vVyb0PH3UM=; b=US9HseWUsjCUTKBU7575DxzgcdK4daVT3TqGBjjbqShgchdKs6CUTqMxWThJNbJEAk OtzF2AXbKdJruej86UwRYNXVSCifEtF2IPjtGj/+6h0LgG2R8ihMiLCOg2tbm0IaC2RC 8xAHiny1tvQqDcIbpLu3yLFQ5wx7aidB2b6QBg0qrsJohJrTbS5ySExj2q+hH22yCCW1 8WyB13IEKaAyoORV9QvDPv2BU0ClAD+tZlZyl4j9aARE1x4jKvHsbsK/8kRFuBlF/edB vmvgdUSKr2PLiNjCPVSl03LEoaGgxaX/ur1tlC5EmxxkTbnl8Jn0Mi8GsblQq8DM4eM/ 802Q== X-Gm-Message-State: ALoCoQlLnQuXDxgg9N6fMPzNjK8Qw6I5ZJqmWqjCtSbnM0Y39DGGkaLnpe8ZVG27GOBXxp8d1W12 X-Received: by 10.180.76.132 with SMTP id k4mr21834857wiw.1.1403487809896; Sun, 22 Jun 2014 18:43:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sun, 22 Jun 2014 18:42:49 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <539B6F1B.4030407@mit.edu> From: Eric Rescorla Date: Sun, 22 Jun 2014 18:42:49 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=f46d0435c0225b1c0e04fc76f8d1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Pj45wOSoUNF1Ds6oVLl5yGFvPHQ Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 01:43:36 -0000 --f46d0435c0225b1c0e04fc76f8d1 Content-Type: text/plain; charset=UTF-8 On Sun, Jun 22, 2014 at 6:24 PM, Watson Ladd wrote: > On Sun, Jun 22, 2014 at 5:56 PM, Eric Rescorla wrote: > > > > > > > > On Fri, Jun 13, 2014 at 7:05 PM, Watson Ladd > wrote: > >> > >> On Fri, Jun 13, 2014 at 8:02 PM, Eric Rescorla wrote: > >> > > >> > > >> > > >> > On Fri, Jun 13, 2014 at 2:59 PM, Watson Ladd > >> > wrote: > >> >> > >> >> On Fri, Jun 13, 2014 at 6:37 PM, Andy Lutomirski < > luto@amacapital.net> > >> >> wrote: > >> >> > On 06/13/2014 02:30 PM, Watson Ladd wrote: > >> >> >> For TLS 1.3 we should ensure contributory behaviour is not > required > >> >> >> to > >> >> >> avoid these issues. > >> >> > > >> >> > What needs to change for this to be the case? It would be even > nicer > >> >> > if > >> >> > the result were provably correct in some reasonable model. > >> >> > >> >> Hash the entire exchange into the generated key, so that a key made > by > >> >> someone cheating is only shared with them. I still don't understand > >> >> why this isn't done already: it's needed for the finished message, so > >> >> nothing is saved by not doing it. This is what the triple handshake > >> >> fix is supposed to do, but it does a strange variant that reuses the > >> >> oddball finished message. > >> >> > >> >> (And use a strong hash function: apparently the reason we haven't > >> >> finished fixing Triple Handshake is that some people want to use > >> >> SHA-1. On their heads be it!) > >> > > >> > > >> > Hmm... I don't believe that this isn't done strictly because of SHA-1. > >> > Looking back at what I wrote a while ago: > >> > > >> > http://www.ietf.org/mail-archive/web/tls/current/msg12574.html > >> > > >> > I believe the question is whether it is acceptable to have a *hash* of > >> > the handshake hashed into the generated key as opposed to having > >> > the handshake itself hashed into the generated key and whether it's > >> > acceptable to have that hash be the combined MD5/SHA1 variant > >> > in TLS < 1.2 and if not what recommendation we should make for > >> > those versions. > >> > >> Why wouldn't it be? If H(m)=H(m'), that's just as much a collision as > >> if H(m || stuff)=H(m' || stuff). > > > > > > Well, this isn't quite the two cases we are considering, since we are > > computing either: > > > > HMAC(Key, stuff) > > > > or: > > > > HMAC(Key, H(stuff)) > > > > with: > > - stuff being under partial control of the attacker and > > - the Key being subject to the issue you raise in the message > > that started this thread. > > HMAC is H(key || H(stuff)) right? Actually: H(key^mask1 || H(key^mask2 || stuff)) where mask1 and mask2 are fixed. > So it turns into H(key || H(stuff)) > vs H(key || H(H(stuff))). (Yes, there is padding: that's an injective > function, so doesn't matter for this analysis). Once again a collision > means stuff equals stuff both ways. > > Of course, this presumes resistance to collisions. But if we don't > have that, there is a lot more going wrong. Sorry, my mistake for not being clearer: I was assuming that there was at least some partial failure of collision resistance in the hash function. As you suggest, that means that a lot of other stuff is going wrong, so maybe it's not worth worrying about. -Ekr --f46d0435c0225b1c0e04fc76f8d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, Jun 22, 2014 at 6:24 PM, Watson Ladd <= watsonbladd@gmai= l.com> wrote:
On Sun, Jun 22, 2014 at 5:56 PM, E= ric Rescorla <ekr@rtfm= .com> wrote:
>
>
>
> On Fri, Jun 13, 2014 at 7:05 PM, Watson Ladd <watsonbladd@gmail.com> wrote:<= br> >>
>> On Fri, Jun 13, 2014 at 8:02 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>> >
>> >
>> >
>> > On Fri, Jun 13, 2014 at 2:59 PM, Watson Ladd <watsonbladd@gmail.com>= ;
>> > wrote:
>> >>
>> >> On Fri, Jun 13, 2014 at 6:37 PM, Andy Lutomirski <luto@amacapital.net>
>> >> wrote:
>> >> > On 06/13/2014 02:30 PM, Watson Ladd wrote:
>> >> >> For TLS 1.3 we should ensure contributory behavi= our is not required
>> >> >> to
>> >> >> avoid these issues.
>> >> >
>> >> > What needs to change for this to be the case? =C2=A0= It would be even nicer
>> >> > if
>> >> > the result were provably correct in some reasonable = model.
>> >>
>> >> Hash the entire exchange into the generated key, so that = a key made by
>> >> someone cheating is only shared with them. I still don= 9;t understand
>> >> why this isn't done already: it's needed for the = finished message, so
>> >> nothing is saved by not doing it. This is what the triple= handshake
>> >> fix is supposed to do, but it does a strange variant that= reuses the
>> >> oddball finished message.
>> >>
>> >> (And use a strong hash function: apparently the reason we= haven't
>> >> finished fixing Triple Handshake is that some people want= to use
>> >> SHA-1. On their heads be it!)
>> >
>> >
>> > Hmm... I don't believe that this isn't done strictly = because of SHA-1.
>> > Looking back at what I wrote a while ago:
>> >
>> > http://www.ietf.org/mail-archive/web/tls/cu= rrent/msg12574.html
>> >
>> > I believe the question is whether it is acceptable to have a = *hash* of
>> > the handshake hashed into the generated key as opposed to hav= ing
>> > the handshake itself hashed into the generated key and whethe= r it's
>> > acceptable to have that hash be the combined MD5/SHA1 variant=
>> > in TLS < 1.2 and if not what recommendation we should make= for
>> > those versions.
>>
>> Why wouldn't it be? If H(m)=3DH(m'), that's just as mu= ch a collision as
>> if H(m || stuff)=3DH(m' || stuff).
>
>
> Well, this isn't quite the two cases we are considering, since we = are
> computing either:
>
> HMAC(Key, stuff)
>
> or:
>
> HMAC(Key, H(stuff))
>
> with:
> - stuff being under partial control of the attacker and
> - the Key being subject to the issue you raise in the message
> that started this thread.

HMAC is H(key || H(stuff)) right?

<= div>Actually: H(key^mask1 || H(key^mask2 || stuff))

where mask1 and mask2 are fixed.

=C2=A0
So it turns into H(key || H(stuff))
vs H(key || H(H(stuff))). (Yes, there is padding: that's an injective function, so doesn't matter for this analysis). Once again a collision<= br> means stuff equals stuff both ways.

Of course, this presumes resistance to collisions. But if we don't
have that, there is a lot more going wrong.

Sorry, my mistake for not being clearer: I was assuming that there
was at least some partial failure of collision resistance in the hash
function. As you suggest, that means that a lot of other stuff is goin= g
wrong, so maybe it's not worth worrying about.
-Ekr


--f46d0435c0225b1c0e04fc76f8d1-- From nobody Sun Jun 22 19:28:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AB81B287F for ; Sun, 22 Jun 2014 19:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.143 X-Spam-Level: * X-Spam-Status: No, score=1.143 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9pDNrXCaQCf for ; Sun, 22 Jun 2014 19:28:14 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.56.159.17]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A4BE1B2957 for ; Sun, 22 Jun 2014 19:28:14 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id A83B3AD3A3557; Sun, 22 Jun 2014 21:28:13 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 8DD2BAD3A3530 for ; Sun, 22 Jun 2014 21:28:13 -0500 (CDT) Received: from [96.231.225.192] (port=49656 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WytzQ-0002q1-PI; Sun, 22 Jun 2014 21:28:13 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <8B2FFA4C-9BBF-4E7E-B0E4-032139FF0EB5@ieca.com> Date: Sun, 22 Jun 2014 22:27:56 -0400 To: ietf-secretariat@ietf.org, "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1WytzQ-0002q1-PI X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:49656 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/r_wgjGLY-ZpYHCFOiza7Tafq0Ag Subject: [TLS] interim meeting anoucement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 02:28:18 -0000 WG Members, Per the doodle results, the TLS WG will hold an interim meeting prior to the IETF from 10am-4pm on Sunday July 20. The most likely location will be the Mozilla offices in Toronto. The chairs will post details with an agenda and a final location closer to the meeting. spt for the chairs [For the chairs] From nobody Sun Jun 22 22:18:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A78E1B286A for ; Sun, 22 Jun 2014 22:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KQkyXg6wo6l for ; Sun, 22 Jun 2014 22:17:59 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80E11A045D for ; Sun, 22 Jun 2014 22:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=793; q=dns/txt; s=iport; t=1403500679; x=1404710279; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=W1FbkaXDfQNxhjWBlCGUBzLEQI41lwZ48qzFI+mWAks=; b=b+YGN+Dm64TJGd04alteVxZID2K1yMo12CnrukdKDkOVRwrobx8aDMBt Y19U8XHR2wN/IxBmSr+mNvpHlUWqvl6hcX7u2pYSkby5AVLIG09gd/eOd KCc7tftA82X+R1/QrCk0NwCW+ZFfAiRTWA5RgKfvQAFyEQiHRAXlmxjV3 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAFANy3p1OtJV2Z/2dsb2JhbABZgw2BLKozAQEBAQEBBQGaPBZ1hAo6UQE+QicEiFWZGax1F4VjjE2BFgSaTIs1iC6DQoIw X-IronPort-AV: E=Sophos;i="5.01,527,1400025600"; d="scan'208";a="55142604" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 23 Jun 2014 05:17:59 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5N5HxRK006755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Jun 2014 05:17:59 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 23 Jun 2014 00:17:58 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Resolution on gmt_time Thread-Index: AQHPjqJ/wY/3f0zKxEu+heHKOI3tZw== Date: Mon, 23 Jun 2014 05:17:58 +0000 Message-ID: <338B3B88-CCE5-4D79-97DC-1EC7D84891AA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.22] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ErOz9OpC29Hfgwwh_1XR7crhmRg Subject: [TLS] Resolution on gmt_time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 05:18:01 -0000 Thanks all. Based on the list discussion, the chairs believe there is rough consensus on the following points: For TLS 1.3: - Remove GMT time from the ClientHello entirely. - Remove GMT time from the ServerHello at the MUST or SHOULD level. For TLS 1.2: - Remove GMT time from the ClientHello entirely. - Remove GMT time from the ServerHello at the SHOULD level. Next steps for TLS 1.3 are as follows: The editor is directed to remove GMT time from both random values and open an issue as to whether or not the ServerHello can have a time value in it. Next steps for TLS 1.2 are as follows: Absent any objections, the chairs intend to adopt draft-matthewson as a WG draft. Anyone who objects to this, please say something by Friday June 27. Joe (For the chairs)=20 From nobody Sun Jun 22 22:27:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919541B2997 for ; Sun, 22 Jun 2014 22:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZgNHkyZwSJa for ; Sun, 22 Jun 2014 22:27:50 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E1C1B286A for ; Sun, 22 Jun 2014 22:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=526; q=dns/txt; s=iport; t=1403501270; x=1404710870; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=EoLgaO6+3AqKzv8eOXJiRJiqGn4yk2XMkoEvmF9voaY=; b=KRE/wqslUIqO763HQ9AC5afRUFY9dnlc7LhTpLrSo6ZzYw40PB32Uklk +lICKv1BBAWTDhjL4yQ92XE0BR3ZpwDTkNPKI2XOw7u7ECKqvsiGvYVzh 2QlaHzbOB85DTAYfaj7w0kEwkeUTP6t7zlMC4+RQKtUfLuVoZciyoXUPl k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4IADy6p1OtJA2M/2dsb2JhbABZgw1SWqozAQEBAQEBBQECA5o4FnWECh0dUQE+QicEiFUNmRCsdReFY4xNgRYEmkyBRZIeg0KCMA X-IronPort-AV: E=Sophos;i="5.01,527,1400025600"; d="scan'208";a="55089502" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP; 23 Jun 2014 05:27:46 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5N5Rk2u010938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Jun 2014 05:27:46 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 23 Jun 2014 00:27:46 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Consensus Call for acceptance of draft-gillmor-tls-negotiated-dl-dhe-02 Thread-Index: AQHPjqPckmOp0Rap2USkBN7Y7o0McQ== Date: Mon, 23 Jun 2014 05:27:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.22] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fyI_LK5YdR1fnQZFgDElhJQoG7U Subject: [TLS] Consensus Call for acceptance of draft-gillmor-tls-negotiated-dl-dhe-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 05:27:51 -0000 WG Members, The chairs would like to get the sense of the WG on adopting as a WG document: http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-02 Please make any comments in favor of or against adoption by Friday July 4. Note: the chairs are aware that there has been some discussion of the specific groups in this document.=20 Adopting this document does not commit the WG to these=20 groups as some or all of these groups may be changed prior=20 to publication. Thanks Joe (for the chairs) From nobody Sun Jun 22 23:37:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204DC1B29BA for ; Sun, 22 Jun 2014 23:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVh4b78Zhzf2 for ; Sun, 22 Jun 2014 23:36:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F4F1B29B7 for ; Sun, 22 Jun 2014 23:36:58 -0700 (PDT) Received: from [10.143.194.115] ([31.55.17.102]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s5N6arY8099879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 22 Jun 2014 23:36:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host [31.55.17.102] claimed to be [10.143.194.115] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: Date: Mon, 23 Jun 2014 07:36:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8583B665-5964-4AD0-977B-D53620D465EE@vpnc.org> References: <539B6F1B.4030407@mit.edu> To: "tls@ietf.org" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LPhmykr7D-Ww8or0G5RreXF9XEw Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 06:36:59 -0000 On Jun 23, 2014, at 2:24 AM, Watson Ladd wrote: >>> Why wouldn't it be? If H(m)=3DH(m'), that's just as much a collision = as >>> if H(m || stuff)=3DH(m' || stuff). >>=20 >>=20 >> Well, this isn't quite the two cases we are considering, since we are >> computing either: >>=20 >> HMAC(Key, stuff) >>=20 >> or: >>=20 >> HMAC(Key, H(stuff)) >>=20 >> with: >> - stuff being under partial control of the attacker and >> - the Key being subject to the issue you raise in the message >> that started this thread. >=20 > HMAC is H(key || H(stuff)) right? So it turns into H(key || H(stuff)) > vs H(key || H(H(stuff))). (Yes, there is padding: that's an injective > function, so doesn't matter for this analysis). Once again a collision > means stuff equals stuff both ways. Bellare showed that weakening of the collision resistance in the = underlying hash doesn't matter, right? = ? I haven't seen any = refutation or weakening of that paper, but I could have missed it. --Paul Hoffman= From nobody Mon Jun 23 01:31:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246E61A041D for ; Mon, 23 Jun 2014 01:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZS6pf0puQAdg for ; Mon, 23 Jun 2014 01:31:24 -0700 (PDT) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE641AD62A for ; Mon, 23 Jun 2014 01:31:23 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id db11so5795254veb.32 for ; Mon, 23 Jun 2014 01:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mnO5AwsJ31npu9Y4DbyqubcZG/9NKuZ/n/xGR4knpMw=; b=dFMKYBRbeyBs3wwPA41/NkjHukwf10Ocy9yjrgfvpjOlLysJHSWK2bzfxXDSSBph46 rCIYyipkesvEx+fHVeJbNQL5x2nV6o4X9KsjRiChhHEcq+FVEPzYf4x+a4kfMpw3oUjs soOgMdfmMXNVK4hC+vzfHDa0fdFSMaFNMCLIQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mnO5AwsJ31npu9Y4DbyqubcZG/9NKuZ/n/xGR4knpMw=; b=SyBqZYKLc7R5WZPX0Qc9t9glWopqhprgNOuDhYyQd5LGBKbZzyRnXO8s8UuMIJ081b HdF76Booa8SRMwb3fzbF3RB8kH/Q6ZxzDRKnzwwdTuiauTKYBrk4UHvHQf8NGUTMJ/z/ XGnpygC7TVuBL7KbTc25bGqIjiYsbIZyTLkaJJUG5NU8+wca/+gR7hs2SWgclEfYUN9v RXhZ/uZTEMWZtZ8jeHwX1IIHaWq/ipOM/3uRSndWPSWR8iBVqTxyN6Gb1qLglYKJi8/o FvKgT8WKXnrSXsCPP6qdonhg2iF50ZTEOZWDTNmOAkwpNr56xbono3PTY7RAqRQXqZ5D YjTg== X-Gm-Message-State: ALoCoQk02ZZWQQFvFy40za5AiNWeN5JSeoUrrTrvKty2SjojlUI+tqvHPxzFQ/2RMl1WxrfclxjC MIME-Version: 1.0 X-Received: by 10.58.236.170 with SMTP id uv10mr5508855vec.31.1403512283122; Mon, 23 Jun 2014 01:31:23 -0700 (PDT) Received: by 10.52.139.78 with HTTP; Mon, 23 Jun 2014 01:31:23 -0700 (PDT) X-Originating-IP: [128.93.62.11] In-Reply-To: References: Date: Mon, 23 Jun 2014 10:31:23 +0200 Message-ID: From: Alfredo Pironti To: "Joseph Salowey (jsalowey)" Content-Type: multipart/alternative; boundary=047d7bdc1a9c12eacb04fc7cab20 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/L-qpeSWwtHxbtYiAd2PrMzjLiJ8 Cc: "" Subject: Re: [TLS] Consensus Call for acceptance of draft-gillmor-tls-negotiated-dl-dhe-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 08:31:26 -0000 --047d7bdc1a9c12eacb04fc7cab20 Content-Type: text/plain; charset=UTF-8 I favor the draft. In sec. 3.1 however, I would rather define a new Server Key Exchange message type, where only dh_Ys is sent (and signed). For complying implementations, this should be a small change to implement, but it completely eliminates ambiguous messages and signatures thereof. We could push even further, and force the server to use the same messages as the client: Key Exchange + Certificate Verify (to defeat cross protocol attacks); but I understand this is a long shot for a draft which is meant to be minimal and quick to implement. Best, Alfredo On Mon, Jun 23, 2014 at 7:27 AM, Joseph Salowey (jsalowey) < jsalowey@cisco.com> wrote: > WG Members, > > The chairs would like to get the sense of the WG on adopting > as a WG document: > > http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-02 > > Please make any comments in favor of or against adoption by > Friday July 4. Note: the chairs are aware that there has been > some discussion of the specific groups in this document. > Adopting this document does not commit the WG to these > groups as some or all of these groups may be changed prior > to publication. > > Thanks > > Joe > (for the chairs) > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7bdc1a9c12eacb04fc7cab20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I favor the draft.

In sec. 3.1= however, I would rather define a new Server Key Exchange message type, whe= re only dh_Ys is sent (and signed). For complying implementations, this sho= uld be a small change to implement, but it completely eliminates ambiguous = messages and signatures thereof.

We could push even further, and force the server to use the same = messages as the client: Key Exchange + Certificate Verify (to defeat cross = protocol attacks); but I understand this is a long shot for a draft which i= s meant to be minimal and quick to implement.

Best,
Alfredo


On Mon, Jun 23, 2014 at 7:27 AM, Joseph Salowey (jsa= lowey) <jsalowey@cisco.com> wrote:
WG Members,

The chairs would like to get the sense of the WG on adopting
as a WG document:

http://tools.ietf.org/html/draft-gillmor-tls-negotiate= d-dl-dhe-02

Please make any comments in favor of or against adoption by
Friday July 4. Note: the chairs are aware that there has been
some discussion of the specific groups in this document.
Adopting this document does not commit the WG to these
groups as some or all of these groups may be changed prior
to publication.

Thanks

Joe
(for the chairs)

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

--047d7bdc1a9c12eacb04fc7cab20-- From nobody Mon Jun 23 05:02:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B80C1B2915 for ; Mon, 23 Jun 2014 05:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.654 X-Spam-Level: X-Spam-Status: No, score=-5.654 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99qqWmdjjeK9 for ; Mon, 23 Jun 2014 05:01:56 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.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 B56E91B2916 for ; Mon, 23 Jun 2014 05:01:56 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5NC1oO5009805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Jun 2014 08:01:50 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5NC1mLs006869 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2014 08:01:49 -0400 Message-ID: <1403524908.2337.11.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "Joseph Salowey (jsalowey)" Date: Mon, 23 Jun 2014 14:01:48 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4chLabZJ6jxnsXNOj4Z9yMa7h8s Cc: "" Subject: Re: [TLS] Consensus Call for acceptance of draft-gillmor-tls-negotiated-dl-dhe-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 12:02:01 -0000 On Mon, 2014-06-23 at 05:27 +0000, Joseph Salowey (jsalowey) wrote: > WG Members, > > The chairs would like to get the sense of the WG on adopting > as a WG document: > > http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-02 > > Please make any comments in favor of or against adoption by > Friday July 4. Note: the chairs are aware that there has been > some discussion of the specific groups in this document. > Adopting this document does not commit the WG to these > groups as some or all of these groups may be changed prior > to publication. I support the adoption of this document. From nobody Mon Jun 23 05:08:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D4D1B29C0 for ; Mon, 23 Jun 2014 05:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPCtu7NucsXT for ; Mon, 23 Jun 2014 05:08:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.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 19BFA1B2A1A for ; Mon, 23 Jun 2014 05:07:57 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5NC7ttc013604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Jun 2014 08:07:55 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5NC7r8b012413 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2014 08:07:54 -0400 Message-ID: <1403525272.2337.17.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Martin Thomson Date: Mon, 23 Jun 2014 14:07:52 +0200 In-Reply-To: References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> <1402990596.2335.18.camel@dhcp-2-127.brq.redhat.com> <53A0AB7E.4050706@fifthhorseman.net> <1403173608.5825.6.camel@dhcp-2-127.brq.redhat.com> <1403249527.30440.11.camel@dhcp-2-127.brq.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/A9wE4XqYVcvfJBUbGefR4orwRfU Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 12:08:19 -0000 On Fri, 2014-06-20 at 09:50 -0700, Martin Thomson wrote: > On 20 June 2014 00:32, Nikos Mavrogiannopoulos wrote: > > Could you elaborate on the applications that will be affected by such > > change? I've never seen any such applications, and in fact for the 99% > > of the renegotiation uses (e.g., the web) the renegotiation operation > > would be identical before and after my proposed change. > I'm concerned about applications that rely on renegotiation for > rekeying purposes, not the web scenarios. For instance, those small > number of F5 users that have set a renegotiation timer (see David's > email earlier in the thread). How would these applications be affected? Do you know whether the F5 implementation interleaves the re-handshake with application data? In any case I don't see how can this be used as an argument for removing renegotiation instead of what I proposed. In both cases (if we assume that the F5 implementation does interleave application with handshake data), the implementation would need to be updated. regards, Nikos From nobody Mon Jun 23 06:39:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5811B2AE3 for ; Mon, 23 Jun 2014 06:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-_5NoAk6Yla for ; Mon, 23 Jun 2014 06:39:43 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id CD1171B2AE7 for ; Mon, 23 Jun 2014 06:39:42 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s5NDdZBj004148; Mon, 23 Jun 2014 09:39:41 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "'paul.hoffman@vpnc.org'" , "'tls@ietf.org'" Thread-Topic: [TLS] Curve25519 and TLS Thread-Index: AQHPh06/w7h17LYA/Eqm4mxt4/KM9Jtv08yAgAAGL4CAABFuAIAAM2OAgA4RkYCAAAfKAIAAV1GAgAAy/kc= Date: Mon, 23 Jun 2014 13:39:21 +0000 Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC16668D@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: <8583B665-5964-4AD0-977B-D53620D465EE@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.34.14.22] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-23_07:2014-06-23,2014-06-23,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406230146 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/707KwdBmGLaAOB9DS7S2sT3puEg Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 13:39:45 -0000 You are correct. But the underlying hash must be a PRF for the proofs to ho= ld. -- Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory Cell: (339) 223-5363 244 Wood Street Email: Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ =20 MIT LL Root CA:=20 DSN: 478-5980 ask Lincoln ext.1638 ----- Original Message ----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Monday, June 23, 2014 02:36 AM=0A= To: tls@ietf.org Subject: Re: [TLS] Curve25519 and TLS On Jun 23, 2014, at 2:24 AM, Watson Ladd wrote: >>> Why wouldn't it be? If H(m)=3DH(m'), that's just as much a collision as >>> if H(m || stuff)=3DH(m' || stuff). >>=20 >>=20 >> Well, this isn't quite the two cases we are considering, since we are >> computing either: >>=20 >> HMAC(Key, stuff) >>=20 >> or: >>=20 >> HMAC(Key, H(stuff)) >>=20 >> with: >> - stuff being under partial control of the attacker and >> - the Key being subject to the issue you raise in the message >> that started this thread. >=20 > HMAC is H(key || H(stuff)) right? So it turns into H(key || H(stuff)) > vs H(key || H(H(stuff))). (Yes, there is padding: that's an injective > function, so doesn't matter for this analysis). Once again a collision > means stuff equals stuff both ways. Bellare showed that weakening of the collision resistance in the underlying= hash doesn't matter, right? ? I haven't seen any refutation or weakening of that paper, but I cou= ld have missed it. --Paul Hoffman _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jun 23 07:23:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7181B2961 for ; Mon, 23 Jun 2014 07:23:58 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk6Ilb8gtLwJ for ; Mon, 23 Jun 2014 07:23:56 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37711A0401 for ; Mon, 23 Jun 2014 07:23:56 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id i57so5055829yha.41 for ; Mon, 23 Jun 2014 07:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rioau62lW0zW+pH8zPE3tAd3zLW7nJaJeYp1r0zBlxI=; b=N/2s/Rm7h/3YGpw4A9BRjZlwttYMLHf2/OGAU9ltxPj6F9QvHOhdE7s7aJsnSgveSi 4S56nNkpUixjyed+WjoKSCHaM2y6vkRLYn5RTiNB2wmVSTeyQBRQ+UThwhPSdB7aeOpG UPi4NL1CK5SQ2Jih469EQ2O5v7Gh/yAIo6hqXV95aidiqSWzdHRr/z18b/RklJ1tiwKA lZpRKj90MLCz7SalqRj5nyQ4FhyLLu39OXayC6o2IakUdOluYNuzicfguATnqXvtD9EY 8HyKOxI8q7YrvYE4fWQUBWxKOtTXWS5RgRhTMhoCw8dYEeVKX0Pes2kCSi3VpmvkuEt7 CpYQ== MIME-Version: 1.0 X-Received: by 10.236.15.133 with SMTP id f5mr36013563yhf.63.1403533436012; Mon, 23 Jun 2014 07:23:56 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Mon, 23 Jun 2014 07:23:55 -0700 (PDT) In-Reply-To: <8583B665-5964-4AD0-977B-D53620D465EE@vpnc.org> References: <539B6F1B.4030407@mit.edu> <8583B665-5964-4AD0-977B-D53620D465EE@vpnc.org> Date: Mon, 23 Jun 2014 07:23:55 -0700 Message-ID: From: Watson Ladd To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/29lkv5IopPPGhUM1g9LOtbhFXB0 Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 14:23:59 -0000 On Sun, Jun 22, 2014 at 11:36 PM, Paul Hoffman wrote: > On Jun 23, 2014, at 2:24 AM, Watson Ladd wrote: > >>>> Why wouldn't it be? If H(m)=H(m'), that's just as much a collision as >>>> if H(m || stuff)=H(m' || stuff). >>> >>> >>> Well, this isn't quite the two cases we are considering, since we are >>> computing either: >>> >>> HMAC(Key, stuff) >>> >>> or: >>> >>> HMAC(Key, H(stuff)) >>> >>> with: >>> - stuff being under partial control of the attacker and >>> - the Key being subject to the issue you raise in the message >>> that started this thread. >> >> HMAC is H(key || H(stuff)) right? So it turns into H(key || H(stuff)) >> vs H(key || H(H(stuff))). (Yes, there is padding: that's an injective >> function, so doesn't matter for this analysis). Once again a collision >> means stuff equals stuff both ways. > > Bellare showed that weakening of the collision resistance in the underlying hash doesn't matter, right? ? I haven't seen any refutation or weakening of that paper, but I could have missed it. But here the key is known to the attacker (because it was the result of a DH operation on a point of small order) : that paper is completely irrelevant. Furthermore, all TLS implementations somehow validate signatures: we can use the collision resistant hash from that and avoid having to think about these issues. Sincerely, Watson Ladd > > --Paul Hoffman > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Jun 23 09:54:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C3F1B2B79 for ; Mon, 23 Jun 2014 09:54: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4SO-_aF34YK for ; Mon, 23 Jun 2014 09:54:02 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD9D1B2BEA for ; Mon, 23 Jun 2014 09:43:47 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cc10so4724662wib.1 for ; Mon, 23 Jun 2014 09:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l7nV5W14QcXUSMB3LEbVPZ2zJ7vU8LG1VuvZrKTQsBI=; b=TupASaTYDJb/KUxRSiQ2bjmpat7PSYksIPXp9Qci6cmcvU8w4WKNxe1UrzfB+wLMgA YC3FGJW4E/bLxnM9myNcVtYAbqGwsX0RaOczFkqJO9isVv0P5ifqruMCGyXtWknBzNMa ChPAKH8aVUIqDc5oaQ+dSYQ5MTu/I5I61SlMu85oesQJIjXLX0m0y3J3qzVCtssw2Kyf 2/TyVSN7bz8dPVnmmC/OH7y0HoXPc3UyG1NvQVHp6glSR8JElLKKdWFoIYqbNDu9Hfq+ 6C0jRLxetc/OtRV3wseBfFDaQoierFgoVPS2NxiepaH1PfWrXQcCwm7BntPl6sAOU1Nv jiyw== MIME-Version: 1.0 X-Received: by 10.194.89.168 with SMTP id bp8mr29515800wjb.73.1403541825845; Mon, 23 Jun 2014 09:43:45 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Mon, 23 Jun 2014 09:43:45 -0700 (PDT) In-Reply-To: <1403525272.2337.17.camel@dhcp-2-127.brq.redhat.com> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> <1402990596.2335.18.camel@dhcp-2-127.brq.redhat.com> <53A0AB7E.4050706@fifthhorseman.net> <1403173608.5825.6.camel@dhcp-2-127.brq.redhat.com> <1403249527.30440.11.camel@dhcp-2-127.brq.redhat.com> <1403525272.2337.17.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 23 Jun 2014 09:43:45 -0700 Message-ID: From: Martin Thomson To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dNQohC-zAXFL8f9t9HWOie3HgAU Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 16:54:03 -0000 On 23 June 2014 05:07, Nikos Mavrogiannopoulos wrote: > How would these applications be affected? Dead air is unacceptable for at least one application I'm aware of for long-lived connections (and therefore occasional rekeying), and that is server-to-server XMPP. > Do you know whether the F5 > implementation interleaves the re-handshake with application data? No. Most likely scenarios is that it's not going to do anything other than impose some extra latency on HTTP requests. Though I'll point out that some people do care about that quite a bit. From nobody Mon Jun 23 10:09:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7081A039A; Mon, 23 Jun 2014 10:09:20 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuBbogFnqN2f; Mon, 23 Jun 2014 10:09:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8134E1B2B39; Mon, 23 Jun 2014 10:04:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140623170420.18078.60604.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 10:04:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/699MbLfShVGX3UBKFsSuiW-CtgU Cc: tls@ietf.org Subject: [TLS] TLS Working Group Interim Meeting, July 20, 2014 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 17:09:20 -0000 The TLS WG will hold an interim meeting prior to IETF90 from 10am-4pm on Sunday July 20. The most likely location will be the Mozilla offices in Toronto. The chairs will post details with an agenda and a final location closer to the meeting. Additional information will be announced on the TLS WG mailing list: http://www.ietf.org/mail-archive/web/tls/current/maillist.html From nobody Mon Jun 23 20:12:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3311B2817 for ; Mon, 23 Jun 2014 20:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.879 X-Spam-Level: X-Spam-Status: No, score=0.879 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RncVVlcWCbs0 for ; Mon, 23 Jun 2014 20:12:15 -0700 (PDT) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C92A1B2813 for ; Mon, 23 Jun 2014 20:12:15 -0700 (PDT) Received: from woodstock.owlhill.net (a88-113-163-188.elisa-laajakaista.fi [88.113.163.188]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 8066D40016 for ; Tue, 24 Jun 2014 06:12:10 +0300 (EEST) Received: from [IPv6:2001:14b8:14e:1:a592:1147:e7f2:38ee] (unknown [IPv6:2001:14b8:14e:1:a592:1147:e7f2:38ee]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by woodstock.owlhill.net (Postfix) with ESMTP id 99A9E9092CA for ; Tue, 24 Jun 2014 06:12:10 +0300 (EEST) Message-ID: <53A8EC80.3060309@iki.fi> Date: Tue, 24 Jun 2014 06:12:00 +0300 From: Tapio Sokura User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KBRauEz_i08ZmWtYyPkSZ0YRRRQ Subject: Re: [TLS] Consensus Call for acceptance of draft-gillmor-tls-negotiated-dl-dhe-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 03:12:18 -0000 Hello, On 23.6.2014 8:27, Joseph Salowey (jsalowey) wrote: > The chairs would like to get the sense of the WG on adopting > as a WG document: > > http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-02 Looks good, I support this. A small editorial note, the middle of section 1.2 should include the abbreviation ECDHE immediately in the sentence where it is spelled out, for example "TLS also supports elliptic-curve-based Diffie Hellman ephemeral (ECDHE) key exchanges, but this document does not discuss their use." My layman view on section 5.1 is that I don't think the server needs to indicate it's support of named DHE groups if the negotiated ciphersuite doesn't use them. The client should not make any conclusions about the support of named DHE groups on the server now or in the future, if the server chooses a non-DHE group. Consequently the client should always include the extension on every ClientHello, if the client is willing to use those groups. A good thing in including a 1024 DHE group (section 5.2) in the named group list would be that the client would not need to verify that the group parameters are secure when using a small group. But then again a modern server or client that comes to support this extension will with very high probability support the stronger groups anyway, so I don't think there is a need for weak groups in the spec. If we think of the strengths of the groups in the draft, 112-125-150-175-192 bits, do we even need the 2432 bit group, it's so close to a 3072 bit group? Tapio From nobody Mon Jun 23 21:20:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3959E1B2827 for ; Mon, 23 Jun 2014 21:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.92 X-Spam-Level: X-Spam-Status: No, score=0.92 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Z9jhX87Vb1g for ; Mon, 23 Jun 2014 21:19:58 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5B21B2825 for ; Mon, 23 Jun 2014 21:19:58 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 142so5296572ykq.3 for ; Mon, 23 Jun 2014 21:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=JPnhMt/jOXj+Of+w8g0uGnxtlAoDQVGW4uNCp1ukeis=; b=OCVMtv7gZnh+nR/2ze/k8Xn5h4uszo23AR9dJJgCsnmPiWHmPTuHzIifw8VpiPUzuE wUl02wCt8C9DyOrhyKsHMRrCr5515WFQzrnxsP/LycatEhwVTIp8v4dlS10oyol59CIb 2qopQPXKTV1OIVFZhnZn/PvIN7jF6XZLOeNY+r6jOSaYYVSW8bmnheF69RX52OFeHi/c Dgc0Cy9a+4tcwb3aoH2EEQwITqTZvGQBp3Jm6/UYSsvTEJoLQ4c6Fz6wpjacj/CoT6e8 OGjjod8LUUp/RpVG4oK/Dz/XHrEd2kdeQmQaS/lZBbb2P58JlxMtrQ7sJvLf9tHRb+dO eJ8A== MIME-Version: 1.0 X-Received: by 10.236.156.170 with SMTP id m30mr41248556yhk.60.1403583597645; Mon, 23 Jun 2014 21:19:57 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Mon, 23 Jun 2014 21:19:57 -0700 (PDT) In-Reply-To: <53A8EC80.3060309@iki.fi> References: <53A8EC80.3060309@iki.fi> Date: Mon, 23 Jun 2014 21:19:57 -0700 Message-ID: From: Watson Ladd Cc: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jilrP6yp9vPPg_2PRMpjAi5ZyKQ Subject: Re: [TLS] Consensus Call for acceptance of draft-gillmor-tls-negotiated-dl-dhe-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 04:19:59 -0000 Dear all, I'm very undecided about this proposal. While it does solve a security issue in TLS, so does disabling DHE in favor of ECDH. It's likely that this extension will not be widely deployed, and DHE without the extension is insecure. I think we run the risk of implementations supporting DHE, ostensibly with the extension, but in practice still vulnerable to Triple DH. Given the performance disadvantages of DHE compared with ECDH, I don't really see a benefit to supporting it, given that legacy implementations will not support this extension. Sincerely, Watson From nobody Tue Jun 24 02:24:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1771B28A4 for ; Tue, 24 Jun 2014 02:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.654 X-Spam-Level: X-Spam-Status: No, score=-5.654 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFHCkybsAy5L for ; Tue, 24 Jun 2014 02:24:13 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.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 D725D1B289E for ; Tue, 24 Jun 2014 02:24:13 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5O9OBCt004906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 24 Jun 2014 05:24:12 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5O9O9UX022515 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2014 05:24:11 -0400 Message-ID: <1403601849.2337.50.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Watson Ladd Date: Tue, 24 Jun 2014 11:24:09 +0200 In-Reply-To: References: <53A8EC80.3060309@iki.fi> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DsvabnCueJCUU4hf6xeNHHaRURk Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus Call for acceptance of draft-gillmor-tls-negotiated-dl-dhe-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 09:24:15 -0000 On Mon, 2014-06-23 at 21:19 -0700, Watson Ladd wrote: > Dear all, > > I'm very undecided about this proposal. While it does solve a security > issue in TLS, so does disabling DHE in favor of ECDH. It's likely that > this extension will not be widely deployed, and DHE without the > extension is insecure. I think we run the risk of implementations > supporting DHE, ostensibly with the extension, but in practice still > vulnerable to Triple DH. Given the performance disadvantages of DHE > compared with ECDH, I don't really see a benefit to supporting it, > given that legacy implementations will not support this extension. The disadvantage of what you propose is that we stick with ECDHE, and on the first vulnerability known for the ECDHE ciphersuites we have no alternative to fall back (note that the proposal solves a compatibility issue of the DHE ciphersuites, it is not solely a security enhancement as you imply - see the abstract and introduction). regards, Nikos From nobody Tue Jun 24 03:05:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0421B29B3 for ; Tue, 24 Jun 2014 03:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIxi7c56UAxX for ; Tue, 24 Jun 2014 03:05:07 -0700 (PDT) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by ietfa.amsl.com (Postfix) with ESMTP id 639F81B28BC for ; Tue, 24 Jun 2014 03:05:07 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s5OA56iv004237; Tue, 24 Jun 2014 06:05:06 -0400 Date: Tue, 24 Jun 2014 06:05:05 -0400 (EDT) From: Hubert Kario To: Tapio Sokura Message-ID: <1792783108.31711137.1403604305162.JavaMail.zimbra@redhat.com> In-Reply-To: <53A8EC80.3060309@iki.fi> References: <53A8EC80.3060309@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF30 (Linux)/8.0.6_GA_5922) Thread-Topic: Consensus Call for acceptance of draft-gillmor-tls-negotiated-dl-dhe-02 Thread-Index: xXSQlYt6RAH0t0U5tkpmGnxmMeF1zw== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jdnBmBPw5YJ88PWaL-SneI41o-k Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call for acceptance of draft-gillmor-tls-negotiated-dl-dhe-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 10:05:09 -0000 ----- Original Message ----- > From: "Tapio Sokura" > To: tls@ietf.org > Sent: Tuesday, 24 June, 2014 5:12:00 AM > Subject: Re: [TLS] Consensus Call for acceptance of draft-gillmor-tls-negotiated-dl-dhe-02 > > Hello, > > On 23.6.2014 8:27, Joseph Salowey (jsalowey) wrote: > > The chairs would like to get the sense of the WG on adopting > > as a WG document: > > > > http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-02 > If we think of the > strengths of the groups in the draft, 112-125-150-175-192 bits, do we > even need the 2432 bit group, it's so close to a 3072 bit group? 112 bits matches the strength of 3DES, while 125 bit is basically the 128 bit level of AES or Camellia. Since the work factor for the server increases exponentially, I'd say that yes, we need both 2432 bit and 3072 bit groups. -- Regards, Hubert Kario From nobody Tue Jun 24 16:44:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852871B29CB for ; Tue, 24 Jun 2014 16:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Itt3wXubqPOM for ; Tue, 24 Jun 2014 16:43:57 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C526C1B29BF for ; Tue, 24 Jun 2014 16:43:56 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s5ONhp4Q016249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jun 2014 01:43:51 +0200 (MEST) In-Reply-To: To: Geoffrey Keating Date: Wed, 25 Jun 2014 01:43:51 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140624234351.32F161AD64@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4JeuYcA0ixCzXYP98YEHMI12UOY Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation: trying to summarize X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 23:43:58 -0000 Geoffrey Keating wrote: > > I believe there was also a proposal to allow client auth at any point > during the session, but not renegotiate: no new ciphers, no new keys, > just send CertificateRequest and get back Client Certificate and > CertificateVerify. This does prevent use of client certificates with > encryption-only algorithms, but it seems such a thing should be used > from the start of the connection anyway. > > Compared to renegotiation this allows many simplifications: I believe that just the opposite is true, this opens a whole new can of worms. Really, the existing renegotiation is both strong and simple. For most of our (customer's) usage scenarios, TLS session caching is a MUST, and the session caching concept with renegotiation is simple and clear. A TLS session that authenticates only the server (certificate) within TLS has different properties than a TLS session that authenticates both, client&server. With traditional renegotiation, these are distinct SSL sessions (as far as caching is concerned), and either one can be resumed. The most common use of renegotiation is to change the status of one (or both) peers from not authenticated in the existing session to authenticated in the renegotiated session. There was a problem with TLS implementations *NOT* nailing down an authenticated identiy to _not_change_ during renegotiation, unless the application has specifically requested for this to be allowed through new/non-standard API calls (this is nothing that should happen to an application by mere configuration tweaks). This problem has already been described in the security considerations of rfc5746 and it was the interim workaround suggested to browsers for the triple-handshake-attack (which seem to have boldly ignored the issue from the rfc5746 security considerations section...). -Martin From nobody Tue Jun 24 19:18:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8EC1B2A4C for ; Tue, 24 Jun 2014 19:18:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_66=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niNsTeJu8H92 for ; Tue, 24 Jun 2014 19:18:28 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C518D1B2A44 for ; Tue, 24 Jun 2014 19:18:28 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id q9so737169ykb.15 for ; Tue, 24 Jun 2014 19:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UAYY48BGFVLCXUzVoLBc9C2o9Iq8uSj/KJ0F9klIFm4=; b=yTNhBHTTS+p0zrYa9KrIpCGk26JMmeeO26PVyuV5pWx3gCeWiIPdmdqn1QWOztUE8h 063oHghlvYC9KeAcV14sok+PtjP4Mbesxke9RqYmUYRqrKI/1hjYrA+BWqoH4RhiNcZT egto6jyFCFx3Uqix6eQT8lCxX9cgG19USm/vmz2pv1I8SWyqp1bDWmouTaY3OZOiwAXj 9takgs9/ddho1TXxlJE3fZzEcvc1QtcQQk8w2shz1Hs++dpB29RXLDuTn02aOldgrYhN Ki6dy4ZRQs2JqhWD9js5x19yN4YQwt0H3MIbakov08npx2hWi1HgoSilc1EHORtB/u36 chug== MIME-Version: 1.0 X-Received: by 10.236.108.176 with SMTP id q36mr6776507yhg.87.1403662708072; Tue, 24 Jun 2014 19:18:28 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Tue, 24 Jun 2014 19:18:28 -0700 (PDT) In-Reply-To: <20140624234351.32F161AD64@ld9781.wdf.sap.corp> References: <20140624234351.32F161AD64@ld9781.wdf.sap.corp> Date: Tue, 24 Jun 2014 19:18:28 -0700 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/po0w5FgD1IIGXunKvOC9110ZzEw Cc: Geoffrey Keating , "tls@ietf.org" Subject: Re: [TLS] Renegotiation: trying to summarize X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 02:18:30 -0000 On Tue, Jun 24, 2014 at 4:43 PM, Martin Rex wrote: > Geoffrey Keating wrote: >> >> I believe there was also a proposal to allow client auth at any point >> during the session, but not renegotiate: no new ciphers, no new keys, >> just send CertificateRequest and get back Client Certificate and >> CertificateVerify. This does prevent use of client certificates with >> encryption-only algorithms, but it seems such a thing should be used >> from the start of the connection anyway. >> >> Compared to renegotiation this allows many simplifications: > > I believe that just the opposite is true, this opens a whole new can > of worms. > > Really, the existing renegotiation is both strong and simple. > > > For most of our (customer's) usage scenarios, TLS session caching > is a MUST, and the session caching concept with renegotiation is > simple and clear. > > A TLS session that authenticates only the server (certificate) within > TLS has different properties than a TLS session that authenticates > both, client&server. With traditional renegotiation, these are > distinct SSL sessions (as far as caching is concerned), and either > one can be resumed. Yes, this is a problem that has to be carefully considered if we permit state changes in TLS. > > > The most common use of renegotiation is to change the status of > one (or both) peers from not authenticated in the existing session > to authenticated in the renegotiated session. > > There was a problem with TLS implementations *NOT* nailing down > an authenticated identiy to _not_change_ during renegotiation, unless > the application has specifically requested for this to be allowed > through new/non-standard API calls (this is nothing that should happen > to an application by mere configuration tweaks). This problem has > already been described in the security considerations of rfc5746 > and it was the interim workaround suggested to browsers for the > triple-handshake-attack (which seem to have boldly ignored the > issue from the rfc5746 security considerations section...). There is nothing a client can do about the original renegotiation issue. With Triple-Handshake some usages (tls-unique channel bindings) are doomed, and others (web authentication) have to take special care that server names don't change on renegotiation, even though it was "fixed". It's not surprising that people ignored the need for client-side fixes, because rfc5746 had an extension that claimed to fix the problem without rewriting code. However, end of the day we have to deal with the implementations and code that we have. 90% of it cannot handle renegotiation correctly in the most general form. So we need to restrict the semantics, and how we do that I don't know, because I don't know what the expected semantics are. Sincerely, Watson Ladd > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue Jun 24 20:03:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22D51B2A77 for ; Tue, 24 Jun 2014 20:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcrH6eQj-do9 for ; Tue, 24 Jun 2014 20:03:30 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F871B2A3F for ; Tue, 24 Jun 2014 20:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1403665410; x=1435201410; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=qAI5o3C2Wyv5QsgA/zbm2eQ526fdSf3HanckRt9NOkk=; b=iCoIPTTLgcakxpiHJ/+z/z6cFHwsCFkDWblGMfsjkurUvCde0lUCTC8Z dUklXK0AGXTGwNZT7ocP1+XDVzUKhmnZfy+CLwCzoJ/+JscknN13BoNdK zG0O+fKw81zjbGMYPNMKv8hZHMiCSdWk4O8rEBWRjdIIQ1ARIn3EQxwZG U=; X-IronPort-AV: E=Sophos;i="5.01,542,1399982400"; d="scan'208";a="260440635" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 25 Jun 2014 15:03:27 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 25 Jun 2014 15:03:26 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Consensus Call for acceptance of Thread-Index: Ac+QIggiGi1D+35SSRqlhCEAyPCO6g== Date: Wed, 25 Jun 2014 03:03:25 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DECE365@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rnfKeQ0Pq-8MziEwcNHf9I4XpVc Subject: Re: [TLS] Consensus Call for acceptance of X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 03:03:36 -0000 Watson Ladd writes:=0A= =0A= >DHE without the extension is insecure.=0A= =0A= Why?=0A= =0A= (I know the abstract reason, but an unqualified "DHE without the extension = is=0A= insecure" is a bit like saying "ECDH is insecure", there is a situation whe= re=0A= it's insecure but it's pretty unlikely).=0A= =0A= >Given the performance disadvantages of DHE compared with ECDH, I don't rea= lly=0A= >see a benefit to supporting it, given that legacy implementations will not= =0A= >support this extension.=0A= =0A= Legacy implementations won't support ECDH either, and adding a minor extens= ion=0A= to DH is easier and quicker than adding support for ECC.=0A= =0A= Peter.=0A= From nobody Tue Jun 24 21:51:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0833D1B2AB6 for ; Tue, 24 Jun 2014 21:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bU5Affa0bTut for ; Tue, 24 Jun 2014 21:51:25 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931C01B2AAD for ; Tue, 24 Jun 2014 21:51:25 -0700 (PDT) Received: from [10.0.69.132] (unknown [198.0.208.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by dragaera.releasedominatrix.com (Postfix) with ESMTP id E4ED233D025; Wed, 25 Jun 2014 04:51:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Geoff Keating In-Reply-To: <20140624234351.32F161AD64@ld9781.wdf.sap.corp> Date: Tue, 24 Jun 2014 21:51:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <59837AA9-8C37-42D2-AB8B-A45AF6B02B97@geoffk.org> References: <20140624234351.32F161AD64@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_aT3EYGl13itnmkYHIyYAed7tc0 Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation: trying to summarize X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 04:51:28 -0000 On 24 Jun 2014, at 4:43 pm, Martin Rex wrote: > Geoffrey Keating wrote: >>=20 >> I believe there was also a proposal to allow client auth at any point >> during the session, but not renegotiate: no new ciphers, no new keys, >> just send CertificateRequest and get back Client Certificate and >> CertificateVerify. This does prevent use of client certificates with >> encryption-only algorithms, but it seems such a thing should be used >> from the start of the connection anyway. >>=20 >> Compared to renegotiation this allows many simplifications: >=20 > I believe that just the opposite is true, this opens a whole new can > of worms. >=20 > Really, the existing renegotiation is both strong and simple. >=20 >=20 > For most of our (customer's) usage scenarios, TLS session caching > is a MUST, and the session caching concept with renegotiation is > simple and clear. I think there is strong evidence to the contrary: If it was simple and = clear, the triple handshake attacks would not have been possible. > A TLS session that authenticates only the server (certificate) within > TLS has different properties than a TLS session that authenticates > both, client&server. With traditional renegotiation, these are > distinct SSL sessions (as far as caching is concerned), and either > one can be resumed. So, in current TLS, if a session is established with no client = authentication, and then there's renegotiation with a client = certificate, and then the first session is resumed, has that resumed = session been authenticated by the client certificate? It seems like = with the renegotiation fix, the entity that established the second = session has signed data that associates them with the first session. = Did they mean to do that? Will the server interpret it that way? Is it = safe for the server to interpret it that way? > The most common use of renegotiation is to change the status of > one (or both) peers from not authenticated in the existing session > to authenticated in the renegotiated session. Actually, it is used to change the status in *both* sessions. In HTTPS, = the protocol exchange does not go: -> PUT authenticated path <- please renegotiate, and now I want a client auth <> renegotiation <- thank you, but your previous request gets an error because it was = sent before you authenticated -> PUT authenticated path <- OK, send me the data what actually happens is: -> PUT authenticated path <- please renegotiate, and now I want a client auth <> renegotiation <- thank you, send me the data The server uses the renegotiation to authenticate the request sent = before the renegotiation. (I used PUT here to make it clearer, but the = same principle applies to a regular GET request.) From csnps@bristol.ac.uk Wed Jun 25 01:28:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013331B2B18 for ; Wed, 25 Jun 2014 01:28:55 -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_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM7KIhYaDH_n for ; Wed, 25 Jun 2014 01:28:44 -0700 (PDT) Received: from eu1sys200aog131.obsmtp.com (eu1sys200aog131.obsmtp.com [207.126.144.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334FD1B2B16 for ; Wed, 25 Jun 2014 01:28:43 -0700 (PDT) Received: from mail-wg0-f41.google.com ([74.125.82.41]) (using TLSv1) by eu1sys200aob131.postini.com ([207.126.147.11]) with SMTP ID DSNKU6qIOdcTLMlzWOMbDodKGFxFMw918Y1v@postini.com; Wed, 25 Jun 2014 08:28:44 UTC Received: by mail-wg0-f41.google.com with SMTP id a1so1646258wgh.24 for ; Wed, 25 Jun 2014 01:28:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=s7DENSeXJdlzQtbWaj3JlmhhFWoE6bouJ64lNW5+/Eo=; b=CdJGaBW5pU2cY+2CnxdaUBhOkpGGfRZ5SqsJuozSpl/RDr10+Cn7j78bglca2UAqAK gcdqBpvySpo4+b1QKd5oT1J5tB/NZzfAbg5LRiS4nB1/l6LIuCKd3FsxFvmksiBzTGdO Kfa5MmpwwGQhaNW/qQxzDpXvb8jY9SqEB/obTG/YnqPIcp0YU1Vj44EJmDTFGnLUBAnX sYcNNbZwnvqbaj8APxnp0VWSxV7y5NShJ5nvOypnw7echDeykaGn24cDPvMs71crQbFa IbsWvPHjJdBn+OQtS0owpGAb0aoCrxMUxCuMjIPNDuUpxlVjBG/m6rPBlxPcbd0s0PBT h+BA== X-Gm-Message-State: ALoCoQmNlMAqGOy3iko1rCYDhHn/iBkTlRs5MdRGVaPrF224pJQRYQp6rPhtfqNx34crYzH6U+D7XBi1TsuFSj5O9YF3gAaTJIDvZn0J516cGjrJJvkhSug2DNQhPQ73czZ6f5OvRz+i X-Received: by 10.194.237.135 with SMTP id vc7mr8183659wjc.86.1403684921616; Wed, 25 Jun 2014 01:28:41 -0700 (PDT) X-Received: by 10.194.237.135 with SMTP id vc7mr8183648wjc.86.1403684921537; Wed, 25 Jun 2014 01:28:41 -0700 (PDT) Received: from [192.168.1.78] (host86-173-16-66.range86-173.btcentralplus.com. [86.173.16.66]) by mx.google.com with ESMTPSA id wu6sm5922918wjb.46.2014.06.25.01.28.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 01:28:40 -0700 (PDT) Sender: Nigel Smart Message-ID: <53AA8839.8000507@cs.bris.ac.uk> Date: Wed, 25 Jun 2014 09:28:41 +0100 From: Nigel Smart User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/p1O87r2lm34ZCjqs4IMp06LXIAM Subject: [TLS] Schnorr Signatures X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 08:30:02 -0000 Hi [First post to list so please ignore any breaking of etiquette etc] As we are moving to TLS 1.3 I wondered why not include EC-Schnorr signatures in the standard as a possible addition to EC-DSA for the signing. Some notes... i) Schnorr is faster than EC-DSA ii) Patent has expired iii) Shorter signatures iv) Has a proper proof of security and not "tainted" by NSA design - Unlike EC-DSA in both instances. v) Protects against hash collisions. i.e. any hash function break involving collisions does not provide an attack on the signature scheme. vi) Allows various other tricks to be done more easily vii) Already standardized in ISO. The ISO standard just gives Schnorr as a tweak on the EC-DSA signature. So there is not much work to do. viii) Can use the same EC-DSA certs as EC-DSA signing. All that changes is how the signing equation is generated and verified. Cheers Nigel From nobody Wed Jun 25 11:04:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339931B2D8D for ; Wed, 25 Jun 2014 11:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQOd9G9yY7U3 for ; Wed, 25 Jun 2014 11:04:49 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B951B2D9A for ; Wed, 25 Jun 2014 11:04:48 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 0659233D0BA; Wed, 25 Jun 2014 18:04:47 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C738DECE365@uxcn10-tdc06.UoA.auckland.ac.nz> From: Geoffrey Keating Date: 25 Jun 2014 11:04:47 -0700 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738DECE365@uxcn10-tdc06.UoA.auckland.ac.nz> Message-ID: Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9_hSeD1a0NFdB2CkAHqIgx7zfF8 Cc: "" Subject: Re: [TLS] Consensus Call for acceptance of X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 18:04:51 -0000 Peter Gutmann writes: > Legacy implementations won't support ECDH either, and adding a minor > extension to DH is easier and quicker than adding support for ECC. I think for most cases, the effort is exactly the same: you have to upgrade to something later than Windows XP or OpenSSL 0.9.7. Except that for ECDH you can upgrade to something that actually exists today (and has existed for many years) but to implement this new extension you need to upgrade to something that does not yet exist. From nobody Wed Jun 25 11:20:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB871B2DD1 for ; Wed, 25 Jun 2014 11:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8muBsVmMq68 for ; Wed, 25 Jun 2014 11:20:30 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 85DD61B2DD6 for ; Wed, 25 Jun 2014 11:20:29 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D1B80482FF; Wed, 25 Jun 2014 18:20:28 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id C5AE5482FE; Wed, 25 Jun 2014 18:20:28 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id ACDFE1E03D; Wed, 25 Jun 2014 18:20:28 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Wed, 25 Jun 2014 14:20:28 -0400 From: "Salz, Rich" To: Geoffrey Keating , Peter Gutmann Date: Wed, 25 Jun 2014 14:20:26 -0400 Thread-Topic: [TLS] Consensus Call for acceptance of Thread-Index: Ac+Qn/7ebflCDmNvRFGpk40ztOL7WwAAfnsA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF0D0@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C738DECE365@uxcn10-tdc06.UoA.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zfmlegzi4L5uFUQ_F10lR63IN3E Cc: "" Subject: Re: [TLS] Consensus Call for acceptance of X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 18:20:33 -0000 In our experience, the issue is legacy embedded devices and old Android pho= nes, not XP. And therefore, I'd be inclined to go with Peter's suggestion. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Wed Jun 25 11:24:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547351B2E06 for ; Wed, 25 Jun 2014 11:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LHEVK0mCkSC for ; Wed, 25 Jun 2014 11:23:48 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8181F1B2E01 for ; Wed, 25 Jun 2014 11:23:47 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id r20so3103071wiv.10 for ; Wed, 25 Jun 2014 11:23:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DIUXWmA61LcgxgYN3rCIQe67Kn118T+v9Da4zrT54aM=; b=gs9pKEEWMpqrsG/TmFTgTRh3hThfY0E0ZhGWVwGOtVHgsHm7L93nfaighrR7hGrsZe yAQZ0XE0zJ555Rdzb061qdTr3AF9KwmVTYvWQv79VRVvZhuHPfPoBRs8eWg4yxMyTK5T 234r8xF3Cfqd5WbA/aYPVS0IiY0KiGqAp4V4CM8CW15RTEG1lb3a2PaBCRY1KXlSOwXO tHh9nyAuy4RUCwk1Xz8IJO69mIxtCkcSa5C9Sf0+C9xoEaKc9CjW4LHmEmV9wktzK++o AzkgQbDmk0RJea78MWoQKR4h2rWQNgK22I5sPB4iZN7ESzbAZuS1wc8G9STUjRGeEKeZ l70A== X-Gm-Message-State: ALoCoQlwznPIHJBm+YNyQLT+CUFkAdaNHXPrVgS/PM6uNE0iPB1JpC2JNiXMJPyHtUH9VMSfPOMy X-Received: by 10.194.1.164 with SMTP id 4mr11597611wjn.17.1403720626064; Wed, 25 Jun 2014 11:23:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 25 Jun 2014 11:23:05 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:f15c:fb0:15f2:d485] In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF0D0@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C738DECE365@uxcn10-tdc06.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF0D0@USMBX1.msg.corp.akamai.com> From: Eric Rescorla Date: Wed, 25 Jun 2014 11:23:05 -0700 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=047d7b3a817647e90104fcad2d38 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/76ihG9PxwIoVtdO3fLJnlzrv-6w Cc: "" , Geoffrey Keating Subject: Re: [TLS] Consensus Call for acceptance of X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 18:23:56 -0000 --047d7b3a817647e90104fcad2d38 Content-Type: text/plain; charset=UTF-8 Speaking as individual I am in favor of adopting this draft. -Ekr On Wed, Jun 25, 2014 at 11:20 AM, Salz, Rich wrote: > In our experience, the issue is legacy embedded devices and old Android > phones, not XP. And therefore, I'd be inclined to go with Peter's > suggestion. > > /r$ > > -- > Principal Security Engineer > Akamai Technologies, Cambridge, MA > IM: rsalz@jabber.me; Twitter: RichSalz > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7b3a817647e90104fcad2d38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Speaking as individual I am in = favor of adopting this draft.

-Ekr


On Wed, Jun 25, 2014 at 11:20 AM, Salz, Rich <rsalz@akamai.com> wrote:
In our experience, the issue is legacy embedded devices and old Android pho= nes, not XP. =C2=A0And therefore, I'd be inclined to go with Peter'= s suggestion.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 /r$

--
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rsalz@jabber.me; Twitter: RichSa= lz

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

--047d7b3a817647e90104fcad2d38-- From nobody Wed Jun 25 11:34:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245691B2DD7 for ; Wed, 25 Jun 2014 11:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3Ccbmpzk6DC for ; Wed, 25 Jun 2014 11:34:46 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A2F1B2DB1 for ; Wed, 25 Jun 2014 11:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=620; q=dns/txt; s=iport; t=1403721285; x=1404930885; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=mlMvzntc7HJpxinZ0aIFtGoTxzg/xjBIbuBjUw8Oe0o=; b=K8qN2nmUD6HnNVkh4z4UCCQ10V2H3g7BVvTY21v3l3BvfzyA9Qk7ahpx hpL7565eNg93RX8Vx75jJcTWD0KFs8/tU55DrCoY4Jp/BUe5jkdWAaP3S O5ljpmAqSGfxTfcZsyYZj2/qp2n+rSh+MybjPIghME0Wn+BSvwbEsgjMQ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFACkVq1OtJV2c/2dsb2JhbABXgw2BLKoNBQGaSRZ1hAodHVEBPkInBIhVlSKtQheFY4xNgRYFmlGTa4NCgjA X-IronPort-AV: E=Sophos;i="5.01,547,1400025600"; d="scan'208";a="55922281" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP; 25 Jun 2014 18:34:45 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5PIYiuL001282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 25 Jun 2014 18:34:45 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Wed, 25 Jun 2014 13:34:44 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Call for Consensus on removal of renegotiation Thread-Index: AQHPkKQi2ibdHwQZAU+UoLazXGbTxA== Date: Wed, 25 Jun 2014 18:34:44 +0000 Message-ID: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.35] Content-Type: text/plain; charset="us-ascii" Content-ID: <328BE6F6958F5F409C6F4564DF4667DB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/flU2jm5yfFwFolKpt9QxG6DTgC4 Subject: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 18:34:47 -0000 We would like to see if there is consensus on removing renegotiation in TLS= 1.3. We had rough consensus at the interim to remove renegotiation. Pleas= e state your position by indicating preference for one of the following (we= will have a separate consensus call to decide on rekey approach).=20 1. Do you favor removing renegotiation from TLS 1.3 either with or without = an additional facility for rekey? 2. Are you in favor of not removing renegotiation regardless of the additio= n of a separate rekey facility? Please respond to the list by July 1, 2014. =20 Thanks, Joe (for the chairs)= From nobody Wed Jun 25 11:47:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BDC1B2E1A for ; Wed, 25 Jun 2014 11:47:29 -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_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8F5F4wHLWaw for ; Wed, 25 Jun 2014 11:47:26 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 195EF1B2E1D for ; Wed, 25 Jun 2014 11:47:26 -0700 (PDT) Received: from [10.70.10.68] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id CF887F984 for ; Wed, 25 Jun 2014 14:47:23 -0400 (EDT) Message-ID: <53AB192F.2040001@fifthhorseman.net> Date: Wed, 25 Jun 2014 14:47:11 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: "" References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> In-Reply-To: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kTSKiBd5Ruko2c3WwWq3hAPuVBWPKs6E8" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2Uyoi_pQJg1nns0gb4mTB5NbdxI Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 18:47:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kTSKiBd5Ruko2c3WwWq3hAPuVBWPKs6E8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/25/2014 02:34 PM, Joseph Salowey (jsalowey) wrote: > We would like to see if there is consensus on removing renegotiation in= TLS 1.3. We had rough consensus at the interim to remove renegotiation.= Please state your position by indicating preference for one of the follo= wing (we will have a separate consensus call to decide on rekey approach)= =2E=20 >=20 > 1. Do you favor removing renegotiation from TLS 1.3 either with or with= out an additional facility for rekey? > 2. Are you in favor of not removing renegotiation regardless of the add= ition of a separate rekey facility? If we're supposed to select either 1 or 2, i wouldn't feel comfortable with either one. If we aren't providing an additional facility for re-keying, then i am not OK with removing renegotiation. TLS needs a way for high-traffic, longstanding connections to stay up without "dead air" (as i think Sean called it earlier). So i can't choose (1). OTOH, if we have a separate rekey facility, i think that the semantics of TLS will be clearer (easier for application developers to understand and work with; easier for cryptanalysts to evaluate) if we get rid of renegotiation. So i can't choose (2). Maybe this question needs to be re-framed, or we need an option 0? --dkg --kTSKiBd5Ruko2c3WwWq3hAPuVBWPKs6E8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTqxkvXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcQHQP/1RzMaEUXghJGUr3KFYlhpzZ NhOeb6CQ1484qf5JSebc2b/pjms0+8iJToXlvM2hjQW7rLmCyFFMxtuQSZnx4xSn 8L6fTMbp44/J+H8iFRe0zahpRI4plSxg8don4YEfq12mj5v9nwoQecSvUCGXZoLd l14h79r91HsNLUIAhWeAnBjtfZutGKQnuMbtvoVjvI1mqCnc/5dguXGJdSURAih8 JKlP/Y5VNH4QV8UTpG8eqdPGkrtArl8sKdUUio+9sg23c+OphlfA+zJQr8JQlEzt dIWm3Y8aUwDh95GQwZ/FE+xeQSzXjPCPlSjEi/X4HzyKv5Ipsmrj3Ly7BPlEBSWw nT56WNJiVjKAzWIYyW17UK0Re1skzsHA4qG0vA0XFve2Hy3UbPmFr0HsG3R/VPQT r7wlvTutgN1LobAUrFvuOpok9aY1X5/6whCsvrVCrPtH9NEd0Fn2ks0ubTq1wgkB RJyMk4CiiyxlwT4xnQlVGEvSFQXCbBvj4amVRAU0BFv0U8vlx01GbknCpPqsEvMy nkBEp0bFJyCZc0Iy5qxauKWN9r/WUtKtf2yyczDGczdDKF0jNu6Xzh0ygy5L+ZzU cOc0emKq8zOHp21bytmopH0ipqbUR6+tsFVwa+GTKJ7VPx/jn5HdQuBBX+/wYvow 5iOvDQY1OaQevS4tP+We =YfUz -----END PGP SIGNATURE----- --kTSKiBd5Ruko2c3WwWq3hAPuVBWPKs6E8-- From nobody Wed Jun 25 13:03:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05E21B2E59 for ; Wed, 25 Jun 2014 13:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyidcsHhcDZy for ; Wed, 25 Jun 2014 13:03:08 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0949F1B2E58 for ; Wed, 25 Jun 2014 13:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2797; q=dns/txt; s=iport; t=1403726588; x=1404936188; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=P9pQ9uVaYasr9j72mS5T6Li5bR8osDoTSDyyaDcMeAk=; b=RY6n1X0e4QBA3oy4ZTk3EKVh5Z36IPUxm+71C8KewyFATfEpc7Rhy6Mk C2lh1InlmLy4AZksqDsKKoxcvLafB/nqXdd2KjCZg0YkkCLPIvR6cjIFG O/rsYZBbzBUmn8xn696cGp1vrcEswnSDTQDiStjpx0A1FpRKm28tue0JU Q=; X-Files: signature.asc : 495 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAFAE4qq1OtJA2L/2dsb2JhbABZgw1SWqoSBQGReodAAYEOFnWEAwEBAQMBAQEBGlELBQsCAQgYLicLJQIEDgUOiCwIDcMzEwSFY4kZB4MtgRYFkgiBQYcIk2uDQoIw X-IronPort-AV: E=Sophos;i="5.01,547,1400025600"; d="asc'?scan'208";a="335723733" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP; 25 Jun 2014 20:03:07 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s5PK37Xj002118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Jun 2014 20:03:07 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Wed, 25 Jun 2014 15:03:07 -0500 From: "Joseph Salowey (jsalowey)" To: Daniel Kahn Gillmor Thread-Topic: [TLS] Call for Consensus on removal of renegotiation Thread-Index: AQHPkKQi2ibdHwQZAU+UoLazXGbTxJuCfkiAgAAVKgA= Date: Wed, 25 Jun 2014 20:03:06 +0000 Message-ID: References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> In-Reply-To: <53AB192F.2040001@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.35] Content-Type: multipart/signed; boundary="Apple-Mail=_24927898-5E06-4552-B0A4-5D8A1BCC788F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NL-JDDPe-XYEkRZmOI-Mh7iJaXs Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 20:03:14 -0000 --Apple-Mail=_24927898-5E06-4552-B0A4-5D8A1BCC788F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 25, 2014, at 11:47 AM, Daniel Kahn Gillmor = wrote: > On 06/25/2014 02:34 PM, Joseph Salowey (jsalowey) wrote: >> We would like to see if there is consensus on removing renegotiation = in TLS 1.3. We had rough consensus at the interim to remove = renegotiation. Please state your position by indicating preference for = one of the following (we will have a separate consensus call to decide = on rekey approach).=20 >>=20 >> 1. Do you favor removing renegotiation from TLS 1.3 either with or = without an additional facility for rekey? >> 2. Are you in favor of not removing renegotiation regardless of the = addition of a separate rekey facility? >=20 > If we're supposed to select either 1 or 2, i wouldn't feel comfortable > with either one. >=20 > If we aren't providing an additional facility for re-keying, then i am > not OK with removing renegotiation. TLS needs a way for high-traffic, > longstanding connections to stay up without "dead air" (as i think = Sean > called it earlier). So i can't choose (1). >=20 > OTOH, if we have a separate rekey facility, i think that the semantics > of TLS will be clearer (easier for application developers to = understand > and work with; easier for cryptanalysts to evaluate) if we get rid of > renegotiation. So i can't choose (2). >=20 > Maybe this question needs to be re-framed, or we need an option 0? >=20 [Joe] to simplify: 1. In favor of removing renegotiation 2. In favor of removing renegotiation with the addition of rekey = facility 3. Not in favor of removing renegotiation=20 (the first attempt combined 1 and 2) > --dkg >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_24927898-5E06-4552-B0A4-5D8A1BCC788F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTqyr7AAoJEHDh2NpbGbjAD84H/jw7cM2gGRF/c8n4sUIZ+R3J crasi4uSzX7MYZrCrpWExGpRz/MLjmXO74+H7NDtMEMdODUkYOzEj/RnGDujybSO Wsi9pzUfs+j8gIkdU04xqessklLFZznmrbkI0p81qCBivZfkjJ0hPWn4H6+BTfJj Moo5fHQTSsNyv3uRrF321U1t8084c9LNhddTfXfitJHzYD8uxIrRgw5xaEZDqvRR l5rGM96JU/6TovYDOuFvlOfJ9yVMIWooqY8JJQsQQksEG+8SuXnGAlwgQGTadKN7 EGs7tjwbQ0miAMewmb1TWI/i6zeujaDUfRkmK/BELKPh3jAEGrUyykpHm9xsYDA= =G0xZ -----END PGP SIGNATURE----- --Apple-Mail=_24927898-5E06-4552-B0A4-5D8A1BCC788F-- From nobody Wed Jun 25 13:13:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562BB1A00BE for ; Wed, 25 Jun 2014 13:13:18 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvwmP4kPeSqZ for ; Wed, 25 Jun 2014 13:13:15 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2AE1A00D3 for ; Wed, 25 Jun 2014 13:13:15 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 70A9E33D0DF; Wed, 25 Jun 2014 20:13:14 +0000 (UTC) Sender: geoffk@localhost.localdomain To: "Salz, Rich" References: <9A043F3CF02CD34C8E74AC1594475C738DECE365@uxcn10-tdc06.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF0D0@USMBX1.msg.corp.akamai.com> From: Geoffrey Keating Date: 25 Jun 2014 13:13:14 -0700 In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF0D0@USMBX1.msg.corp.akamai.com> Message-ID: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VJo8tEXVNLHLiXSc7TMytOLE7gk Cc: "" Subject: Re: [TLS] Consensus Call for acceptance of X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 20:13:18 -0000 "Salz, Rich" writes: > In our experience, the issue is legacy embedded devices and old > Android phones, not XP. And therefore, I'd be inclined to go with > Peter's suggestion. For Android, it's the same? If your device is running some old Android, like the 2.x versions, chances are this is because it can't or won't be upgraded, ever, and the solution is to get a new device, which comes with Android 4.x, which I believe has ECDH. I don't know about general 'legacy embedded devices', but can you give an example of one such device which does not support ECDH, will not support ECDH, but is still being updated and for which the manufacturer has indicated they might add this extension? If there aren't any, I would oppose this RFC as a needless complication to the SSL protocol. From nobody Wed Jun 25 13:21:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0481B2E77 for ; Wed, 25 Jun 2014 13:20:56 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WfeVGYGBxod for ; Wed, 25 Jun 2014 13:20:48 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22EA61A0291 for ; Wed, 25 Jun 2014 13:20:46 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z12so2585962wgg.13 for ; Wed, 25 Jun 2014 13:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9v2pUB8WOPhuNNiX2wTurmve+6SDERcvfjOaWYHKy8M=; b=BsEXHtkOt3eGh3ucBeUnJ6eaY9Bs9gbZfzW1EcbHNSxcjtoYuUm9LU30/6LZ9cc5oD WDd9/YycZ6gyG4EvJZ3gb37RU+wTRmOCrt9UtUM5SdXe3kM+eEJwDvPhCVOgPfVe+Tdk 7gFM0ecXw2E4hO9iB2If6FqjpdvzPAEickUleNjFNc9fUAH5K3ZwB7edKaeOv/ePFpCU xoet/Eo5wcnzqGQ6dHrTf0NcxVTodwgIC5N+0MDYP22AygBGhf7pMYCRo9hZ2dyo9Xnn Yq+W9ps6AHdWDTkZgE/eC/VBexlOgJooyorvYsvHnc0gZ4Zr8/G2YUvbwvSk28zArc89 I3QQ== MIME-Version: 1.0 X-Received: by 10.194.238.6 with SMTP id vg6mr10261826wjc.24.1403727645730; Wed, 25 Jun 2014 13:20:45 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Wed, 25 Jun 2014 13:20:45 -0700 (PDT) In-Reply-To: References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> Date: Wed, 25 Jun 2014 13:20:45 -0700 Message-ID: From: Martin Thomson To: "Joseph Salowey (jsalowey)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/J7aE7YYlnhwDqc7uGxV77g1kDAc Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 20:20:57 -0000 On 25 June 2014 13:03, Joseph Salowey (jsalowey) wrote: > 1. In favor of removing renegotiation > 2. In favor of removing renegotiation with the addition of rekey facility > 3. Not in favor of removing renegotiation 2 > 1 >> 3 > 4 >From a browser perspective, 1 would be OK: we simply don't have connections that live that long. But when you have long-lived connections, rekeying is highly valuable. It's also clear to me that some users want to rekey more often than that even. I don't think that there is any value in keeping renegotiation, but having artificial constraints on what can change. I think that it's significantly easier to reason about *anything* where the things that are immutable simply cannot change. For my #4.... I'll note that the options don't include anything like the poor-mans renegotiation: end the TLS session and make a new one on the same underlying transport. Is that intentional? In case you decide to poll that option, I think that it's strictly worse than renegotiation due to the 'dead air' problem. From nobody Wed Jun 25 13:26:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C627A1A0383 for ; Wed, 25 Jun 2014 13:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgiPoPS4M45i for ; Wed, 25 Jun 2014 13:26:02 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D2C1A0339 for ; Wed, 25 Jun 2014 13:26:02 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id o6so2790410oag.32 for ; Wed, 25 Jun 2014 13:26:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rFGFAu32ny/XhhEZznag2kTD222SdGRGbCf/zz7sa9M=; b=X0u+31miAC0HMVcmNCmO5O7ooaha2NgWZKeAAIInKJZNyaaqDlJNStxRUZ+26FzUYH GW4hHbUxTYT4dXeZSMYckyllz8AePoa6ayWEhmFhS/QwCKxU3Xlhlx7ZXz7ffN+VdGNl Us9QilzGEHqfb0QmXhg5xUqlu9ZZPub72JEa0mnQB8HifR5/MLQ2Q/miA4f5R5UN7BxB TbhMoT6zKhUq5FSMVqPcn5zrG743PhVx0jR9JNMMxPROifHI7Nn8kbFmztrNKNhrotfq 5Rm2xI5nOD7mDJADfisux1UxNPKAV8Op2xKYCL/pytpyXcJBNzqTR7RynDj0OzWmV+jh K5SA== X-Gm-Message-State: ALoCoQl3QHoHAD3m5fXGU7WhKfRL6j0UEh2sNJJk/MfnVnpHYAw23XDUBceYjy1qN0nF1/YTExQU MIME-Version: 1.0 X-Received: by 10.60.52.226 with SMTP id w2mr10737439oeo.3.1403727961332; Wed, 25 Jun 2014 13:26:01 -0700 (PDT) Received: by 10.76.20.164 with HTTP; Wed, 25 Jun 2014 13:26:01 -0700 (PDT) In-Reply-To: <53AB192F.2040001@fifthhorseman.net> References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> Date: Wed, 25 Jun 2014 13:26:01 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6taxwC5rKxnKeHeRyLBFShRAI6w Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 20:26:02 -0000 On Wed, Jun 25, 2014 at 11:47 AM, Daniel Kahn Gillmor wrote: > If we aren't providing an additional facility for re-keying, then i am > not OK with removing renegotiation. TLS needs a way for high-traffic, > longstanding connections to stay up without "dead air" (as i think Sean > called it earlier). So i can't choose (1). Probably a stupid and ignorant question; but what prevents applications with this kind of requirement from creating a new connection, negotiating a new key, and then switching to the new connection when they're ready? -- Colm From nobody Wed Jun 25 13:31:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F851A02BB for ; Wed, 25 Jun 2014 13:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJ4EU86SDUHo for ; Wed, 25 Jun 2014 13:31:00 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id C62F91A02B2 for ; Wed, 25 Jun 2014 13:31:00 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 4D7829A4409; Wed, 25 Jun 2014 16:30:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id ffUfIodFdNlR; Wed, 25 Jun 2014 16:30:29 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-144-77.washdc.fios.verizon.net [96.255.144.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7BE219A4405; Wed, 25 Jun 2014 16:30:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> Date: Wed, 25 Jun 2014 16:30:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> To: "Joseph Salowey (jsalowey)" X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yDuYJto2SHpCxvXyh1tckAE3Y4U Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 20:31:02 -0000 Please count me in camp 1. On Jun 25, 2014, at 2:34 PM, Joseph Salowey (jsalowey) wrote: > We would like to see if there is consensus on removing renegotiation = in TLS 1.3. We had rough consensus at the interim to remove = renegotiation. Please state your position by indicating preference for = one of the following (we will have a separate consensus call to decide = on rekey approach).=20 >=20 > 1. Do you favor removing renegotiation from TLS 1.3 either with or = without an additional facility for rekey? > 2. Are you in favor of not removing renegotiation regardless of the = addition of a separate rekey facility? >=20 > Please respond to the list by July 1, 2014. =20 >=20 > Thanks, >=20 > Joe > (for the chairs) From nobody Wed Jun 25 13:39:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95591A02A3 for ; Wed, 25 Jun 2014 13:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGMM0KTUtF1a for ; Wed, 25 Jun 2014 13:39:13 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B23751A0146 for ; Wed, 25 Jun 2014 13:39:12 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so3158622wiv.8 for ; Wed, 25 Jun 2014 13:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oVINxlKMvhrwLyYTy21I42u0tzFiZHP+B4oypFzMi8g=; b=nbJ/S+0bQg1uN6jYiMBKA1rhnyP7m0M5PT4JaZ21rA/XwH/HTDuL/Krivwi24rFYEz 0AjaiTY1uKS4aD70kF4gppLvAKFjzr/+ieYKp7oHIu29kOWCIiLtPJG8NIR0MtAnIuBr naVIF92Y3U/CIsH6jJHTLQxEM80vFNDpGwLo9KBPhe/0YL6cUQJn/LzPGy3v+jQaD9pr pMuVgUndDjzin8hLdv7RWW5j8Z6faX9ap9vKlFbrs6m1A6orhnbOeY2GT5M13nrcAoy5 +pcluQWrLcHrcG5qXtgkdlYAFNSiremhIwHe6+fzG4XQ4SfaMIqqYY4F8cFjkUm2YUW9 w2+g== X-Received: by 10.194.71.12 with SMTP id q12mr12524269wju.5.1403728751149; Wed, 25 Jun 2014 13:39:11 -0700 (PDT) Received: from [192.168.1.104] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id di7sm9660213wjb.34.2014.06.25.13.39.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 13:39:10 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: Date: Wed, 25 Jun 2014 23:39:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> To: =?windows-1252?Q?Colm_MacC=E1rthaigh?= X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LWP7luLDu2petHNLLPCV1AbGQtA Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 20:39:14 -0000 On Jun 25, 2014, at 11:26 PM, Colm MacC=E1rthaigh = wrote: > On Wed, Jun 25, 2014 at 11:47 AM, Daniel Kahn Gillmor > wrote: >> If we aren't providing an additional facility for re-keying, then i = am >> not OK with removing renegotiation. TLS needs a way for = high-traffic, >> longstanding connections to stay up without "dead air" (as i think = Sean >> called it earlier). So i can't choose (1). >=20 > Probably a stupid and ignorant question; but what prevents > applications with this kind of requirement from creating a new > connection, negotiating a new key, and then switching to the new > connection when they're ready? Nothing. But that would require changing those applications.=20 Before: The client opens a connection, calls the TLS library, and then = transmits arbitrarily-much data for an arbitrarily-long time. If so much = data has been transmitted that rekeying is warranted, The TLS library = will do it transparently to the application. After: The client opens a connection, calls the TLS library, and then = transmits information. After a while, either a data count passes some = limit, or a timer expires, and the application is informed by the TLS = library that this connection can no longer be used. So the client opens = a new connection and calls the TLS library again. Simple? Not really, = because now we need to add to the application some session mechanism to = bind the old and the new connections. Think telnet-over-ssl as an = alternative to SSH. You don=92t want to lose your environment and what = you were just typing, right? This is a requirement from the application = that didn=92t exist before.= From nobody Wed Jun 25 13:41:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92D91A02A3 for ; Wed, 25 Jun 2014 13:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJYNhkgmmAlg for ; Wed, 25 Jun 2014 13:41:12 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04B31A0146 for ; Wed, 25 Jun 2014 13:41:11 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id k14so2691320wgh.30 for ; Wed, 25 Jun 2014 13:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iX70/lpwsf0y7Spc+qanrdNSV6Ua3ucaadWKV5DnHTY=; b=efh/YRgCU+x84Fb92lfVesU/GWfZERR2/PU0L4GQwNUjD6wiSmRJ71qFI+gG2jUhxh cE0gtbWFU8rc+vQuqzJn3wSJEcf/NRTMIJxB55Lw7VDK33ZY7Qw+5BW7P7cVytXmsqY6 uGrTWw9l4cApbTNEsKaMOKuYiDwUU2A2OO+2yTaRSmUpQi5f1xOH80oICsD4LL2TQkYo WcM3EmobLERshU3Cm/0lehyz550KOJN3s4k9pcM9AkXZYhdTXZ8/iTT4ZE68GZKZ+6pV i3cqS2vUvJpfnPxQazpy5J1FzmHzdpCcxVOlHVeKhCbYxmxCZyogblYSn+mEa11WmasL n/kw== MIME-Version: 1.0 X-Received: by 10.180.206.73 with SMTP id lm9mr44534590wic.54.1403728870107; Wed, 25 Jun 2014 13:41:10 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Wed, 25 Jun 2014 13:41:10 -0700 (PDT) Date: Wed, 25 Jun 2014 13:41:10 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ab1-WxhTZ8BEIaiVyJse6F4ug4o Cc: "" Subject: [TLS] Dealing with dead air (was Re: Call for Consensus on removal of renegotiation) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 20:41:13 -0000 On 25 June 2014 13:26, Colm MacC=C3=A1rthaigh wrote: > Probably a stupid and ignorant question; but what prevents > applications with this kind of requirement from creating a new > connection, negotiating a new key, and then switching to the new > connection when they're ready? They can. But that new connection will be subject to TCP slow start, so it might take some time. And then there are applications that accumulate state associated with a connection, making it quite costly to move, since the state has to be ported over. In the worst case, this can be a deal breaker, because the peer and the protocol aren't under client control - and the client is the only entity able to force the creation of a new connection. At some level, you have to be willing to do this sort of thing in order to deal with transient faults, but to be forced to do it frequently is something else. Often that fault recovery won't carry all state forward, at least without extra engineering effort. Exceptional circumstances and all that... So it's not as simple as just making a new connection and using that. From nobody Wed Jun 25 13:42:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD0D1A02B2 for ; Wed, 25 Jun 2014 13:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.551 X-Spam-Level: X-Spam-Status: No, score=-4.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VB1LyJsb2VIc for ; Wed, 25 Jun 2014 13:42:45 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2982B1A02A3 for ; Wed, 25 Jun 2014 13:42:45 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9EF9A285BC; Wed, 25 Jun 2014 20:42:43 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 8CE54285BA; Wed, 25 Jun 2014 20:42:43 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 89BDD8004E; Wed, 25 Jun 2014 20:42:43 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Wed, 25 Jun 2014 16:42:43 -0400 From: "Salz, Rich" To: Yoav Nir , =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= Date: Wed, 25 Jun 2014 16:42:42 -0400 Thread-Topic: [TLS] Call for Consensus on removal of renegotiation Thread-Index: Ac+QtYy+K+IThdgYSLmXukZnQhySfgAAE9VA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF192@USMBX1.msg.corp.akamai.com> References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KuQqj1sbJF3p8jcEse1m9-OEBEo Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 20:42:46 -0000 > Nothing. But that would require changing those applications. Wouldn't they already have to change in order to use TLS 1.3? Or would the= underlying library switch to it, and then not do the magic rekey calls? /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Wed Jun 25 13:48:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D802D1A02E8 for ; Wed, 25 Jun 2014 13:47:56 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJCwo9zo297K for ; Wed, 25 Jun 2014 13:47:55 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E677C1A01B8 for ; Wed, 25 Jun 2014 13:47:54 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id x48so2674877wes.23 for ; Wed, 25 Jun 2014 13:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tCKMBZB0B8bdTtRp3INRxLFb/Q0hK0yTTr4ywKTc0uc=; b=cAro1mWUnwQwSGwAc3Dy9EuUp9RmbjFoPrws1ebk2jzfEC27DUqOTIDVvDVcEMwLbH TWhLilpMdWIvXQLHa/FqNHOkAk1S9TbD/hC9O0s8uE2A3PJo05cL1Ei//qk2ZlfzV4nT W7iU3Nv2tjHTsj+BgwYtum9jSVph60Bva9Hfq7Y7VmpJzU78p9hw5b0NOkuzhsd0aX8i 0NTlweouO4zzxXkYDXScKVmcWuOqF69z5RrN6MmYzukHYss/F5jsqyOKgnLRC0neLQVt wG6OavQv+swiqgOVxs8aEDF2Q9ZxcGhGMR7tZSPv0DLALQJhl0YDGsIoP0Zi6i94HSdk 8x3w== X-Received: by 10.180.73.106 with SMTP id k10mr44603117wiv.11.1403729273484; Wed, 25 Jun 2014 13:47:53 -0700 (PDT) Received: from [192.168.1.104] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id gi8sm16222736wib.8.2014.06.25.13.47.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 13:47:53 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF192@USMBX1.msg.corp.akamai.com> Date: Wed, 25 Jun 2014 23:47:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6B247363-E6E2-4A81-92D8-FE2F02C14227@gmail.com> References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF192@USMBX1.msg.corp.akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aCbWcSlwu2L8c2JgZWXpULskCO8 Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 20:47:57 -0000 On Jun 25, 2014, at 11:42 PM, Salz, Rich wrote: >> Nothing. But that would require changing those applications. >=20 > Wouldn't they already have to change in order to use TLS 1.3? Or = would the underlying library switch to it, and then not do the magic = rekey calls? An application running on something like Apache can replace the OpenSSL = library, and instantly get upgraded from supporting only SSLv3 and TLS = 1.0 to support TLS 1.2 and AES-GCM and ECDHE. If that application ever ran enough traffic that renegotiation for = rekeying was needed, upgrading to the next OpenSSL that includes TLS 1.3 = would not be as smooth. BTW: This discussion is totally missing the other use of renegotiation - = to move from server-authenticated to mutually-authenticated. Unless that = need is addressed (by some mechanism), I can=92t support removing = renegotiation. Yoav From nobody Wed Jun 25 13:52:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5A51A03BC for ; Wed, 25 Jun 2014 13:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWMH-OipAgkO for ; Wed, 25 Jun 2014 13:52:39 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 832A01A037D for ; Wed, 25 Jun 2014 13:52:39 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2225D285BD; Wed, 25 Jun 2014 20:52:39 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 0DF9D285B9; Wed, 25 Jun 2014 20:52:39 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 0B6648004A; Wed, 25 Jun 2014 20:52:39 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Wed, 25 Jun 2014 16:52:38 -0400 From: "Salz, Rich" To: Yoav Nir Date: Wed, 25 Jun 2014 16:52:37 -0400 Thread-Topic: [TLS] Call for Consensus on removal of renegotiation Thread-Index: Ac+Qtr8YYz8WEVBgQdi6bD0V5HOvdwAACudQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1A5@USMBX1.msg.corp.akamai.com> References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF192@USMBX1.msg.corp.akamai.com> <6B247363-E6E2-4A81-92D8-FE2F02C14227@gmail.com> In-Reply-To: <6B247363-E6E2-4A81-92D8-FE2F02C14227@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TxOAQfpqLIg3tWKwd3Ymlsb_Bqk Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 20:52:41 -0000 > If that application ever ran enough traffic that renegotiation for rekeyi= ng was > needed, upgrading to the next OpenSSL that includes TLS 1.3 would not be = as > smooth. Unless that next OpenSSL knew enough to do the re-key work. Hm. This would = argue that Martin's approach is probably less disruptive than my preferred = approach. > BTW: This discussion is totally missing the other use of renegotiation - = to > move from server-authenticated to mutually-authenticated. Unless that > need is addressed (by some mechanism), I can't support removing > renegotiation. I believe the consensus is to adopt http://datatracker.ietf.org/doc/draft-t= homson-tls-care/ which I prefer to think of as "do have any idea who I am" /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Wed Jun 25 14:06:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D804D1A050E for ; Wed, 25 Jun 2014 14:06:20 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lroDfOhTsPw for ; Wed, 25 Jun 2014 14:06:19 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E221A046A for ; Wed, 25 Jun 2014 14:06:18 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so2607517wes.36 for ; Wed, 25 Jun 2014 14:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QPN0QEo7YTzIc6C/yuckhCgFcZMPSlc1gSLOS+kSjOc=; b=RWfS+xL+0U/e/L8+HY5aiq79MKI/FMQKcQtn6zWizzR285q4W0ORqEaaSgpukR7Zkl hsQSE7Ep0o75j2BTeyIfmiATt4LU+fbJRMkFD/dbo4mQVFi2aMSChtiYLlGiJ3UP9Tq1 vGXS+FWEDmqebqPSnZdMsu+O9dzJH2uPZYLIAFv/8ZqzHhKLeFmZ0qF2lmu/O1qtWeij hUxOU5CDD/+6EKwPo2UYQFpDVTmOxtBtidZGkPLDun7gcb3yb9FWQhN1h6Wvdr9VzYhu rKutxFSgTGM4pbf2Wfh4oA24lbjUuIrs0DIva2I9rkTrtA6PmRPyCH8lp4zN9yFra2o7 ClHg== X-Received: by 10.194.186.178 with SMTP id fl18mr12249509wjc.83.1403730376156; Wed, 25 Jun 2014 14:06:16 -0700 (PDT) Received: from [192.168.1.104] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id ft20sm16355749wic.14.2014.06.25.14.06.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 14:06:15 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1A5@USMBX1.msg.corp.akamai.com> Date: Thu, 26 Jun 2014 00:06:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3E3ED127-E1DE-469A-A322-8B14856CFEE9@gmail.com> References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF192@USMBX1.msg.corp.akamai.com> <6B247363-E6E2-4A81-92D8-FE2F02C14227@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1A5@USMBX1.msg.corp.akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jWS-hMcWeSjE7Rf8ox6buBOPccs Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 21:06:21 -0000 On Jun 25, 2014, at 11:52 PM, Salz, Rich wrote: >> If that application ever ran enough traffic that renegotiation for = rekeying was >> needed, upgrading to the next OpenSSL that includes TLS 1.3 would not = be as >> smooth. >=20 > Unless that next OpenSSL knew enough to do the re-key work. Hm. This = would argue that Martin's approach is probably less disruptive than my = preferred approach. Even if OpenSSL knows enough to start a new connection, the application = needs to be able to bind the old connection to the new, unless we add = some kind of session management to TLS. But that would trade new = complexity for old complexity, so I don=92t think we want that. >> BTW: This discussion is totally missing the other use of = renegotiation - to >> move from server-authenticated to mutually-authenticated. Unless that >> need is addressed (by some mechanism), I can't support removing >> renegotiation. >=20 > I believe the consensus is to adopt = http://datatracker.ietf.org/doc/draft-thomson-tls-care/ which I prefer = to think of as "do have any idea who I am=94 I must have missed when they called consensus on that. In that case, I=92m= with the =93remove it entirely (1)=94 camp. We use 128-bit ciphers = today. Even with CBC, you will replace the client and the server long = before you=92ve encrypted so much that you need to rekey. Periodic = rekeying is something that auditors like, but is very rarely needed in = HTTPS, SMTP and the like. I=92m fine with forcing the few applications = that need to to adapt. Yoav From nobody Wed Jun 25 14:08:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175BF1A04AE for ; Wed, 25 Jun 2014 14:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GF15I5UCY_hd for ; Wed, 25 Jun 2014 14:08:10 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 412781A046A for ; Wed, 25 Jun 2014 14:08:10 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C8E41474E3; Wed, 25 Jun 2014 21:08:08 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id AB024474DC; Wed, 25 Jun 2014 21:08:08 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 9836C204B; Wed, 25 Jun 2014 21:08:08 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 25 Jun 2014 17:08:08 -0400 From: "Salz, Rich" To: Yoav Nir Date: Wed, 25 Jun 2014 17:08:07 -0400 Thread-Topic: [TLS] Call for Consensus on removal of renegotiation Thread-Index: Ac+QuVD+S9MLTw2ZS7SK+EWBR9uLswAAC3PQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1B6@USMBX1.msg.corp.akamai.com> References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF192@USMBX1.msg.corp.akamai.com> <6B247363-E6E2-4A81-92D8-FE2F02C14227@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1A5@USMBX1.msg.corp.akamai.com> <3E3ED127-E1DE-469A-A322-8B14856CFEE9@gmail.com> In-Reply-To: <3E3ED127-E1DE-469A-A322-8B14856CFEE9@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d39FSiaJ8W2_HqmDHgLDy7KUsgo Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 21:08:12 -0000 > > I believe the consensus is to adopt http://datatracker.ietf.org/doc/dra= ft- > thomson-tls-care/ which I prefer to think of as "do have any idea who I a= m" >=20 > I must have missed when they called consensus on that. Or equally likely just wishful thinking on my part. -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Wed Jun 25 14:12:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CFE1A0601 for ; Wed, 25 Jun 2014 14:12: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_w1MGw9lB3x for ; Wed, 25 Jun 2014 14:12:08 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0BB1A0538 for ; Wed, 25 Jun 2014 14:12:04 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id bs8so8775886wib.7 for ; Wed, 25 Jun 2014 14:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bKrzhx59J2lGcLNtJ+GvzB4wZvWiuCtVxO7teB9d/mU=; b=kTnyztjU8byLHE6kxso5AXVRImM09Nb4QIxfD2ARPGnjq4LIxkxP/8bHCHbY5GNoki g+nX6SVcOd69hoJXwgiCTxlsSEZrNXnJsl6vze3fvAWhuDTAEAo4Cjzjon6W6cp8Vtp3 lIyA/ndAyJU7+3YrCqPq3yvp4YtrA1aQA0iU/OwPgIb66V9PBysXZ5zxNWLNLcXS6GTV CbfxpbxhYOQDuiRv2gK31N+NErV1f+Ed1Cw+ll0t5EFG8MNi80b+gawIUFM2bsiFUUCU UtPSI8qjlddr8UZ316qcBYmweNprikCRa5Nu48sc6bmBKbLAGAB/pbz85DIbSHtvBSsL Ta9A== MIME-Version: 1.0 X-Received: by 10.180.79.38 with SMTP id g6mr12793475wix.61.1403730722996; Wed, 25 Jun 2014 14:12:02 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Wed, 25 Jun 2014 14:12:02 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1A5@USMBX1.msg.corp.akamai.com> References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF192@USMBX1.msg.corp.akamai.com> <6B247363-E6E2-4A81-92D8-FE2F02C14227@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1A5@USMBX1.msg.corp.akamai.com> Date: Wed, 25 Jun 2014 14:12:02 -0700 Message-ID: From: Martin Thomson To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MWU2-hBkt1GOij02AUo99YoqZ6Y Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 21:12:10 -0000 On 25 June 2014 13:52, Salz, Rich wrote: > I believe the consensus is to adopt http://datatracker.ietf.org/doc/draft-thomson-tls-care/ which I prefer to think of as "do have any idea who I am" I wouldn't have characterized it as consensus... But "do you have any idea who I am" is the less critical piece of the puzzle. I'd say that http://tools.ietf.org/html/draft-thomson-httpbis-cant-00 - and anything like it, is more important. I've recently made a tweak to that to remove the dependency on any TLS extension. I've been sitting on it, but I'll have -01 out in a few minutes. From nobody Wed Jun 25 14:15:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB151A0416 for ; Wed, 25 Jun 2014 14:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9fKiRsedSF2 for ; Wed, 25 Jun 2014 14:15:36 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF721A0384 for ; Wed, 25 Jun 2014 14:15:36 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id uy5so2730274obc.36 for ; Wed, 25 Jun 2014 14:15:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hbnds/zQVq5IqcJIE7nGt59L69yPl4/XL7H5nJg8lnM=; b=VhErB3idnhr6XT3e6igjJ6xYYFtGrAVITLBWoFRy2nQmsWLOJ4NxYy2rvrZG6TuC1y At44LaMssOXCsrcWDzO86tOOuESOobxbMXUiRW6PAqtlSKpMKkwh++4Y/KbbxiMJP79N HZlaIX/VsjDM9A5RKclDNmQcnb65hVkeQZ//3bas3m3jQroTABa6VqLNrisY9ccg0hrJ 6zIi84+EqgIizEL2Jr22BXgGLIkO94D6EeKmS1ye67zBX2ohs6x4f3ISd7TocJ/bCGHu pLMs1Seq1kG1d2fISSi6260XSBXtEmDRBPN+6Vp7DF2mXdDBzRU24MFfEyGFpBBalFP1 5fQg== X-Gm-Message-State: ALoCoQlIDvuc5XFwz6nRQgvxMS3EXki4WfqPGm1wPt3blXiPKP8CrG3vlrmDv9vi3Buo5rcDq2bz MIME-Version: 1.0 X-Received: by 10.182.213.100 with SMTP id nr4mr10940441obc.39.1403730935929; Wed, 25 Jun 2014 14:15:35 -0700 (PDT) Received: by 10.76.20.164 with HTTP; Wed, 25 Jun 2014 14:15:35 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Jun 2014 14:15:35 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pxvtWZ0yoVyrDXvZHj8PFdDstGk Cc: "" Subject: Re: [TLS] Dealing with dead air (was Re: Call for Consensus on removal of renegotiation) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 21:15:38 -0000 On Wed, Jun 25, 2014 at 1:41 PM, Martin Thomson wrote: > At some level, you have to be willing to do this sort of thing in > order to deal with transient faults, but to be forced to do it > frequently is something else. Often that fault recovery won't carry > all state forward, at least without extra engineering effort. > Exceptional circumstances and all that... A MITM can introduce just those kinds of faults - so if the application protocol isn't tolerant of that and it causes some kind of DoS, it seems like it's a non-starter to begin with. -- Colm From nobody Wed Jun 25 14:17:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984251A0538 for ; Wed, 25 Jun 2014 14:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMleHYo4u-g6 for ; Wed, 25 Jun 2014 14:17:45 -0700 (PDT) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFFA1A0384 for ; Wed, 25 Jun 2014 14:17:44 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id uz6so2830801obc.24 for ; Wed, 25 Jun 2014 14:17:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u+dqpTZmr6h/0ex20+1eAQ1gnL5AoKUbnkeTY4U8g10=; b=Ay0nreEYPSGE3PdG0xAHhTpkxbNTxqzP2LieU8IjKWgF+7SkL/mpcbG7jzxZ/PruhA hSLmlZbjLVDhvBGt/vPlm4p3HwagDmvJhGJ7ZgM5Fx4m2Fk4OTakiFxAorRmWZBgKeiB wtrgG3TwYMntxg0Lf5KcIE2l9hGhW7WP1m0C4YUPy0oz9Qy31BprnN7nRUsoBiIOJ5J1 48KsaU6fKkiB8/GsGogQDZo29Q9RfOl/dhTOYiUyKl8IzpqkZZG+mBrPzlgZ13WF/DjZ xsdadoD26KS61g+2IWfL5g7LkHTMWRwZTQyDnKwd61q0rWufUHITW/BRkpVfBG00/Iui V3ZQ== X-Gm-Message-State: ALoCoQk4Q4vzk//aSPnWCui0BA+5PC10giU0bxxkU67s8xMGV5UoaS2OrVQRUbcdH6IULWgieWAi MIME-Version: 1.0 X-Received: by 10.182.138.65 with SMTP id qo1mr11125472obb.9.1403731064133; Wed, 25 Jun 2014 14:17:44 -0700 (PDT) Received: by 10.76.20.164 with HTTP; Wed, 25 Jun 2014 14:17:44 -0700 (PDT) In-Reply-To: References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> Date: Wed, 25 Jun 2014 14:17:44 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/g1QbEoa8ow-Tu6mqOok30t7AGbY Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 21:17:45 -0000 On Wed, Jun 25, 2014 at 1:39 PM, Yoav Nir wrote: > Before: The client opens a connection, calls the TLS library, and then tr= ansmits arbitrarily-much data for an arbitrarily-long time. If so much data= has been transmitted that rekeying is warranted, The TLS library will do i= t transparently to the application. > > After: The client opens a connection, calls the TLS library, and then tra= nsmits information. After a while, either a data count passes some limit, o= r a timer expires, and the application is informed by the TLS library that = this connection can no longer be used. So the client opens a new connection= and calls the TLS library again. Simple? This seems like a strawman argument. Why can't a library make connections and hide that detail of the application? Of course a library can, as database connection pool libraries do, for example. --=20 Colm From nobody Wed Jun 25 14:18:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4461A05CB for ; Wed, 25 Jun 2014 14:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy6mEM83AkIl for ; Wed, 25 Jun 2014 14:18:22 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79DC1A0601 for ; Wed, 25 Jun 2014 14:18:21 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s5PLIEQt011953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jun 2014 23:18:14 +0200 (MEST) In-Reply-To: To: Geoffrey Keating Date: Wed, 25 Jun 2014 23:18:14 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140625211814.A41BB1AD69@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6Rxa8BOPqhEeqVSiEtVoilWLM-M Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call for acceptance of X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 21:18:23 -0000 Geoffrey Keating wrote: > "Salz, Rich" writes: >> >> In our experience, the issue is legacy embedded devices and old >> Android phones, not XP. And therefore, I'd be inclined to go with >> Peter's suggestion. > > For Android, it's the same? If your device is running some old > Android, like the 2.x versions, chances are this is because it can't > or won't be upgraded, ever, and the solution is to get a new device, > which comes with Android 4.x, which I believe has ECDH. I think you're underestimating the size of the Android 2.x problem. There are still plenty of *BRAND NEW* phones sold with Android 2.x today. The list of this German price search engine currently lists ~190 phones that are still on sale and equipped with Android 2.x http://www.heise.de/preisvergleich/?cat=umtsover&xf=148_Android+2#xf_top and if you want to check for the newest vendor firmware of these phones, here is where you could look it up for Samsung phones (e.g. Galaxy Y): http://live.samsung-updates.com/index.php?device=GT-S5360 -Martin From nobody Wed Jun 25 14:39:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8CE1A0418 for ; Wed, 25 Jun 2014 14:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PB0XLDs79DPI for ; Wed, 25 Jun 2014 14:39:36 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4311A0054 for ; Wed, 25 Jun 2014 14:39:36 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so62987wib.4 for ; Wed, 25 Jun 2014 14:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ST3aR7i7p2yGFhOYzrtJgKV0IIIfhsFHWgrRfsG9FVY=; b=qD9Z+ekgFUFpSsK0O+28mx0b24AuiC2SN1P0lcQinw4Tw0pBTRIJirsKvKwI4kB8pH 3Ctv3U64MZNtGZzWy5EpVBwtjJQCqC5aCcBWsOMnh6IXj5aFsAe48Jdi93f0PZb+XtKE oV3ei8VYDCQtK7zDUOr8kLAcWYRiVg09yj1s5gRmb0oe0epDisGz+FWm2Mj+mHXf974r x31Ey0MG5szPJjTZMMf46/nXYyacFYOMuKysI3kgILv36YWZjM4yUuFwFAzzLaVwWLFP ciMUXFUMnoaUXw2mlfjLj1XjsY207kkdazJ+CYTTUtYkoekDFWCXbi+8n/wdeXJ3AOab RDDw== X-Received: by 10.180.206.73 with SMTP id lm9mr44819697wic.54.1403732374985; Wed, 25 Jun 2014 14:39:34 -0700 (PDT) Received: from [192.168.1.104] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id h3sm9929106wjz.48.2014.06.25.14.39.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 14:39:34 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: Date: Thu, 26 Jun 2014 00:39:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> To: =?windows-1252?Q?Colm_MacC=E1rthaigh?= X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sOx5CsR4NiC6F8hxqZeyy7yyu1k Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 21:39:37 -0000 On Jun 26, 2014, at 12:17 AM, Colm MacC=E1rthaigh = wrote: > On Wed, Jun 25, 2014 at 1:39 PM, Yoav Nir wrote: >> Before: The client opens a connection, calls the TLS library, and = then transmits arbitrarily-much data for an arbitrarily-long time. If so = much data has been transmitted that rekeying is warranted, The TLS = library will do it transparently to the application. >>=20 >> After: The client opens a connection, calls the TLS library, and then = transmits information. After a while, either a data count passes some = limit, or a timer expires, and the application is informed by the TLS = library that this connection can no longer be used. So the client opens = a new connection and calls the TLS library again. Simple? >=20 > This seems like a strawman argument. Why can't a library make > connections and hide that detail of the application? Of course a > library can, as database connection pool libraries do, for example. I disagree. Suppose we did a telnet-over-tls protocol (yes, of course = somebody=92s already done it).=20 When I=92m logged in through telnet (or SSH, or telnet-over-tls), I = enter some credentials, and I get an environment. It=92s fine for the = library to take over sockets and such, but the server has to (a) be = convinced that the new connection is associated with the same user, and = (b) associate the old environment with the new connection.=20 I don=92t see how you can do that without modifying telnet. Can you? Yoav From nobody Wed Jun 25 14:45:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4CA1A0646 for ; Wed, 25 Jun 2014 14:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Zye-MZFmBH5 for ; Wed, 25 Jun 2014 14:45:32 -0700 (PDT) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCB21A05CB for ; Wed, 25 Jun 2014 14:45:32 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id n16so2869373oag.34 for ; Wed, 25 Jun 2014 14:45:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8lH22TugM7Iwt+NuLd6XQOKLDI1s3XGVaLYCsHEn7pc=; b=WWDlKCMDNQbzjI914bWPdFQR+tapufgMy6qZEL9hjLRntt2P0r/sx33QKl/pesqYDB Cq2F/DlfARsmi6UZJ22/5ruccj0WYIbepk1kC0RNLwwLGEx9u/i+HslAPNFHDf6JZ82V yLHrOkM4vUnMMy7dlTGSEzzA0EKIYXG7/6i7GPJ//e/BWB+zdUWugyLGAQs1aXTFsLtA t24cSU3em8DkeONErgtGkhy6HpkHugPICoFu8aLb57KHF8oYViEfW8UPw1MNPAVvCg8Q CNUpRiMEfCzzCFLtyZ+hZm640Fed6kN+hvtLvnty2crFwgDgm4vqp/MCcHlHpSo9lWim 5DqA== X-Gm-Message-State: ALoCoQkpijWRlwkX9c8WJPva1fqKzxs67Q1qoaA5vyZEvYA3AJ4y21xiJa8JkaC6MdwpUz2N/XYV MIME-Version: 1.0 X-Received: by 10.60.103.76 with SMTP id fu12mr11013352oeb.34.1403732731717; Wed, 25 Jun 2014 14:45:31 -0700 (PDT) Received: by 10.76.20.164 with HTTP; Wed, 25 Jun 2014 14:45:31 -0700 (PDT) In-Reply-To: References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> Date: Wed, 25 Jun 2014 14:45:31 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dEseon2PADWwDHSl7Pa6UOpmdfY Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 21:45:33 -0000 On Wed, Jun 25, 2014 at 2:39 PM, Yoav Nir wrote: > I disagree. Suppose we did a telnet-over-tls protocol (yes, of course som= ebody=E2=80=99s already done it). > > When I=E2=80=99m logged in through telnet (or SSH, or telnet-over-tls), I= enter some credentials, and I get an environment. It=E2=80=99s fine for th= e library to take over sockets and such, but the server has to (a) be convi= nced that the new connection is associated with the same user, and (b) asso= ciate the old environment with the new connection. > > I don=E2=80=99t see how you can do that without modifying telnet. Can yo= u? This too seems like a strawman; SSH does not use TLS, and telnet-over-tls is not common. The requirements of securing interactive logins differ enough from TLSs features that those applications have found other solutions entirely. --=20 Colm From nobody Wed Jun 25 14:59:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD191B27B1 for ; Wed, 25 Jun 2014 14:59:05 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeTa9Nh4FcAA for ; Wed, 25 Jun 2014 14:59:03 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B80B1B27A1 for ; Wed, 25 Jun 2014 14:59:02 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 20B3033D0DF; Wed, 25 Jun 2014 21:59:02 +0000 (UTC) Sender: geoffk@localhost.localdomain To: mrex@sap.com References: <20140625211814.A41BB1AD69@ld9781.wdf.sap.corp> From: Geoffrey Keating Date: 25 Jun 2014 14:59:02 -0700 In-Reply-To: <20140625211814.A41BB1AD69@ld9781.wdf.sap.corp> Message-ID: Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZrB-TtboG1mRoC4bD47E9l55_Hw Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call for acceptance of X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 21:59:05 -0000 mrex@sap.com (Martin Rex) writes: > Geoffrey Keating wrote: > > "Salz, Rich" writes: > >> > >> In our experience, the issue is legacy embedded devices and old > >> Android phones, not XP. And therefore, I'd be inclined to go with > >> Peter's suggestion. > > > > For Android, it's the same? If your device is running some old > > Android, like the 2.x versions, chances are this is because it can't > > or won't be upgraded, ever, and the solution is to get a new device, > > which comes with Android 4.x, which I believe has ECDH. > > I think you're underestimating the size of the Android 2.x problem. > > There are still plenty of *BRAND NEW* phones sold with Android 2.x today. Do you think that the vendors of these phones will implement the proposed extension? From nobody Wed Jun 25 15:24:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42041B27DC for ; Wed, 25 Jun 2014 15:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPQQYKfaC25M for ; Wed, 25 Jun 2014 15:24:43 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4569B1A039C for ; Wed, 25 Jun 2014 15:24:43 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s5PMObw7004783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jun 2014 00:24:37 +0200 (MEST) In-Reply-To: To: Geoffrey Keating Date: Thu, 26 Jun 2014 00:24:37 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140625222437.94A281AD69@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/inFnkDZeK2B2yMfwMEGVjnedH78 Cc: tls@ietf.org Subject: Re: [TLS] Consensus Call for acceptance of< X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 22:24:51 -0000 Geoffrey Keating wrote: > mrex@sap.com (Martin Rex) writes: > > > Geoffrey Keating wrote: > > > "Salz, Rich" writes: > > >> > > >> In our experience, the issue is legacy embedded devices and old > > >> Android phones, not XP. And therefore, I'd be inclined to go with > > >> Peter's suggestion. > > > > > > For Android, it's the same? If your device is running some old > > > Android, like the 2.x versions, chances are this is because it can't > > > or won't be upgraded, ever, and the solution is to get a new device, > > > which comes with Android 4.x, which I believe has ECDH. > > > > I think you're underestimating the size of the Android 2.x problem. > > > > There are still plenty of *BRAND NEW* phones sold with Android 2.x today. > > Do you think that the vendors of these phones will implement the > proposed extension? I don't know. This is just an example problem. There are _hundreds_ of independent TLS implementations out there on the internet, and the fact that ECDH exists in newer versions of some OpenSource implementations doesn't mean that everyone can or will just use that instead of what he is currently using (there are many reasons not to). Code size and complexity of a change is often a deciding factor whether a software update is (a) possible at all and (b) might get produced by the vendor. Looking at the capabilities of a product like this: http://www.oracle.com/us/products/servers-storage/036080.pdf a DH-improving firmware update seems possible, but moving to ECDH looks more like impossible. -Martin From nobody Wed Jun 25 17:50:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A391B2E77 for ; Wed, 25 Jun 2014 17:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.133 X-Spam-Level: * X-Spam-Status: No, score=1.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYiMpVED1LxQ for ; Wed, 25 Jun 2014 17:50:44 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.56.159.17]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377421B2E73 for ; Wed, 25 Jun 2014 17:50:44 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id 82A1CB6DCF12A; Wed, 25 Jun 2014 19:50:43 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 3B8BBB6DCF049 for ; Wed, 25 Jun 2014 19:50:43 -0500 (CDT) Received: from [198.180.150.142] (port=49663 helo=v142.vpn.iad.rg.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wzxti-0005RP-2v for tls@ietf.org; Wed, 25 Jun 2014 19:50:42 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Thu, 26 Jun 2014 01:50:39 +0100 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 198.180.150.142 X-Exim-ID: 1Wzxti-0005RP-2v X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (v142.vpn.iad.rg.net) [198.180.150.142]:49663 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hNRglSZFT3Tpfyk3aAPQBnc31AA Subject: [TLS] Call for Consensus: ECC on standards track X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 00:50:45 -0000 WG Members, Based on the mailing list discussion, the chairs believe that there is strong support to publish TLS ECC Cipher Suites on the Standards Track - Should we include TLS ECC Cipher Suites for AES-GCM directly in the TLS 1.3 document (and hence on the Standards Track). - Should we reclassify the TLS ECC Cipher Suites that correspond to currently recommended ciphers as Standards Track. If there is general consensus for this, the chairs will solicit/develop a detailed proposals, but this will presumably include AES-GCM, not include RC4, and we'll have do debate AES-CBC. Note that we are not currently calling for consensus on whether ECC-based cipher suites should be MTI for TLS 1.3. We expect that to be a topic of a separate discussion later in the TLS 1.3 process. spt [For the chairs] From nobody Wed Jun 25 18:58:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876751B2EED for ; Wed, 25 Jun 2014 18:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d90FFFbdtxnn for ; Wed, 25 Jun 2014 18:58:02 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id E017D1B291A for ; Wed, 25 Jun 2014 18:58:01 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 964FF165703; Thu, 26 Jun 2014 01:58:00 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 8B9371656FF; Thu, 26 Jun 2014 01:58:00 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 736751E03D; Thu, 26 Jun 2014 01:58:00 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 25 Jun 2014 21:58:00 -0400 From: "Salz, Rich" To: Martin Thomson Date: Wed, 25 Jun 2014 21:57:59 -0400 Thread-Topic: [TLS] Call for Consensus on removal of renegotiation Thread-Index: Ac+QuiEzqaNgPPZoQFOCBdMFYPKVJQAJ9PLA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1FD@USMBX1.msg.corp.akamai.com> References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF192@USMBX1.msg.corp.akamai.com> <6B247363-E6E2-4A81-92D8-FE2F02C14227@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1A5@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vH1Cqut02-2q9EUkBgLgGUa5IfU Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 01:58:03 -0000 VGhlIHdlYiBpcyBtb3JlIHRoYW4gSFRUUDsgdGxzLWNhcmUgaXMgZ2xvYmFsLCBodHRwLWNhbnQg aXMgZm9yIHNvbWUgc21hbGwgcGFydCBvZiB0aGUgd2ViIDopDQoNCg0KLS0gIA0KUHJpbmNpcGFs IFNlY3VyaXR5IEVuZ2luZWVyDQpBa2FtYWkgVGVjaG5vbG9naWVzLCBDYW1icmlkZ2UsIE1BDQpJ TTogcnNhbHpAamFiYmVyLm1lOyBUd2l0dGVyOiBSaWNoU2Fseg0KDQo= From nobody Wed Jun 25 19:01:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5E41B291A for ; Wed, 25 Jun 2014 19:01: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUs5bIgVn0uF for ; Wed, 25 Jun 2014 19:01:20 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A722C1B2EEA for ; Wed, 25 Jun 2014 19:01:19 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id k48so2964765wev.20 for ; Wed, 25 Jun 2014 19:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TV2Zf5zTMqWuWG+9ivLXURp1OsG8TZTf0a7ZTmgQebg=; b=QLmQHXcp9psBwwd/S3FlwTSCeIemgzkkbxb65lXWMZS3xMQG682t+o5EhGelaKHbrt wq6+Pw9Og/va4ya61UI/FS6HWLL13PsJNLeBlmCY4DruMb5UNJEVjc9wYj4EisygRA2Z XT2SB0GQOrr1y7atEsuCjVgYm4mPiLiSzIzx1/LYeWSBryE849ML9imeaKJPXQV2KlCl apfpPKSx9613yIYAsnxWAbJqytmnevRx3jj5X2Qxu/Olfr8ginHUxnNXxKlMP5waPTET Yw+QlexWKWZ1sWwt8v9ue7mA0jC/UUJnfrj3pY9h/Y2KMOzsA81cRYicNk/sC3tGgUqV N4Ow== MIME-Version: 1.0 X-Received: by 10.180.76.132 with SMTP id k4mr633170wiw.1.1403748077948; Wed, 25 Jun 2014 19:01:17 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Wed, 25 Jun 2014 19:01:17 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1FD@USMBX1.msg.corp.akamai.com> References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF192@USMBX1.msg.corp.akamai.com> <6B247363-E6E2-4A81-92D8-FE2F02C14227@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1A5@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1FD@USMBX1.msg.corp.akamai.com> Date: Wed, 25 Jun 2014 19:01:17 -0700 Message-ID: From: Martin Thomson To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9m2Y36xq_jZTFF9-G9i3AQ_1zow Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 02:01:21 -0000 On 25 June 2014 18:57, Salz, Rich wrote: > The web is more than HTTP; tls-care is global, http-cant is for some small part of the web :) That's true, but the key point of this is that the application protocol needs a signal to cause a new connection to be created. So far, HTTP is the only application protocol that needs this; hence -cant. My point regarding -cant was that it can work without a TLS extension, i.e., it works if the CertificateRequest is triggered on renego (<= 1.2) or clients can unilaterally authenticate (>= 1.3). From nobody Wed Jun 25 20:05:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3DF1B2F1E for ; Wed, 25 Jun 2014 20:05:04 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODxVpnbDaBDq for ; Wed, 25 Jun 2014 20:04:56 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C821B2A47 for ; Wed, 25 Jun 2014 20:04:55 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id v1so1763449yhn.20 for ; Wed, 25 Jun 2014 20:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xGCFZivnxY4HZk06U2/6+fcvxym0x6ZY32zGk2KdMvg=; b=gWIOARCwlM3Wr9tWg0sYe+U7QuPQ8DgKdLSITLe7cH81ZNVp3SWpdERWdYRS2ijvbe 9TzNe4evVgQ0qPMJxX3V2A4gftvvmmGNLtbBTii6LV4lUstwHG/Au7YCqknCaAhxGsSZ IqSTWqo0hBN4UQgSR4oc249TmQoO4/16MtyRptUdfaOqhxjO2K+GIcYzGfWiQMkFcsml idWA3rwq38oORRw9U6FVfAU59GwqClyqFK+mrjT9fw1S2QU04yvR3rP7m8R27RQRxB/v SIyjAFPK3G//ypQh7Ihvn0JQgxEJKeJek965saOsbpkFP+QB8fWLmth4z+Z6sq4L6aIr skfg== MIME-Version: 1.0 X-Received: by 10.236.152.169 with SMTP id d29mr17503608yhk.83.1403751894873; Wed, 25 Jun 2014 20:04:54 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Wed, 25 Jun 2014 20:04:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Jun 2014 20:04:54 -0700 Message-ID: From: Watson Ladd To: Sean Turner Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oK8fm-fQJvSOEd2fc9wIr_1LqnU Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Call for Consensus: ECC on standards track X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 03:05:05 -0000 On Wed, Jun 25, 2014 at 5:50 PM, Sean Turner wrote: > WG Members, > > Based on the mailing list discussion, the chairs believe that there is > strong support to publish TLS ECC Cipher Suites on the Standards > Track > > - Should we include TLS ECC Cipher Suites for AES-GCM > directly in the TLS 1.3 document (and hence on the Standards Track). Yes, including Curve25519. (Why isn't the CFRG ready? It doesn't take 6 months to decide on the deposition of a single bit) > > - Should we reclassify the TLS ECC Cipher Suites that correspond > to currently recommended ciphers as Standards Track. If there is > general consensus for this, the chairs will solicit/develop a detailed > proposals, but this will presumably include AES-GCM, not include > RC4, and we'll have do debate AES-CBC. This is for TLS 1.2 and below, correct? What difference does this make to anything being standards track or not? Sincerely, Watson Ladd > > Note that we are not currently calling for consensus on whether > ECC-based cipher suites should be MTI for TLS 1.3. We expect > that to be a topic of a separate discussion later in the TLS 1.3 > process. > > spt > [For the chairs] > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Jun 25 20:45:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF441B29D2 for ; Wed, 25 Jun 2014 20:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjLYDGXjnloI for ; Wed, 25 Jun 2014 20:45:31 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4ED1B2A52 for ; Wed, 25 Jun 2014 20:45:30 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s5Q3jO6S010873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jun 2014 05:45:24 +0200 (MEST) In-Reply-To: To: Sean Turner Date: Thu, 26 Jun 2014 05:45:24 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140626034524.4F3C41AD69@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NPpwjE-zqInlFzUAixMBnLUPIlY Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Call for Consensus: ECC on standards track X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 03:45:33 -0000 Sean Turner wrote: > > Based on the mailing list discussion, the chairs believe that there is > strong support to publish TLS ECC Cipher Suites on the Standards > Track > > - Should we include TLS ECC Cipher Suites for AES-GCM > directly in the TLS 1.3 document (and hence on the Standards Track). I believe this message is somehow falling short of the real situation. rfc4492, which specifies the use of ECC crypto with TLS is currently an Informational document, i.e. the whole use of ECC in TLS is limited audience rather than standards track. Similarly, while AES-GCM with RSA and DHE_RSA key exchange (rfc5288) is a standards track document today, AES-GCM with ECC (rfc5289) is an informational document just like underlying rfc4492. You would have to move the whole ECC for TLS stuff to standards track before thinking about adding any cipher suites that depend on this into the base TLS spec. -Martin From nobody Wed Jun 25 21:37:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D4B1B2F18 for ; Wed, 25 Jun 2014 21:37:03 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhL4fdkCO0WM for ; Wed, 25 Jun 2014 21:36:57 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39AA11B2A9C for ; Wed, 25 Jun 2014 21:36:56 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id E0C6333D0DF; Thu, 26 Jun 2014 04:36:55 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Sean Turner References: From: Geoffrey Keating Date: 25 Jun 2014 21:36:55 -0700 In-Reply-To: Message-ID: Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TR1XycL0xpk0TmB3CvBoXUXHgcs Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Call for Consensus: ECC on standards track X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 04:37:03 -0000 Sean Turner writes: > WG Members, > > Based on the mailing list discussion, the chairs believe that there is > strong support to publish TLS ECC Cipher Suites on the Standards > Track > > - Should we include TLS ECC Cipher Suites for AES-GCM > directly in the TLS 1.3 document (and hence on the Standards Track). > > - Should we reclassify the TLS ECC Cipher Suites that correspond > to currently recommended ciphers as Standards Track. If there is > general consensus for this, the chairs will solicit/develop a detailed > proposals, but this will presumably include AES-GCM, not include > RC4, and we'll have do debate AES-CBC. I support these proposals. From nobody Wed Jun 25 21:38:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18501B2F18 for ; Wed, 25 Jun 2014 21:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZ6OryKcNd1R for ; Wed, 25 Jun 2014 21:38:01 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD521B2A9C for ; Wed, 25 Jun 2014 21:38:00 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id n12so3009001wgh.31 for ; Wed, 25 Jun 2014 21:37:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=T/qmDm6FsUQZcktAg5REeG5QhuJNXzoh4GTjBaSYx/0=; b=lAQlWzBsxTfBRlCqc43ynGUoypnZ2Wv7sLCqlqdp2rJD2PtFR5oK8jWYV8wF0d5Oia 8cphbkTbbhig7GjwbLwzutg3exO2Nt8Kq++B3UtQCQT6T/7w4eGaFVDOK+3qZzONi1W+ ZwH99aN2izP+JPQz0F6V1l5LzQrM6ZtiBvKuVct02BaRZtEjx4G+RkxrG2f85EbjmcyW 81XEj9dSD5xhnaHJcYcHkGRlmzy4snx3Aoc81pBmS+SowJi4vxawvvnGPsYRngQ1Vblu 6R92NI/QVuuCbDcvQOY6Dhl9ItH/R1v6xKXzlRXBt+Y24N5TTSSnfTVq8ePLpcD25UD3 25bg== X-Gm-Message-State: ALoCoQlcswLTiZw1hmqsLYxgjO6/6gNvh+L0QFK/Fq2xY5Z66f73oQHltAhZRWfYCZfmAWNSNRvt X-Received: by 10.194.222.5 with SMTP id qi5mr14356731wjc.62.1403757479547; Wed, 25 Jun 2014 21:37:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 25 Jun 2014 21:37:19 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <20140626034524.4F3C41AD69@ld9781.wdf.sap.corp> References: <20140626034524.4F3C41AD69@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Wed, 25 Jun 2014 21:37:19 -0700 Message-ID: To: "mrex@sap.com" Content-Type: multipart/alternative; boundary=001a11c1b326eb6fdd04fcb5c1fe Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FwxKeZo91cJb9nM2RF0CpWLcK9c Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Call for Consensus: ECC on standards track X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 04:38:03 -0000 --001a11c1b326eb6fdd04fcb5c1fe Content-Type: text/plain; charset=UTF-8 On Wed, Jun 25, 2014 at 8:45 PM, Martin Rex wrote: > Sean Turner wrote: > > > > Based on the mailing list discussion, the chairs believe that there is > > strong support to publish TLS ECC Cipher Suites on the Standards > > Track > > > > - Should we include TLS ECC Cipher Suites for AES-GCM > > directly in the TLS 1.3 document (and hence on the Standards Track). > > > I believe this message is somehow falling short of the real situation. > > rfc4492, which specifies the use of ECC crypto with TLS is currently > an Informational document, i.e. the whole use of ECC in TLS is > limited audience rather than standards track. > > Similarly, while AES-GCM with RSA and DHE_RSA key exchange (rfc5288) > is a standards track document today, AES-GCM with ECC (rfc5289) > is an informational document just like underlying rfc4492. > > > You would have to move the whole ECC for TLS stuff to standards track > before thinking about adding any cipher suites that depend on this > into the base TLS spec Unless I am missing something, RFC 3967 permits normative references from Standards Track RFCs to Informational RFCs, provided that those issues are called out in IETF LC. So, I believe we could simply refer to 4492 from TLS 1.3 provided we follow the RFC 3967 Section 3. However, this isn't the only alternative: 1.As the sense of the second question suggests, a potentially more attractive avenue would be to produce a new document that specified ECC w/ the current recommended set of symmetric ciphers and advance that on the standard track. 2. If people don't feel like messing with the pre TLS 1.3 documents, but do want ECC to be a basic part of 1.3 we could just import the relevant sections of 4492 into TLS 1.3 (this might be desirable for editorial reasons in any case) and just advance those pieces on the standards track. -Ekr --001a11c1b326eb6fdd04fcb5c1fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 25, 2014 at 8:45 PM, Martin Rex <<= a href=3D"mailto:mrex@sap.com" target=3D"_blank">mrex@sap.com> wrote:
Sean Turner wrote:
>
> Based on the mailing list discussion, the chairs believe that there is=
> strong support to publish TLS ECC Cipher Suites on the Standards
> Track
>
> - Should we include TLS ECC Cipher Suites for AES-GCM
> =C2=A0 directly in the TLS 1.3 document (and hence on the Standards Tr= ack).


I believe this message is somehow falling short of the real situation= .

rfc4492, =C2=A0which specifies the use of ECC crypto with TLS is currently<= br> an Informational document, i.e. the whole use of ECC in TLS is
limited audience rather than standards track.

Similarly, while AES-GCM with RSA and DHE_RSA key exchange (rfc5288)
is a standards track document today, AES-GCM with ECC (rfc5289)
is an informational document just like underlying rfc4492.


You would have to move the whole ECC for TLS stuff to standards track
before thinking about adding any cipher suites that depend on this
into the base TLS spec

Unless I am missing = something, RFC 3967 permits normative references
from Standards T= rack RFCs to Informational RFCs, provided that those
issues are c= alled out in IETF LC. So, I believe we could simply refer to
4492 from TLS 1.3 provided we follow the RFC 3967 Section 3.

However, this isn't the only alternative:
1.A= s the sense of the second question suggests, a potentially
more a= ttractive avenue would be to produce a new document that
specified ECC w/ the current recommended set of symmetric ciphers
and advance that on the standard track.

2. I= f people don't feel like messing with the pre TLS 1.3 documents,
but do want ECC to be a basic part of 1.3 we could just import the
relevant sections of 4492 into TLS 1.3 (this might be desirable for<= /div>
editorial reasons in any case) and just advance those pieces
on the standards track.

-Ekr
--001a11c1b326eb6fdd04fcb5c1fe-- From nobody Wed Jun 25 21:41:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E591B2F21 for ; Wed, 25 Jun 2014 21:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApYvZkCbkGWN for ; Wed, 25 Jun 2014 21:41:19 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A030E1B2F23 for ; Wed, 25 Jun 2014 21:41:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 09E492AB297; Thu, 26 Jun 2014 04:41:05 +0000 (UTC) Date: Thu, 26 Jun 2014 04:41:04 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140626044104.GR16666@mournblade.imrryr.org> References: <20140626034524.4F3C41AD69@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PryiJGzVIfRnw9htAi4r7bESQJs Subject: Re: [TLS] Call for Consensus: ECC on standards track X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 04:41:20 -0000 On Wed, Jun 25, 2014 at 09:37:19PM -0700, Eric Rescorla wrote: > 2. If people don't feel like messing with the pre TLS 1.3 documents, > but do want ECC to be a basic part of 1.3 we could just import the > relevant sections of 4492 into TLS 1.3 (this might be desirable for > editorial reasons in any case) and just advance those pieces > on the standards track. Any chance that missing AECDH AEAD ciphersuites will be added? Right now, I can have anon ECDHE (AECDH) key exchange or AEAD symmetric crypto, but not both. -- Viktor. From nobody Wed Jun 25 21:47:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93E51B2F1F for ; Wed, 25 Jun 2014 21:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZ7Oqqqj4MRr for ; Wed, 25 Jun 2014 21:47:04 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7A01B2F18 for ; Wed, 25 Jun 2014 21:47:03 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so2939681wgh.28 for ; Wed, 25 Jun 2014 21:47:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=zVEsks4aDWNzKa7nunVO2hlvBtekSLWV5EADyvKHNdo=; b=YpgfFg2O4YV+9oKzTh+D4XI6ezm11EYWmpVJR1BQBBcGyNkf+2PnDt/HwmB0lPxmPp MAL8EFooFB5vfFu3uu3dGx8CzCt1j/TPTEjF67RCABCsv4yNHAtJGnxOT2iaNGd7u5a1 Cu3pD8sV4ybqDOvD2deqBIxLDERb3C0mY5jyvOlt40U0pTL62W20DRABSOkmcDdlCNfq O3+y/Og9rXP/fY5WHD0qXr/uVXvbiWs1woDd1Ro3al4QkggPXCv1UupLm1PwQejJVQDs FcRM6FfY+P0gYMqWVgky5WJ92i12ohBz9RkgZWNydeYKBbITOlCp7ybj22qlvvcidCeP jiVQ== X-Gm-Message-State: ALoCoQmS68WGHYeuoaCTMz1LSWNcuAsEyWmg3ESSd0iP54inuDGa7QACE23lla4Slc5UpYaJR5Kk X-Received: by 10.180.8.195 with SMTP id t3mr1224550wia.55.1403758022612; Wed, 25 Jun 2014 21:47:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 25 Jun 2014 21:46:22 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <20140626044104.GR16666@mournblade.imrryr.org> References: <20140626034524.4F3C41AD69@ld9781.wdf.sap.corp> <20140626044104.GR16666@mournblade.imrryr.org> From: Eric Rescorla Date: Wed, 25 Jun 2014 21:46:22 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=f46d044304ea49f7d704fcb5e2f1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hDX4gRsnjoYQ_URr-BuvTuVeaeA Subject: Re: [TLS] Call for Consensus: ECC on standards track X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 04:47:05 -0000 --f46d044304ea49f7d704fcb5e2f1 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 25, 2014 at 9:41 PM, Viktor Dukhovni wrote: > On Wed, Jun 25, 2014 at 09:37:19PM -0700, Eric Rescorla wrote: > > > 2. If people don't feel like messing with the pre TLS 1.3 documents, > > but do want ECC to be a basic part of 1.3 we could just import the > > relevant sections of 4492 into TLS 1.3 (this might be desirable for > > editorial reasons in any case) and just advance those pieces > > on the standards track. > > Any chance that missing AECDH AEAD ciphersuites will be added? > Right now, I can have anon ECDHE (AECDH) key exchange or AEAD > symmetric crypto, but not both. This certainly seems like something the WG could discuss, though I think it's separable from the broader ECC question. I've created a Github issue to track this topic so we don't lose it. https://github.com/tlswg/tls13-spec/issues/50 -Ekr --f46d044304ea49f7d704fcb5e2f1 Content-Type: text/html; charset=UTF-8



On Wed, Jun 25, 2014 at 9:41 PM, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:
On Wed, Jun 25, 2014 at 09:37:19PM -0700, Eric Rescorla wrote:

> 2. If people don't feel like messing with the pre TLS 1.3 documents,
> but do want ECC to be a basic part of 1.3 we could just import the
> relevant sections of 4492 into TLS 1.3 (this might be desirable for
> editorial reasons in any case) and just advance those pieces
> on the standards track.

Any chance that missing AECDH AEAD ciphersuites will be added?
Right now, I can have anon ECDHE (AECDH) key exchange or AEAD
symmetric crypto, but not both.

This certainly seems like something the WG could discuss, though
I think it's separable from the broader ECC question.

I've created a Github issue to track this topic so we don't lose it.

-Ekr


--f46d044304ea49f7d704fcb5e2f1-- From nobody Wed Jun 25 22:34:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369DA1B2ABE for ; Wed, 25 Jun 2014 22:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iBetRmSrpdt for ; Wed, 25 Jun 2014 22:34:49 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8601B2AB9 for ; Wed, 25 Jun 2014 22:34:49 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s5Q5Yh2X026198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jun 2014 07:34:44 +0200 (MEST) In-Reply-To: To: Eric Rescorla Date: Thu, 26 Jun 2014 07:34:43 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140626053443.DBBE71AD68@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z0UOxFyhOvtOXL2uxTtG7FU-_Ww Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Call for Consensus: ECC on standards track X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 05:34:51 -0000 Eric Rescorla wrote: > On Wed, Jun 25, 2014 at 8:45 PM, Martin Rex wrote: > > > Sean Turner wrote: > > > > > > Based on the mailing list discussion, the chairs believe that there is > > > strong support to publish TLS ECC Cipher Suites on the Standards > > > Track > > > > > > - Should we include TLS ECC Cipher Suites for AES-GCM > > > directly in the TLS 1.3 document (and hence on the Standards Track). > > > > You would have to move the whole ECC for TLS stuff to standards track > > before thinking about adding any cipher suites that depend on this > > into the base TLS spec > > Unless I am missing something, RFC 3967 permits normative references > from Standards Track RFCs to Informational RFCs, provided that those > issues are called out in IETF LC. So, I believe we could simply refer to > 4492 from TLS 1.3 provided we follow the RFC 3967 Section 3. The copy of rfc3967 that I'm just looking at contains the following exclusion (last paragraph of Section 3): This procedure should not be used if the proper step is to move the document to which the reference is being made into the appropriate category. It is not intended as an easy way out of normal process. Rather, the procedure is intended for dealing with specific cases where putting particular documents into the required category is problematic and unlikely ever to happen. -Martin From nobody Thu Jun 26 00:14:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2024F1B2EA8 for ; Thu, 26 Jun 2014 00:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TR_ylSOwmdib for ; Thu, 26 Jun 2014 00:14:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.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 435D01B2F24 for ; Thu, 26 Jun 2014 00:14:06 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5Q7E4M9002653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 26 Jun 2014 03:14:04 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5Q7E2Af009342 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2014 03:14:03 -0400 Message-ID: <1403766841.4179.3.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "Joseph Salowey (jsalowey)" Date: Thu, 26 Jun 2014 09:14:01 +0200 In-Reply-To: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JjOe57H4IXWpN_bYlPs-jSznDjc Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 07:14:21 -0000 On Wed, 2014-06-25 at 18:34 +0000, Joseph Salowey (jsalowey) wrote: > We would like to see if there is consensus on removing renegotiation in TLS 1.3. We had rough consensus at the interim to remove renegotiation. Please state your position by indicating preference for one of the following (we will have a separate consensus call to decide on rekey approach). > > 1. Do you favor removing renegotiation from TLS 1.3 either with or without an additional facility for rekey? > 2. Are you in favor of not removing renegotiation regardless of the addition of a separate rekey facility? > Please respond to the list by July 1, 2014. I don't understand how this got into the discussion of TLS 1.3. This was never approved as part of the TLS 1.3 charter, so I believe that there should be a re-charter to include changes like that. As it is now the discussion on TLS 1.3 is moving wherever the wind blows. regards, Nikos From nobody Thu Jun 26 03:50:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDB91B2B3C for ; Thu, 26 Jun 2014 03:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9tkao-Vjfhx for ; Thu, 26 Jun 2014 03:49:59 -0700 (PDT) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by ietfa.amsl.com (Postfix) with ESMTP id AB1161B2B32 for ; Thu, 26 Jun 2014 03:49:59 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s5QAnvoM017553; Thu, 26 Jun 2014 06:49:57 -0400 Date: Thu, 26 Jun 2014 06:49:56 -0400 (EDT) From: Hubert Kario To: Yoav Nir Message-ID: <2082143270.33157164.1403779796220.JavaMail.zimbra@redhat.com> In-Reply-To: <3E3ED127-E1DE-469A-A322-8B14856CFEE9@gmail.com> References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF192@USMBX1.msg.corp.akamai.com> <6B247363-E6E2-4A81-92D8-FE2F02C14227@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1A5@USMBX1.msg.corp.akamai.com> <3E3ED127-E1DE-469A-A322-8B14856CFEE9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF30 (Linux)/8.0.6_GA_5922) Thread-Topic: Call for Consensus on removal of renegotiation Thread-Index: ZhtHVRuFyaj/vzv7vWPSqAvDooYxXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/C-6wmLj7AUJ-W5_v9s67UFFZE2g Cc: tls Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 10:50:03 -0000 ----- Original Message ----- > From: "Yoav Nir" > To: "Rich Salz" > Cc: "" > Sent: Wednesday, 25 June, 2014 11:06:11 PM > Subject: Re: [TLS] Call for Consensus on removal of renegotiation >=20 >=20 > On Jun 25, 2014, at 11:52 PM, Salz, Rich wrote: >=20 > >=20 > > I believe the consensus is to adopt > > http://datatracker.ietf.org/doc/draft-thomson-tls-care/ which I prefer = to > > think of as "do have any idea who I am=E2=80=9D >=20 > I must have missed when they called consensus on that. In that case, I=E2= =80=99m with > the =E2=80=9Cremove it entirely (1)=E2=80=9D camp. We use 128-bit ciphers= today. Even with > CBC, you will replace the client and the server long before you=E2=80=99v= e encrypted > so much that you need to rekey. Periodic rekeying is something that > auditors like, but is very rarely needed in HTTPS, SMTP and the like. I= =E2=80=99m > fine with forcing the few applications that need to to adapt. Current FIPS states that you can't encrypt more than 64GiB with a single ke= y using AES-GCM. It's not a lot, and it is definetely in the realm of possibi= lity even for HTTPS (games, disk images), let alone actually long lived connecti= ons... --=20 Regards, Hubert Kario From nobody Thu Jun 26 05:40:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB1F1B2BB6 for ; Thu, 26 Jun 2014 05:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1lBO7RztRlr for ; Thu, 26 Jun 2014 05:40:45 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8A21B2BB3 for ; Thu, 26 Jun 2014 05:40:43 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id r20so960164wiv.10 for ; Thu, 26 Jun 2014 05:40:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QQzyGzJVH+FW6rHgNrr4v4rib5RZFNgEWV60gNqY/g8=; b=HlmwjGsLtxLhZn9DQH2wreTWgiu3WtN4y2I8iFYHyHy31O6XIkjpV5lTrEfAkRj+W7 f0QsLMAiCLQSSoxaGCCU980gZl0yQDLOs/Wst3Sr+nlTz2N3xED3VV5pXFuyo22OIT7A BokOnmqsmZR9bYrym1XHOBYOTU4uFTR0NEVphgx/ewlmPgv3WdP3HxZL+5sk1qb7LHcN woOgTnBgQ568PWsoVt+/UZWQt+l/qHvdVwqMLxrfYA71E9HnImi14OPe74/aWdjJCWXz Phibh1KHFKor+57/w91reNZx3rMQDUPr3uLbRUHeFc2e5FFMoSs36VTbbHC2rqjmdShC 1W9A== X-Gm-Message-State: ALoCoQnMFqsAq5zaHZZLLsLFNQqArk+iql2T3wGKYTjGzwRoWROQsXC6VvTmwZjTi/q0VdkQ+vRH X-Received: by 10.180.76.20 with SMTP id g20mr4097887wiw.7.1403786442201; Thu, 26 Jun 2014 05:40:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Thu, 26 Jun 2014 05:40:01 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <20140626053443.DBBE71AD68@ld9781.wdf.sap.corp> References: <20140626053443.DBBE71AD68@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Thu, 26 Jun 2014 05:40:01 -0700 Message-ID: To: "mrex@sap.com" Content-Type: multipart/alternative; boundary=f46d043439463a647904fcbc807a Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8D_Re80nNcDsaetViwiTDuXwXGs Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Call for Consensus: ECC on standards track X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 12:40:47 -0000 --f46d043439463a647904fcbc807a Content-Type: text/plain; charset=UTF-8 On Wed, Jun 25, 2014 at 10:34 PM, Martin Rex wrote: > Eric Rescorla wrote: > > On Wed, Jun 25, 2014 at 8:45 PM, Martin Rex wrote: > > > > > Sean Turner wrote: > > > > > > > > Based on the mailing list discussion, the chairs believe that there > is > > > > strong support to publish TLS ECC Cipher Suites on the Standards > > > > Track > > > > > > > > - Should we include TLS ECC Cipher Suites for AES-GCM > > > > directly in the TLS 1.3 document (and hence on the Standards > Track). > > > > > > You would have to move the whole ECC for TLS stuff to standards track > > > before thinking about adding any cipher suites that depend on this > > > into the base TLS spec > > > > Unless I am missing something, RFC 3967 permits normative references > > from Standards Track RFCs to Informational RFCs, provided that those > > issues are called out in IETF LC. So, I believe we could simply refer to > > 4492 from TLS 1.3 provided we follow the RFC 3967 Section 3. > > The copy of rfc3967 that I'm just looking at contains the following > exclusion > (last paragraph of Section 3): > > This procedure should not be used if the proper step is to move the > document to which the reference is being made into the appropriate > category. It is not intended as an easy way out of normal process. > Rather, the procedure is intended for dealing with specific cases > where putting particular documents into the required category is > problematic and unlikely ever to happen Yes, I have read that as well, but as a practical matter, we have done normative downrefs to documents which in principle could have been uplifted but in practice are not going to be, See, for instance the case of 2818: http://datatracker.ietf.org/doc/rfc2818/referencedby/ Also, see: http://tools.ietf.org/html/rfc4897 However, as I said in my previous response, we can also publish standards track documents which describe ECC without referring to 4492, so I don't think this is really a problem procedurally if the WG decides that what it wants is for ECC to be on the standards track. -Ekr --f46d043439463a647904fcbc807a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 25, 2014 at 10:34 PM, Martin Rex <= mrex@sap.com> wrote:
Eric Rescorla wrote:
> On Wed, Jun 25, 2014 at 8:45 PM, Martin Rex <mrex@sap.com> wrote:
>
> > Sean Turner wrote:
> > >
> > > Based on the mailing list discussion, the chairs believe tha= t there is
> > > strong support to publish TLS ECC Cipher Suites on the Stand= ards
> > > Track
> > >
> > > - Should we include TLS ECC Cipher Suites for AES-GCM
> > > =C2=A0 directly in the TLS 1.3 document (and hence on the St= andards Track).
> >
> > You would have to move the whole ECC for TL= S stuff to standards track
> > before thinking about adding any cipher suites that depend on thi= s
> > into the base TLS spec
>
> Unless I am missing something, RFC 3967 permits normative references > from Standards Track RFCs to Informational RFCs, provided that those > issues are called out in IETF LC. So, I believe we could simply refer = to
> 4492 from TLS 1.3 provided we follow the RFC 3967 Section 3.

The copy of rfc3967 that I'm just looking at contains the followi= ng exclusion
(last paragraph of Section 3):

=C2=A0 =C2=A0This procedure should not be used if the proper step is to mov= e the
=C2=A0 =C2=A0document to which the reference is being made into the appropr= iate
=C2=A0 =C2=A0category. =C2=A0It is not intended as an easy way out of norma= l process.
=C2=A0 =C2=A0Rather, the procedure is intended for dealing with specific ca= ses
=C2=A0 =C2=A0where putting particular documents into the required category = is
=C2=A0 =C2=A0problematic and unlikely ever to happen

<= /div>
Yes, I have read that as well, but as a practical matter, we have= done
normative downrefs to documents which in principle coul= d have
been uplifted but in practice are not going to be, See, for instance
the case of 2818:

Also, see:


However, as I said in my previous response, = we can also publish
standards track documents which describe ECC without referring
to 4492, so I don't think this is really a problem procedurally if
the WG decides that what it wants is for ECC to be on the standard= s
track.

-Ekr




=C2=A0
--f46d043439463a647904fcbc807a-- From nobody Thu Jun 26 07:54:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFC41B2A26 for ; Thu, 26 Jun 2014 07:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErgZBtUtL2tp for ; Thu, 26 Jun 2014 07:54:45 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A6B1B2A4F for ; Thu, 26 Jun 2014 07:09:07 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s5QE8vxp003845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jun 2014 16:08:57 +0200 (MEST) In-Reply-To: <2082143270.33157164.1403779796220.JavaMail.zimbra@redhat.com> To: Hubert Kario Date: Thu, 26 Jun 2014 16:08:57 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140626140857.7D7841AD68@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FABVkvKZ2rd4vbjSkyQ-ywJUWyw Cc: tls Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 14:54:47 -0000 Hubert Kario wrote: > > Current FIPS states that you can't encrypt more than 64GiB with > a single key using AES-GCM. It's not a lot, and it is definetely > in the realm of possibility even for HTTPS (games, disk images), > let alone actually long lived connections... For some, 64 GigaBytes is at the small end already today. I know folks who transfer database backups over TLS-protected communiation links (i.e TeraByte(s) of data). -Martin From nobody Thu Jun 26 08:24:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDBF1B3022 for ; Thu, 26 Jun 2014 08:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuaFI0Be7NEj for ; Thu, 26 Jun 2014 08:24:28 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DCDB1B3025 for ; Thu, 26 Jun 2014 07:30:51 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s5QEUjq9021467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jun 2014 16:30:45 +0200 (MEST) In-Reply-To: To: "Joseph Salowey (jsalowey)" Date: Thu, 26 Jun 2014 16:30:44 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140626143044.F3B0C1AD68@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UwMlvfBfjl4mfEklbZlDVZQkVtA Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 15:24:33 -0000 Joseph Salowey (jsalowey) wrote: > > 1. In favor of removing renegotiation > 2. In favor of removing renegotiation with the addition of rekey facility > 3. Not in favor of removing renegotiation (3) Leave it in the spec, Make it a true option for implementors. with a guidance that clients might need it for interop, but should play safe (and nail down identities once they're established) by default I never offered/exposed renegotiation at the API to application callers, and since January 2010, I have the server-side reject renegotiation attempts from clients. But the installed base of _other_ servers that use (or require) it is to large to be ignored, and I don't see it go away that easily... Everything that you change from TLSv1.0/1/2 toward v1.3 will add complexity and require more code. This applies not just to adding new features, but also to axing existing features that may be in current use. A TLSv1.3 spec that requires implementors to carefully avoid TLSv1.3 for a number of commonly used TLSv1.0/1/2 features may be even harder to sell than TLSv1.2 and IPv6. -Martin From nobody Thu Jun 26 08:29:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE52E1B30A5 for ; Thu, 26 Jun 2014 08:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th3mS2DzVkjX for ; Thu, 26 Jun 2014 08:29:30 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4D21B30A7 for ; Thu, 26 Jun 2014 07:35:57 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id a41so2157797yho.16 for ; Thu, 26 Jun 2014 07:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LWBNTF9nSu2NuVMO54SIRjvn+krzdQBSrdkZoDWskhk=; b=nYICYKxIrphdFfYtdtGyv1yd0PrM+sPpvIv8Eb4x1QZ32/YNe7hHYPeNJrhsWvUVhW gjVWGsMN0kW2lJscDds1T1xXTAevmGQ9DekWIralM5NUcwQ/8q2alTBkJVXc0WzeZW4g MoemaUQxnV0nIYBpibWbj6Yik3eZZGvxsuWkmMsqrd/6XqPMma4MsMeZuq3tEljhl6m/ haTTKdXJlwh7jz8GibHfNQ14RuvtBtYdcGlgBuApDeaAxvz+ET19/COMhk2HYw+j33gi QqGiwzwvh8mueOwKCm77YSgC5T+dG8aIc40qKY6N1GSBpafLfZmePajuWmAYbqsqgE1P WHdA== MIME-Version: 1.0 X-Received: by 10.236.134.169 with SMTP id s29mr22559325yhi.4.1403793356847; Thu, 26 Jun 2014 07:35:56 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Thu, 26 Jun 2014 07:35:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Jun 2014 07:35:56 -0700 Message-ID: From: Watson Ladd To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IF4r9zb7poZ8QbF90BcBYMVsdNc Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 15:29:35 -0000 On Thu, Jun 26, 2014 at 1:18 AM, Bodo Moeller wrote: > Watson Ladd : > >> TLS with ECC computes the premaster secret as H(abg) where g is the >> generator of the group, and a and b are the ephemeral exponents. >> Because of protocol weaknesses, this premaster secret must be >> "contributory": neither side can be allowed to dictate it. > > > [...] >> >> The solution is to follow the advice on contributory behaviour and >> disallow a fixed list of public keys, namely those of small order. > > > Good point. Given that the cofactor present in your secret key guarantees > that you'll end up in a prime-order group (regardless of how the peer's > input was chosen), I think you'd rather want to check the ECDH result > instead of checking against that larger blacklist of public keys. > >> Alternatively we can compute the premaster secret as the hash of H(ag >> | bg | abg): I have not yet confirmed that this solves the problem. > > > Hm, this looks like something that rather belongs into the premaster secret > => master secret step. If you have this there (such as when you're using > the proposed Extended Master Secret Extension > [draft-bhargavan-tls-session-hash-00]), including the public keys here too > would be redundant. If you'd normally be doing a public-key check or an > ECDH result check, you could just skip this check if the protocol no longer > has a need for such protection. In contrast, if you hash those additional > inputs when computing the premaster secret, that's not something you could > remove without affecting compatibility. Yes, we could make EMSE a dependency of Curve25519. Or we could change the way we compute the PMS to avoid doing this: I proposed this solution because its very simple for some implementations. What do we gain from having the PMS calculated the same way for each curve? > > (On the flip site, of course, if an implementation omits a check that's > necessary for security reasons in the protocol that you're using, you > wouldn't normally notice interoperability problems as a result. In > contrast, if the protocol has those additional hash inputs, implementations > couldn't get that wrong without failing to interoperate with others. > However, there are many other more complex essential security checks that we > trust implementations to get right, so the extra protocol complexity for > this particular case doesn't seem warranted.) This is a mistake in the design. Unfortunately I can't go into details right now. Sincerely, Watson Ladd > > Bodo > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Jun 26 08:35:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACFD1B310A for ; Thu, 26 Jun 2014 08:35: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTZGE9srjonq for ; Thu, 26 Jun 2014 08:35:08 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7CFF1B2FD6 for ; Thu, 26 Jun 2014 07:40:49 -0700 (PDT) Received: by mail-yk0-f180.google.com with SMTP id 131so2033216ykp.39 for ; Thu, 26 Jun 2014 07:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Bxq/Q4eT6Uhz+g38wyMGe1XOPwAYWQNjC9zCU0fN8Ek=; b=mFrffUBCFs9eawUjmusl7KE2/j7RW8WYUB1dzRMwOWo88Dj22B3ZKDX4bMYwGWgG4R bAVSyRqLOZ4Kb74Asbpx+Dfxk/EYCN8L0mfBUXcf1JcyldyvJVDnB55Q26aLutcZJVby lbD+IVLzJ2qSUbvd5CW6kjAz3LpPeTo6bgsyqbiKntInuTMsGHD0fKVGGYg7XO8Q7uRP W/Yi26EQV/jpm11KHA+o5PgyNl6KFrfsSq9BaMQI8s2rmoSEA8yIXT3CAPvojY1W2997 v2UR1G9iI2C+hbSIVTZj4k0xjSnjIJH2jfimLuPnG5k6oZF81wOzWEVvLqRseYgxR9pO 3cKg== MIME-Version: 1.0 X-Received: by 10.236.15.133 with SMTP id f5mr22309741yhf.63.1403793649276; Thu, 26 Jun 2014 07:40:49 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Thu, 26 Jun 2014 07:40:49 -0700 (PDT) In-Reply-To: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> Date: Thu, 26 Jun 2014 07:40:49 -0700 Message-ID: From: Watson Ladd To: "Joseph Salowey (jsalowey)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XVm3zS60OqFxRhGWgMYbISR1omA Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 15:35:13 -0000 On Wed, Jun 25, 2014 at 11:34 AM, Joseph Salowey (jsalowey) wrote: > We would like to see if there is consensus on removing renegotiation in T= LS 1.3. We had rough consensus at the interim to remove renegotiation. Ple= ase state your position by indicating preference for one of the following (= we will have a separate consensus call to decide on rekey approach). > > 1. Do you favor removing renegotiation from TLS 1.3 either with or withou= t an additional facility for rekey? Remove renegotiation: we need a properly working rekey compatible with session tickets. > 2. Are you in favor of not removing renegotiation regardless of the addit= ion of a separate rekey facility? > > Please respond to the list by July 1, 2014. > > Thanks, > > Joe > (for the chairs) > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Jun 26 08:44:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A119B1B3164 for ; Thu, 26 Jun 2014 08:44:19 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXYK6PZu2Z85 for ; Thu, 26 Jun 2014 08:44:18 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8EDC1B3192 for ; Thu, 26 Jun 2014 07:48:14 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 79so2081922ykr.28 for ; Thu, 26 Jun 2014 07:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=uLjeIj5YJvuWu51IX2rbM598yh0vqQTiu38uVPlhiAw=; b=mO6+NQjby2IinN+tltFuXcbWaq5mVnrCofE5SxqDIY5+SquNG+tJwhaZesq41Kr5C0 ZGpn+k2GqsbOnPURRnh6E3xwTgyOQbynTRyXI6kadqbLpQ8lgSKP4ErKFjPoVrMxX26Y 1x+c1VOjrLmAyo+ATOAfzAaGBubp5JrA9WCPJLy8Zzkwm/iBTPgKu9iGM153WuwuPwIn ONpAgAa8UMQroCaCrKZwIyzmRBrkzpFQePZrGworyr/usORTOQgZuLFFkVYfRLpHu8Gk 8yHiehlNwmARr8S6ProRbYAtbcpzQfYoBERl/gszOpIJaQ6WvSGYWvfwbfY9lMYnqtPD QuiQ== MIME-Version: 1.0 X-Received: by 10.236.134.169 with SMTP id s29mr22653573yhi.4.1403794093994; Thu, 26 Jun 2014 07:48:13 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Thu, 26 Jun 2014 07:48:13 -0700 (PDT) In-Reply-To: <53ABCA3E.3080201@cs.bris.ac.uk> References: <53AA8839.8000507@cs.bris.ac.uk> <810C31990B57ED40B2062BA10D43FBF5CA9DB3@XMB116CNC.rim.net> <53ABCA3E.3080201@cs.bris.ac.uk> Date: Thu, 26 Jun 2014 07:48:13 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/i1Inb411bFhwuncr_E6-ehtCdB0 Subject: Re: [TLS] [Cfrg] FW: Schnorr Signatures X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 15:44:19 -0000 Dear all, Schnorr permits batching and is faster as there is no inverse. But to take full advantage, you have to send R, the temporary point, not just the x-coordinate. With point compression this is easy, without the signature gets a little bigger. In the case of TLS the benefit is limited: ECDSA is required for certs, which are going to be around for a while. As a result there is only one Schnorr signature, so batching doesn't help much. I think it's still worth doing: that inversion is a real pain. Sincerely, Watson Ladd From nobody Thu Jun 26 08:49:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6138D1B2904 for ; Thu, 26 Jun 2014 08:49: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yh37NOCKxpOn for ; Thu, 26 Jun 2014 08:49:07 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7E3D1B31B0 for ; Thu, 26 Jun 2014 07:51:20 -0700 (PDT) Received: by mail-yk0-f175.google.com with SMTP id 9so2045990ykp.20 for ; Thu, 26 Jun 2014 07:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=L1Vzee0M+llQ3v7I/jUxedfxA5PNnaVlB5IYD2JXz9w=; b=rxRzMk85f740U4D7S8QhGopcMks907nlL7wdXLCjQTQmMWJThFvVHt+LnRkW9nHfcm xoecJUhlo2Xw55tgVSEQLyIwtE72Nx+U6qQ8vBG3U0VyWwRlSjGTBes4HhQfJZDxy4GB SMjDPTEC4uWE0DzOFBKiZ4JXSohW9+PNfT4wv0G/HJc2SY+h1v2WHomjTgl29eOy/VP1 bYc3B7TwaCTHNi2SSOBb5xvXpBSq6vis0KQm7WyOjwojLPGV9Z0RYR9TLYlybgp7xePd gSpzSQf6vRnj4ZbUh6Uo5wW2/OWfceCYgpEc6jEdKDVRwCj8j0GlCZFhgnxLsy4Jplf/ zYig== MIME-Version: 1.0 X-Received: by 10.236.173.71 with SMTP id u47mr22830608yhl.66.1403794280016; Thu, 26 Jun 2014 07:51:20 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Thu, 26 Jun 2014 07:51:19 -0700 (PDT) In-Reply-To: <1403766841.4179.3.camel@dhcp-2-127.brq.redhat.com> References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <1403766841.4179.3.camel@dhcp-2-127.brq.redhat.com> Date: Thu, 26 Jun 2014 07:51:19 -0700 Message-ID: From: Watson Ladd To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TavrUADrVavAF_2FhANJPku1-Bk Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 15:49:09 -0000 On Thu, Jun 26, 2014 at 12:14 AM, Nikos Mavrogiannopoulos wrote: > On Wed, 2014-06-25 at 18:34 +0000, Joseph Salowey (jsalowey) wrote: >> We would like to see if there is consensus on removing renegotiation in = TLS 1.3. We had rough consensus at the interim to remove renegotiation. Pl= ease state your position by indicating preference for one of the following = (we will have a separate consensus call to decide on rekey approach). >> >> 1. Do you favor removing renegotiation from TLS 1.3 either with or witho= ut an additional facility for rekey? >> 2. Are you in favor of not removing renegotiation regardless of the addi= tion of a separate rekey facility? >> Please respond to the list by July 1, 2014. > > I don't understand how this got into the discussion of TLS 1.3. This was > never approved as part of the TLS 1.3 charter, so I believe that there > should be a re-charter to include changes like that. As it is now the > discussion on TLS 1.3 is moving wherever the wind blows. The TLS 1.3 charter didn't include security as a charter goal. It was also very controversial: significant numbers of implementers indicated that they wished the committee would deal with problems ignored for a decade or two before trying to make something new. Sincerely, Watson Ladd > > regards, > Nikos > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Jun 26 09:28:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168271B28DA for ; Thu, 26 Jun 2014 09:27: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX304U8cJIjN for ; Thu, 26 Jun 2014 09:27:54 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A80C61B2900 for ; Thu, 26 Jun 2014 08:48:47 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id x13so3883996wgg.15 for ; Thu, 26 Jun 2014 08:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=go/RkyatJdt+iqIxN1W77bLXWDisqh/I/4uljukqIzA=; b=Wz02lE90IV/s01ZcN3tOqBTL0895lVbsJYnNCLwF2c2t41f9Ap1eGNErgYw6PvUSxH AImVuhhPLF0O6lTwYu+8ixYNzL2x01g6N59wvJGS7bwhVZ5xDRedw8irTKH5PnGDpYsQ aOUntF3CALxNiBoeU0+r/X3xVFT8pRfAkEHAYvkq+xZCGYXLQSySRMTD8WlGLb7+DkDx lFEHCNV4Oj5lhkRvVby8uPeiftGEUxjbyXkE4ASd3aXap05igBgUxpbO7Voddj4/ccAZ u0kBb93RWaLosgBzFe+RobqQuamVijbYjMFiJcJ9JnEpIeR7yIpjFrv1H716fjoE9Aaf U+7Q== X-Received: by 10.180.19.70 with SMTP id c6mr5326449wie.19.1403797725912; Thu, 26 Jun 2014 08:48:45 -0700 (PDT) Received: from [10.4.19.106] ([82.102.169.113]) by mx.google.com with ESMTPSA id w5sm67206632wif.3.2014.06.26.08.48.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 08:48:45 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: <2082143270.33157164.1403779796220.JavaMail.zimbra@redhat.com> Date: Thu, 26 Jun 2014 18:48:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF192@USMBX1.msg.corp.akamai.com> <6B247363-E6E2-4A81-92D8-FE2F02C14227@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1A5@USMBX1.msg.corp.akamai.com> <3E3ED127-E1DE-469A-A322-8B14856CFEE9@gmail.com> <2082143270.33157164.1403779796220.JavaMail.zimbra@redhat.com> To: Hubert Kario X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w2VTqnnD0oa6bbD4JCz9lzl3ZSo Cc: tls Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 16:27:57 -0000 On Jun 26, 2014, at 1:49 PM, Hubert Kario wrote: > ----- Original Message ----- >> From: "Yoav Nir" >> To: "Rich Salz" >> Cc: "" >> Sent: Wednesday, 25 June, 2014 11:06:11 PM >> Subject: Re: [TLS] Call for Consensus on removal of renegotiation >>=20 >>=20 >> On Jun 25, 2014, at 11:52 PM, Salz, Rich wrote: >>=20 >>>=20 >>> I believe the consensus is to adopt >>> http://datatracker.ietf.org/doc/draft-thomson-tls-care/ which I = prefer to >>> think of as "do have any idea who I am=94 >>=20 >> I must have missed when they called consensus on that. In that case, = I=92m with >> the =93remove it entirely (1)=94 camp. We use 128-bit ciphers today. = Even with >> CBC, you will replace the client and the server long before you=92ve = encrypted >> so much that you need to rekey. Periodic rekeying is something that >> auditors like, but is very rarely needed in HTTPS, SMTP and the like. = I=92m >> fine with forcing the few applications that need to to adapt. >=20 > Current FIPS states that you can't encrypt more than 64GiB with a = single key > using AES-GCM. It's not a lot, and it is definetely in the realm of = possibility > even for HTTPS (games, disk images), let alone actually long lived = connections=85 That number seemed suspiciously low, so I went and read SP-800-38D. It recommends two different limits depending on the length of the IV. For IVs that are constructed deterministically, but whose length is = *not* 96 bits, the limit is 2^32 invocations. 2^32 invocations means 4 = billion TLS records, which could be up to 16 Terabytes. But that doesn=92t matter anyway, because in TLS the recommendation is = to create the nonce deterministically and the length *is* 96 bits, so = the limit is 2^64 invocations.=20 Even with 1-byte records, that=92s more terabytes than we know what to = do with. So I stand by what I said earlier. Just because of volume, there is no = reason to rekey an AES session. Yoav From nobody Thu Jun 26 09:30:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C9D1B29A9 for ; Thu, 26 Jun 2014 09:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FOMc0YB5JWX for ; Thu, 26 Jun 2014 09:30:31 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C935C1B2FAA for ; Thu, 26 Jun 2014 09:14:58 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id x48so3906297wes.37 for ; Thu, 26 Jun 2014 09:14:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=8XtwUecVIuCWVu0QgNpr9r+S3FADWzIk/PybraH+FnQ=; b=ZH6oum4BXqHqBVFacGGQgIClsBwKSW/w6NTk4OjPUQMQFWoI0qLxQaWXjdxOzXFZoZ pzWrMqhdQrQlg777Sjzc3KCQ06mEDrB55L+c2JpL/e98bQZtzSkWDy4qpLdpAKI8h2z8 km4OmR6fYQ9lWENncLw7dcMZe0jPxd4R619LdEZpFjQDZoHVwxILAAfTh8M/Z2bag32H HALtqL7usaMavOV2mTAyYjH/rvmVMMkvNMn2Kff67lgacb6f7xhQp/4TEjScN3MbY/eu jkxKC64BcsZx+ZVazK0/ytJIfCuivYQm93GnnwLu9jYjt5ZDO4TTH+LE101pTW07/Ova OEjg== X-Gm-Message-State: ALoCoQm4wNuUz4g8GlAECd/A3QqbCVHRq5Zz6Mpiqm3Cf8qX2VBJ+GM+qJRYm6rVxiuPHRNT9n1l X-Received: by 10.194.192.201 with SMTP id hi9mr15330496wjc.28.1403799295472; Thu, 26 Jun 2014 09:14:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Thu, 26 Jun 2014 09:14:15 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:e88c:a4b4:d3a:6b6a] From: Eric Rescorla Date: Thu, 26 Jun 2014 09:14:15 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b8739a857dbc204fcbf7e61 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uYpCW_bgNs2m0lKdFYa3BAmkXLA Subject: [TLS] Does anyone still want dh_rsa and dh_dss? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 16:30:32 -0000 --047d7b8739a857dbc204fcbf7e61 Content-Type: text/plain; charset=UTF-8 We've already removed static RSA for TLS 1.3 but we didn't emove dh_rsa and dh_dss (as opposed to dhe_rsa and dhe_dss). It seems like the arguments for removing static RSA apply even more strongly here. Is there any reason to retain these in TLS 1.3? -Ekr --047d7b8739a857dbc204fcbf7e61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We've already removed static RSA for TLS 1.3 but we di= dn't=C2=A0
emove dh_rsa and dh_dss (as opposed to dhe_rsa and
=
dhe_dss). It seems like the arguments for removing static
RS= A apply even more strongly here.

Is there any reason to retain these in TLS 1.3?

-Ekr

--047d7b8739a857dbc204fcbf7e61-- From nobody Thu Jun 26 10:25:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4F11B2BE5 for ; Thu, 26 Jun 2014 10:25:52 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5sKfK3Y56Kq for ; Thu, 26 Jun 2014 10:25:47 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4BB1B2BE6 for ; Thu, 26 Jun 2014 10:25:14 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so1475093wib.12 for ; Thu, 26 Jun 2014 10:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IJuveRYLDdiVnh0UIRlcWVJj1dFh49X9QcRdJoOFMBM=; b=AqWI6fdBLwYzgPcMUkWjwp8H86nyx1oNd84lplFzzUjPeUSBKU1EoZ0OSLj8MGWdCj VUMr897ZL+d90gG2qJJ33mjv0N5763aLc4gEzvxrgAov3k43ovj3lR0pVknvhLTb+/qY 8YAiBpsChknLY7OtWGdc4USb4wJYtILmTzjaSVQwDkLxth6o53X8+L6kRabZSVbrZ2li tq6qaz2CTgmIdozCPyVYGWSDGltop/wwavdc895MkDztz9yVW7V3yzX5jUXMf5B3uFP0 9yTwdzIxe5lLeseIj0GY3Zat1yVwBEkB7uniE1/ozLld1rehizIP965XUMzvTjdgk9UY PeeQ== MIME-Version: 1.0 X-Received: by 10.194.86.42 with SMTP id m10mr4801999wjz.132.1403803510698; Thu, 26 Jun 2014 10:25:10 -0700 (PDT) Received: by 10.194.37.162 with HTTP; Thu, 26 Jun 2014 10:25:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Jun 2014 20:25:10 +0300 Message-ID: From: Yoav Nir To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e0102f17096f95704fcc0797e Archived-At: http://mailarchive.ietf.org/arch/msg/tls/U72gs0QBrbl_CiCP6yr6Eqll6Jg Cc: "tls@ietf.org" Subject: Re: [TLS] Does anyone still want dh_rsa and dh_dss? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 17:25:52 -0000 --089e0102f17096f95704fcc0797e Content-Type: text/plain; charset=UTF-8 On Thu, Jun 26, 2014 at 7:14 PM, Eric Rescorla wrote: > We've already removed static RSA for TLS 1.3 but we didn't > emove dh_rsa and dh_dss (as opposed to dhe_rsa and > dhe_dss). It seems like the arguments for removing static > RSA apply even more strongly here. > > Is there any reason to retain these in TLS 1.3? > None that I can see --089e0102f17096f95704fcc0797e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 26, 2014 at 7:14 PM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>
We've already removed static RSA for TLS 1.3 but we di= dn't=C2=A0
emove dh_rsa and dh_dss (as opposed to dhe_rsa and
=
dhe_dss). It seems like the arguments for removing static
RS= A apply even more strongly here.

Is there any reason to retain these in TLS 1.3?

None that I can see

--089e0102f17096f95704fcc0797e-- From nobody Thu Jun 26 10:32:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E59E1B2C4A for ; Thu, 26 Jun 2014 10:32:00 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmG1NbQ7wiNn for ; Thu, 26 Jun 2014 10:31:58 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78E6F1B2C8A for ; Thu, 26 Jun 2014 10:29:47 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id r20so1503075wiv.14 for ; Thu, 26 Jun 2014 10:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/G8Fb/SaQ9llTvq1gpojUz0EMQlYnS9ujOY1HCB3DyA=; b=i608ofi3LdlTqTNhH72hge4epjaKSNxy82+3KSJIm1aDPGjXYCnuTpt6IrlueNegIE oovxxj0KgPWTpqTN8y1uqim6Uy2J5SWZ1LeGOmvYkQtCGMlBQ+merD4h4YIzEBKDOYpR 6aLQ0rLPGtP9Uf7+1991lswgiRkL5d6s+BwzK+HbChD9OV2OJootZF5V48uLttu0s3bs bTM8HH1YwKxjeL3kyip+bfD1p8oi4adoVg+eSBGtBakayqyTgXrDynHvJM7S0QWeKyPs zB6RAFQZ7ohj07PvvL7ElIp1SZBrvE8LDrgv5fawsds8VAl21fiQ82UGlar7o2ldYni1 T5Og== MIME-Version: 1.0 X-Received: by 10.194.110.10 with SMTP id hw10mr19682605wjb.81.1403803785901; Thu, 26 Jun 2014 10:29:45 -0700 (PDT) Received: by 10.194.37.162 with HTTP; Thu, 26 Jun 2014 10:29:45 -0700 (PDT) In-Reply-To: References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF192@USMBX1.msg.corp.akamai.com> <6B247363-E6E2-4A81-92D8-FE2F02C14227@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1A5@USMBX1.msg.corp.akamai.com> <3E3ED127-E1DE-469A-A322-8B14856CFEE9@gmail.com> <2082143270.33157164.1403779796220.JavaMail.zimbra@redhat.com> Date: Thu, 26 Jun 2014 20:29:45 +0300 Message-ID: From: Yoav Nir To: Hubert Kario Content-Type: multipart/alternative; boundary=089e010d870cfe3f4204fcc08976 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4opDgduFvas1NjKUmYfVgNiF0bI Cc: tls Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 17:32:00 -0000 --089e010d870cfe3f4204fcc08976 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 26, 2014 at 6:48 PM, Yoav Nir wrote: > > That number seemed suspiciously low, so I went and read SP-800-38D. > > It recommends two different limits depending on the length of the IV. > > For IVs that are constructed deterministically, but whose length is *not* > 96 bits, the limit is 2^32 invocations. 2^32 invocations means 4 billion > TLS records, which could be up to 16 Terabytes. > Sorry. That's 64 TB. --089e010d870cfe3f4204fcc08976 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --089e010d870cfe3f4204fcc08976-- From nobody Thu Jun 26 10:35:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444F31B2CE5 for ; Thu, 26 Jun 2014 10:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuD2Elu77DHK for ; Thu, 26 Jun 2014 10:35:49 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3631B2C50 for ; Thu, 26 Jun 2014 10:32:20 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id s18so2156560lam.34 for ; Thu, 26 Jun 2014 10:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KJs6t76jEkg1NRvB6Pkqm6PrFsxCttPvrSbLz2W59LE=; b=yerpMLiWD4DTehAHLibFNJCLVny6A4j8dz/Vc96cHwtCrzmqh10ooeNwrlEuwUD1JE WBZHt7X30neJcO4xJEnXsWmynGK0q60pxQi2s1fG/aDuREZ4nKk1yM1zMJ7nwDGjlXfS LTAJlFDZ6E9FfG+SfPoaZ98bdnuJk60ClEmLhy9FxRpnm/vqys1zoJcygHGTJc3Y5OzW UKDQMUSfqIBozwoHIuWRyJeMDhkNByn+De9CabqQdpzQERYwIUImB5AiN0JKcDV1/mYk ikaYy/7jcD/a+dTLkNTotuY53BqyzYhNj2bCLjBpWM3nH7gIsNFRManSAhPbv68iG8mb joag== MIME-Version: 1.0 X-Received: by 10.152.10.40 with SMTP id f8mr3047698lab.75.1403803939037; Thu, 26 Jun 2014 10:32:19 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.32.196 with HTTP; Thu, 26 Jun 2014 10:32:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Jun 2014 10:32:18 -0700 X-Google-Sender-Auth: LghxrEYalkKVUY8i0AqC4y6YGjk Message-ID: From: Adam Langley To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/et_droWdTb0Kez7DHWuU9XXVPpU Cc: "tls@ietf.org" Subject: Re: [TLS] Does anyone still want dh_rsa and dh_dss? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 17:35:54 -0000 On Thu, Jun 26, 2014 at 9:14 AM, Eric Rescorla wrote: > Is there any reason to retain these in TLS 1.3? I don't believe so. (Additionally, I would drop DSS completely.) Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu Jun 26 10:36:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340001B2D8D for ; Thu, 26 Jun 2014 10:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un-pXOt3floB for ; Thu, 26 Jun 2014 10:36:43 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.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 884A01B2C7A for ; Thu, 26 Jun 2014 10:33:00 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5QHWvlZ016395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 26 Jun 2014 13:32:58 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5QHWtus021952 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2014 13:32:57 -0400 Message-ID: <1403803975.24165.5.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Yoav Nir Date: Thu, 26 Jun 2014 19:32:55 +0200 In-Reply-To: References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF192@USMBX1.msg.corp.akamai.com> <6B247363-E6E2-4A81-92D8-FE2F02C14227@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1A5@USMBX1.msg.corp.akamai.com> <3E3ED127-E1DE-469A-A322-8B14856CFEE9@gmail.com> <2082143270.33157164.1403779796220.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dq5GBoqc_G2GkNuS1nfapXM1Gro Cc: tls Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 17:36:45 -0000 On Thu, 2014-06-26 at 18:48 +0300, Yoav Nir wrote: > > Current FIPS states that you can't encrypt more than 64GiB with a single key > > using AES-GCM. It's not a lot, and it is definetely in the realm of possibility > > even for HTTPS (games, disk images), let alone actually long lived connections… > That number seemed suspiciously low, so I went and read SP-800-38D. > It recommends two different limits depending on the length of the IV. > For IVs that are constructed deterministically, but whose length is *not* 96 bits, the limit is 2^32 invocations. 2^32 invocations means 4 billion TLS records, which could be up to 16 Terabytes. > But that doesn’t matter anyway, because in TLS the recommendation is to create the nonce deterministically and the length *is* 96 bits, so the limit is 2^64 invocations. > Even with 1-byte records, that’s more terabytes than we know what to do with. > So I stand by what I said earlier. Just because of volume, there is no reason to rekey an AES session. That's true for TLS. DTLS has its record counter is limited to 2^48 bits, and that could require a rekey as it is often used for long-lived VPN sessions. Of course this call is about TLS though. regards, Nikos From nobody Thu Jun 26 10:46:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDAE1B2C75 for ; Thu, 26 Jun 2014 10:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgTcTZ4sSm7U for ; Thu, 26 Jun 2014 10:46:08 -0700 (PDT) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CAD11B2DF4 for ; Thu, 26 Jun 2014 10:39:06 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u57so3912415wes.5 for ; Thu, 26 Jun 2014 10:39:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Wigyed5pgR+ADUvDH6J1bdCdsGH1/WJI6jSmMKwddSU=; b=AlmvwlnzO4pGuNLBe/rxioPvtwJyfhpCgpIrOPscI0/UJlHtXYTZ83A3RnoYNzxKmL hlD34vDZMzblO6eM3/xIIvPOHpm0apcHLZxvuDEEUBRhbMmbC97FFpmUKh9VD71Ma58d IURuqx2z34z+H31vEhsI+40iItjtESr/uKFX13Yf+TizeERdmTu8l3QxyswIPPXD5fOT zeS5l4F2/UU7u/PnkqVGnCqgmUtPcI+0GEXvAGRXZ3qrOR1Exhn5z3ZgCMdacFzxegOE Kav9sx7m7hfquOHmLWorU+M3hsqrhSXpVAIgpzwZua/AbqbA7TUqsPfaH15lHZntFIfN doQQ== X-Gm-Message-State: ALoCoQnKrdEqQ7mOVuuvt4LGyIqhoWOglXI3r+DT2IxjsuuDD+yy9FtgIAHQgwxqSY8MS6YJo5mx X-Received: by 10.194.192.201 with SMTP id hi9mr15912395wjc.28.1403804341009; Thu, 26 Jun 2014 10:39:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Thu, 26 Jun 2014 10:38:20 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:e88c:a4b4:d3a:6b6a] In-Reply-To: <1403803975.24165.5.camel@dhcp-2-127.brq.redhat.com> References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF192@USMBX1.msg.corp.akamai.com> <6B247363-E6E2-4A81-92D8-FE2F02C14227@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF1A5@USMBX1.msg.corp.akamai.com> <3E3ED127-E1DE-469A-A322-8B14856CFEE9@gmail.com> <2082143270.33157164.1403779796220.JavaMail.zimbra@redhat.com> <1403803975.24165.5.camel@dhcp-2-127.brq.redhat.com> From: Eric Rescorla Date: Thu, 26 Jun 2014 10:38:20 -0700 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=047d7b8739a814970704fcc0ab8f Archived-At: http://mailarchive.ietf.org/arch/msg/tls/skIlbtTtPo3ZCKMknKP-89QxPkM Cc: tls Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 17:46:11 -0000 --047d7b8739a814970704fcc0ab8f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 26, 2014 at 10:32 AM, Nikos Mavrogiannopoulos wrote: > On Thu, 2014-06-26 at 18:48 +0300, Yoav Nir wrote: > > > > Current FIPS states that you can't encrypt more than 64GiB with a > single key > > > using AES-GCM. It's not a lot, and it is definetely in the realm of > possibility > > > even for HTTPS (games, disk images), let alone actually long lived > connections=E2=80=A6 > > That number seemed suspiciously low, so I went and read SP-800-38D. > > It recommends two different limits depending on the length of the IV. > > For IVs that are constructed deterministically, but whose length is > *not* 96 bits, the limit is 2^32 invocations. 2^32 invocations means 4 > billion TLS records, which could be up to 16 Terabytes. > > But that doesn=E2=80=99t matter anyway, because in TLS the recommendati= on is to > create the nonce deterministically and the length *is* 96 bits, so the > limit is 2^64 invocations. > > Even with 1-byte records, that=E2=80=99s more terabytes than we know wh= at to do > with. > > So I stand by what I said earlier. Just because of volume, there is no > reason to rekey an AES session. > > That's true for TLS. DTLS has its record counter is limited to 2^48 > bits, and that could require a rekey as it is often used for long-lived > VPN sessions. Of course this call is about TLS though > I would expect any decision made here to apply to DTLS as well. -Ekr --047d7b8739a814970704fcc0ab8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 26, 2014 at 10:32 AM, Nikos Mavrogiannopoulos <nmav@redh= at.com> wrote:
On Thu, 2014-06-26 at 18:48 = +0300, Yoav Nir wrote:

> > Current FIPS states that you can't encrypt more than 64GiB wi= th a single key
> > using AES-GCM. It's not a lot, and it is definetely in the re= alm of possibility
> > even for HTTPS (games, disk images), let alone actually long live= d connections=E2=80=A6
> That number seemed suspiciously low, so I went and read SP-800-38D. > It recommends two different limits depending on the length of the IV.<= br> > For IVs that are constructed deterministically, but whose length is *n= ot* 96 bits, the limit is 2^32 invocations. 2^32 invocations means 4 billio= n TLS records, which could be up to 16 Terabytes.
> But that doesn=E2=80=99t matter anyway, because in TLS the recommendat= ion is to create the nonce deterministically and the length *is* 96 bits, s= o the limit is 2^64 invocations.
> Even with 1-byte records, that=E2=80=99s more terabytes than we know w= hat to do with.
> So I stand by what I said earlier. Just because of volume, there is no= reason to rekey an AES session.

That's true for TLS. DTLS has its record counter is limited to 2^= 48
bits, and that could require a rekey as it is often used for long-lived
VPN sessions. Of course this call is about TLS though
=
I would expect any decision made here to apply to DTLS as we= ll.

-Ekr
--047d7b8739a814970704fcc0ab8f-- From nobody Thu Jun 26 11:10:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371911B2CBC for ; Thu, 26 Jun 2014 11:10:19 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArzLw4YWuSVq for ; Thu, 26 Jun 2014 11:10:17 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 21D811B2DC1 for ; Thu, 26 Jun 2014 10:54:05 -0700 (PDT) Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 26 Jun 2014 13:54:03 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0174.001; Thu, 26 Jun 2014 13:54:01 -0400 From: Dan Brown To: "'ekr@rtfm.com'" , "'tls@ietf.org'" Thread-Topic: [TLS] Does anyone still want dh_rsa and dh_dss? Thread-Index: AQHPkVv4Ug/SyRRqGUmFANIGryOLJpuDqTCw Date: Thu, 26 Jun 2014 17:54:01 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5CAA8F2@XMB116CNC.rim.net> References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F8_01CF9146.15A951B0" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/h1nvbBPdK7KGa6LuE8ERvBY2uAU Subject: Re: [TLS] Does anyone still want dh_rsa and dh_dss? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 18:10:19 -0000 ------=_NextPart_000_00F8_01CF9146.15A951B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla > > It seems like the arguments for removing static >RSA apply even more strongly here. I agree in that client auth + static DH is weaker than client auth + static RSA, because the former is vulnerable to key-compromise impersonation (KCI). I mentioned KCI a while back on this list, but forgot to add that it depends on client auth. ------=_NextPart_000_00F8_01CF9146.15A951B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUoDCCBo8w ggV3oAMCAQICCm2p3UcABAAABWowDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGMB4XDTE0MDUxNDE0MzYzOFoXDTE1MDUxNDE0MzYzOFowgaQxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsTAkNBMRQwEgYD VQQLEwtNaXNzaXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBCcm93bjEiMCAG CSqGSIb3DQEJARYTZGJyb3duQGNlcnRpY29tLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA54YaBOai2UDS89LoHMbDcC4+c8dEl5TpkJWz0muqjnXP6xpSYqBzotsw9SpPD3/0wF8Dz77Z hkYN8BDSF0RAdtmfXKXe40tQkHoplN4pos9jnBZW5e8HuTZUkEVC/q7bf399cskpxMt9MA934gvB rSk1QNbR3D7Hq34t4bOHXSUCAwEAAaOCA5gwggOUMAsGA1UdDwQEAwIFoDBEBgkqhkiG9w0BCQ8E NzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcw FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMCkGA1UdJQQiMCAGCisGAQQBgjcKAwQGCCsGAQUFBwME BggrBgEFBQcDAjBBBgNVHREEOjA4oCEGCisGAQQBgjcUAgOgEwwRZGFuaWJyb3duQHJpbS5uZXSB E2Ricm93bkBjZXJ0aWNvbS5jb20wHQYDVR0OBBYEFFdFrujr5LyMGa3Hl1U4MTjlEtfvMB8GA1Ud IwQYMBaAFObbryVSYEL0jYI1VF2A64ahrO/cMIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiG gctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1NQ0EwMllL RixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFz ZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZIaHR0cDovL21jYTAyeWtmLnJpbS5u ZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRpbmF0ZSUyMENBJTIwTUNBMDJZS0YuY3JsMIIBQQYI KwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwMllLRixDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxo dHRwOi8vbWNhMDJ5a2YucmltLm5ldC9DZXJ0RW5yb2xsL01DQTAyWUtGLnJpbS5uZXRfUklNJTIw U3Vib3JkaW5hdGUlMjBDQSUyME1DQTAyWUtGKDQpLmNydDANBgkqhkiG9w0BAQUFAAOCAQEActBk hryrMh5+C+8YiOrR8xi+G1NkUycfNLuz4fYdQzFNB9yWxyRs2K0ydl0X5PZXejhbIif0dFoyaxnh g/D5hYfeGIhXfAOFG22EpMJWXVOavqYLxslnc2enihWAYcWkjPfE6tf3XMXkodFkMYvEd+qFj8eU vxbbcR1dBqiBFNNDcKlAKn/oElp/iI/LjUGMEb+tJdHttsGExvQzSd1zwk1U6cOinYD82Y08zA5b z38l5bE2+plmfX3EQ8vCKYA95psgGg3hsffn150smpY7HeEPGRZh9vglGfi2wnMqY/QgO+qs78dq O/C1be3quQU3WHQ6YcZr3JP1Rc7yj76K7jCCBr8wggSnoAMCAQICEDIa85KxFFmUTU0vlRGze+Ew DQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcwFQYKCZImiZPyLGQBGRYH d2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcNMDYxMDEzMDEyNDU1WhcN MTYxMDEzMDEzMDQxWjBPMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3 aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBAMbous78rVQBLT87+jYSuzmZ2osP40BMhFbJA3+cs3BZC0//uT87SG7/nhZi 9Qj9hYby7/HkGSQyheGL/lLIzxDdZV+AwxiirdDT6ck/acEMxWolLdK5xEYEmm6OxLaUuEvg7i/B vXPpZlsA6m9FFrTzHVX2693w8IoMs9cofr1TAB3YYDnvZTwupz7YifSF02pu1eZiZg09Jjaav9Hy aNyRGjbwyqFwTpCr+iHW7SsSszyJxulWGgnYCQgE95loK/ZMYhEBFCSq7yNn1yNM0WJ5S+uPILyv OKXbE9sWSxba+DnWQJuEZCvFPnILq5Ugq+jVap326uv9zejBpsnPUgdgMoZNlUuuu+e1eJwc3mng /rK6ZOCF1NzUzP/mIEdc1UuNV8L2WqvVH+fY9EyYTfcRlWTvO9XlVa9lXzca9MTqlKcHMYeSWWJF nJlCRZWIkIdAjNj632g0U06kWUHeBd8VJXFxQFzhob2lyr4pHiOv7rZ1+rwpw8DFMZnp85b/HqTW rcQ7LiIDljuKX6oBjMs1qNobnUPe/ucp1Kgy19+J61M7MxniBNyqKmLJLMTBd7aiIGnbfYTVl2j/ xJJ2aUQJmj9LNFeWb4Isl8PVK6p1sJkWy0JOx52HNIR0AY16AcikojsoYEkvci+mvuwANq4QT6bE lSPS2AbNnDSpT7GXAgMBAAGjggGVMIIBkTATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AUYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNV HR8EggEgMIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YsQ049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6 Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNB MDFZS0YuY3JsMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBBQUAA4ICAQBDnlhbuDlU58ff o2JPdog62tn9QXOY9VnrBBiDZeFQmPVicup9e2/4dnw5o4/SnyLaNyxNlno++5Uiar/y0ne8J300 FWVW9cAXtmbfi7jwKour1kgwEFTn3TjGFbuYps553/mTTC3bk6l2f2xUCk1rINqoQVsGomH8RGO5 1YN/mX0rasHPUd7/7Rx/m/ZF9xbii6FUOikq6lMgYn4SEY+e3jsOvyYzwPkiHf6dshGfsZgDUN9b xNwRxUZttJGRx6gH3Qpk7dUuyw0ixwY9xmVyBVIHvWjyqswF3ntgwmEz92GHIKz/xWxRdkahkSIT zPjHYya2jI3sfpzU/tigvxCFrG1PQ4BSCNMByqUcfK5STTfJJm/x/ahqnDWlvUP6cFE6V9W10nW8 72BbNzWOypmGIouENEUAhq/ejrw09P0uvyK51vr6mY5z1djF6hLskNC+R11Tpwou+vbhmHEZBKOc cxCfxDL49O7wlpxu4fcpDYSxBDHMoFZgXVz/ajqqIHcjyQdAM8QGBqgkjE/Dq7NTP7K2Ul1An0nx DR+YgXe28R+7l5he5GzhIIaJuwHHAtgpbeA1NLY/bBciFoOR+s8ujS3rZtv5M3Q95hmN7trVrYo1 Z3dglmNmLM2KNZWwwHxH4xi//bhaR+/WbfXpEUg+WW0p9Uja9Z443hqVd48MrjCCB0YwggUuoAMC AQICChJuoPAAAAAAAiswDQYJKoZIhvcNAQEFBQAwTzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRcw FQYKCZImiZPyLGQBGRYHd2luZG93czEdMBsGA1UEAxMUUklNIFJvb3QgQ0EgTUNBMDFZS0YwHhcN MTQwNDAyMDA1MTEyWhcNMTYwNDAyMDEwMTEyWjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYK CZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZS0YwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzrn3UT996pLvUIVlnExxcXGmYftIOq1qMwitW RCBe2j32VmDvzlJseIkfQuXDqjWnoqoE4sxQjxD5QNwhyBw9eXMCvLjHBW+HM4+HcmGIdan2w17E 4rR+RHVK6NzvkE1Gm4ziBTDr2jzSliZJpowLM+M/+cY2pyym074TQx+QCZQOKIqLnEgZ2uYw4kSj nCcE7eJ+WmJFq9bX6Cv9SONQfgN5Z3O1N/36lgavm/G6Amt/ePNE0AhcJwxin7Fahkx6/SjRbf0r Oa8uhCMxK8ebqTqD0+0VpViARFterasW5FTU2rcRFLHwwWV67yoFc2fbozkj5iseBXctM8NmqKt5 AgMBAAGjggMhMIIDHTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTm268lUmBC9I2CNVRdgOuG oazv3DALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQQwIwYJKwYBBAGCNxUCBBYEFCLdxB/L akuvuaYdTyqIgHmfibLUMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFNZp gmQkFsHMJNvxFH1HEnzcyU3uMIIBKQYDVR0fBIIBIDCCARwwggEYoIIBFKCCARCGgcRsZGFwOi8v L0NOPVJJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPU1DQTAxWUtGLENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRv d3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS TERpc3RyaWJ1dGlvblBvaW50hkdodHRwOi8vbWNhMDF5a2Yud2luZG93cy5sb2NhbC9DZXJ0RW5y b2xsL1JJTSUyMFJvb3QlMjBDQSUyME1DQTAxWUtGLmNybDCCATwGCCsGAQUFBwEBBIIBLjCCASow gbsGCCsGAQUFBzAChoGubGRhcDovLy9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MGoGCCsGAQUFBzAChl5odHRwOi8vbWNhMDF5a2Yud2luZG93cy5s b2NhbC9DZXJ0RW5yb2xsL01DQTAxWUtGLndpbmRvd3MubG9jYWxfUklNJTIwUm9vdCUyMENBJTIw TUNBMDFZS0YuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQCUe8BMuuw2GW4AUAag80hqgwOQyezrSatL SIadEDvzg3LgXMJcN7onC+1B7vHsMxVMbFz3V+85WSKtzCtaBe5rhUCXLBZEGbM+WPavYgYMnUsD TpJwSXiDaM9Ym/ZLFsgfo3Qv7rfglydpqPCBfHUEQys2KeBVsDGd7HDK5Nk5fNaSmK0KgIBIvbXR bJKzhTsuctYGlOf/2nFtuoxWcdhu7t6UR7DbSTerjug7rvCZH4bie5cphsu4lZDXdNRp2IKWVEF6 0VcEK8dXK1hZXEGgjuen7R03uaA+7VsSr7eUZSLiouG7XnvXWik11aNCgBiQcIGsHVRIccHphmfS sFaZ0Bc+4/c/+K/v7X7RvdE29J9b1DqB2iV2SGZp58M0JLscohJ9uY0SJj8Hwl9YeuznijFBIC2y Psb1V9CgoRtBl+Ek37tPp1Wm4XSS+as2kcdcsZwiM/LywbFvYDEBa71b0mquxjisPyPvmVccA0e6 WW6RDNYKUqBJsZDpjTbRZkQA7CmzrOK6YHip2F/92ZYmpqM84BsEkLuf6kzzk+r0OVsWaFP+plU3 MfqtAeKtBgJu6yd4SYbA9eFX9ePeIzBaCjTzIcd+CclwA8SeoAgP07Ut2WcB3QnD7fcU6CBegHSd 7504Ty34G+FymbG6ZBBUU0exF44VAplxv4rWFA7mPTGCAvMwggLvAgEBMF4wUDETMBEGCgmSJomT 8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRl IENBIE1DQTAyWUtGAgptqd1HAAQAAAVqMAkGBSsOAwIaBQCgggHrMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDYyNjE3NTQwMVowIwYJKoZIhvcNAQkEMRYEFNlt ITsV9ZRllgtDZc7C3vRJOCpZMG0GCSsGAQQBgjcQBDFgMF4wUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAy WUtGAgptqd1HAAQAAAVqMG8GCyqGSIb3DQEJEAILMWCgXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0 MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDJZ S0YCCm2p3UcABAAABWowgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYI KoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFl AwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEgYA3yjNAqFpcw+WlKSBYJivl8u697CfP QwjomZnzCAqGasgRbiREJdZKussCc1pJJASY9bCSjRsh1AUvVVJvPie6VCIutKWErh6GmZGIY56m uG5NI7Bp4KjSqfp+6l/TbhMNHxzZeHXFCKUANCymAOln7gvmsbMl1TZoH9szZ2hKXgAAAAAAAA== ------=_NextPart_000_00F8_01CF9146.15A951B0-- From SRS0=59t6=3X=acm.org=bmoeller@srs.kundenserver.de Thu Jun 26 09:17:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AD71B2C01 for ; Thu, 26 Jun 2014 09:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.421 X-Spam-Level: X-Spam-Status: No, score=0.421 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMDJKgWeyHYS for ; Thu, 26 Jun 2014 09:17:49 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED51C1B305F for ; Thu, 26 Jun 2014 08:27:43 -0700 (PDT) Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) by mrelayeu.kundenserver.de (node=mreue004) with ESMTP (Nemesis) id 0MVqDE-1XBC3J1XKa-00X7kh; Thu, 26 Jun 2014 17:27:41 +0200 Received: by mail-yh0-f47.google.com with SMTP id v1so2195742yhn.6 for ; Thu, 26 Jun 2014 08:27:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.36.45 with SMTP id v33mr22866971yha.129.1403796460436; Thu, 26 Jun 2014 08:27:40 -0700 (PDT) Received: by 10.170.83.215 with HTTP; Thu, 26 Jun 2014 08:27:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Jun 2014 17:27:40 +0200 Message-ID: From: Bodo Moeller To: Watson Ladd Content-Type: multipart/alternative; boundary=089e0160bc685c851204fcbed5c4 X-Provags-ID: V02:K0:mfn4FG15A632/2wngEqy3P9/4wDwBkSgSVZxJxdJeOV lWk609X9vykxLIAF14wgt9C34rEWoiPA9PtPkNNFrU0uARCI+l NNBDmjL6SVqmBRq4sJtHDqqRtOui5+6kgK0F2RbyGRHQSTZ1ur w4Qnp+mlya/zfvQ/MISX4EdOlHqjz2JBvR58iYK1QO0vG93aMw kkjNWEcxHm2mjiem+6VCjujZU0pGJiiajU/TYxKpfoy2Cmi5ND DTwPGq4j4FWoSL7rzPIHA7tV0Z8FI8yGxHi7iYtKEaijUuAxmH +wIyLXr7xVZ62v+LgOM+mDTAMIW7G6Y60ovVFBGMn0aEhMa2se 8Ve+xBSrI5+/bzVexs46uxocS7Lto4OZTqkNNaVsh+vA0nSr7S 5gfP+VsJzHjjFRNdIxc30rs+YvwsmcLxyS9+Ng5azmJVflQTFq Vry5v Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9pxSjPld8XmP3CKJDYdRuJ5-jtQ Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 20:39:21 -0000 --089e0160bc685c851204fcbed5c4 Content-Type: text/plain; charset=UTF-8 Watson Ladd : >> Alternatively we can compute the premaster secret as the hash of H(ag > >> | bg | abg): I have not yet confirmed that this solves the problem. > > > Hm, this looks like something that rather belongs into the premaster > secret > > => master secret step. If you have this there (such as when you're using > > the proposed Extended Master Secret Extension > > [draft-bhargavan-tls-session-hash-00]), including the public keys here > too > > would be redundant. If you'd normally be doing a public-key check or an > > ECDH result check, you could just skip this check if the protocol no > longer > > has a need for such protection. In contrast, if you hash those > additional > > inputs when computing the premaster secret, that's not something you > could > > remove without affecting compatibility. > > Yes, we could make EMSE a dependency of Curve25519. Or we could change > the way we compute > the PMS to avoid doing this: I proposed this solution because its very > simple for some implementations. > > What do we gain from having the PMS calculated the same way for each curve? > My argument wasn't about doing things the same way for each curve. What I don't like is introducing overhead (hashing an input at the premaster secret level that we'll be hashing at the master secret level too, in certain protocol variants) that could be avoided by using your other proposal, a Curve25519-specific check. (For many hashes, it would be actual computational overhead because those two public keys are large enough to take up an additional input block.) --089e0160bc685c851204fcbed5c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wats= on Ladd <watsonbladd@gmail.com>:

>> Alternatively we can compute the premaster secret as the hash of H= (ag
>> | bg | abg): I have not yet confirmed that this solves the problem= .
=C2=A0
> Hm, this looks like something that rather belongs into the premaster s= ecret
> =3D> master secret step. =C2=A0If you have this there (such as when= you're using
> the proposed Extended Master Secret Extension
> [draft-bhargavan-tls-session-hash-00]), including the public keys here= too
> would be redundant. =C2=A0If you'd normally be doing a public-key = check or an
> ECDH result check, you could just skip this check if the protocol no l= onger
> has a need for such protection. =C2=A0In contrast, if you hash those a= dditional
> inputs when computing the premaster secret, that's not something y= ou could
> remove without affecting compatibility.
=C2= =A0
Yes, we could make EMSE a dependency of Curve25519. Or we could chang= e
the way we compute
the PMS to avoid doing this: I proposed this solution because its very
simple for some implementations.

What do we gain from having the PMS calculated the same way for each curve?=

My argument wasn't about doing thi= ngs the same way for each curve. What I don't like is introducing overh= ead (hashing an input at the premaster secret level that we'll be hashi= ng at the master secret level too, in certain protocol variants) that could= be avoided by using your other proposal, a Curve25519-specific check.

(For many hashes, it would be actual computational over= head because those two public keys are large enough to take up an additiona= l input block.)

--089e0160bc685c851204fcbed5c4-- From nobody Thu Jun 26 13:56:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6658A1A028F for ; Thu, 26 Jun 2014 13:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njNFWwJXybpY for ; Thu, 26 Jun 2014 13:56:23 -0700 (PDT) Received: from eu1sys200aog128.obsmtp.com (eu1sys200aog128.obsmtp.com [207.126.144.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4601A019E for ; Thu, 26 Jun 2014 13:56:22 -0700 (PDT) Received: from mail-wi0-f174.google.com ([209.85.212.174]) (using TLSv1) by eu1sys200aob128.postini.com ([207.126.147.11]) with SMTP ID DSNKU6yI8gyECwx5/7x22811P3GsNNI72x3B@postini.com; Thu, 26 Jun 2014 20:56:22 UTC Received: by mail-wi0-f174.google.com with SMTP id bs8so1810192wib.1 for ; Thu, 26 Jun 2014 13:56:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=lpGqJ7zFoXvc2aJg5p/i5jm5VnEdelD1z1Ptn4o1wrQ=; b=O0vfj8ESSJAE3+EzaVubjIfQsRlS2VbENkExMzOJk692G2TYEgBAl5OpcXHHHhk9Cn QH+1O3ogzpqQ2SDFtuXtQF9a/7nrrwYNOoo0s3NMCG4h3AV4wQBJcy20QrasOKiFqPGC l0zVNjPZCbEdwI5kTqfM4dmYEquFuS+UsZEDa8OqP5kusie7oy+oR0iq+p0K09Ihd77h eW8goUExAl5yEioR166im9dG2nKodsitHvybeIOB4x6bLv5N76P0I5D5Cbl0HsgEr0y6 9f6YBhj6mQ/82GnffjEEWXFGzhdXOtYlh/vhbsGR+tHuRsntTPykqAsdmQfUo7TOO5M7 eoRg== X-Gm-Message-State: ALoCoQk+I/1CJzuB1gzY9klDNt4K9/wcjfdvYEsNvxEyJBRDlvTJouJY2izqN2tsMGyHqI5GyqGKCXCWbtQpG2nFLYPDXnExb3AsH/ROkvtS/W7go5lAWnqc6OlYSuU8qWDLv9RMUA8+ X-Received: by 10.194.142.148 with SMTP id rw20mr20154469wjb.69.1403816178306; Thu, 26 Jun 2014 13:56:18 -0700 (PDT) X-Received: by 10.194.142.148 with SMTP id rw20mr20154461wjb.69.1403816178128; Thu, 26 Jun 2014 13:56:18 -0700 (PDT) Received: from [192.168.1.242] ([95.144.51.46]) by mx.google.com with ESMTPSA id v17sm16739084wjr.33.2014.06.26.13.56.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 13:56:17 -0700 (PDT) Sender: Nigel Smart Message-ID: <53AC88F2.7020405@cs.bris.ac.uk> Date: Thu, 26 Jun 2014 21:56:18 +0100 From: Nigel Smart User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PsdlV9qoAwJp070WUT0XwqDnzcE Subject: Re: [TLS] [Cfrg] FW: Schnorr Signatures X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 20:56:25 -0000 > > > Schnorr permits batching and is faster as there is no inverse. But to > take full advantage, you have to send R, the temporary point, not just > the x-coordinate. With point compression this is easy, without the > signature gets a little bigger. With Schnorr you dont send the x-coord of R. What you send is half the hash value e e=Hash(R||Message) So if using SHA-256 you send 128 bits of e over. Batching is not so important for TLS. With Schnorr however you can do distributed signing much easier, which means you can protect your signing key much easier Nigel -- Prof. Nigel P. Smart | Tel +44 (0)117 9545163 Computer Science Department, | Fax +44 (0)117 9545208 Woodland Road, | Email nigel@cs.bris.ac.uk Bristol, BS8 1UB, UK | http://www.cs.bris.ac.uk~nigel From nobody Thu Jun 26 14:19:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8751B2F2C for ; Thu, 26 Jun 2014 14:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4eA2RHQw1nA for ; Thu, 26 Jun 2014 14:18:59 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A994A1B2F14 for ; Thu, 26 Jun 2014 14:18:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208";a="119746832" X-IPAS-Result: AqQEADD7RVPAqArr/2dsb2JhbABQCYNBV7xBHYc1gTd0giUBAQEBAwEBARodNAsMBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIE4duzBATBI4RKjEHBoMegRQElHGZX4Ir Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 26 Jun 2014 21:19:00 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 26 Jun 2014 14:18:58 -0700 From: Brian Hamon To: "mrex@sap.com" , "Joseph Salowey (jsalowey)" Thread-Topic: [TLS] Call for Consensus on removal of renegotiation Thread-Index: AQHPkKQi2ibdHwQZAU+UoLazXGbTxJuCn8+AgAAVNgCAATV4AP//97oQ Date: Thu, 26 Jun 2014 21:18:58 +0000 Message-ID: References: <20140626143044.F3B0C1AD68@ld9781.wdf.sap.corp> In-Reply-To: <20140626143044.F3B0C1AD68@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.236] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RwJpKe_G8EdpJQi8B0YFPbxJM_g Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 21:19:01 -0000 Over the past week, I've been watching for an answer to the question posed = regarding how we deal with the situation where the server must examine some= Application Data messages in order to determine whether client authenticat= ion is required. Presently, this situation is handled by allowing an unauthenticated client = to send some Application Data, then if client authentication is required, i= t will send a HelloRequest, starting renegotiation. During the subsequent h= andshake, the server sends a CertificateRequest and drops the connection if= the client fails to authenticate and authorize. I've seen the following concerns raised with this approach: 1) How does the client authentication persist (or not persist) in the face = of session resumption? 2) If the answer to #1 is that yes, the authentication persists, then does = the most-recently-supplied identity replace or aggregate with previous iden= tities presented in the same session? I worked through a number of possible alternatives where we separate client= authentication completely from the handshake, and I think the solution lie= s down this path; however, before digging into those details, let me ask fo= r the group's consensus on the two questions posed above. I would argue that session resumption should revert the client's identity b= ack to "unauthenticated". This avoids a lot of the complicated workarounds = required for #2. -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex Sent: Thursday, June 26, 2014 7:31 AM To: Joseph Salowey (jsalowey) Cc: Subject: Re: [TLS] Call for Consensus on removal of renegotiation Joseph Salowey (jsalowey) wrote: >=20 > 1. In favor of removing renegotiation 2. In favor of removing=20 > renegotiation with the addition of rekey facility 3. Not in favor of=20 > removing renegotiation =20 (3) Leave it in the spec, Make it a true option for implementors. with a guidance that clients might need it for interop, but should play safe (and nail down identities once they're established) by defaul= t I never offered/exposed renegotiation at the API to application callers, an= d since January 2010, I have the server-side reject renegotiation attempts = from clients. But the installed base of _other_ servers that use (or requi= re) it is to large to be ignored, and I don't see it go away that easily... Everything that you change from TLSv1.0/1/2 toward v1.3 will add complexity= and require more code. This applies not just to adding new features, but = also to axing existing features that may be in current use. A TLSv1.3 spec that requires implementors to carefully avoid TLSv1.3 for a = number of commonly used TLSv1.0/1/2 features may be even harder to sell tha= n TLSv1.2 and IPv6. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Jun 26 14:29:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656A91B2F4B for ; Thu, 26 Jun 2014 14:29:17 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHX3fA42ougx for ; Thu, 26 Jun 2014 14:29:16 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09191B2F46 for ; Thu, 26 Jun 2014 14:29:15 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id b13so4229108wgh.26 for ; Thu, 26 Jun 2014 14:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OI5fleOy91f6VJp9gA486DZjYUR57ECWqKkhQ+I/CJY=; b=yqbjX4ZPgw5G/U2gU/A3CwmLPZdOeNEnYacbfSNGYdZupi0tFbyU7OZrrEseI/cTLB efYfH27wqRj8vG8mtJ4s+dyF8/ifwvuS6o+8tI9O34jxjC5v39G3VIIACUDpDNE9GADk 8LUA4yDlZllsfPkxghzwpANJ6LV/nie8fKqN44a5Yc5q7PAUwV3VIOjpYxjQQZWcmDeP DykRHwpLj6I5U6NyR6qpO7CkSmxOSKkPY8Q4hC/xqfuPRkoqtnb5Vv8XN35w7I3d0Mu5 krAC3MtxyCI46Z+pmfTtFvU5zi86lT9e/dKpgnGiikgYqHm0MHLV1fcAaM2ydZw7ITfz 8+Dw== MIME-Version: 1.0 X-Received: by 10.180.79.38 with SMTP id g6mr6998794wix.61.1403818154247; Thu, 26 Jun 2014 14:29:14 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Thu, 26 Jun 2014 14:29:14 -0700 (PDT) In-Reply-To: References: <20140626143044.F3B0C1AD68@ld9781.wdf.sap.corp> Date: Thu, 26 Jun 2014 14:29:14 -0700 Message-ID: From: Martin Thomson To: Brian Hamon Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kbeTUl-u_1bU3nBVHG3vnQ5ggYQ Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 21:29:17 -0000 On 26 June 2014 14:18, Brian Hamon wrote: > I would argue that session resumption should revert the client's identity back to "unauthenticated". This avoids a lot of the complicated workarounds required for #2. I hope that you realize that we're not talking about resumption right at this moment. There are some interactions with resumption, but I think we're trying not to overcomplicate the issue by considering the implications of those just yet. That said, if you did mean renegotiation in the above statement. I don't think that making any recommendation to this effect will have any material impact on the sorts of bugs we've seen with renegotiation. You can *say* that people should do this or that because it's good practice, but I think that that is just wishful thinking. From nobody Thu Jun 26 14:38:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735B81B2F2C for ; Thu, 26 Jun 2014 14:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6hfOkrPw1bN for ; Thu, 26 Jun 2014 14:38:09 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 762641B2F17 for ; Thu, 26 Jun 2014 14:38:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208";a="119749351" X-IPAS-Result: AqYEADD7RVPAqArr/2dsb2JhbABQCYQYgw7BBRmBHnSCJQEBAQEDHQYRRQwEAgEIEQQBAQECAgYdAwICAh8RFAEICAIEDgUIE4dNA6kmm3INhwkXgSmLKoE+KgYrBwQCgmk1gRQElHGBf45hiH+CKw Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 26 Jun 2014 21:38:09 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Thu, 26 Jun 2014 14:38:08 -0700 From: Brian Hamon To: Martin Thomson Thread-Topic: [TLS] Call for Consensus on removal of renegotiation Thread-Index: AQHPkKQi2ibdHwQZAU+UoLazXGbTxJuCn8+AgAAVNgCAATV4AP//97oQgAB9MwD//4sSAA== Date: Thu, 26 Jun 2014 21:38:08 +0000 Message-ID: References: <20140626143044.F3B0C1AD68@ld9781.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.236] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZI2sTypSRy6x8f-FRnXWikjPlcw Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 21:38:11 -0000 WWVzLCBJIGRvIHVuZGVyc3RhbmQgdGhpcyBpcyBhIGRpc2N1c3Npb24gb2YgcmVuZWdvdGlhdGlv biwgYW5kIEknbSBpbiBiYXNpYyBhZ3JlZW1lbnQgd2l0aCB5b3VyIHByb3Bvc2FsLiBIb3dldmVy LCBpdCBkb2VzIGxlYXZlIHVuYWRkcmVzc2VkIHRoZSBpc3N1ZSBJIHByZXNlbnRlZCByZWdhcmRp bmcgdGhlIGxvc3Mgb2YgdGhlIGFiaWxpdHkgb2YgdGhlIHNlcnZlciB0byBwb3N0cG9uZSBkZW1h bmRpbmcgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHVudGlsIHRoZSBjb250ZW50cyBvZiBvbmUgb3Ig bW9yZSBBcHBsaWNhdGlvbkRhdGEgbWVzc2FnZXMgYXJlIGV4YW1pbmVkLg0KDQpJIHdhcyB0cnlp bmcgdG8gZ2F0aGVyIGEgbGlzdCBvZiBvYmplY3Rpb25zIHRoYXQgc29tZSBoYXZlIGV4cHJlc3Nl ZCBvZiB0aGUgdXNlIG9mIHJlbmVnb3RpYXRpb24gdG8gZGVhbCB3aXRoIHRoaXMgc3BlY2lmaWMg c2l0dWF0aW9uLCBhbmQgYXMgZmFyIGFzIEkgY2FuIHJlY2FsbCB0aGUgb25seSBvbmVzIGRlYWx0 IHdpdGggcmVzdW1wdGlvbi4gQW0gSSBmb3JnZXR0aW5nIGFueSBvdGhlcnM/DQoNCk15IG1haW4g Y29uY2VybiBpcyB0aGF0IGlmIHlvdXIgcHJvcG9zYWwgaXMgYWNjZXB0ZWQsIHdoYXQgaXMgdGhl IHNvbHV0aW9uIGZvciBhIHNlcnZlciB0aGF0IG11c3QgZXhhbWluZSBzb21lIEFwcGxpY2F0aW9u RGF0YSBpbiBvcmRlciB0byBkZXRlcm1pbmUgaWYgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIHJl cXVpcmVkPyAgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhv bXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpTZW50OiBUaHVyc2RheSwg SnVuZSAyNiwgMjAxNCAyOjI5IFBNDQpUbzogQnJpYW4gSGFtb24NCkNjOiBtcmV4QHNhcC5jb207 IEpvc2VwaCBTYWxvd2V5IChqc2Fsb3dleSk7IDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W1RMU10gQ2FsbCBmb3IgQ29uc2Vuc3VzIG9uIHJlbW92YWwgb2YgcmVuZWdvdGlhdGlvbg0KDQpP biAyNiBKdW5lIDIwMTQgMTQ6MTgsIEJyaWFuIEhhbW9uIDxCLkhhbW9uQGY1LmNvbT4gd3JvdGU6 DQo+IEkgd291bGQgYXJndWUgdGhhdCBzZXNzaW9uIHJlc3VtcHRpb24gc2hvdWxkIHJldmVydCB0 aGUgY2xpZW50J3MgaWRlbnRpdHkgYmFjayB0byAidW5hdXRoZW50aWNhdGVkIi4gVGhpcyBhdm9p ZHMgYSBsb3Qgb2YgdGhlIGNvbXBsaWNhdGVkIHdvcmthcm91bmRzIHJlcXVpcmVkIGZvciAjMi4N Cg0KSSBob3BlIHRoYXQgeW91IHJlYWxpemUgdGhhdCB3ZSdyZSBub3QgdGFsa2luZyBhYm91dCBy ZXN1bXB0aW9uIHJpZ2h0IGF0IHRoaXMgbW9tZW50LiAgVGhlcmUgYXJlIHNvbWUgaW50ZXJhY3Rp b25zIHdpdGggcmVzdW1wdGlvbiwgYnV0IEkgdGhpbmsgd2UncmUgdHJ5aW5nIG5vdCB0byBvdmVy Y29tcGxpY2F0ZSB0aGUgaXNzdWUgYnkgY29uc2lkZXJpbmcgdGhlIGltcGxpY2F0aW9ucyBvZiB0 aG9zZSBqdXN0IHlldC4NCg0KVGhhdCBzYWlkLCBpZiB5b3UgZGlkIG1lYW4gcmVuZWdvdGlhdGlv biBpbiB0aGUgYWJvdmUgc3RhdGVtZW50LiAgSSBkb24ndCB0aGluayB0aGF0IG1ha2luZyBhbnkg cmVjb21tZW5kYXRpb24gdG8gdGhpcyBlZmZlY3Qgd2lsbCBoYXZlIGFueSBtYXRlcmlhbCBpbXBh Y3Qgb24gdGhlIHNvcnRzIG9mIGJ1Z3Mgd2UndmUgc2VlbiB3aXRoIHJlbmVnb3RpYXRpb24uICBZ b3UgY2FuICpzYXkqIHRoYXQgcGVvcGxlIHNob3VsZCBkbyB0aGlzIG9yIHRoYXQgYmVjYXVzZSBp dCdzIGdvb2QgcHJhY3RpY2UsIGJ1dCBJIHRoaW5rIHRoYXQgdGhhdCBpcyBqdXN0IHdpc2hmdWwg dGhpbmtpbmcuDQo= From nobody Thu Jun 26 14:59:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617BB1B2FA1 for ; Thu, 26 Jun 2014 14:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wG0LGoWJW7sq for ; Thu, 26 Jun 2014 14:59:05 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04F11B2FA0 for ; Thu, 26 Jun 2014 14:59:04 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id q108so3591665qgd.21 for ; Thu, 26 Jun 2014 14:59:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=6Y4DsZDhDZOdGVEzRbnJEY+YG66YiFixxUQMKkwl47Q=; b=GdgH+AvSmgK0MVTxRjyYGpqc2XCPEZzOghZg/oWa999fROZXRNm+1rNGurLmmG+Y8L VfkX0qWcpm6zdzGUd+BSx+2KXEauPF3vIDNeS/Uroi+9S7D5Tv6z+qvCufYyV7t66wVh pJAdAskhHK8IfUz4Qyze9caFv1TdKYm4vX2dlgZVpewCvMR7YzqDqYzzm1DmufiYicIR KDtyVHm7H/m/YmZcx37XiqC+o5F2dxAJ0nlayil8y0uwhygkHpGK/nD2u6H1hXYsxVkr Pu5FghI7LOBBB60+GyPs9J40X8CJkOvXx1YF9+z9fPBdSVFSr0gUaQxyWZcLt4O5qjMC SiKQ== X-Gm-Message-State: ALoCoQnW+6nL3j1LycYZsoQjNfJLYv4ItZ2Ls4XKk7GQooRablwXvJ1vbcZl/vepqVSjYK9N0ZR5 X-Received: by 10.140.92.144 with SMTP id b16mr2680742qge.41.1403819944111; Thu, 26 Jun 2014 14:59:04 -0700 (PDT) Received: from [10.90.129.164] (edge-gw-rwc.silverspringnet.com. [74.121.22.10]) by mx.google.com with ESMTPSA id l33sm5010663qgd.6.2014.06.26.14.59.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 14:59:03 -0700 (PDT) Message-ID: <53AC97B8.2080909@nthpermutation.com> Date: Thu, 26 Jun 2014 17:59:20 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DML_1443EVBJTd1VL-o6-ODHkT8 Subject: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 21:59:06 -0000 There's been a small but vocal minority agitating for the adoption of Curve25519 for use in TLS (and other IETF protocols). As the discussion has gone on, what I haven't seen is compelling evidence that this technology has been vetted sufficiently that it would meet the "Best Commercial Practices" threshold for safe harbor status for encryption. It may eventually get there, but for at least the next few (5-10??) years, I would expect businesses to avoid the use in privacy sensitive, or financially sensitive operations. There are also possible IPR issues, definite infrastructure issues (e.g. no off the shelf, commercial hardware or software AFAIK), documentation issues (not the base curve, but how to incorporate curve data into certificates and other protocol messages, and the fact it's key agreement only (vs the current EC curves which can be used for both signature and agreement). A long list of items that probably, but not definitely, can be resolved. AFACT, one of the main reasons for looking at Curve25519 (possibly more important than performance or security) is that there is a fear that the US Government has placed trapdoors in the current set of curves (NIST P256, P384, P521 etc). The argument against the "provably random" creation claim with respect to those curves appears to be that many "seed" values could have been generated to generate curve parameters and those curves tested to find "weak" curves of a particular flavor and the seeds for weak curves retained. In other words, we don't know how the seed values were generated and it could be nefarious. I haven't as yet found any argument against the generation process, nor specifically against the elliptic curve math. Given that the EC math in FIPS186, X9.62, X9.63, SP800-56A, SEC1, and the various ISO documents is pretty much identical, instead of throwing away all that implementation and standardization, how about we just generate new curves: 1) 20 organizations publicly contribute random/pseudo-random strings of 1kbits - they get to decide exactly which bits to send. 1a) discard any of these with detectable bias. 2) Randomly select 10 sets of contributed bits from those remaining (using public randomness sources to select those to be retained). 3) Concatenate the bits in a random order (using public randomness sources such as stock prices etc to select the order). 4) Run the concatenated data through an entropy extraction process (e.g. hash, hmac, other PRF) to produce a seed value of sufficient length. (or seed values if all the curves come from this one pass). 5) Generate the curve data and generator points from the seed. 6) Assign IETF OIDs to each curve generated this way. 7) Permanently record ALL the data used to generate the curves so we don't have future conspiracy theories. For most of libraries and hardware devices with which I work, the curve data is pretty much static configuration (external table referenced by OID) or compilation (ditto but compiled in), or provided as a library argument and most libraries have a mechanism to insert or use new curves fairly easily - at least within the same family. I'd recommend that we generate curves equivalent in strength to the current NIST curves in all of prime, binary and koblitz flavors. Mike From nobody Thu Jun 26 15:08:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28B41B2EF2 for ; Thu, 26 Jun 2014 15:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h21ApASoxgly for ; Thu, 26 Jun 2014 15:08:14 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id EA9D41B2EEB for ; Thu, 26 Jun 2014 15:08:13 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s5QM86uC004283; Thu, 26 Jun 2014 18:08:12 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "'msj@nthpermutation.com'" , "'tls@ietf.org'" Thread-Topic: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, Thread-Index: AQHPkYsby4lwS2ov3UyI8SAB87cE8A== Date: Thu, 26 Jun 2014 22:08:06 +0000 Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC16A96C@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: <53AC97B8.2080909@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.34.14.22] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-26_07:2014-06-26,2014-06-26,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406260234 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hVOOj4CgzKrEequUuY9438N5X-0 Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 22:08:18 -0000 +1 -- Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory Cell: (339) 223-5363 244 Wood Street Email: Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ =20 MIT LL Root CA:=20 DSN: 478-5980 ask Lincoln ext.1638 ----- Original Message ----- From: Michael StJohns [mailto:msj@nthpermutation.com] Sent: Thursday, June 26, 2014 05:59 PM=0A= To: tls@ietf.org Subject: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf3= 84p, ietf521p,=20 There's been a small but vocal minority agitating for the adoption of=20 Curve25519 for use in TLS (and other IETF protocols). As the discussion=20 has gone on, what I haven't seen is compelling evidence that this=20 technology has been vetted sufficiently that it would meet the "Best=20 Commercial Practices" threshold for safe harbor status for encryption. =20 It may eventually get there, but for at least the next few (5-10??)=20 years, I would expect businesses to avoid the use in privacy sensitive,=20 or financially sensitive operations. There are also possible IPR issues, definite infrastructure issues (e.g.=20 no off the shelf, commercial hardware or software AFAIK), documentation=20 issues (not the base curve, but how to incorporate curve data into=20 certificates and other protocol messages, and the fact it's key=20 agreement only (vs the current EC curves which can be used for both=20 signature and agreement). A long list of items that probably, but not=20 definitely, can be resolved. AFACT, one of the main reasons for looking at Curve25519 (possibly more=20 important than performance or security) is that there is a fear that the=20 US Government has placed trapdoors in the current set of curves (NIST=20 P256, P384, P521 etc). The argument against the "provably random"=20 creation claim with respect to those curves appears to be that many=20 "seed" values could have been generated to generate curve parameters and=20 those curves tested to find "weak" curves of a particular flavor and the=20 seeds for weak curves retained. In other words, we don't know how the=20 seed values were generated and it could be nefarious. I haven't as yet=20 found any argument against the generation process, nor specifically=20 against the elliptic curve math. Given that the EC math in FIPS186, X9.62, X9.63, SP800-56A, SEC1, and=20 the various ISO documents is pretty much identical, instead of throwing=20 away all that implementation and standardization, how about we just=20 generate new curves: 1) 20 organizations publicly contribute random/pseudo-random strings of=20 1kbits - they get to decide exactly which bits to send. 1a) discard any of these with detectable bias. 2) Randomly select 10 sets of contributed bits from those remaining=20 (using public randomness sources to select those to be retained). 3) Concatenate the bits in a random order (using public randomness=20 sources such as stock prices etc to select the order). 4) Run the concatenated data through an entropy extraction process (e.g.=20 hash, hmac, other PRF) to produce a seed value of sufficient length. (or=20 seed values if all the curves come from this one pass). 5) Generate the curve data and generator points from the seed. 6) Assign IETF OIDs to each curve generated this way. 7) Permanently record ALL the data used to generate the curves so we=20 don't have future conspiracy theories. For most of libraries and hardware devices with which I work, the curve=20 data is pretty much static configuration (external table referenced by=20 OID) or compilation (ditto but compiled in), or provided as a library=20 argument and most libraries have a mechanism to insert or use new curves=20 fairly easily - at least within the same family. I'd recommend that we=20 generate curves equivalent in strength to the current NIST curves in all=20 of prime, binary and koblitz flavors. Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Jun 26 15:11:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080681B2F02 for ; Thu, 26 Jun 2014 15:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qrh98t5j6fjo for ; Thu, 26 Jun 2014 15:10:54 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65ECA1B2EF5 for ; Thu, 26 Jun 2014 15:10:54 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so4463230wgg.32 for ; Thu, 26 Jun 2014 15:10:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=21xGl+VqLlh40mBy1Oj38W7TU6th+oABrm785hp3hXA=; b=lLnez6xyGMoFXDVlbwo39k6nVGuCavQIR3ys0EKnFFEzV2S0beOVOeLmH1m891eY5N 61y9erFPYYEZChenqaOkmM+gWkVZG12+LolVpj10bfGMjAjdjAd5Z2snvDXgp1jX2J7Q NODLT0MlVn1G3bvyNsYtG3/s1LCkKf8PLes1xLp/5mNAOL35UyIRQ+y97Pu9StY+z6ge /yzsbjlJbL0OTENsHdNFFjKiy8KTp5lsAyM7jNdS/dqsLUj05LNR2L4dKB+skpv/vgHu 9+X5fMtDihLT3ZdULyiJNU4cAjy3mrKCajL9CXHl109zdFvDm4flGYycQ8e455Wf+sYV CvWA== X-Gm-Message-State: ALoCoQnmIOrmrjOaQOfOkuwVpodcYsj7zS+jHQgM3C/cyr9uZb++3zVXurqYz1KBZLLLtIDxLhuA X-Received: by 10.194.110.10 with SMTP id hw10mr21188172wjb.81.1403820652899; Thu, 26 Jun 2014 15:10:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Thu, 26 Jun 2014 15:10:12 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:e88c:a4b4:d3a:6b6a] In-Reply-To: <53AC97B8.2080909@nthpermutation.com> References: <53AC97B8.2080909@nthpermutation.com> From: Eric Rescorla Date: Thu, 26 Jun 2014 15:10:12 -0700 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=089e010d870c584bbe04fcc4771a Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dhdYwXDqrhrioJ5kNYGoej3XsL4 Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 22:10:58 -0000 --089e010d870c584bbe04fcc4771a Content-Type: text/plain; charset=UTF-8 On Thu, Jun 26, 2014 at 2:59 PM, Michael StJohns wrote: > There's been a small but vocal minority agitating for the adoption of > Curve25519 for use in TLS (and other IETF protocols). As the discussion > has gone on, what I haven't seen is compelling evidence that this > technology has been vetted sufficiently that it would meet the "Best > Commercial Practices" threshold for safe harbor status for encryption. It > may eventually get there, but for at least the next few (5-10??) years, I > would expect businesses to avoid the use in privacy sensitive, or > financially sensitive operations. > > There are also possible IPR issues, definite infrastructure issues (e.g. > no off the shelf, commercial hardware or software AFAIK), documentation > issues (not the base curve, but how to incorporate curve data into > certificates and other protocol messages, and the fact it's key agreement > only (vs the current EC curves which can be used for both signature and > agreement). A long list of items that probably, but not definitely, can be > resolved. > > AFACT, one of the main reasons for looking at Curve25519 (possibly more > important than performance or security) is that there is a fear that the US > Government has placed trapdoors in the current set of curves (NIST P256, > P384, P521 etc). The argument against the "provably random" creation > claim with respect to those curves appears to be that many "seed" values > could have been generated to generate curve parameters and those curves > tested to find "weak" curves of a particular flavor and the seeds for weak > curves retained. In other words, we don't know how the seed values were > generated and it could be nefarious. I haven't as yet found any argument > against the generation process, nor specifically against the elliptic curve > math. > > Given that the EC math in FIPS186, X9.62, X9.63, SP800-56A, SEC1, and the > various ISO documents is pretty much identical, instead of throwing away > all that implementation and standardization, how about we just generate new > curves: > [Snip] I'm cutting here because I would like to encourage WG members to focus on the general merits of this suggestion (or lack thereof, depending on your perspective) rather than on the specific details of the procedure Mike has proposed. I think it's clear that we could develop a procedure for producing verifiably random seeds, but let's try to figure out first whether that's a good idea before we worry about how to do it. Also, this seems like a bigger topic than TLS. Perhaps the AD should sponsor a discussion in SAAG? -Ekr --089e010d870c584bbe04fcc4771a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 26, 2014 at 2:59 PM, Michael StJohns = <msj@nthperm= utation.com> wrote:
There's been a small but vocal minority = agitating for the adoption of Curve25519 for use in TLS (and other IETF pro= tocols). =C2=A0As the discussion has gone on, what I haven't seen is co= mpelling evidence that this technology has been vetted sufficiently that it= would meet the "Best Commercial Practices" threshold for safe ha= rbor status for encryption. =C2=A0It may eventually get there, but for at l= east the next few (5-10??) years, I would expect businesses to avoid the us= e in privacy sensitive, or financially sensitive operations.

There are also possible IPR issues, definite infrastructure issues (e.g. no= off the shelf, commercial hardware or software AFAIK), documentation issue= s (not the base curve, but how to incorporate curve data into certificates = and other protocol messages, and the fact it's key agreement only (vs t= he current EC curves which can be used for both signature and agreement). = =C2=A0A long list of items that probably, but not definitely, can be resolv= ed.

AFACT, one of the main reasons for looking at Curve25519 (possibly more imp= ortant than performance or security) is that there is a fear that the US Go= vernment has placed trapdoors in the current set of curves (NIST P256, P384= , P521 etc). =C2=A0 The argument against the "provably random" cr= eation claim with respect to those curves appears to be that many "see= d" values could have been generated to generate curve parameters and t= hose curves tested to find "weak" curves of a particular flavor a= nd the seeds for weak curves retained. =C2=A0In other words, we don't k= now how the seed values were generated and it could be nefarious. =C2=A0I h= aven't as yet found any argument against the generation process, nor sp= ecifically against the elliptic curve math.

Given that the EC math in FIPS186, X9.62, X9.63, SP800-56A, SEC1, and the v= arious ISO documents is pretty much identical, instead of throwing away all= that implementation and standardization, how about we just generate new cu= rves:

[Snip]
I'm cutting here beca= use I would like to encourage WG members to
focus on the general = merits of this suggestion (or lack thereof, depending
on your per= spective) rather than on the specific details of the procedure
Mike has proposed. I think it's clear that we could develop a proc= edure
for producing verifiably random seeds, but let's try to= figure out first
whether that's a good idea before we worry = about how to do it.

Also, this seems like a bigger topic than TLS. Perhaps = the
AD should sponsor a discussion in SAAG?

<= div>-Ekr

--089e010d870c584bbe04fcc4771a-- From nobody Thu Jun 26 15:13:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835661B2EDD for ; Thu, 26 Jun 2014 15:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.898 X-Spam-Level: * X-Spam-Status: No, score=1.898 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xb4NZFer_2Fy for ; Thu, 26 Jun 2014 15:13:07 -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 95FCD1A050E for ; Thu, 26 Jun 2014 15:13:07 -0700 (PDT) Received: from localhost (91-64-49-24-dynip.superkabel.de [::ffff:91.64.49.24]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-SHA) by zucker.schokokeks.org with ESMTPSA; Fri, 27 Jun 2014 00:13:05 +0200 id 000000000000002E.0000000053AC9AF1.00003F38 Date: Fri, 27 Jun 2014 00:12:15 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20140627001215.75dffc43@hboeck.de> In-Reply-To: <53AC97B8.2080909@nthpermutation.com> References: <53AC97B8.2080909@nthpermutation.com> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-16184-1403820785-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Zh35IPm0sqAoC1srl4kTUtDEAMk Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 22:13:10 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-16184-1403820785-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 26 Jun 2014 17:59:20 -0400 Michael StJohns wrote: > AFACT, one of the main reasons for looking at Curve25519 (possibly > more important than performance or security) is that there is a fear > that the US Government has placed trapdoors in the current set of > curves (NIST P256, P384, P521 etc). The argument against the > "provably random" creation claim with respect to those curves appears > to be that many "seed" values could have been generated to generate > curve parameters and those curves tested to find "weak" curves of a > particular flavor and the seeds for weak curves retained. In other > words, we don't know how the seed values were generated and it could > be nefarious. I haven't as yet found any argument against the > generation process, nor specifically against the elliptic curve math. I think another major argument against NIST curves was that it's hard to implement them in constant time. DJB had this and other issues explained in a blog post [1]. As we saw a lot of timing attacks lately (Lucky Thirteen, Comeback of Bleichenbacher attack in Java and OpenSSL) and I'd expect we'll see more of that I think timing safety should be a crucial feature of all future TLS algorithms. [1] http://blog.cr.yp.to/20140323-ecdsa.html --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-16184-1403820785-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJTrJq/AAoJEKWIAHK7tR5C+RgP/3qFvo9dc4VLm1xHr9BPLNZc kOzkQ86dXNdMTmqnSvRcQ4fehcaPtQzMe4knXqWVhdvKSG4xGZcfmIhO78ZpdlVy z7AVVDv2vKxUfXIAuTc749B+YbauXt+1/G5XLDzkKLsgx08UzaWqvyvhTFeCaMsC QiEwd8CGu+IStvW+NDtFzWzKeQhIOopkcfTXK6HnB/y3zHnrSOCvPxUEc6K0HCc9 8rjG52xwPbcMR1GDEbdy+PuSZY7CnMBF3roBHCBjnenkfzuDTZsD68yaznp6XDBS C7hwNgvHIAMlAFbEJpy2iJ+VFy3Ijga2DN81t/gRX/AzMNCOPkQP06cn+wKRmSCc qMNmysz0zSeYiQBAujhbsz7yu8CfEb4YDL9Kseg/Sbp0rf3LK653xlmrOFnMy39I uzsi1bkNb1+Q1V3nJVZYJDmivY5gU67cdW+iJcvlWh11idQiBAQAXgvzLwU8A6KT RehdsfTSW6NOjVtwq0I6lNnr6ltJKud6+LaGHd6mt+zU1LyRPG48jLHZZTdxvxdU FpglSwXAa3GCFw9H62eWmyt5LqwrpXuddUq3t/Ezwhorre288lrbLPJe9Y4KV3Hk xWCi9p916PsOt9G50grYAOEU9W78i5pdX6A1pyQiv/15dVZqxLvnceECpZEDDpPI mQEvPQUkALJPVhxHUbLX =siuF -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-16184-1403820785-0001-2-- From nobody Thu Jun 26 15:14:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF611B2EDD for ; Thu, 26 Jun 2014 15:14: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbN0F7G0I9Bl for ; Thu, 26 Jun 2014 15:14:06 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBB9E1A050E for ; Thu, 26 Jun 2014 15:14:05 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u57so4450450wes.19 for ; Thu, 26 Jun 2014 15:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m6SZ1VwWcmZ4jnCTW/pIeYLF5zqMD3KKo2P18onnCbU=; b=erb8iac0baMDV8KVdXA0ZMU0hXcBqvgQAXc7MtXE36Fet8/cKTUPS5ki8Iok6+Yzwn X3/8WuDzw6ObZd13VvpRKwrYQ0/52xpy+OsXR+jeunL8no2InYC7XD54pFbu9GfIKiD4 47KbvNgHiz2ekv2aH+Y2P2ghZhRXCgTu3Rtz//oFzdTdBzn4JTBQWAQlcbb0MKzBX8wS 5mDaRINEBo660pdJ4NsdAR8VlBo6jRLZl2usiWBQ8JrcmdSQUA26a5Uld5HFUzXYLOU7 vKsxMwiZ+nDN2Nvkhawhwm2lONZ2cKG2jGxeB9eWMVAnxdF97j4etE2SZ9BL1Atxa3qg gwIA== MIME-Version: 1.0 X-Received: by 10.180.14.162 with SMTP id q2mr7561318wic.54.1403820844565; Thu, 26 Jun 2014 15:14:04 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Thu, 26 Jun 2014 15:14:04 -0700 (PDT) In-Reply-To: References: <53AC97B8.2080909@nthpermutation.com> Date: Thu, 26 Jun 2014 15:14:04 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4K3cxvqrgC1AUjC0YpM3AHoXWCc Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 22:14:09 -0000 On 26 June 2014 15:10, Eric Rescorla wrote: > Also, this seems like a bigger topic than TLS. Perhaps the > AD should sponsor a discussion in SAAG? I think that this is more relevant right here and now. TLS has enough to handle already. I think that we might want to start by finding a more appropriate venue. SAAG might be a good place to start. From nobody Thu Jun 26 15:18:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D201B2FBF for ; Thu, 26 Jun 2014 15:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QE7R-IVNkmQg for ; Thu, 26 Jun 2014 15:18:25 -0700 (PDT) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED01E1B2FA5 for ; Thu, 26 Jun 2014 15:18:24 -0700 (PDT) Received: from woodstock.owlhill.net (a88-113-163-188.elisa-laajakaista.fi [88.113.163.188]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 10A0A40078 for ; Fri, 27 Jun 2014 01:18:21 +0300 (EEST) Received: from [IPv6:2001:14b8:14e:1:a592:1147:e7f2:38ee] (unknown [IPv6:2001:14b8:14e:1:a592:1147:e7f2:38ee]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by woodstock.owlhill.net (Postfix) with ESMTP id B20ED734B261 for ; Fri, 27 Jun 2014 01:18:21 +0300 (EEST) Message-ID: <53AC9C22.30907@iki.fi> Date: Fri, 27 Jun 2014 01:18:10 +0300 From: Tapio Sokura User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xD4fYwF7BD9G2XFUrEgSJ4g4SIg Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 22:18:28 -0000 On 25.6.2014 23:03, Joseph Salowey (jsalowey) wrote: > [Joe] to simplify: > > 1. In favor of removing renegotiation > 2. In favor of removing renegotiation with the addition of rekey facility > 3. Not in favor of removing renegotiation I would choose 1 or 2. I wonder how many real-life usage scenarios actually move enough data and/or over long enough time to need rekeying for real cryptographic reasons. In case there are some, I'm including 2 on my list. dh_rsa and dh_dss can also be dumped in my opinion. Tapio From nobody Thu Jun 26 15:20:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB051B2FC1 for ; Thu, 26 Jun 2014 15:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id et_V6WEyYNfP for ; Thu, 26 Jun 2014 15:20:29 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id A7D211B2F0A for ; Thu, 26 Jun 2014 15:20:29 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s5QMKRkb015440; Thu, 26 Jun 2014 18:20:28 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "'ekr@rtfm.com'" , "'msj@nthpermutation.com'" Thread-Topic: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, Thread-Index: AQHPkYzVe6FkOdg2hkqxkkG+QCkPAQ== Date: Thu, 26 Jun 2014 22:20:27 +0000 Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC16A9F7@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.34.14.22] Content-Type: multipart/alternative; boundary="_000_65D2FD736B6B2B48B2EAD2BD189DC9CC16A9F7LLE2K10MBX01mitll_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-26_07:2014-06-26,2014-06-26,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406260238 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xTCmBXgyq33G5IsNeME4sFDx29s Cc: "'tls@ietf.org'" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 22:20:41 -0000 --_000_65D2FD736B6B2B48B2EAD2BD189DC9CC16A9F7LLE2K10MBX01mitll_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SU1ITyB2ZXJpZmlhYmx5IHJhbmRvbSBnZW5lcmF0aW9uIG9mIGN1cnZlcyBpcyBkZXNpcmFibGUu DQoNCi0tDQpSZWdhcmRzLA0KVXJpIEJsdW1lbnRoYWwgVm9pY2U6ICg3ODEpIDk4MS0xNjM4DQpD eWJlciBTeXN0ZW1zIGFuZCBUZWNobm9sb2d5IEZheDogKDc4MSkgOTgxLTAxODYNCk1JVCBMaW5j b2xuIExhYm9yYXRvcnkgQ2VsbDogKDMzOSkgMjIzLTUzNjMNCjI0NCBXb29kIFN0cmVldCBFbWFp bDogPHVyaUBsbC5taXQuZWR1Pg0KTGV4aW5ndG9uLCBNQSAwMjQyMC05MTg1DQoNCldlYjogaHR0 cDovL3d3dy5sbC5taXQuZWR1L0NTVC8NCg0KDQoNCk1JVCBMTCBSb290IENBOg0KDQo8aHR0cHM6 Ly93d3cubGwubWl0LmVkdS9sYWJjZXJ0aWZpY2F0ZWF1dGhvcml0eS5odG1sPg0KDQoNCkRTTjog NDc4LTU5ODAgYXNrIExpbmNvbG4gZXh0LjE2MzgNCg0KRnJvbTogRXJpYyBSZXNjb3JsYSBbbWFp bHRvOmVrckBydGZtLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDI2LCAyMDE0IDA2OjEwIFBN DQpUbzogTWljaGFlbCBTdEpvaG5zIDxtc2pAbnRocGVybXV0YXRpb24uY29tPg0KQ2M6IHRsc0Bp ZXRmLm9yZyA8dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIE9uIEN1cnZlMjU1MTkg YW5kIG90aGVyIHBvc3NpYmlsaXRpZXMgKGUuZy4gaWV0ZjI1NnAsIGlldGYzODRwLCBpZXRmNTIx cCwNCg0KDQoNCg0KT24gVGh1LCBKdW4gMjYsIDIwMTQgYXQgMjo1OSBQTSwgTWljaGFlbCBTdEpv aG5zIDxtc2pAbnRocGVybXV0YXRpb24uY29tPG1haWx0bzptc2pAbnRocGVybXV0YXRpb24uY29t Pj4gd3JvdGU6DQpUaGVyZSdzIGJlZW4gYSBzbWFsbCBidXQgdm9jYWwgbWlub3JpdHkgYWdpdGF0 aW5nIGZvciB0aGUgYWRvcHRpb24gb2YgQ3VydmUyNTUxOSBmb3IgdXNlIGluIFRMUyAoYW5kIG90 aGVyIElFVEYgcHJvdG9jb2xzKS4gIEFzIHRoZSBkaXNjdXNzaW9uIGhhcyBnb25lIG9uLCB3aGF0 IEkgaGF2ZW4ndCBzZWVuIGlzIGNvbXBlbGxpbmcgZXZpZGVuY2UgdGhhdCB0aGlzIHRlY2hub2xv Z3kgaGFzIGJlZW4gdmV0dGVkIHN1ZmZpY2llbnRseSB0aGF0IGl0IHdvdWxkIG1lZXQgdGhlICJC ZXN0IENvbW1lcmNpYWwgUHJhY3RpY2VzIiB0aHJlc2hvbGQgZm9yIHNhZmUgaGFyYm9yIHN0YXR1 cyBmb3IgZW5jcnlwdGlvbi4gIEl0IG1heSBldmVudHVhbGx5IGdldCB0aGVyZSwgYnV0IGZvciBh dCBsZWFzdCB0aGUgbmV4dCBmZXcgKDUtMTA/PykgeWVhcnMsIEkgd291bGQgZXhwZWN0IGJ1c2lu ZXNzZXMgdG8gYXZvaWQgdGhlIHVzZSBpbiBwcml2YWN5IHNlbnNpdGl2ZSwgb3IgZmluYW5jaWFs bHkgc2Vuc2l0aXZlIG9wZXJhdGlvbnMuDQoNClRoZXJlIGFyZSBhbHNvIHBvc3NpYmxlIElQUiBp c3N1ZXMsIGRlZmluaXRlIGluZnJhc3RydWN0dXJlIGlzc3VlcyAoZS5nLiBubyBvZmYgdGhlIHNo ZWxmLCBjb21tZXJjaWFsIGhhcmR3YXJlIG9yIHNvZnR3YXJlIEFGQUlLKSwgZG9jdW1lbnRhdGlv biBpc3N1ZXMgKG5vdCB0aGUgYmFzZSBjdXJ2ZSwgYnV0IGhvdyB0byBpbmNvcnBvcmF0ZSBjdXJ2 ZSBkYXRhIGludG8gY2VydGlmaWNhdGVzIGFuZCBvdGhlciBwcm90b2NvbCBtZXNzYWdlcywgYW5k IHRoZSBmYWN0IGl0J3Mga2V5IGFncmVlbWVudCBvbmx5ICh2cyB0aGUgY3VycmVudCBFQyBjdXJ2 ZXMgd2hpY2ggY2FuIGJlIHVzZWQgZm9yIGJvdGggc2lnbmF0dXJlIGFuZCBhZ3JlZW1lbnQpLiAg QSBsb25nIGxpc3Qgb2YgaXRlbXMgdGhhdCBwcm9iYWJseSwgYnV0IG5vdCBkZWZpbml0ZWx5LCBj YW4gYmUgcmVzb2x2ZWQuDQoNCkFGQUNULCBvbmUgb2YgdGhlIG1haW4gcmVhc29ucyBmb3IgbG9v a2luZyBhdCBDdXJ2ZTI1NTE5IChwb3NzaWJseSBtb3JlIGltcG9ydGFudCB0aGFuIHBlcmZvcm1h bmNlIG9yIHNlY3VyaXR5KSBpcyB0aGF0IHRoZXJlIGlzIGEgZmVhciB0aGF0IHRoZSBVUyBHb3Zl cm5tZW50IGhhcyBwbGFjZWQgdHJhcGRvb3JzIGluIHRoZSBjdXJyZW50IHNldCBvZiBjdXJ2ZXMg KE5JU1QgUDI1NiwgUDM4NCwgUDUyMSBldGMpLiAgIFRoZSBhcmd1bWVudCBhZ2FpbnN0IHRoZSAi cHJvdmFibHkgcmFuZG9tIiBjcmVhdGlvbiBjbGFpbSB3aXRoIHJlc3BlY3QgdG8gdGhvc2UgY3Vy dmVzIGFwcGVhcnMgdG8gYmUgdGhhdCBtYW55ICJzZWVkIiB2YWx1ZXMgY291bGQgaGF2ZSBiZWVu IGdlbmVyYXRlZCB0byBnZW5lcmF0ZSBjdXJ2ZSBwYXJhbWV0ZXJzIGFuZCB0aG9zZSBjdXJ2ZXMg dGVzdGVkIHRvIGZpbmQgIndlYWsiIGN1cnZlcyBvZiBhIHBhcnRpY3VsYXIgZmxhdm9yIGFuZCB0 aGUgc2VlZHMgZm9yIHdlYWsgY3VydmVzIHJldGFpbmVkLiAgSW4gb3RoZXIgd29yZHMsIHdlIGRv bid0IGtub3cgaG93IHRoZSBzZWVkIHZhbHVlcyB3ZXJlIGdlbmVyYXRlZCBhbmQgaXQgY291bGQg YmUgbmVmYXJpb3VzLiAgSSBoYXZlbid0IGFzIHlldCBmb3VuZCBhbnkgYXJndW1lbnQgYWdhaW5z dCB0aGUgZ2VuZXJhdGlvbiBwcm9jZXNzLCBub3Igc3BlY2lmaWNhbGx5IGFnYWluc3QgdGhlIGVs bGlwdGljIGN1cnZlIG1hdGguDQoNCkdpdmVuIHRoYXQgdGhlIEVDIG1hdGggaW4gRklQUzE4Niwg WDkuNjIsIFg5LjYzLCBTUDgwMC01NkEsIFNFQzEsIGFuZCB0aGUgdmFyaW91cyBJU08gZG9jdW1l bnRzIGlzIHByZXR0eSBtdWNoIGlkZW50aWNhbCwgaW5zdGVhZCBvZiB0aHJvd2luZyBhd2F5IGFs bCB0aGF0IGltcGxlbWVudGF0aW9uIGFuZCBzdGFuZGFyZGl6YXRpb24sIGhvdyBhYm91dCB3ZSBq dXN0IGdlbmVyYXRlIG5ldyBjdXJ2ZXM6DQoNCltTbmlwXQ0KSSdtIGN1dHRpbmcgaGVyZSBiZWNh dXNlIEkgd291bGQgbGlrZSB0byBlbmNvdXJhZ2UgV0cgbWVtYmVycyB0bw0KZm9jdXMgb24gdGhl IGdlbmVyYWwgbWVyaXRzIG9mIHRoaXMgc3VnZ2VzdGlvbiAob3IgbGFjayB0aGVyZW9mLCBkZXBl bmRpbmcNCm9uIHlvdXIgcGVyc3BlY3RpdmUpIHJhdGhlciB0aGFuIG9uIHRoZSBzcGVjaWZpYyBk ZXRhaWxzIG9mIHRoZSBwcm9jZWR1cmUNCk1pa2UgaGFzIHByb3Bvc2VkLiBJIHRoaW5rIGl0J3Mg Y2xlYXIgdGhhdCB3ZSBjb3VsZCBkZXZlbG9wIGEgcHJvY2VkdXJlDQpmb3IgcHJvZHVjaW5nIHZl cmlmaWFibHkgcmFuZG9tIHNlZWRzLCBidXQgbGV0J3MgdHJ5IHRvIGZpZ3VyZSBvdXQgZmlyc3QN CndoZXRoZXIgdGhhdCdzIGEgZ29vZCBpZGVhIGJlZm9yZSB3ZSB3b3JyeSBhYm91dCBob3cgdG8g ZG8gaXQuDQoNCkFsc28sIHRoaXMgc2VlbXMgbGlrZSBhIGJpZ2dlciB0b3BpYyB0aGFuIFRMUy4g UGVyaGFwcyB0aGUNCkFEIHNob3VsZCBzcG9uc29yIGEgZGlzY3Vzc2lvbiBpbiBTQUFHPw0KDQot RWtyDQoNCg== --_000_65D2FD736B6B2B48B2EAD2BD189DC9CC16A9F7LLE2K10MBX01mitll_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGZvbnQgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklNSE8gdmVyaWZpYWJseSByYW5kb20gZ2Vu ZXJhdGlvbiBvZiBjdXJ2ZXMgaXMgZGVzaXJhYmxlLjxicj4NCjxicj4NCi0tIDxicj4NClJlZ2Fy ZHMsIDxicj4NClVyaSBCbHVtZW50aGFsIFZvaWNlOiAoNzgxKSA5ODEtMTYzOCA8YnI+DQpDeWJl ciBTeXN0ZW1zIGFuZCBUZWNobm9sb2d5IEZheDogKDc4MSkgOTgxLTAxODYgPGJyPg0KTUlUIExp bmNvbG4gTGFib3JhdG9yeSBDZWxsOiAoMzM5KSAyMjMtNTM2MyA8YnI+DQoyNDQgV29vZCBTdHJl ZXQgRW1haWw6ICZsdDt1cmlAbGwubWl0LmVkdSZndDsgPGJyPg0KTGV4aW5ndG9uLCBNQSAwMjQy MC05MTg1IDxicj4NCjxicj4NCldlYjogaHR0cDovL3d3dy5sbC5taXQuZWR1L0NTVC8gPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KTUlUIExMIFJvb3QgQ0E6IDxicj4NCjxicj4NCiZsdDtodHRwczov L3d3dy5sbC5taXQuZWR1L2xhYmNlcnRpZmljYXRlYXV0aG9yaXR5Lmh0bWwmZ3Q7IDxicj4NCjxi cj4NCjxicj4NCkRTTjogNDc4LTU5ODAgYXNrIExpbmNvbG4gZXh0LjE2Mzg8L2ZvbnQ+PGJyPg0K Jm5ic3A7PGJyPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGZvbnQgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxiPkZyb208L2I+OiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29t XQ0KPGJyPg0KPGI+U2VudDwvYj46IFRodXJzZGF5LCBKdW5lIDI2LCAyMDE0IDA2OjEwIFBNPGJy Pg0KPGI+VG88L2I+OiBNaWNoYWVsIFN0Sm9obnMgJmx0O21zakBudGhwZXJtdXRhdGlvbi5jb20m Z3Q7IDxicj4NCjxiPkNjPC9iPjogdGxzQGlldGYub3JnICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7IDxi cj4NCjxiPlN1YmplY3Q8L2I+OiBSZTogW1RMU10gT24gQ3VydmUyNTUxOSBhbmQgb3RoZXIgcG9z c2liaWxpdGllcyAoZS5nLiBpZXRmMjU2cCwgaWV0ZjM4NHAsIGlldGY1MjFwLA0KPGJyPg0KPC9m b250PiZuYnNwOzxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPGRpdiBjbGFzcz0i Z21haWxfZXh0cmEiPjxicj4NCjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUaHUs IEp1biAyNiwgMjAxNCBhdCAyOjU5IFBNLCBNaWNoYWVsIFN0Sm9obnMgPHNwYW4gZGlyPSJsdHIi Pg0KJmx0OzxhIGhyZWY9Im1haWx0bzptc2pAbnRocGVybXV0YXRpb24uY29tIiB0YXJnZXQ9Il9i bGFuayI+bXNqQG50aHBlcm11dGF0aW9uLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDti b3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NClRoZXJlJ3MgYmVl biBhIHNtYWxsIGJ1dCB2b2NhbCBtaW5vcml0eSBhZ2l0YXRpbmcgZm9yIHRoZSBhZG9wdGlvbiBv ZiBDdXJ2ZTI1NTE5IGZvciB1c2UgaW4gVExTIChhbmQgb3RoZXIgSUVURiBwcm90b2NvbHMpLiAm bmJzcDtBcyB0aGUgZGlzY3Vzc2lvbiBoYXMgZ29uZSBvbiwgd2hhdCBJIGhhdmVuJ3Qgc2VlbiBp cyBjb21wZWxsaW5nIGV2aWRlbmNlIHRoYXQgdGhpcyB0ZWNobm9sb2d5IGhhcyBiZWVuIHZldHRl ZCBzdWZmaWNpZW50bHkgdGhhdCBpdA0KIHdvdWxkIG1lZXQgdGhlICZxdW90O0Jlc3QgQ29tbWVy Y2lhbCBQcmFjdGljZXMmcXVvdDsgdGhyZXNob2xkIGZvciBzYWZlIGhhcmJvciBzdGF0dXMgZm9y IGVuY3J5cHRpb24uICZuYnNwO0l0IG1heSBldmVudHVhbGx5IGdldCB0aGVyZSwgYnV0IGZvciBh dCBsZWFzdCB0aGUgbmV4dCBmZXcgKDUtMTA/PykgeWVhcnMsIEkgd291bGQgZXhwZWN0IGJ1c2lu ZXNzZXMgdG8gYXZvaWQgdGhlIHVzZSBpbiBwcml2YWN5IHNlbnNpdGl2ZSwgb3IgZmluYW5jaWFs bHkgc2Vuc2l0aXZlDQogb3BlcmF0aW9ucy48YnI+DQo8YnI+DQpUaGVyZSBhcmUgYWxzbyBwb3Nz aWJsZSBJUFIgaXNzdWVzLCBkZWZpbml0ZSBpbmZyYXN0cnVjdHVyZSBpc3N1ZXMgKGUuZy4gbm8g b2ZmIHRoZSBzaGVsZiwgY29tbWVyY2lhbCBoYXJkd2FyZSBvciBzb2Z0d2FyZSBBRkFJSyksIGRv Y3VtZW50YXRpb24gaXNzdWVzIChub3QgdGhlIGJhc2UgY3VydmUsIGJ1dCBob3cgdG8gaW5jb3Jw b3JhdGUgY3VydmUgZGF0YSBpbnRvIGNlcnRpZmljYXRlcyBhbmQgb3RoZXIgcHJvdG9jb2wgbWVz c2FnZXMsIGFuZA0KIHRoZSBmYWN0IGl0J3Mga2V5IGFncmVlbWVudCBvbmx5ICh2cyB0aGUgY3Vy cmVudCBFQyBjdXJ2ZXMgd2hpY2ggY2FuIGJlIHVzZWQgZm9yIGJvdGggc2lnbmF0dXJlIGFuZCBh Z3JlZW1lbnQpLiAmbmJzcDtBIGxvbmcgbGlzdCBvZiBpdGVtcyB0aGF0IHByb2JhYmx5LCBidXQg bm90IGRlZmluaXRlbHksIGNhbiBiZSByZXNvbHZlZC48YnI+DQo8YnI+DQpBRkFDVCwgb25lIG9m IHRoZSBtYWluIHJlYXNvbnMgZm9yIGxvb2tpbmcgYXQgQ3VydmUyNTUxOSAocG9zc2libHkgbW9y ZSBpbXBvcnRhbnQgdGhhbiBwZXJmb3JtYW5jZSBvciBzZWN1cml0eSkgaXMgdGhhdCB0aGVyZSBp cyBhIGZlYXIgdGhhdCB0aGUgVVMgR292ZXJubWVudCBoYXMgcGxhY2VkIHRyYXBkb29ycyBpbiB0 aGUgY3VycmVudCBzZXQgb2YgY3VydmVzIChOSVNUIFAyNTYsIFAzODQsIFA1MjEgZXRjKS4gJm5i c3A7IFRoZSBhcmd1bWVudCBhZ2FpbnN0DQogdGhlICZxdW90O3Byb3ZhYmx5IHJhbmRvbSZxdW90 OyBjcmVhdGlvbiBjbGFpbSB3aXRoIHJlc3BlY3QgdG8gdGhvc2UgY3VydmVzIGFwcGVhcnMgdG8g YmUgdGhhdCBtYW55ICZxdW90O3NlZWQmcXVvdDsgdmFsdWVzIGNvdWxkIGhhdmUgYmVlbiBnZW5l cmF0ZWQgdG8gZ2VuZXJhdGUgY3VydmUgcGFyYW1ldGVycyBhbmQgdGhvc2UgY3VydmVzIHRlc3Rl ZCB0byBmaW5kICZxdW90O3dlYWsmcXVvdDsgY3VydmVzIG9mIGEgcGFydGljdWxhciBmbGF2b3Ig YW5kIHRoZSBzZWVkcyBmb3Igd2VhayBjdXJ2ZXMNCiByZXRhaW5lZC4gJm5ic3A7SW4gb3RoZXIg d29yZHMsIHdlIGRvbid0IGtub3cgaG93IHRoZSBzZWVkIHZhbHVlcyB3ZXJlIGdlbmVyYXRlZCBh bmQgaXQgY291bGQgYmUgbmVmYXJpb3VzLiAmbmJzcDtJIGhhdmVuJ3QgYXMgeWV0IGZvdW5kIGFu eSBhcmd1bWVudCBhZ2FpbnN0IHRoZSBnZW5lcmF0aW9uIHByb2Nlc3MsIG5vciBzcGVjaWZpY2Fs bHkgYWdhaW5zdCB0aGUgZWxsaXB0aWMgY3VydmUgbWF0aC48YnI+DQo8YnI+DQpHaXZlbiB0aGF0 IHRoZSBFQyBtYXRoIGluIEZJUFMxODYsIFg5LjYyLCBYOS42MywgU1A4MDAtNTZBLCBTRUMxLCBh bmQgdGhlIHZhcmlvdXMgSVNPIGRvY3VtZW50cyBpcyBwcmV0dHkgbXVjaCBpZGVudGljYWwsIGlu c3RlYWQgb2YgdGhyb3dpbmcgYXdheSBhbGwgdGhhdCBpbXBsZW1lbnRhdGlvbiBhbmQgc3RhbmRh cmRpemF0aW9uLCBob3cgYWJvdXQgd2UganVzdCBnZW5lcmF0ZSBuZXcgY3VydmVzOjxicj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PltTbmlwXTwvZGl2Pg0KPGRpdj5J J20gY3V0dGluZyBoZXJlIGJlY2F1c2UgSSB3b3VsZCBsaWtlIHRvIGVuY291cmFnZSBXRyBtZW1i ZXJzIHRvPC9kaXY+DQo8ZGl2PmZvY3VzIG9uIHRoZSBnZW5lcmFsIG1lcml0cyBvZiB0aGlzIHN1 Z2dlc3Rpb24gKG9yIGxhY2sgdGhlcmVvZiwgZGVwZW5kaW5nPC9kaXY+DQo8ZGl2Pm9uIHlvdXIg cGVyc3BlY3RpdmUpIHJhdGhlciB0aGFuIG9uIHRoZSBzcGVjaWZpYyBkZXRhaWxzIG9mIHRoZSBw cm9jZWR1cmU8L2Rpdj4NCjxkaXY+TWlrZSBoYXMgcHJvcG9zZWQuIEkgdGhpbmsgaXQncyBjbGVh ciB0aGF0IHdlIGNvdWxkIGRldmVsb3AgYSBwcm9jZWR1cmU8L2Rpdj4NCjxkaXY+Zm9yIHByb2R1 Y2luZyB2ZXJpZmlhYmx5IHJhbmRvbSBzZWVkcywgYnV0IGxldCdzIHRyeSB0byBmaWd1cmUgb3V0 IGZpcnN0PC9kaXY+DQo8ZGl2PndoZXRoZXIgdGhhdCdzIGEgZ29vZCBpZGVhIGJlZm9yZSB3ZSB3 b3JyeSBhYm91dCBob3cgdG8gZG8gaXQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5B bHNvLCB0aGlzIHNlZW1zIGxpa2UgYSBiaWdnZXIgdG9waWMgdGhhbiBUTFMuIFBlcmhhcHMgdGhl PC9kaXY+DQo8ZGl2PkFEIHNob3VsZCBzcG9uc29yIGEgZGlzY3Vzc2lvbiBpbiBTQUFHPzwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+LUVrcjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_65D2FD736B6B2B48B2EAD2BD189DC9CC16A9F7LLE2K10MBX01mitll_-- From nobody Thu Jun 26 15:22:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF221B2EEE for ; Thu, 26 Jun 2014 15:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.156 X-Spam-Level: X-Spam-Status: No, score=-0.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNxeiL927Sq5 for ; Thu, 26 Jun 2014 15:22:06 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1AED1B2EF5 for ; Thu, 26 Jun 2014 15:22:05 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id u10so3412516lbd.19 for ; Thu, 26 Jun 2014 15:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=k0vTkUcGltv1TIIGEd5FhK/yoboRUdfFSbmX2CAjZw4=; b=BPm6LC7rZf+Z8TOUfKilMgT4KrVwHH22Yq1OwpOlrlLF0RJt8OVjNj2+7DCyKFMakW iXsCwPMx0pe19Hz6V8giDJNVy8MD+WkzknIJkMBf8OuxW/eZ1EH3t3F3GlJxEbBih39W /oCchbupTE3L4QgWPTcszXA27NiJXJ4uoL09l1pn3BwEY+QLD4iJg1PHDUkxluIiyO1l G2oJPUPRec5NIofYXeC1mrDs+NmXEJh5+f9GBOrRXIFSPr2nlhjEHSKS/Mp2uBRNZJXM HANYr18nH9VJ8EHh/TOsqDKCNZF2GH9xDYOfi0z8KTbDD17cCuOmg2BmNv6KAR/ppcDs KfcA== MIME-Version: 1.0 X-Received: by 10.112.97.163 with SMTP id eb3mr4086923lbb.67.1403821323836; Thu, 26 Jun 2014 15:22:03 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.32.196 with HTTP; Thu, 26 Jun 2014 15:22:03 -0700 (PDT) In-Reply-To: <53AC97B8.2080909@nthpermutation.com> References: <53AC97B8.2080909@nthpermutation.com> Date: Thu, 26 Jun 2014 15:22:03 -0700 X-Google-Sender-Auth: rMaha81PejUSm4k2OUIf3Wh_x8E Message-ID: From: Adam Langley To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rzkd1hH1cSTIlBkL1oUDWEq8S0A Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 22:22:08 -0000 On Thu, Jun 26, 2014 at 2:59 PM, Michael StJohns wrote: > There's been a small but vocal minority agitating for the adoption of > Curve25519 for use in TLS (and other IETF protocols). As the discussion has > gone on, what I haven't seen is compelling evidence that this technology has > been vetted sufficiently that it would meet the "Best Commercial Practices" > threshold for safe harbor status for encryption. It may eventually get > there, but for at least the next few (5-10??) years, I would expect > businesses to avoid the use in privacy sensitive, or financially sensitive > operations. I assume that such organisations are not going to adopt any newer curves either then. > There are also possible IPR issues I don't believe that there's any basis to this (beyond the level of any other ECC). > definite infrastructure issues (e.g. no > off the shelf, commercial hardware or software AFAIK) There are plenty of software implementations with a higher general quality than any of the NIST curves, although certainly there isn't any hardware. However, hardware support is the result of demand and time. There's no hardware support for any curves that the IETF might come up with either. > documentation issues > (not the base curve, but how to incorporate curve data into certificates and > other protocol messages Again, I feel that this applies equally to anything new. > and the fact it's key agreement only (vs the > current EC curves which can be used for both signature and agreement). The curve is not key-agreement only. Many implementations provide only a Montgomery ladder, which does only provide key agreement, but it works fine for signatures too: http://ed25519.cr.yp.to/ (In fact, I'm not sure if any elliptic curve could be key-agreement only. Signature schemes fall out of any suitable group, no?) > AFACT, one of the main reasons for looking at Curve25519 (possibly more > important than performance or security) is that there is a fear that the US > Government has placed trapdoors in the current set of curves (NIST P256, > P384, P521 etc). Although some certainly subscribe to that, my main motivation for moving away from P-{256,384} is that they simply aren't good curves. They are difficult to implement correctly and have many pitfalls. Elliptic curve design has advanced significantly since then. > Given that the EC math in FIPS186, X9.62, X9.63, SP800-56A, SEC1, and the > various ISO documents is pretty much identical, instead of throwing away all > that implementation and standardization, how about we just generate new > curves: Let's just take is as read that new parameters (with the same field?) could be generated. I'd suggest that the approach in [1] would be better, but that's not important. [1] https://research.microsoft.com/apps/pubs/default.aspx?id=209303 > For most of libraries and hardware devices with which I work, the curve data > is pretty much static configuration (external table referenced by OID) or > compilation (ditto but compiled in), or provided as a library argument and > most libraries have a mechanism to insert or use new curves fairly easily - > at least within the same family. In my experience, the cost of a change is mostly fixed. I believe that the development work that goes into the change is small compared to the effort to update all the software. Even if that's not true, we would have to be very careful to understand the range of easy reconfiguration of these libraries. Do they specialise the field reduction? (Probably) Thus that would be fixed. I assume that a=-3 is fixed too. They might be other limitations in code that would be hard to discover, meaning that the cost of implementing the change ends up being about the same as any new curve anyway. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu Jun 26 15:24:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827E71B2EEE for ; Thu, 26 Jun 2014 15:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYnZp7sVZmIO for ; Thu, 26 Jun 2014 15:24:44 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A71A61B2F0A for ; Thu, 26 Jun 2014 15:24:44 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AB3402AB297; Thu, 26 Jun 2014 22:24:43 +0000 (UTC) Date: Thu, 26 Jun 2014 22:24:43 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140626222443.GI16666@mournblade.imrryr.org> References: <53AC97B8.2080909@nthpermutation.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mYkFTmgS6cGQrwzqlnRKYbNclOA Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 22:24:47 -0000 On Thu, Jun 26, 2014 at 03:10:12PM -0700, Eric Rescorla wrote: > I'm cutting here because I would like to encourage WG members to > focus on the general merits of this suggestion (or lack thereof, depending > on your perspective) rather than on the specific details of the procedure > Mike has proposed. I think it's clear that we could develop a procedure > for producing verifiably random seeds, but let's try to figure out first > whether that's a good idea before we worry about how to do it. Note, that RedHat and (probably some others) truncate the curve support in OpenSSL to just P-256, P-384 and P-521 for IPR reasons. I see little reason to expect that they would include implementations of any of the new proposed curves. The new curves would also suffer from all the ECDSA defects noted by DJB and would not have the performance advantages of Edwards curves. So I see little value in a new batch of essentially the same type of curves. Just more bloat in the client HELLO listing curves nobody has or is willing to use. If we have an opportunity to advance the state of the art, and use (subject to CFRG review, ...) new EC techniques based on lessons learned after ECDSA, that are more performant and less prone to implementation errors, then there is a good reason to add new curves. They might still not get adopted until all the EC patents expire, but at least eventually they move things forward, not sideways. Just adding more of the same old stuff, but with a different proof of randomness does not seem compelling. -- Viktor. From nobody Thu Jun 26 17:17:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734ED1B3042; Thu, 26 Jun 2014 17:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOxDfKj4T3Pq; Thu, 26 Jun 2014 17:17:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id E40D41B303E; Thu, 26 Jun 2014 17:17:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 697C61801A4; Thu, 26 Jun 2014 17:15:46 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140627001546.697C61801A4@rfc-editor.org> Date: Thu, 26 Jun 2014 17:15:46 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/F00iKNgPPAx0UrpqT-aEhXwTJgI Cc: drafts-update-ref@iana.org, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 7250 on Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 00:17:29 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7250 Title: Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Author: P. Wouters, Ed., H. Tschofenig, Ed., J. Gilmore, S. Weiler, T. Kivinen Status: Standards Track Stream: IETF Date: June 2014 Mailbox: pwouters@redhat.com, Hannes.Tschofenig@gmx.net, gnu@toad.com, weiler@tislabs.com, kivinen@iki.fi Pages: 18 Characters: 38040 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-oob-pubkey-11.txt URL: http://www.rfc-editor.org/rfc/rfc7250.txt This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard. 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 Internet Official Protocol Standards (STD 1) 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 http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html 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 Thu Jun 26 18:23:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4C21B3094 for ; Thu, 26 Jun 2014 18:23:37 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRMvSpGgNlca for ; Thu, 26 Jun 2014 18:23:35 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBE51B298B for ; Thu, 26 Jun 2014 18:23:35 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id b6so2637667yha.12 for ; Thu, 26 Jun 2014 18:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6Cyxfn0PGLtahZQM/Ww1K95xlxFSTJQa3VUNzBXWdnA=; b=udfJidnp+yFiVCIQgHWER5YXQDRYm6bEfu3iw5xod2hRvlSbIxqFaDCq5H2k2hkBSJ jMFJG2nUl6Ip0LEIwOqg1LztASbxGr+9KCr5vTBU5TylgFc2xOv6ClJkBlVbXGsx59LW LcmwcSGWEXiahbXrkc/E/FIAte/7zi86NqdPptJSXgkXeVUh6a5qpnx3/4c9T35prs8d uCJgvOAzW5cylgqIedNK2rIz7d4QF5y44OottwCOdHekMWV9QIVz75PogA0P+Phc/ExN eOC0xlv/Ft15vfXJk/dai8s8ed+jLanNNHR+m8M5Dfqirqc+WxBufHQBCbyExm8nn91U HCwQ== MIME-Version: 1.0 X-Received: by 10.236.129.115 with SMTP id g79mr26638627yhi.86.1403832215063; Thu, 26 Jun 2014 18:23:35 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Thu, 26 Jun 2014 18:23:34 -0700 (PDT) In-Reply-To: <20140626143044.F3B0C1AD68@ld9781.wdf.sap.corp> References: <20140626143044.F3B0C1AD68@ld9781.wdf.sap.corp> Date: Thu, 26 Jun 2014 18:23:34 -0700 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/melHiFK8oVi4J3u9GQ74HQyqA1E Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 01:23:37 -0000 On Thu, Jun 26, 2014 at 7:30 AM, Martin Rex wrote: > Joseph Salowey (jsalowey) wrote: >> >> 1. In favor of removing renegotiation >> 2. In favor of removing renegotiation with the addition of rekey facility >> 3. Not in favor of removing renegotiation > > > (3) Leave it in the spec, Make it a true option for implementors. > with a guidance that clients might need it for interop, but should > play safe (and nail down identities once they're established) by default > > > I never offered/exposed renegotiation at the API to application callers, > and since January 2010, I have the server-side reject renegotiation attempts > from clients. But the installed base of _other_ servers that use > (or require) it is to large to be ignored, and I don't see it go away > that easily... > > Everything that you change from TLSv1.0/1/2 toward v1.3 will add complexity > and require more code. This applies not just to adding new features, but > also to axing existing features that may be in current use. > > A TLSv1.3 spec that requires implementors to carefully avoid TLSv1.3 for > a number of commonly used TLSv1.0/1/2 features may be even harder to > sell than TLSv1.2 and IPv6. I think this is an excellent point: unless we are making TLS 1.3 web only, and committing to supporting TLS 1.2 (including renegotation!) for a long time, we cannot ax this feature. As much as I dislike renegotiation, it may be that we need to include it as an optional feature if we want to replace TLS 1.2. Conversely, if we're committed to stabilizing the security flaws in TLS 1.2 and phasing it out, while not having everything upgrade to TLS 1.3, we can get away with eliminating renegotation. Sincerely, Watson Ladd > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Jun 26 18:24:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD331B30B1 for ; Thu, 26 Jun 2014 18:24: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BobyYfZWxTuz for ; Thu, 26 Jun 2014 18:24:51 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09FB1B298B for ; Thu, 26 Jun 2014 18:24:51 -0700 (PDT) Received: by mail-yk0-f174.google.com with SMTP id 19so2488045ykq.33 for ; Thu, 26 Jun 2014 18:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wn3+JG68P1xTARog5JReH2DXc/hPw0yN8VmTI4rufRE=; b=dRb5q2uGuvgdY/Z4F9Z3SeN6ORZVqVKJS567MtERq+hkrKQGzTi5SE1pxExvzePFK+ EGSUOnjUwi6dYHOgReChRyHMq/hwXq/xVMv6WD1Q3KV/fscRajw/Xr2ZB9BXleSBnvrp F6UkJqTWAUn4lTv4pk21Mz8/PmoOA7nIhPfwyb/Qqv5tM5lxDCIb3x+IrQH69qT6+MoD gXhjEqKzlXQ+6SWQRV7ePdz92BGByKA3jcAo9vFsSIOJkDbZWh5odX1eieu/hj1c3oWt a6T9xbpkxxYR8L61xPhKMoiBoMXn0s+77cvB6I2/612J2AckEFNWgB/fIdYxJAf0/agX lU5A== MIME-Version: 1.0 X-Received: by 10.236.129.115 with SMTP id g79mr26644962yhi.86.1403832291161; Thu, 26 Jun 2014 18:24:51 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Thu, 26 Jun 2014 18:24:51 -0700 (PDT) In-Reply-To: <53AC97B8.2080909@nthpermutation.com> References: <53AC97B8.2080909@nthpermutation.com> Date: Thu, 26 Jun 2014 18:24:51 -0700 Message-ID: From: Watson Ladd To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sy5bZ0TEql7EoDEuYGbZRiHXLWU Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 01:24:54 -0000 On Thu, Jun 26, 2014 at 2:59 PM, Michael StJohns wrote: > There's been a small but vocal minority agitating for the adoption of > Curve25519 for use in TLS (and other IETF protocols). As the discussion has > gone on, what I haven't seen is compelling evidence that this technology has > been vetted sufficiently that it would meet the "Best Commercial Practices" > threshold for safe harbor status for encryption. It may eventually get > there, but for at least the next few (5-10??) years, I would expect > businesses to avoid the use in privacy sensitive, or financially sensitive > operations. And RC4 meets them? The fact is that we understand ECC very, very well: the issues involved with changing curves are akin to those in changing primes in Diffie-Hellman: most choices are terrible, but they are easy to avoid. Furthermore, TLS has many options that are little-used: I don't see the harm with adding another curve, particularly when it will not be little used. > > There are also possible IPR issues, definite infrastructure issues (e.g. no > off the shelf, commercial hardware or software AFAIK), documentation issues > (not the base curve, but how to incorporate curve data into certificates and > other protocol messages, and the fact it's key agreement only (vs the > current EC curves which can be used for both signature and agreement). A > long list of items that probably, but not definitely, can be resolved. IPR issues: Montgomery curves were developed in 1985. Any patents would have expired in 2005. The key agreement only issue doesn't affect the currently envisioned use as a faster and more secure key negotiation mechanism. There is a signature variant Ed25519, but yes, this cannot go into x509 certificates right now, and likely due to legacy software, for a long time. As for software, there are many mature, well tested, and secure implementations. > > AFACT, one of the main reasons for looking at Curve25519 (possibly more > important than performance or security) is that there is a fear that the US > Government has placed trapdoors in the current set of curves (NIST P256, > P384, P521 etc). The argument against the "provably random" creation claim > with respect to those curves appears to be that many "seed" values could > have been generated to generate curve parameters and those curves tested to > find "weak" curves of a particular flavor and the seeds for weak curves > retained. In other words, we don't know how the seed values were generated > and it could be nefarious. I haven't as yet found any argument against the > generation process, nor specifically against the elliptic curve math. Other than slow speed, exceptional cases, and primes that are painful on 64 bit processors (P256 specific) there are no problems. Oh, and the lack of point validation in some widely deployed software. > > Given that the EC math in FIPS186, X9.62, X9.63, SP800-56A, SEC1, and the > various ISO documents is pretty much identical, instead of throwing away all > that implementation and standardization, how about we just generate new > curves: > > 1) 20 organizations publicly contribute random/pseudo-random strings of > 1kbits - they get to decide exactly which bits to send. > 1a) discard any of these with detectable bias. > 2) Randomly select 10 sets of contributed bits from those remaining (using > public randomness sources to select those to be retained). > 3) Concatenate the bits in a random order (using public randomness sources > such as stock prices etc to select the order). > 4) Run the concatenated data through an entropy extraction process (e.g. > hash, hmac, other PRF) to produce a seed value of sufficient length. (or > seed values if all the curves come from this one pass). > 5) Generate the curve data and generator points from the seed. > 6) Assign IETF OIDs to each curve generated this way. > 7) Permanently record ALL the data used to generate the curves so we don't > have future conspiracy theories. What does this get us that Brainpool did not? > > For most of libraries and hardware devices with which I work, the curve data > is pretty much static configuration (external table referenced by OID) or > compilation (ditto but compiled in), or provided as a library argument and > most libraries have a mechanism to insert or use new curves fairly easily - > at least within the same family. I'd recommend that we generate curves > equivalent in strength to the current NIST curves in all of prime, binary > and koblitz flavors. You do realize there is only koblitz curve for each binary field size, right? For prime koblitz it's a similar story. Why? What do these curves have to offer above Brainpool or NIST? There's a strong case for including Curve25519 for performance and implementation quality reasons. For another Weierstrass curve, those don't exist. Sincerely, Watson Ladd > > Mike > > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Jun 26 18:50:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B681B30CC for ; Thu, 26 Jun 2014 18:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20DzrY0T7pgm for ; Thu, 26 Jun 2014 18:50:45 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 5E78E1B3074 for ; Thu, 26 Jun 2014 18:50:45 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B188C48358; Fri, 27 Jun 2014 01:50:44 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id A631D48355; Fri, 27 Jun 2014 01:50:44 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 7FAD398045; Fri, 27 Jun 2014 01:50:44 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Thu, 26 Jun 2014 21:50:44 -0400 From: "Salz, Rich" To: Eric Rescorla , Michael StJohns Date: Thu, 26 Jun 2014 21:50:43 -0400 Thread-Topic: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, Thread-Index: Ac+Ri4ml5YK+lAAhSN+JUpyV2SV0ggAHJ+Iw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF63A@USMBX1.msg.corp.akamai.com> References: <53AC97B8.2080909@nthpermutation.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C71854BEF63AUSMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vU_vLzMhrrgxBs5WmD8q_WMYjXI Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 01:50:47 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C71854BEF63AUSMBX1msgcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IGZpbmQgTWlrZeKAmXMgY29uY2VybnMgY29tcGVsbGluZzsgbW9zdCBvZiB0aGVt IGhhdmUgYmVlbiAodG8gbWUpIGFkZXF1YXRlbHkgZGlzY291bnRlZCBieSBBZGFtIGFuZCBWaWN0 b3LigJlzIHBvc3RzLiAgRm9yIGZ1cnRoZXIgaW5mbyBvbiBwYXRlbnRzIGFuZCBzdWNoLCBzZWUg aHR0cDovL2NyLnlwLnRvL2VjZGgvcGF0ZW50cy5odG1sLg0KDQpNb3N0IGltcG9ydGFudGx5LCBJ TUhPLCBpcyBhdCB0aGUgU3ByaW5nIGludGVyaW0gbWVldGluZyBvZiB0aGUgQ0ZSRywgaXQgd2Fz IGRlY2lkZWQgdG8gcmVjb21tZW5kIEN1cnZlMjU1MTkgIGZvciB1c2UgaW4gSUVURiBwcm90b2Nv bHM7IHNlZQ0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NmcmcvY3VycmVu dC9tc2cwNDUwNS5odG1sDQoNCi0tDQpQcmluY2lwYWwgU2VjdXJpdHkgRW5naW5lZXINCkFrYW1h aSBUZWNobm9sb2dpZXMsIENhbWJyaWRnZSwgTUENCklNOiByc2FsekBqYWJiZXIubWU8bWFpbHRv OnJzYWx6QGphYmJlci5tZT47IFR3aXR0ZXI6IFJpY2hTYWx6DQoNCg== --_000_2A0EFB9C05D0164E98F19BB0AF3708C71854BEF63AUSMBX1msgcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1F Ti1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgZG9u4oCZdCBmaW5kIE1pa2Xi gJlzIGNvbmNlcm5zIGNvbXBlbGxpbmc7IG1vc3Qgb2YgdGhlbSBoYXZlIGJlZW4gKHRvIG1lKSBh ZGVxdWF0ZWx5IGRpc2NvdW50ZWQgYnkgQWRhbSBhbmQgVmljdG9y4oCZcyBwb3N0cy4gwqBGb3Ig ZnVydGhlciBpbmZvIG9uIHBhdGVudHMgYW5kIHN1Y2gsIHNlZSA8YSBocmVmPSJodHRwOi8vY3Iu eXAudG8vZWNkaC9wYXRlbnRzLmh0bWwiPmh0dHA6Ly9jci55cC50by9lY2RoL3BhdGVudHMuaHRt bDwvYT4uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Nb3N0IGltcG9ydGFudGx5LCBJTUhPLCBpcyBhdCB0 aGUgU3ByaW5nIGludGVyaW0gbWVldGluZyBvZiB0aGUgQ0ZSRywgaXQgd2FzIGRlY2lkZWQgdG8g cmVjb21tZW5kIEN1cnZlMjU1MTkgwqBmb3IgdXNlIGluIElFVEYgcHJvdG9jb2xzOyBzZWU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NmcmcvY3VycmVudC9tc2cw NDUwNS5odG1sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLcKgIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QcmluY2lwYWwgU2VjdXJp dHkgRW5naW5lZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+QWthbWFpIFRlY2hub2xvZ2llcywgQ2FtYnJpZGdlLCBNQTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5JTTogPGEgaHJlZj0ibWFpbHRvOnJzYWx6QGphYmJlci5tZSI+PHNwYW4gc3R5bGU9J2NvbG9y OmJsdWUnPnJzYWx6QGphYmJlci5tZTwvc3Bhbj48L2E+OyBUd2l0dGVyOiBSaWNoU2FsejxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_2A0EFB9C05D0164E98F19BB0AF3708C71854BEF63AUSMBX1msgcorp_-- From nobody Thu Jun 26 20:38:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBED1B2A4C for ; Thu, 26 Jun 2014 20:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DpY-cCR-Zcu for ; Thu, 26 Jun 2014 20:38:12 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65C7F1B2946 for ; Thu, 26 Jun 2014 20:38: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=uoa; t=1403840292; x=1435376292; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ko3K02CIYtAATNDU/6u/FdiSHNzfUo/9TAnKHJ4yyn8=; b=VP9D9nVo+Bh+aOeJWi/PqmVsP0QTjVDqFblbGOV/uhuyYsoXPKyTgbt+ hjz1SiWabHERB9G8Qd7xNNzj8zo4KiYBZ/Kgbmzm3kzkYiBNGZcs9aqFQ hZ8CqXc7Ucxggo8rPHttvE36Qm/ucdUvCJB3sRpMO6S/RDs/Ol0FZP1ZF g=; X-IronPort-AV: E=Sophos;i="5.01,558,1399982400"; d="scan'208";a="260841177" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 27 Jun 2014 15:38:09 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Fri, 27 Jun 2014 15:38:10 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, Thread-Index: Ac+RuTZg2E8kCQh7QyGvg7kxrT/RSg== Date: Fri, 27 Jun 2014 03:38:08 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DECF8F8@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/t0EwLVMob_RZI--4fIenU-p7ys0 Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 03:38:18 -0000 Michael StJohns writes:=0A= =0A= >Given that the EC math in FIPS186, X9.62, X9.63, SP800-56A, SEC1, and the= =0A= >various ISO documents is pretty much identical, instead of throwing away a= ll=0A= >that implementation and standardization, how about we just generate new=0A= >curves:=0A= =0A= How about we just use the Brainpool curves? They're already standardised f= or=0A= use in TLS, and supported in many implementations.=0A= =0A= Peter.= From nobody Thu Jun 26 20:40:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500B81B2DEB for ; Thu, 26 Jun 2014 20:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZyIAsGkBDXa for ; Thu, 26 Jun 2014 20:40:47 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1371B2A4C for ; Thu, 26 Jun 2014 20:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1403840447; x=1435376447; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ZFTIzpRD/mI76g6Q/UFOqfx/IiNrB4ZlmGxBViiFdZ4=; b=ubkFImbKTV+MiFMa4gbuKZ9AJHYebshx06eDFdUcyc79DbwoOneVaSE0 uit1FHmRB2/l+0tDmfw0Vm7fdpFGXYzr2NRdceDgLsypPhRhu9blnbpSd LEax18hbtb9urNorPYumcC6Vwhs0MR667EEk7HBq7AbDKFUI7pc234n3a 0=; X-IronPort-AV: E=Sophos;i="5.01,558,1399982400"; d="scan'208";a="260842105" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 27 Jun 2014 15:40:45 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Fri, 27 Jun 2014 15:40:45 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Call for Consensus on removal of renegotiation Thread-Index: Ac+RuZPWAcrPAyLATh2/vQ9zGEuAdg== Date: Fri, 27 Jun 2014 03:40:45 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DECF906@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8FVNEgBaBswhmEYOFairjIgsiqo Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 03:40:49 -0000 Tapio Sokura writes:=0A= >On 25.6.2014 23:03, Joseph Salowey (jsalowey) wrote:=0A= >> [Joe] to simplify:=0A= >>=0A= >> 1. In favor of removing renegotiation=0A= >> 2. In favor of removing renegotiation with the addition of rekey facili= ty=0A= >> 3. Not in favor of removing renegotiation=0A= >=0A= >I would choose 1 or 2.=0A= =0A= +1.=0A= =0A= Peter.=0A= From nobody Thu Jun 26 20:49:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BA91B313B for ; Thu, 26 Jun 2014 20:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giqrGrCCWHQZ for ; Thu, 26 Jun 2014 20:49:41 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBFFD1B2F20 for ; Thu, 26 Jun 2014 20:49: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=uoa; t=1403840981; x=1435376981; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ECx4s2C46s4rZj81OtYjsSqVwfr56ICB4zV+M64QX1M=; b=a+o5XYRUDtgKXzyt4vpWO56ED1bNmlHCc8ZRXHBiNlGhHMVSskB5bn7N 1BNeUnVnA0gL++kLJSBpQTVdSmFzGpgZG8QTwnSJSSDgyxixN8KM+Qun4 R+hDDln9UvvTRb6SnaA63EzsYbNRNANyJQmY+tj7Kkm3mrgIs4WnyxmgD I=; X-IronPort-AV: E=Sophos;i="5.01,558,1399982400"; d="scan'208";a="260844410" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 27 Jun 2014 15:49:12 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Fri, 27 Jun 2014 15:49:10 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, Thread-Index: Ac+RusBx+WXT/cCqSCixQ+dbotOa5Q== Date: Fri, 27 Jun 2014 03:49:09 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DECF913@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cLO0yWCx_gWLA7F4RvxJ1NtEgak Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 03:49:42 -0000 Viktor Dukhovni writes:=0A= =0A= >If we have an opportunity to advance the state of the art, and use (subjec= t=0A= >to CFRG review, ...) new EC techniques based on lessons learned after ECDS= A,=0A= >that are more performant and less prone to implementation errors, then the= re=0A= >is a good reason to add new curves.=0A= =0A= If we're going to do that then we need to have something like the=0A= AES/SHA-3/PHC competition to decide on a suitable curve (and whatever other= =0A= deckchairs are going to be rearranged in TLS 1.3), not just take the first= =0A= trendy thing that pops up. I have a great deal of respect for djb and he= =0A= designs some really good stuff, but with the thought of having to implement= =0A= huge amounts of new material for TLS 1.3 (after already having had to do it= =0A= for 1.2) I really, really don't want to have to start again from scratch if= ,=0A= in two years' time, someone finds some issue in 25519 and/or the other bits= =0A= that are being thrown in. Using the oldest SSL algorithms that come to min= d,=0A= 3DES, DHE, and HMAC-SHA1, I'm pretty confident that I'm, as I quoted a=0A= cryptographer earlier, "unlikely to be surprised". Introducing several tre= ndy=0A= new algorithms all at once gives me nothing like that level of confidence.= =0A= =0A= Peter.=0A= From nobody Thu Jun 26 21:15:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C091B306F for ; Thu, 26 Jun 2014 21:15: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Slyhizwy5tIb for ; Thu, 26 Jun 2014 21:15:33 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C111B2F49 for ; Thu, 26 Jun 2014 21:15:33 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id 200so2564420ykr.30 for ; Thu, 26 Jun 2014 21:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wOW9O4ZzwLV65mddLFhvzsQGgJR6sBLE2EqW2nLdz0g=; b=KOn4nfLBI2wMhM9arxAsm8qIAuFQvUcbwa/nVj2O9QHImL3BtSmP3+Lsv/NWP4+6ZH djvP7gS2ksqiUzpnRNubUm+Nn9CkUME0Zf7VST31VwxEkN6gHpEw5UorU8NTrnNHNFJG ZRvmQXYzt4NeqlB/SiJX7j32cHeBaDt8l3fG+YlwPT4Go/dHWNi2MChyOjmEJlmpz+Jd lj184n5HflyeSqPmOHMIEBigpgFlWrRj5WA+egD9BJs/+jR8Lruw0EeM2DCUCaLxFSpT UrnmPlII2kLfGo06YawZVlt91GVzELxGSczomqryYiW/uMIoWuAqKXwIOx94eKNkf4P/ QcHw== MIME-Version: 1.0 X-Received: by 10.236.173.71 with SMTP id u47mr28349221yhl.66.1403842532888; Thu, 26 Jun 2014 21:15:32 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Thu, 26 Jun 2014 21:15:32 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738DECF913@uxcn10-tdc06.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C738DECF913@uxcn10-tdc06.UoA.auckland.ac.nz> Date: Thu, 26 Jun 2014 21:15:32 -0700 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/obWdl4o-xcEpuMlGaquMXDZ5VIg Cc: "" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 04:15:38 -0000 On Thu, Jun 26, 2014 at 8:49 PM, Peter Gutmann wrote: > Viktor Dukhovni writes: > >>If we have an opportunity to advance the state of the art, and use (subject >>to CFRG review, ...) new EC techniques based on lessons learned after ECDSA, >>that are more performant and less prone to implementation errors, then there >>is a good reason to add new curves. > > If we're going to do that then we need to have something like the > AES/SHA-3/PHC competition to decide on a suitable curve (and whatever other > deckchairs are going to be rearranged in TLS 1.3), not just take the first > trendy thing that pops up. I have a great deal of respect for djb and he > designs some really good stuff, but with the thought of having to implement > huge amounts of new material for TLS 1.3 (after already having had to do it > for 1.2) I really, really don't want to have to start again from scratch if, > in two years' time, someone finds some issue in 25519 and/or the other bits > that are being thrown in. Using the oldest SSL algorithms that come to mind, > 3DES, DHE, and HMAC-SHA1, I'm pretty confident that I'm, as I quoted a > cryptographer earlier, "unlikely to be surprised". Introducing several trendy > new algorithms all at once gives me nothing like that level of confidence. Already happened: Curve25519 was published in 2006. Since then quite a few people have come up with new proposals, and the CFRG had a meeting this spring to pick between them. Yes, this wasn't a formal contest, but there has been a lot of work on new curve shapes, and Curve25519 has well-validated implementations, very good performance, and meets all security criteria. Furthermore, this is much more like picking a prime for DH, then picking a block cipher: there are many bad choices, but well-understood criteria for picking good ones. Because validation is essential (*ahem*) we need a dictionary of supported options, and because of the criteria you can play fun games to get extra speed. The difference in shape eliminates a lot of pain for implementers. No more special cases, no more validation and having to force callers to handle errors that they might not be prepared to handle. It's a big step forward in closing perennial issues in ECC implementations. Furthermore, you can just rip the guts of NaCl out, the way you did to support ECC in cryptlib. Only NaCl doesn't have the timing attack vulnerability the EC functionality in cryptlib does. It's not much more complicated than going from P-256 and P-224 to include P-384. If you don't want to support it, fine: implement only P-256. Sincerely, Watson Ladd > > Peter. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Jun 26 22:14:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328AD1B3155 for ; Thu, 26 Jun 2014 22:14:19 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS4v30i-HEgT for ; Thu, 26 Jun 2014 22:14:17 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE481B3153 for ; Thu, 26 Jun 2014 22:14:17 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so4545460wes.15 for ; Thu, 26 Jun 2014 22:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lJ4+PhCa7GY8CVkxxzmI8DsbvhcyMFrxVip8hY8DBkM=; b=0UrLiWI4DQ5dlROLe7nQ7qEGaUqwPhdzzUtK5vCUuQpX/KXPIpvWKQXFNptJUj2wzT re3io+jGsSVBdO1Cdc2xxOuCkHF4ifR7mRye+NapKkGIn+BvwfGT6fw2owC3Tidi6ZfY QPqu6c2ysGTWYhsE1SbDc43/DcWkP/fZbilqhOU/RVgR6QDLs3/DTFZVofYgkQg09lpu x3DbtiNvZspbskLfElob7oylz+U56P76nYySLHkXkGI+I/GOKlNhLFE8SlTladh/NTBI QRcd+06XcOiJu2lL6/XFRYOlNCoaajlrwl95U9L7ZlroBsbPR8SWn3QezB/r/bnaT24/ C/eQ== X-Received: by 10.180.198.226 with SMTP id jf2mr9167912wic.35.1403846056001; Thu, 26 Jun 2014 22:14:16 -0700 (PDT) Received: from [192.168.1.101] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id oy4sm18891052wjb.41.2014.06.26.22.14.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 22:14:15 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Yoav Nir In-Reply-To: <53AC9C22.30907@iki.fi> Date: Fri, 27 Jun 2014 08:14:12 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> <53AC9C22.30907@iki.fi> To: Tapio Sokura X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DxkEcd7R_OVMaX87QF7g-Ff4QLY Cc: tls@ietf.org Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 05:14:19 -0000 On Jun 27, 2014, at 1:18 AM, Tapio Sokura wrote: > On 25.6.2014 23:03, Joseph Salowey (jsalowey) wrote: >> [Joe] to simplify: >>=20 >> 1. In favor of removing renegotiation >> 2. In favor of removing renegotiation with the addition of rekey = facility >> 3. Not in favor of removing renegotiation=20 >=20 > I would choose 1 or 2. I wonder how many real-life usage scenarios > actually move enough data and/or over long enough time to need = rekeying > for real cryptographic reasons. Depends on what you mean by =93cryptographic reasons=94. As we=92ve seen = with other messages on this list, with AES-GCM you=92re fine to use the = same key for 2^64 or 2^48 records or packets. Either is a huge amount, = and I don=92t think we have scenarios that need that much data in a = single session. There is another reason, that I don=92t know if you=92d call = =93cryptographic=94 to rekey. It=92s similar to forward secrecy. If you = have a session that runs for days on the same key, an attacker can = record the session, then use some out of band means (like a warrant) to = force one side to hand over the key. Deleting the crypto key every hour = or so helps here. Yoav From nobody Thu Jun 26 22:28:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79CD1B315A for ; Thu, 26 Jun 2014 22:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uutq8aSoBO24 for ; Thu, 26 Jun 2014 22:28:21 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6101B2F1B for ; Thu, 26 Jun 2014 22:28:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0DA0E2AB299; Fri, 27 Jun 2014 05:28:19 +0000 (UTC) Date: Fri, 27 Jun 2014 05:28:19 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140627052818.GM16666@mournblade.imrryr.org> References: <9A043F3CF02CD34C8E74AC1594475C738DECF913@uxcn10-tdc06.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/32Cfp6k1OuciOkd3f8kUy_obLaU Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 05:28:22 -0000 On Thu, Jun 26, 2014 at 09:15:32PM -0700, Watson Ladd wrote: > > If we're going to do that then we need to have something like the > > AES/SHA-3/PHC competition to decide on a suitable curve (and whatever > > other deckchairs are going to be rearranged in TLS 1.3), not just take > > the first trendy thing that pops up. I have a great deal of respect for > > djb and he designs some really good stuff, but with the thought of having > > to implement huge amounts of new material for TLS 1.3 (after already having > > had to do it for 1.2) I really, really don't want to have to start again > > from scratch if, in two years' time, someone finds some issue in 25519 > > and/or the other bits that are being thrown in. Using the oldest SSL > > algorithms that come to mind, 3DES, DHE, and HMAC-SHA1, I'm pretty confident > > that I'm, as I quoted a cryptographer earlier, "unlikely to be surprised". > > Introducing several trendy new algorithms all at once gives me nothing > > like that level of confidence. > > If you don't want to support it, fine: implement only P-256. I don't think Peter's response is *that* unreasonable, we don't need to pick up our toys and move to another sandbox. There is perhaps room for differences of opinion on the subject of whether Curve25519 does or does not represent state of the art, or as-yet unproven novelty. I don't feel qualified to engage in debate on that issue. Rather, on the specific question of yet more curves of the same type as before, it seems to me that the advantage is likely negligible, and I don't see significant likelihood of widespread or timely adoption. At least with 25519, if it is deemed reasonably sound, there are multiple reasons why it might be preferable to the previous generation of curves. Whether we should expect more surprises than with traditional curve shapes, is a difficult question. The main plausible objection is perhaps that curves over fields with characteristic very close to a 2-power are somehow too special, and may admit non-generic attacks. Are there additional ways in which 25519 is substantially non-generic? -- Viktor. From nobody Thu Jun 26 23:46:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6C61B3165 for ; Thu, 26 Jun 2014 23:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Inbbb3StqugO for ; Thu, 26 Jun 2014 23:46:37 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72691B3168 for ; Thu, 26 Jun 2014 23:46:36 -0700 (PDT) Message-ID: <53AD134E.9010903@akr.io> Date: Fri, 27 Jun 2014 07:46:38 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <53AC97B8.2080909@nthpermutation.com> In-Reply-To: <53AC97B8.2080909@nthpermutation.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nxg68ZWrdwzpoy4-XXnICovtUaM Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 06:46:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 26/06/2014 22:59, Michael StJohns wrote: > There's been a small but vocal minority agitating for the adoption > of Curve25519 for use in TLS (and other IETF protocols). CFRG have selected Curve25519 as the preferred elliptic curve for use in IETF protocols, as Rich has pointed out. That is because it is very, very good: it is 8 years old, extremely fast, and simpler and faster to implement in constant-time, with _far_ fewer special cases, than any Weierstrass-form curve. > possible IPR issues "Total number of IPR disclosures found: 0" As per IETF/IRTF IPR policy, kindly _reference_ any relevant IPR you are aware of. To the best of my knowledge, Curve25519 is patent-free: all relevant patents have expired. No-one has stated anything to the contrary, as far as I can see, including those at Certicom who are on CFRG (who would have had to have raised anything relevant, I gather?). > definite infrastructure issues (e.g. no off the shelf, commercial > hardware or software AFAIK), Please note the extremely liberal license of the very high quality open-source software implementation in NaCl. It is public domain: you can take it and use it right now if you want, with zero IPR issues. Hardware implementations always lag new technologies: ARMv8 only just got SHA-256, and Intel and AMD don't have anything which specifically accelerates any crypto except AES. This is alright, as the software performance of Curve25519 is extraordinarily good. It is of course unreasonable to demand implementations exist _before_ specifications. However, adoption has already begun (OpenSSH, Tor, OpenBSD, Chromium), and perhaps in some places that may surprise you (the Apple iPhone!). > documentation issues (not the base curve, but how to incorporate > curve data into certificates Curve25519 can be used with signatures, in twisted Edwards form: please see Ed25519. That has not yet been codified with CFRG or the PKIX WG, as far as I know, but exists and works very well (OpenBSD uses it, for example): discussion is still ongoing about details, and probably needs a refresh/reminder over there. The use of Curve25519 with ECDHE is covered by the josefsson draft, as you may remember, back from September 2013: > [Re: potential trapdoors in NIST curves] Already very widely discussed, but obviously not relevant to Curve25519. I know of no backdoors in NIST P256 (secp256r1) or P384 (secp384r1); but yes, the possibility one exists is alarming, and investigations into the curve-generation process still leave things remarkably murky. > how about we just generate new curves: With blackjack and hookers? :-) Perhaps the paper at would be of interest to you. I would recommend reading it before proceeding any further with that discussion, especially down to the "Notes on terminology and security" section. Brainpool has already generated a set of 'random' primes, but random primes are extremely slow to implement - and in the case of Brainpool, the 256-bit curve has extremely unfortunate lack of twist security, so any implementation that tries to skip validation is in really big trouble. By adopting Curve25519, we have the opportunity to take advantage of what we've learned about EC _since_ the engineers at Certicom generated the NIST curves. Obviously, I'm part of the 'vocal minority' here, as I'm planning to use it very soon, because it makes ECDHE both secure and really, really fast - and that's a huge win for both TLS 1.2 & TLS 1.3! - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTrRNNAAoJEOyEjtkWi2t6szIP/3/3HjSf7gI/JVNi1MwOW88L Aw1HirLf3cfCEANlv5GCvWhf8873K82qySgpcqRUhp9DiZrSFiGnUNKjFpcY3tp5 Ph94t6ji0f/x8rBHWGM5FutNqUKf3Hu/Mx4e9AQjRs2jEZwkrKlpKucFJbGjadL7 DEnbDZoAN2veYj93Z0rbG8mqhyVZmapoIGoaR8k0fGO6M0ziLS2X52npHt+z7q56 YzED1ta7DCkjbP0q2Qhi/hBDlOxj+p+MmuOt2NGkRqLqHP3Djr8E16KlFaB90KJW uOCmZ/jYU2kS86FxXPHzpdkGeOgQgN6b9noARLbv1GkydSuRvZst9t5BTiYVPd8G PQSTmLiMpvXh8iZ7CKXEb7SRPbqAWkTrIaSkFWJ3HThVotor0wU//x6ARozsGUI1 vtmjTIOaQlGpv0ZYWaYosUY3DE9t+OTcFoBxsknmiiDLDQg/CzknWiELQSf4IVXH b01+uzGnZv2INk1AMW+0M4AEZlKVRQnpDM/yhHWII0iAQqFEcA3CcBUw6GCjpaMv xqymfirQsfDjT1vkkEjN5L4grHYLIqPLkydOYucPlXwFD+q2cRoq4kh1ZKZUWMVu r3Bv68jXcQzNXUz0EsgKKj1ao/KEXlFi1iT3ub1vh6kQrkqpQyh2Few6Fpq/RDPs awVbNQgAz+44Rb7/vvGX =CjJs -----END PGP SIGNATURE----- From nobody Fri Jun 27 01:14:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDB61B278A for ; Fri, 27 Jun 2014 01:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE_Q4Z0nRNzn for ; Fri, 27 Jun 2014 01:13:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F931A02DE for ; Fri, 27 Jun 2014 01:13:29 -0700 (PDT) Received: from [192.168.131.143] ([80.92.115.50]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MFu0Y-1WvSvx0fhe-00EtBv; Fri, 27 Jun 2014 10:13:27 +0200 Message-ID: <53AD27B4.2060901@gmx.net> Date: Fri, 27 Jun 2014 10:13:40 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alyssa Rowan , tls@ietf.org References: <53AC97B8.2080909@nthpermutation.com> <53AD134E.9010903@akr.io> In-Reply-To: <53AD134E.9010903@akr.io> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="60LrpnRTekCU1C8mfoQXhuj8m8oR9LH9l" X-Provags-ID: V03:K0:yjRufLa2z/RupyRzdWZgSitVgPCoQeCOpDWOj7Fj8ExmFnfjYuF HjwdzZhq8Okyvl3/h8jelfu3vugQ8v4WlD9kMzuTKak9b1hkU+XYBhgIYAyfND3R1iPDhGN TGh3Ry1wHBpZH1gt1S41ffqXHuJSm2YZb5E9zbbryQX57rkNnni68FrfTLe7NScQ+h4oazb 7jMQeFFVBfR78ERitSHvA== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VBIVA65r-qyaX6VoGZwQqLzIEVs Subject: [TLS] Hardware Implementations .. Re: On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 08:13:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --60LrpnRTekCU1C8mfoQXhuj8m8oR9LH9l Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It might be worth noting that many boards have dedicated chips for cryptographic operations and even entire protocol stacks. This, however, does not mean that they are hardware implementations. They are software implementations running on separate chips. For embedded systems the benefit of such approach is that the vendor of the board can make the life of the embedded developer easier since they do not have to search for a library and the runtime of the code can be better controlled (particularly relevant if there are some real-time related requirements to consider). Based on the discussions at the IRTF interim meeting a little while ago I took the Curve25519 code and ported it to mbed (the online development platform ARM provides, see https://mbed.org). I wanted to know how long it takes to generate key pairs since this is one of the most performance-demanding operations. To my surprise it was rather fast: - 0.278821 seconds for generating a Curve25519 key pair on a Cortex M0 (FRDM-KL25Z, 48MHz) https://mbed.org/handbook/mbed-FRDM-KL25Z - 0.047394 seconds for generating a Curve25519 key pair on a Cortex M3 (LPC1768, 96MHz) https://mbed.org/platforms/mbed-LPC1768/ (Note that I did not include the calculation of the random numbers in those numbers since it will depend on a variety of factors, including the hardware capabilities of the used board.) These are processors used in the Internet of Things environment. I will have to do more tests using different processors and different curves [but I have to start somewhere]. On 06/27/2014 08:46 AM, Alyssa Rowan wrote: > Hardware implementations always lag new technologies: ARMv8 only just > got SHA-256, and Intel and AMD don't have anything which specifically > accelerates any crypto except AES. Ciao Hannes --60LrpnRTekCU1C8mfoQXhuj8m8oR9LH9l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTrSe0AAoJEGhJURNOOiAtMxUH/jotcxs/lEgSLEoOUIxQGC5p k1t1zzVqxD0CxhYxgNCLMfd8fZhyUzt4iLeQ4301A47NQOr+Gl4zSPFqSMVHD3CP zlX6bkSnNEue7ul0MkZyISmRu+1GOjLQN7hyyZyNPc7hlapjDZJWPZkRcgnHy4nJ kKaJIqdEvdJk0EVf3i31mPPujVOd+RmOZ9ZYXf0hjeCfRdJItV7x3+pssS/Rytcm HEB9Tqox4ryEGcki3gfHpW8ThWSOre9s5gS2nIL7lcGn5CTWKJP9boNiHQAecWYi /JNl+fBy30i6Nq30NvDUaWOONhv4YuqfdgMmgaglG0RrZIKnfJ6OGqn0zNb80Hc= =Ryct -----END PGP SIGNATURE----- --60LrpnRTekCU1C8mfoQXhuj8m8oR9LH9l-- From nobody Fri Jun 27 01:21:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB461B2CDA for ; Fri, 27 Jun 2014 01:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIHyKHmjAjyO for ; Fri, 27 Jun 2014 01:21:03 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6EA41B2CCA for ; Fri, 27 Jun 2014 01:21:02 -0700 (PDT) Received: from secworks82.gotanet.se (unknown [62.80.223.82]) by mail.frobbit.se (Postfix) with ESMTPSA id EAA801FD5F; Fri, 27 Jun 2014 10:21:00 +0200 (CEST) Message-ID: <53AD296C.40204@secworks.se> Date: Fri, 27 Jun 2014 10:21:00 +0200 From: =?ISO-8859-1?Q?Joachim_Str=F6mbergson?= User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Hannes Tschofenig References: <53AC97B8.2080909@nthpermutation.com> <53AD134E.9010903@akr.io> <53AD27B4.2060901@gmx.net> In-Reply-To: <53AD27B4.2060901@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tHcOr48oamnDuVRLfuTnkzrh_60 Cc: "tls@ietf.org" Subject: Re: [TLS] Hardware Implementations .. Re: On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: joachim@secworks.se List-Id: "This is the mailing list 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 Jun 2014 08:21:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Aloha! Hannes Tschofenig wrote: > Based on the discussions at the IRTF interim meeting a little while > ago I took the Curve25519 code and ported it to mbed (the online > development platform ARM provides, see https://mbed.org). > > I wanted to know how long it takes to generate key pairs since this > is one of the most performance-demanding operations. To my surprise > it was rather fast: > > - 0.278821 seconds for generating a Curve25519 key pair on a Cortex > M0 (FRDM-KL25Z, 48MHz) https://mbed.org/handbook/mbed-FRDM-KL25Z > > - 0.047394 seconds for generating a Curve25519 key pair on a Cortex > M3 (LPC1768, 96MHz) https://mbed.org/platforms/mbed-LPC1768/ Great work and information! Have you done a write-up of the results? I'm very interested in info on the code size and data memory during operation. > (Note that I did not include the calculation of the random numbers > in those numbers since it will depend on a variety of factors, > including the hardware capabilities of the used board.) So how did you do the random generation? Fixed values or some other mechanism? - -- Med vnlig hlsning, Yours Joachim Strmbergson - Alltid i harmonisk svngning. ======================================================================== Joachim Strmbergson Secworks AB joachim@secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJTrSlrAAoJEF3cfFQkIuyNOy4P/35il82TWxRBZwC3XrFGoRIw M7FqFmnmgXibjU1GxDXvYAuwTXEyY27vNooPZVBzXVtp1Y834MGQjPwCEec2aYaL /LanQrxoOiwOFLBSYahn867FiM2Trc/w0gyVJ+tOI9tmp6FHbzWzTUHnCbCGnOeS PDh1Zy39/QEHElXc8FAJGJTf7c+W/bv3YbTBJC3E0r/g2NR94Okg0AWKYFQbDerO Ac+DMIYIBy3mlz0vzrIOs2f43fcWHitZKGhZ/5iygY9Qzg1LG59oygr0lSTvIp5H GmhUVYmi8Rhw0VzcQbxaJnivWmatR2kC6aRka4n0Ifxr7dkj70mIm9yOiCxrBJse fnfhXPO97KkyIV3dCRT9aVTBcDIqeMahQ5Dp+WLLNmE8d4SXgQU0h553Xutygnft GtB4SaE+CIJNN3Df+d9I1JFTWZicKizs+UeRl2u8J0B8LH0oqgNwTnLAswkyhyZH nWYXBZjp3lFE+IuoolqcpYVwWlO17ocVLmw1a0+M3k9zq1g8gAGa+yPMY6CvGcyP 58RDVHx+sfWH0O+DWsX90odiqy7cIfLSfk2ECA9xHTFmoQ0N9oWS/Nh0rfnZ3Ukq KxwQgFXNBcV45229Cl1LeavDkqc0m/oL0ilLxMT8L78spPoTfbz9J9GBMV4JNRDn cuf6ieDceHSnQ+1h5OD5 =QKHI -----END PGP SIGNATURE----- From nobody Fri Jun 27 01:38:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818D41B2F33 for ; Fri, 27 Jun 2014 01:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNvHQBxRhpFr for ; Fri, 27 Jun 2014 01:38:55 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C799B1A0215 for ; Fri, 27 Jun 2014 01:38:55 -0700 (PDT) Received: from [10.32.64.173] (31-221-87-78.cust-31.exponential-e.net [31.221.87.78] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s5R8conQ086693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 27 Jun 2014 01:38:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 31-221-87-78.cust-31.exponential-e.net [31.221.87.78] (may be forged) claimed to be [10.32.64.173] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: <53AC97B8.2080909@nthpermutation.com> Date: Fri, 27 Jun 2014 09:38:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <186372F4-EEBF-4EE8-A617-A7503EC1FBB6@vpnc.org> References: <53AC97B8.2080909@nthpermutation.com> To: "tls@ietf.org" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uWgWTY4lHlrgQ8SZK7FhK6th0ps Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 08:38:56 -0000 -1 On Jun 26, 2014, at 10:59 PM, Michael StJohns = wrote: > There's been a small but vocal minority The fairly strong support for other curves from the CFRG to refutes this = statement. --Paul Hoffman= From nobody Fri Jun 27 01:52:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB8B1B3177 for ; Fri, 27 Jun 2014 01:52: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, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6M6iwU9YO9Y for ; Fri, 27 Jun 2014 01:52:11 -0700 (PDT) Received: from eu1sys200aog102.obsmtp.com (eu1sys200aog102.obsmtp.com [207.126.144.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9531B2F33 for ; Fri, 27 Jun 2014 01:52:10 -0700 (PDT) Received: from mail-wg0-f48.google.com ([74.125.82.48]) (using TLSv1) by eu1sys200aob102.postini.com ([207.126.147.11]) with SMTP ID DSNKU60wttwxVBPD5HscWniPM5SBNvjw3A6v@postini.com; Fri, 27 Jun 2014 08:52:10 UTC Received: by mail-wg0-f48.google.com with SMTP id n12so4853820wgh.31 for ; Fri, 27 Jun 2014 01:52:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=CI+21M3ZWdSO53S3OSVXlTW6wE8wz9PAgh+D3VQOoAA=; b=e9kIUSb8CJ0SahfNycS3fxYvlWFLPjJna+225bwaIQefCunKVsldA8O+uEl02zOFHI AFhP75vTc8aH6sGwUKXeOt2Nqht0+oA14PUZc5kiOmO5Ab9HaRaG26SQetGaOb9+8eMy N+u8xbn0PCB01I5kTVJkRMn3lSagaxar6q70gUvvW0l+ZBmpajoKT+T+C7lD0sW9QM3f rZsNrNuBPEWSl9By8L4629zbluStVlhjrXI1zF22VjxCctg6WjJph+n9FflhcYdQtcqZ nk0qtabBBdWa9IO8tkI5e3uuOjS7vht26sOigDDAx9NR40qsB465xaeWnPlPGjO4pF7/ D1lw== X-Gm-Message-State: ALoCoQksHeklrqKNzp9MTOQ6uT8dv22njLzwBPaf56YY+m/y8X0JT0QuDC3HgqstMoDSfpnpLSSCiqHHAyuN4eccmE1PaI8ceSQdX/OJIwyhxfz7eIiPM44KdIn/2Lbm1MAxjxQ9c4pK X-Received: by 10.194.62.110 with SMTP id x14mr23919945wjr.15.1403859125866; Fri, 27 Jun 2014 01:52:05 -0700 (PDT) X-Received: by 10.194.62.110 with SMTP id x14mr23919933wjr.15.1403859125769; Fri, 27 Jun 2014 01:52:05 -0700 (PDT) Received: from [192.168.1.242] ([95.144.51.46]) by mx.google.com with ESMTPSA id fb15sm34061777wid.23.2014.06.27.01.52.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 01:52:05 -0700 (PDT) Sender: Nigel Smart Message-ID: <53AD30B6.6000509@cs.bris.ac.uk> Date: Fri, 27 Jun 2014 09:52:06 +0100 From: Nigel Smart User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0p9w7HB7lLcBIR_U1o5ymgg6KsE Subject: Re: [TLS] On Curve25519 and other possibilities (e.g., ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 08:52:13 -0000 I think the "hype" around the possible issue re random number choice in the NIST curves is just scare mongering etc. The argument against the NIST curves that they are easy to poorly implement is also I think slightly a bit of scare mongering. For Curve25519 you use a non-standard DH exchange (to some extent), it is not of prime order (bringing in more issues), cannot be directly used for standard signatures (modifications do exist), and the code to use it is not the same as for other curves (thus creating code bloat, issues for programming error etc). Thus in my view using Curve25519 would create the same problems which the proponants are trying to solve. Saying people can just use NaCl is also a bit of an issue. I doubt everyone should base there security on a single library (no matter who wrote it). We have seen the issue with OpenSSL that just because something is open source does not mean many eyes have looked at it. And I suspect more eyes have looked at OpenSSL than have looked at NaCl (of course the eyes looking at OpenSSL have probably mainly rolled). My recommendation would be to stick to i) Prime field curves in Weierstrass form with A=-3 ii) Pick curves with prime order groups (no subgroups) iii) Pick curves used in other standards so as to aid interoperability/code re-use) Now the NIST curves meet this spec, as will others. Nigel -- Prof. Nigel P. Smart | Tel +44 (0)117 9545163 Computer Science Department, | Fax +44 (0)117 9545208 Woodland Road, | Email nigel@cs.bris.ac.uk Bristol, BS8 1UB, UK | http://www.cs.bris.ac.uk~nigel From nobody Fri Jun 27 01:58:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7C71B2F2D for ; Fri, 27 Jun 2014 01:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fizi-oB8rNlX for ; Fri, 27 Jun 2014 01:58:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391501B2AF4 for ; Fri, 27 Jun 2014 01:58:32 -0700 (PDT) Received: from [192.168.131.143] ([80.92.115.50]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Mb31L-1XGCWU4AcF-00KhCh; Fri, 27 Jun 2014 10:58:30 +0200 Message-ID: <53AD3248.8000100@gmx.net> Date: Fri, 27 Jun 2014 10:58:48 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: joachim@secworks.se References: <53AC97B8.2080909@nthpermutation.com> <53AD134E.9010903@akr.io> <53AD27B4.2060901@gmx.net> <53AD296C.40204@secworks.se> In-Reply-To: <53AD296C.40204@secworks.se> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7LFJwpuuAFEXdqoUkpjihQPGNXHadHDqo" X-Provags-ID: V03:K0:1WhwaUNaJjidZEt+UtoyErHepavcKmGHYLl+4aI8h4CAGyNWCJt 7ilsDhhHZiM9RpRBdRUAA+d2bUQEg3yNBQrlpFnWIHGnuZKbzeZWTGHrEk153XYGqSQL++z WQf2uZ3s3KRwBuTLWUZsbBiWiFk7aNxigyhA8Kl7mCshYl3FdnDqfF26LOfbDtgi9Exp2Xk XElzV1yKH2G9SNAlaDimQ== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/by_LQTAoaDrbApkCqKQVyvYgxzQ Cc: "tls@ietf.org" Subject: Re: [TLS] Hardware Implementations .. Re: On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 08:58:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7LFJwpuuAFEXdqoUkpjihQPGNXHadHDqo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Joachim, On 06/27/2014 10:21 AM, Joachim Str=F6mbergson wrote: > Aloha! >=20 > Hannes Tschofenig wrote: >> Based on the discussions at the IRTF interim meeting a little while >> ago I took the Curve25519 code and ported it to mbed (the online >> development platform ARM provides, see https://mbed.org). >=20 >> I wanted to know how long it takes to generate key pairs since this >> is one of the most performance-demanding operations. To my surprise >> it was rather fast: >=20 >> - 0.278821 seconds for generating a Curve25519 key pair on a Cortex >> M0 (FRDM-KL25Z, 48MHz) https://mbed.org/handbook/mbed-FRDM-KL25Z >=20 >> - 0.047394 seconds for generating a Curve25519 key pair on a Cortex >> M3 (LPC1768, 96MHz) https://mbed.org/platforms/mbed-LPC1768/ >=20 > Great work and information! Have you done a write-up of the results? I'= m > very interested in info on the code size and data memory during operati= on. No, I haven't created a write-up yet. I believe I should make take a look at other curves first to have a reasonable comparison. I will try to put something together for the upcoming IETF meeting (since it might be relevant to the LWIG working group). (Code size and RAM size is a bit tricky since there is some other stuff that need to be compiled into the code to make it useful.) >=20 >> (Note that I did not include the calculation of the random numbers >> in those numbers since it will depend on a variety of factors, >> including the hardware capabilities of the used board.) >=20 > So how did you do the random generation? Fixed values or some other > mechanism? This is probably more an issue of embedded systems (rather than the TLS working group in general) but I had to put fixed values in there since I didn't want to rely on the library that some other person wrote and a hardware random number generator was only available with another board but the core mbed libaries do not yet offer the API. In a nutshell, I used fixed values. Ciao Hannes --7LFJwpuuAFEXdqoUkpjihQPGNXHadHDqo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTrTJIAAoJEGhJURNOOiAt8GkH/2b2fYDzKZ7SQVZhE5hVgRy7 kbq4ziqU9F5PNAfCWYpCLrBXFvVs8AWYgr00PYhSoLn+QV187eiOJkFIntTDtI41 N1PSeN0bVPb6RuuJ5F7ZFH+R/6FsQtffPG5B/esDLuBN1TVf5JvU/mLNlpaAIXlF 2cIjxAHtBm9uEO2wBIAG+Z0tcdrR9JcpVZ5dcixhJBBKTrwKPRswtPke0txd8Ov0 7MZlF+l4C78J3q0diSxC7ATnUdFIGlvjbB4Yj2W7Z0dil52QoPxH5QFzTsg8cbbb ejRELxFgC6jHzl3njePTWsgc5qdZVj5C4jiZ7ZKbqtOlA/7W81q+BOhdOxf1PBw= =FSC8 -----END PGP SIGNATURE----- --7LFJwpuuAFEXdqoUkpjihQPGNXHadHDqo-- From nobody Fri Jun 27 04:35:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558531B2F6C for ; Fri, 27 Jun 2014 04:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P70YQXxJo37z for ; Fri, 27 Jun 2014 04:34:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2A31B3170 for ; Fri, 27 Jun 2014 04:34:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C2035BE50; Fri, 27 Jun 2014 12:34:41 +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 n1lNm5lZqp3Y; Fri, 27 Jun 2014 12:34:41 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9ED50BE4D; Fri, 27 Jun 2014 12:34:41 +0100 (IST) Message-ID: <53AD56D2.7060200@cs.tcd.ie> Date: Fri, 27 Jun 2014 12:34:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Eric Rescorla , Michael StJohns References: <53AC97B8.2080909@nthpermutation.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jIi1KXUDzbiSy4Hq9YtFGZIjMOQ Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 11:34:58 -0000 Hiya, On 26/06/14 23:10, Eric Rescorla wrote: > Also, this seems like a bigger topic than TLS. Perhaps the > AD should sponsor a discussion in SAAG? Yes, this is not TLS specific, though its probably not really possible to have no discussion of it here since TLS is likely the first large "customer" for 25519 in the IETF, if the WG choose to go that route. CFRG is definitely a better location for any detailed crypto discussion, i.e. for all algorithm internals. As noted before there was no indication from CFRG at the interim that 25519 is problematic. That's not quite as ringing an endorsement as has been represented here, but I figure cryptographers are going to be like lawyers for this - they'll never all agree an algorithm/curve is perfect;-) So its also possible CFRG might come up with more curves that they also like and that's fine. If someone wants more curves generated, CFRG is the place to chat about that and not here. But at that interim 25519 was definitely considered ok for use in IETF protocols - there was no dissent when I (more than once) directly asked that question and said that I wanted to hear dissent should there be any. The proximate cause for my question was allocating a codepoint for ed25519 for ssh, which has happened and the associated draft has completed IETF LC, also without any criticism of the use of 25519. I'm waiting for an updated I-D on that before putting it on an IESG telechat for approval, but my reading of the IETC LC was that there were no cryptographic issues raised at all. That IETF LC is also evidence that the IETF consider 25519 is ok. That said, when/if TLS decide to use it, I expect there'll be more interest in the IETF LC for that, so we'll see what happens then. For now anyway, my interpretation is that we don't have any cryptographic (nor declared IPR) reason to not use 25519 if a WG choose to want it. However, there is some more work to be done to document that so it can be used by WGs. I think that's being done by CFRG though, but if not, or if there are more generic bits that need discussion then saag seems like a fine list for that. If you think such a discussion on saag is needed then please ping me offlist to explain exactly what we need to discuss there (since I'm not clear about that). In the meanwhile most of this thread does seem to me to better belong on the CFRG list and is basically a distraction for TLS. Also, I have to say the language in Mike's original mail was, at best, unfortunate, e.g. "small but vocal minority agitating" is not likely to kick off a calm reasoned debate, and is definitely not going to help the TLS WG keep focused on its work so I really hope folks don't respond in kind, and if the chairs want to loudly stomp on threads with such language (regardless of source and mostly regardless of topic) they have my full backing. Cheers, S. From nobody Fri Jun 27 04:52:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1AC1B2B12 for ; Fri, 27 Jun 2014 04:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXuBTvnOb4fQ for ; Fri, 27 Jun 2014 04:52:46 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7371B3180 for ; Fri, 27 Jun 2014 04:52:45 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s5RBqeqU000559; Fri, 27 Jun 2014 07:52:40 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "'stephen.farrell@cs.tcd.ie'" , "'ekr@rtfm.com'" , "'msj@nthpermutation.com'" Thread-Topic: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, Thread-Index: AQHPkf5MsZ81bnB1ZUS9pvv4HYn3bQ== Date: Fri, 27 Jun 2014 11:52:40 +0000 Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC16B433@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: <53AD56D2.7060200@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.34.14.22] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-27_03:2014-06-27,2014-06-27,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406270123 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kjqhH5OGmfzNqH_NjrhSqk-XKdw Cc: "'tls@ietf.org'" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 11:52:49 -0000 All good points! I'd like to underscore that verifiably-random generated curves are likely t= o provide worse performance than, e.g., 25519 - but have a better chance of= not bringing any cryptographic surprises later on. And in the (unlikely) c= ase one of them does - the replacement path would be far simpler. -- Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory Cell: (339) 223-5363 244 Wood Street Email: Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ =20 MIT LL Root CA:=20 DSN: 478-5980 ask Lincoln ext.1638 ----- Original Message ----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Friday, June 27, 2014 07:34 AM=0A= To: Eric Rescorla ; Michael StJohns Cc: tls@ietf.org Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ie= tf384p, ietf521p,=20 Hiya, On 26/06/14 23:10, Eric Rescorla wrote: > Also, this seems like a bigger topic than TLS. Perhaps the > AD should sponsor a discussion in SAAG? Yes, this is not TLS specific, though its probably not really possible to have no discussion of it here since TLS is likely the first large "customer" for 25519 in the IETF, if the WG choose to go that route. CFRG is definitely a better location for any detailed crypto discussion, i.e. for all algorithm internals. As noted before there was no indication from CFRG at the interim that 25519 is problematic. That's not quite as ringing an endorsement as has been represented here, but I figure cryptographers are going to be like lawyers for this - they'll never all agree an algorithm/curve is perfect;-) So its also possible CFRG might come up with more curves that they also like and that's fine. If someone wants more curves generated, CFRG is the place to chat about that and not here. But at that interim 25519 was definitely considered ok for use in IETF protocols - there was no dissent when I (more than once) directly asked that question and said that I wanted to hear dissent should there be any. The proximate cause for my question was allocating a codepoint for ed25519 for ssh, which has happened and the associated draft has completed IETF LC, also without any criticism of the use of 25519. I'm waiting for an updated I-D on that before putting it on an IESG telechat for approval, but my reading of the IETC LC was that there were no cryptographic issues raised at all. That IETF LC is also evidence that the IETF consider 25519 is ok. That said, when/if TLS decide to use it, I expect there'll be more interest in the IETF LC for that, so we'll see what happens then. For now anyway, my interpretation is that we don't have any cryptographic (nor declared IPR) reason to not use 25519 if a WG choose to want it. However, there is some more work to be done to document that so it can be used by WGs. I think that's being done by CFRG though, but if not, or if there are more generic bits that need discussion then saag seems like a fine list for that. If you think such a discussion on saag is needed then please ping me offlist to explain exactly what we need to discuss there (since I'm not clear about that). In the meanwhile most of this thread does seem to me to better belong on the CFRG list and is basically a distraction for TLS. Also, I have to say the language in Mike's original mail was, at best, unfortunate, e.g. "small but vocal minority agitating" is not likely to kick off a calm reasoned debate, and is definitely not going to help the TLS WG keep focused on its work so I really hope folks don't respond in kind, and if the chairs want to loudly stomp on threads with such language (regardless of source and mostly regardless of topic) they have my full backing. Cheers, S. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Fri Jun 27 07:19:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976FC1B30F5 for ; Fri, 27 Jun 2014 07:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.753 X-Spam-Level: X-Spam-Status: No, score=-0.753 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVfLvIBoV8bQ for ; Fri, 27 Jun 2014 07:19:01 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (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 C892A1B3020 for ; Fri, 27 Jun 2014 07:19:01 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 80BD91EE4C; Fri, 27 Jun 2014 14:19:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1403878740; bh=xnUKDSwA8xcvHXwVfQv39hpPfYuuQ9FU6EpfPOCtgVI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QU18jxHd2nqvid05t7hHu2Nf8DuQ+vayGxLt7O66tM9mqQCSl4Z9maEMSqM9Homi7 35gWXnqKaXWDTdzAP+Ir26UW/x1OyL6/brnL/7m32Ksoto59bCAkwUHcWS34wiXSpa xye5FhOwfEaXAv1vgFUSKVjxFPFvWDOjTb9Xt5xg= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 1E0086001E; Fri, 27 Jun 2014 14:13:48 +0000 (UTC) From: James Cloos To: In-Reply-To: ("Colm =?iso-8859-1?Q?MacC=E1rthaigh=22's?= message of "Wed, 25 Jun 2014 14:45:31 -0700") References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 27 Jun 2014 10:13:23 -0400 Message-ID: Lines: 25 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:140627:tls@ietf.org::x+yrcGm5smFxmBhv:0000J4rOC X-Hashcash: 1:30:140627:colm@allcosts.net::n/ORZwMfNUIMzFGc:0000000000000000000000000000000000000000000Vg7GU Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YELsIOrS-tqQNCLlZgVFIpSI8Vg Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 14:19:07 -0000 >>>>> "CM" == Colm MacCrthaigh writes: CM> This too seems like a strawman; SSH does not use TLS, and CM> telnet-over-tls is not common. The requirements of securing CM> interactive logins differ enough from TLSs features that those CM> applications have found other solutions entirely. So what about something like an sctp connection between switches actively carrying hundreds or thousands of concurrent calls, each on a sub-socket. Even with the media following a different path, the signaling has to remain up. I presume xmpp/tls/tcp/ip works similarly. That is a lot of state to have to redo. If tls1.3 drops rekeying established sockets, then one reasonably can predict that its adoption will be limited enough that any security benefits it has over 1.2 will be, mostly, for naught. Whether rekeying requires renegotiation should be the question. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri Jun 27 09:11:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E631B3010 for ; Fri, 27 Jun 2014 09:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.652 X-Spam-Level: X-Spam-Status: No, score=-7.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEFml8pdPOzT for ; Fri, 27 Jun 2014 09:10:53 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797CD1B2C07 for ; Fri, 27 Jun 2014 09:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1403885454; x=1435421454; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Gz69VMKFKv4N8BPSRcXmV+fhMvJvfSAmk1x/3/gnUvU=; b=dDdWUUHqmWqdzeg6J8hr0SMppgfLOcObswx8RbxsReArLcHy3xOCz18o 1urGLPhErK9Z5R3kBKJnOAO5aA84ghZ+Fm3lVWd+lENh68xmNpixKF4hm +JCimMmkE5BqSKYFEO9cQufzKXWesAs4dvsqMEEFrXyK4pW6JYL043VU2 s=; X-IronPort-AV: E=Sophos;i="5.01,561,1400025600"; d="scan'208";a="119975063" X-IPAS-Result: AvsEAKeWrVPAqArr/2dsb2JhbABahDmqPQEBAQEBAQaZcAGBIXWEAwEBAQECAR0dPwULAgEIIhQQMiUCBA4NE4gfxBcXhWSIcDEHgy2BFgWWRptUgjA Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 27 Jun 2014 16:10:52 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Fri, 27 Jun 2014 09:10:50 -0700 From: Brian Hamon To: Martin Thomson Thread-Topic: [TLS] Call for Consensus on removal of renegotiation Thread-Index: AQHPkKQi2ibdHwQZAU+UoLazXGbTxJuCn8+AgAAVNgCAATV4AP//97oQgAB9MwD//4sSAIABNxcg Date: Fri, 27 Jun 2014 16:10:49 +0000 Message-ID: References: <20140626143044.F3B0C1AD68@ld9781.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9R3XENg_w6WGEmfbo3C0nAUnfzA Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 16:10:55 -0000 Unless someone makes a case otherwise, I think that the answer to my questi= on is that client authentication (assuming Martin's proposal is accepted) i= s either required from initial ServerHello or unavailable? This may be where the WG wants to take TLSv1.3, and from an OSI layering pe= rspective might be the best result. After all, if the application is making= the decision on whether to require client authentication, then client auth= entication is best addressed at the application layer. If so, then perhaps = this committee should eliminate client authentication completely from TLS. > My main concern is that if your proposal is accepted, what is the solutio= n for a server that must examine=20 > some ApplicationData in order to determine if client authentication is re= quired? =20 From nobody Fri Jun 27 09:25:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8721B2992 for ; Fri, 27 Jun 2014 09:25:56 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09ajSPR7WHkq for ; Fri, 27 Jun 2014 09:25:55 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9D41B27EC for ; Fri, 27 Jun 2014 09:25:54 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id x48so5482930wes.23 for ; Fri, 27 Jun 2014 09:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5n3epwE9vju/exJAzIqPj6WcDaMAiL0q2c+eoYRtI2o=; b=RZcB34+OCS8YbywzwCx1OY+2uqov3JXu7T6mzCG4DrFa2fuJPyTdZh8q8gntqznkjL ewx7islhwZAx/SsoHKxBfBN0KhFIlfoVhqcyEaf8oPlqOgibKjzOrom0+0l6j0pWDEmN UqUO2FTFElcOzcrNYd2K5Z0ooW6/cc72BIvJBaSWOfB9iaEz2A3So28XZwhJp4xhhyjw TDceHCUnUvaBs41jz6XxhejWkHK21QPO849xFqXN/NisaPXuFRSDU4qi/HtEvQLWzwh8 VW9orlSuYDJyEWzJ3LnhrpjoRZmg1TXjWZHbUPsASA7QGeg4v+ptJgGmfsTEXId9Jt3/ wmuA== MIME-Version: 1.0 X-Received: by 10.180.14.162 with SMTP id q2mr13048331wic.54.1403886353372; Fri, 27 Jun 2014 09:25:53 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Fri, 27 Jun 2014 09:25:53 -0700 (PDT) In-Reply-To: References: <20140626143044.F3B0C1AD68@ld9781.wdf.sap.corp> Date: Fri, 27 Jun 2014 09:25:53 -0700 Message-ID: From: Martin Thomson To: Brian Hamon Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0RRhU_mb3pwcGjZkeJI43p_zbFU Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 16:25:56 -0000 On 27 June 2014 09:10, Brian Hamon wrote: > Unless someone makes a case otherwise, I think that the answer to my question is that client authentication (assuming Martin's proposal is accepted) is either required from initial ServerHello or unavailable? There are other options: 1. TLS 1.3 could allow clients to authenticate unilaterally (i.e., not require the CertificateRequest message to be sent before sending a client cert, or mandating that servers provide a CertificateRequest always). 2. Authentication might be provided with a separate type of control message. This has been discussed. And any combination of the above, depending on what we think best fits the complexity/functionality trade-off. Personally, I like the idea of doing option 1 here. With confidentiality protection for handshake messages, it could make client authentication considerably more accessible than it was in previous TLS versions. > [...] perhaps this committee should eliminate client authentication completely from TLS. I haven't seen much interest in doing that. My proposal still relies on TLS providing a binding to client credentials. From nobody Fri Jun 27 09:29:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28641B29B3 for ; Fri, 27 Jun 2014 09:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGaCK1IFGAyB for ; Fri, 27 Jun 2014 09:29:27 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19EFF1B2960 for ; Fri, 27 Jun 2014 09:29:26 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id bs8so3126177wib.7 for ; Fri, 27 Jun 2014 09:29:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QwRADSwgB38GtCm8rIDXIPsTBqTTwNVasKnfUV0kl9s=; b=mKx7W7p9/I9u1M9m+bpMLroUSnn3eKcgQXaLkuQWv67l+syhSgaVCOaNk+Bvj+Ynts 1GfhfQvTafblSkmesCOoivRd08R7FFOOKljMpiCyTpwy1AdlyX2tXMls9uH8fQJ/ARnW ex7Zd8yBf75itvLpwiuE1rC+cxJr8n813cSwI7+IZpDH9zMpFC5RG3GUcLDuCGkv88UP PFGcBd2quoGu0fPLYVHx/7Y6iOdvktoafAm/R93qtCgd3tyvjnw8luwPCCYHGpFLVigr R31qO5dgxEFWl6Vpl3kVt0bgI8SyAyTr/ZIJ/L5R/1RyoWqysmvkBSd4UVzTposlrR3c a3gw== X-Gm-Message-State: ALoCoQm9wEDkrFy8Zp5myJdnswjqLlg6Bhz6raD+QrB5tBD50MXbDNZJdeLIMZjUO+kJacJIFhjs X-Received: by 10.180.76.20 with SMTP id g20mr12933446wiw.7.1403886565623; Fri, 27 Jun 2014 09:29:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Fri, 27 Jun 2014 09:28:45 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:41f3:8311:4908:49b1] In-Reply-To: References: <20140626143044.F3B0C1AD68@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Fri, 27 Jun 2014 09:28:45 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d043439460ca35804fcd3d00f Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2mzwxUdyH_Brra32zOX12rRYQY0 Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 16:29:29 -0000 --f46d043439460ca35804fcd3d00f Content-Type: text/plain; charset=UTF-8 On Fri, Jun 27, 2014 at 9:25 AM, Martin Thomson wrote: > On 27 June 2014 09:10, Brian Hamon wrote: > > Unless someone makes a case otherwise, I think that the answer to my > question is that client authentication (assuming Martin's proposal is > accepted) is either required from initial ServerHello or unavailable? > > > There are other options: > > 1. TLS 1.3 could allow clients to authenticate unilaterally (i.e., not > require the CertificateRequest message to be sent before sending a > client cert, or mandating that servers provide a CertificateRequest > always). > > 2. Authentication might be provided with a separate type of control > message. This has been discussed. > > And any combination of the above, depending on what we think best fits > the complexity/functionality trade-off. > > Personally, I like the idea of doing option 1 here. With > confidentiality protection for handshake messages, it could make > client authentication considerably more accessible than it was in > previous TLS versions. > > > [...] perhaps this committee should eliminate client authentication > completely from TLS. > > I haven't seen much interest in doing that. My proposal still relies > on TLS providing a binding to client credentials. I would oppose that. There are plenty of situations where mutual authentication is needed in TLS. -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d043439460ca35804fcd3d00f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 27, 2014 at 9:25 AM, Martin Thomson &= lt;martin.tho= mson@gmail.com> wrote:
On 27 June 2014 09:10, Brian= Hamon <B.Hamon@f5.com> wrote:<= br> > Unless someone makes a case otherwise, I think that the answer to my q= uestion is that client authentication (assuming Martin's proposal is ac= cepted) is either required from initial ServerHello or unavailable?


There are other options:

1. TLS 1.3 could allow clients to authenticate unilaterally (i.e., not
require the CertificateRequest message to be sent before sending a
client cert, or mandating that servers provide a CertificateRequest
always).

2. Authentication might be provided with a separate type of control
message. =C2=A0This has been discussed.

And any combination of the above, depending on what we think best fits
the complexity/functionality trade-off.

Personally, I like the idea of doing option 1 here. =C2=A0With
confidentiality protection for handshake messages, it could make
client authentication considerably more accessible than it was in
previous TLS versions.

> [...] perhaps this committee should eliminate client authentication co= mpletely from TLS.

I haven't seen much interest in doing that. =C2=A0My proposal still rel= ies
on TLS providing a binding to client credentials.

I would oppose that. There are plenty of situations where mutual aut= hentication
is needed in TLS.

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

--f46d043439460ca35804fcd3d00f-- From nobody Fri Jun 27 09:30:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE361B2B3C for ; Fri, 27 Jun 2014 09:30:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_38=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6hICGpkgZtP for ; Fri, 27 Jun 2014 09:30:46 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBD21B2960 for ; Fri, 27 Jun 2014 09:30:45 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id r20so3125740wiv.10 for ; Fri, 27 Jun 2014 09:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZUu1AziC2RLDi5snMjjb3irYmc/NneCMh9xDQgx0+1U=; b=lVGbX5ruHaPMTsvzA1AkjDjGFciRmohvGBuexulfx9HBprhUPr1ZVYsjvmRBjEt4Qq IzH0oh2PyAjcUIbCqm6lgi7qe3GgP2fgjegVJJTicZBsn+4NcUpXR9IitNBFjHQku3fj Eq7fIIGtwlPr8Z9y7JO2HjFs0Z8FHAUd1NMQU70ZcibGeGk0RCF38ql7DMMZq+pc8Be9 zVJv2RZk3UzumIX3G8ndMMtrvXT+5RXWLHSpkJAu56/QO0P0eLfBt/F2RUbPDSJp9NrE phdHVKVYM4fzvWwE/czLNeNVkS+gie5JBYIB1WsttB5C3ooR+MXYe9V3uR6u7Lvvfb7y Umow== MIME-Version: 1.0 X-Received: by 10.194.238.6 with SMTP id vg6mr24356295wjc.24.1403886644190; Fri, 27 Jun 2014 09:30:44 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Fri, 27 Jun 2014 09:30:44 -0700 (PDT) In-Reply-To: References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> Date: Fri, 27 Jun 2014 09:30:44 -0700 Message-ID: From: Martin Thomson To: James Cloos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/P3b4FCFfF3caCy0PLZKJV437pw4 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 16:30:47 -0000 On 27 June 2014 07:13, James Cloos wrote: > If tls1.3 drops rekeying established sockets, then one reasonably can > predict that its adoption will be limited enough that any security > benefits it has over 1.2 will be, mostly, for naught. > > Whether rekeying requires renegotiation should be the question. We're all running the same sort of questions over. I've been looking at TCP crypt and their informal requirements document says this: [...] Use of a single key over a long connection is a known security problem, so it would be preferable to either limit the length of a connection or require in-band keying support. Unfortunately, not all applications are easy to restart. BGP, for which this option is intended, is being augmented for graceful restart [RFC4724] [RFC4781], but this extension is under recent scrutiny. TCP itself has no limit on the length of a connection, and it would be preferable to avoid modifying this semantic. I think that this last sentence answered the rekeying question for me. TLS is considered widely as TCP+security (as much as that abstraction occasionally leaks, c.f., packet length). From nobody Fri Jun 27 10:05:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E661B283E for ; Fri, 27 Jun 2014 10:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOVPsjgsx33J for ; Fri, 27 Jun 2014 10:05:24 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32FA1A03C5 for ; Fri, 27 Jun 2014 10:05:23 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id 63so4638852qgz.32 for ; Fri, 27 Jun 2014 10:05:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2K194bhrkwHm31UwMq3loRb/qVsPwqDsq7PPZ/fcbXY=; b=XCyDYfasLMyLXhw9bpPARmIu9MuNXy4UY+4SckA0YeAXpD5Ma1shO2OY7H7q6kPWu9 AyMYzqD65D7Xx4kG7OFBnFIYYl7pHIuEh97g8dwy11JFnvoaV2zvKegTebEDvvFQRe4g lfgt+brdM4/0WvTrp9RIXwxm9pV7mGr2ikqooXH44Vqt+fuEuiRxvr7eFVv4HS+ngU4h v7ZXnpql2JUJBmjte48xe7BU5zwEX3XSF8n7Xpwy9StnfSb9qXCK7uPUnwreVt3o+SXQ ZBhTJtkwki/feafEkwdX6X9QrlfjDv/mW5Ef46NbrvT6HTpofC4M8bKCNGytUCuRnZNK /ydg== X-Gm-Message-State: ALoCoQmbdpbzbbrDytvatX9tA04lu7wQPKWWEJQaXn1HiCTX/AVKOjXunTv3IrCk2dR6zx19Ab9i MIME-Version: 1.0 X-Received: by 10.140.42.134 with SMTP id c6mr33129705qga.3.1403888722845; Fri, 27 Jun 2014 10:05:22 -0700 (PDT) Received: by 10.224.212.3 with HTTP; Fri, 27 Jun 2014 10:05:22 -0700 (PDT) In-Reply-To: References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> Date: Fri, 27 Jun 2014 10:05:22 -0700 Message-ID: From: Brian Smith To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1139bf0ca13be204fcd4507a Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JXkDWj0e4vUAouxa2f1f2ecJxMs Cc: "tls@ietf.org" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 17:05:28 -0000 --001a1139bf0ca13be204fcd4507a Content-Type: text/plain; charset=UTF-8 On Fri, Jun 27, 2014 at 9:30 AM, Martin Thomson wrote: > I've been looking at TCP crypt and their informal requirements > document says this: > > [...] Use of a single key over a long connection is a > known security problem, so it would be preferable to either > limit the length of a connection or require in-band keying > support. > Citation needed. In particular, what is the definition of "long" here, and what is the security problem, precisely? Usually a cipher's documentation will specify what it means to use a key for too long, and nobody here is proposing to use a key longer than a cipher's specification allows. > Unfortunately, not all applications are easy to restart. > BGP, for which this option is intended, is being augmented > for graceful restart [RFC4724] [RFC4781], but this extension > is under recent scrutiny. TCP itself has no limit on the > length of a connection, and it would be preferable to avoid > modifying this semantic. > > I think that this last sentence answered the rekeying question for me. > TLS is considered widely as TCP+security (as much as that abstraction > occasionally leaks, c.f., packet length). > Theoretical limitations don't matter as long as the practical limitations are reasonable. When the misinformation about AES-GCM being limited to 2^32 records was being considered, it did seem like the practical limitation was bordering on being unreasonable. But, now it seems like the practical limitation is >=2^48 records for the cipher suites that will be retained in TLS 1.3 anyway, and I don't see 2^48 records as being such a significant limitation that we must make the protocol significantly more complex to get around it. My current preference is to remove renegotiation and rekeying altogether, option 1. That said, I think the "forward secrecy" goal of your rekeying proposal potentially has merit as a justification for the feature, but it needs to be fleshed out before anybody can understand it and judge it. I think it is worthwhile to write out the requirements for that feature, decide whether the feature is justified for inclusion in TLS 1.3 (it seems like scope creep to me), and then explore whether a restricted or otherwise modified form of the current renegotiation mechanism can be used for that feature. Reusing a restricted form of the current renegotiation mechanism would reduce complexity for existing implementations that already support renegotiation, whereas adding a new rekeying mechanism seems guaranteed to add significant complexity which would make it a breeding ground for implementation mistakes. However, it isn't clear (a) whether we need any rekeying in TLS 1.3, or (b) whether restricted renegotiation or a new rekeying mechanism is better. Cheers, Brian --001a1139bf0ca13be204fcd4507a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 27, 2014 at 9:30 AM, Martin Thomson <martin.thomson@gmail= .com> wrote:
I've been looking at TCP crypt and their= informal requirements
document says this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...] =C2=A0Use of a single key ov= er a long connection is a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0known security problem, so it woul= d be preferable to either
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0limit the length of a connection o= r require in-band keying
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0support.

=
Citation needed. In particular, what is the definition of "= long" here, and what is the security problem, precisely? Usually a cip= her's documentation will specify what it means to use a key for too lon= g, and nobody here is proposing to use a key longer than a cipher's spe= cification allows.
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Unfortunately, not all application= s are easy to restart.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BGP, for which this option is inte= nded, is being augmented
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for graceful restart [RFC4724] [RF= C4781], but this extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is under recent scrutiny. =C2=A0TC= P itself has no limit on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0length of a connection, and it wou= ld be preferable to avoid
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0modifying this semantic.

I think that this last sentence answered the rekeying question for me.
TLS is considered widely as TCP+security (as much as that abstraction
occasionally leaks, c.f., packet length).

Theoretical limitations don't matter as long as the practical limita= tions are reasonable. When the misinformation about AES-GCM being limited t= o 2^32 records was being considered, it did seem like the practical limitat= ion was bordering on being unreasonable. But, now it seems like the practic= al limitation is >=3D2^48 records for the cipher suites that will be ret= ained in TLS 1.3 anyway, and I don't see 2^48 records as being such a s= ignificant limitation that we must make the protocol significantly more com= plex to get around it.

My current preference is to remove renegotiation and rekeying altogethe= r, option 1.

That said, I think the "forward secrecy= " goal of your rekeying proposal potentially has merit as a justificat= ion for the feature, but it needs to be fleshed out before anybody can unde= rstand it and judge it. I think it is worthwhile to write out the requireme= nts for that feature, decide whether the feature is justified for inclusion= in TLS 1.3 (it seems like scope creep to me), and then explore whether a r= estricted or otherwise modified form of the current renegotiation mechanism= can be used for that feature. Reusing a restricted form of the current ren= egotiation mechanism would reduce complexity for existing implementations t= hat already support renegotiation, whereas adding a new rekeying mechanism = seems guaranteed to add significant complexity which would make it a breedi= ng ground for implementation mistakes. However, it isn't clear (a) whet= her we need any rekeying in TLS 1.3, or (b) whether restricted renegotiatio= n or a new rekeying mechanism is better.

Cheers,
Brian
--001a1139bf0ca13be204fcd4507a-- From nobody Fri Jun 27 10:09:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821C91B27A0 for ; Fri, 27 Jun 2014 10:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8i4c9IrtgO8N for ; Fri, 27 Jun 2014 10:09:36 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4281B288D for ; Fri, 27 Jun 2014 10:09:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389744000"; d="scan'208";a="119849203" X-IPAS-Result: AqcEADD7RVPAqArr/2dsb2JhbABZhBiDDsEFGYEedIIlAQEBAQIBHQYRRQULAgEIDgMEAQEBAgIGDg8DAgICHxEUAQgIAgQBDQUIFodKAwmpHZtyDYcJF4EpiyqBaAYrBwQCEoJXNYEUBJRxgX+OYYh/gis Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 27 Jun 2014 17:09:36 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Fri, 27 Jun 2014 10:09:35 -0700 From: Brian Hamon To: Eric Rescorla , Martin Thomson Thread-Topic: [TLS] Call for Consensus on removal of renegotiation Thread-Index: AQHPkKQi2ibdHwQZAU+UoLazXGbTxJuCn8+AgAAVNgCAATV4AP//97oQgAB9MwD//4sSAIABNxcggAB7a4CAAADNgP//i1ww Date: Fri, 27 Jun 2014 17:09:34 +0000 Message-ID: References: <20140626143044.F3B0C1AD68@ld9781.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.167] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qzdcs7QMvpur_yzJzrorlVX6ZeI Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 17:09:38 -0000 DQoNCkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dIA0KU2VudDogRnJp ZGF5LCBKdW5lIDI3LCAyMDE0IDk6MjkgQU0NClRvOiBNYXJ0aW4gVGhvbXNvbg0KQ2M6IEJyaWFu IEhhbW9uOyA8dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIENhbGwgZm9yIENvbnNl bnN1cyBvbiByZW1vdmFsIG9mIHJlbmVnb3RpYXRpb24NCg0KDQpPbiBGcmksIEp1biAyNywgMjAx NCBhdCA5OjI5IEFNLCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+IHdyb3RlOg0KPk9uIEZy aSwgSnVuIDI3LCAyMDE0IGF0IDk6MjUgQU0sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20+IHdyb3RlOg0KPj5PbiAyNyBKdW5lIDIwMTQgMDk6MTAsIEJyaWFuIEhhbW9u IDxCLkhhbW9uQGY1LmNvbT4gd3JvdGU6DQo+Pj4gVW5sZXNzIHNvbWVvbmUgbWFrZXMgYSBjYXNl IG90aGVyd2lzZSwgSSB0aGluayB0aGF0IHRoZSBhbnN3ZXIgdG8gbXkgcXVlc3Rpb24gaXMgdGhh dCBjbGllbnQgYXV0aGVudGljYXRpb24gKGFzc3VtaW5nIE1hcnRpbidzIHByb3Bvc2FsIGlzIGFj Y2VwdGVkKSBpcyBlaXRoZXIgcmVxdWlyZWQgZnJvbSBpbml0aWFsIFNlcnZlckhlbGxvIG9yIHVu YXZhaWxhYmxlPw0KDQo+PiBUaGVyZSBhcmUgb3RoZXIgb3B0aW9uczoNCg0KPj4gMS4gVExTIDEu MyBjb3VsZCBhbGxvdyBjbGllbnRzIHRvIGF1dGhlbnRpY2F0ZSB1bmlsYXRlcmFsbHkgKGkuZS4s IG5vdA0KcmVxdWlyZSB0aGUgQ2VydGlmaWNhdGVSZXF1ZXN0IG1lc3NhZ2UgdG8gYmUgc2VudCBi ZWZvcmUgc2VuZGluZyBhDQpjbGllbnQgY2VydCwgb3IgbWFuZGF0aW5nIHRoYXQgc2VydmVycyBw cm92aWRlIGEgQ2VydGlmaWNhdGVSZXF1ZXN0DQphbHdheXMpLg0KDQo+PiAyLiBBdXRoZW50aWNh dGlvbiBtaWdodCBiZSBwcm92aWRlZCB3aXRoIGEgc2VwYXJhdGUgdHlwZSBvZiBjb250cm9sDQpt ZXNzYWdlLiDCoFRoaXMgaGFzIGJlZW4gZGlzY3Vzc2VkLg0KDQo+PiBBbmQgYW55IGNvbWJpbmF0 aW9uIG9mIHRoZSBhYm92ZSwgZGVwZW5kaW5nIG9uIHdoYXQgd2UgdGhpbmsgYmVzdCBmaXRzDQp0 aGUgY29tcGxleGl0eS9mdW5jdGlvbmFsaXR5IHRyYWRlLW9mZi4NCg0KPj4gUGVyc29uYWxseSwg SSBsaWtlIHRoZSBpZGVhIG9mIGRvaW5nIG9wdGlvbiAxIGhlcmUuIMKgV2l0aA0KY29uZmlkZW50 aWFsaXR5IHByb3RlY3Rpb24gZm9yIGhhbmRzaGFrZSBtZXNzYWdlcywgaXQgY291bGQgbWFrZQ0K Y2xpZW50IGF1dGhlbnRpY2F0aW9uIGNvbnNpZGVyYWJseSBtb3JlIGFjY2Vzc2libGUgdGhhbiBp dCB3YXMgaW4NCnByZXZpb3VzIFRMUyB2ZXJzaW9ucy4NCg0KSW50ZXJlc3RpbmcgYW5kIGVsZWdh bnQgcHJvcG9zYWwuLi4gQXNzdW1pbmcgd2UgZG9uJ3QgY3JlYXRlIGhlYWRhY2hlcyBmb3IgaW1w bGVtZW50ZXJzIG9yIA0Kb3Bwb3J0dW5pdGllcyBmb3IgRG9TLCBJIHdvdWxkIGZhdm9yIHRoaXMg YWxzby4NCg0KPj4+IFsuLi5dIHBlcmhhcHMgdGhpcyBjb21taXR0ZWUgc2hvdWxkIGVsaW1pbmF0 ZSBjbGllbnQgYXV0aGVudGljYXRpb24gY29tcGxldGVseSBmcm9tIFRMUy4NCg0KPj4gSSBoYXZl bid0IHNlZW4gbXVjaCBpbnRlcmVzdCBpbiBkb2luZyB0aGF0LiDCoE15IHByb3Bvc2FsIHN0aWxs IHJlbGllcw0Kb24gVExTIHByb3ZpZGluZyBhIGJpbmRpbmcgdG8gY2xpZW50IGNyZWRlbnRpYWxz Lg0KDQo+IEkgd291bGQgb3Bwb3NlIHRoYXQuIFRoZXJlIGFyZSBwbGVudHkgb2Ygc2l0dWF0aW9u cyB3aGVyZSBtdXR1YWwgYXV0aGVudGljYXRpb24NCmlzIG5lZWRlZCBpbiBUTFMuDQoNCkkgZW5n YWdlZCBpbiByZWR1Y3RpbyBhZCBhYnN1cmR1bSB0aGVyZSwgYmVjYXVzZSB3aXRob3V0IGVpdGhl ciBvZiB0aGVzZSBhZGRpdGlvbmFsIG1lY2hhbmlzbXMsDQpjbGllbnQgYXV0aGVudGljYXRpb24g aXMgaW1wb3NzaWJsZSAoaW4gc29tZSB2ZXJ5IHNwZWNpZmljIHVzZSBjYXNlcyBvdmVyIHdoaWNo IGFwcGFyZW50bHkgSSB1bmlxdWVseSANCm9ic2VzcykuIA0KDQpXZSBtdXN0IGhhdmUgc2VydmVy IGF1dGhlbnRpY2F0aW9uIGF0IHRoZSB0cmFuc3BvcnQgbGF5ZXIsIGluIG9yZGVyIHRvIHNlY3Vy ZWx5IG5lZ290aWF0ZSB0aGUgbWFzdGVyIA0Kc2VjcmV0LiBUTFMgc3RyaXZlcyBmb3Igc3ltbWV0 cnksIGFsbG93aW5nIHRoZSBzYW1lIGltcGxlbWVudGF0aW9uIHRvIGJlIHVzZWQgaW4gY2xpZW50 cyBhbmQgc2VydmVycy4gDQpUaGVyZWZvcmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG11c3QgYmUg aW4gVExTLCBldmVuIHRob3VnaCBhdXRoZW50aWNhdGlvbiBpbiB0aGUgdHJhbnNwb3J0IGxheWVy DQppcyBhIHZpb2xhdGlvbiBvZiB0aGUgT1NJIG1vZGVsLiBBbnl0aGluZyB0aGF0IG1vdmVzIHRo ZSBJbnRlcm5ldCBhd2F5IGZyb20gcGFzc3dvcmQtYmFzZWQNCmF1dGhlbnRpY2F0aW9uIGlzIGEg d2luLg0KDQpNYWtpbmcgImNsaWVudCBhdXRoZW50aWNhdGlvbiBjb25zaWRlcmFibHkgbW9yZSBh Y2Nlc3NpYmxlIHRoYW4gaXQgd2FzIGluDQpwcmV2aW91cyBUTFMgdmVyc2lvbnMiIHNob3VsZCBi ZSBhIGhpZ2ggcHJpb3JpdHkgZ29hbCBmb3IgVExTdjEuMy4NCiANCg== From nobody Fri Jun 27 11:07:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605AB1A04B0 for ; Fri, 27 Jun 2014 11:07: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udHgppJO5H1U for ; Fri, 27 Jun 2014 11:07:25 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAA7A1A00DB for ; Fri, 27 Jun 2014 11:07:24 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so5516275wgh.4 for ; Fri, 27 Jun 2014 11:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2DZvIwjeXqPVpfWyTvMjBpKXllaaE0EkHIDlAXXdJs4=; b=J8KiubEYPYRMUjb0PYUurM7r9rPxmouTtYFByuaafNPbHOYykASzwCJDkAPkZIyU0+ ZEJy3Ub4HA7J2zxUtv801O4FZT5NyL8qbT1bUd7Sx2ijcqejan3SzU+cqTx0sIwPIE8x yUj8XPHiJbQYLwE/ogXMpNOm0hp8Ub3Dp1adeNAP9bssIG+dol8/MSHP2wiS3Nxq3dux iO1UVAjPzgc2nCBeoms06egBAo+RXcB0zyK8+zwY2yCPitoriEYzpZMKqVRoYriVqc3T rKH+I6AKbtwOtS3ca0Fi4tyJ2ZYV8tCud5ehjFKGTzR+FvaBgz/94ba0doA+Fo0B3O6o nkmg== MIME-Version: 1.0 X-Received: by 10.194.238.6 with SMTP id vg6mr24888696wjc.24.1403892443450; Fri, 27 Jun 2014 11:07:23 -0700 (PDT) Received: by 10.194.51.134 with HTTP; Fri, 27 Jun 2014 11:07:23 -0700 (PDT) In-Reply-To: References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> Date: Fri, 27 Jun 2014 11:07:23 -0700 Message-ID: From: Martin Thomson To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dGRSuvv3vKuSh6w2xY4HawKXxE4 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 18:07:30 -0000 On 27 June 2014 10:05, Brian Smith wrote: > That said, I think the "forward secrecy" goal of your rekeying proposal > potentially has merit as a justification for the feature, but it needs to be > fleshed out before anybody can understand it and judge it. I think it is > worthwhile to write out the requirements for that feature, decide whether > the feature is justified for inclusion in TLS 1.3 That's a reasonable ask. I'm happy to expand on that elsewhere, but I'll try to keep the focus on resolving this point first. From nobody Fri Jun 27 12:03:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDCF1B29CB for ; Fri, 27 Jun 2014 12:03:47 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2qsUsBfQq21 for ; Fri, 27 Jun 2014 12:03:45 -0700 (PDT) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F4E1B29B5 for ; Fri, 27 Jun 2014 12:03:45 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id rr13so4910994pbb.32 for ; Fri, 27 Jun 2014 12:03:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UIuQL4O38dfHfhZhYNJum5TbHCr6C6H3DgwMZYzKAoo=; b=W8sxuraEmwn1Tflwg2qC/M3Oo12fTFiwJgFGGpWb8tANkusaqGu+Xihz7JU7g5Sm+J L6xOX73XweJWGQKhih8HSBpo3p5cPUrYMtLMrO7gKXxpYR7FiNA60mAp2GqDE0mQsZlC k4UuY3eKWeD+/3K7mgxteTC3umLcthFAzE+ZKLd4iOXpEnl15PFibQBc0Xj6tQWjzlB7 7VLTY7Jv9Dgbhf18ckzyuIOQggCHCg+uw3B2kDgTYz130ZIzaP/EinaeB6+Vh2XYxj+9 kkXdr2EUUCzd5ddlXtPYKwizbjQVkE2JmWbAABpgEtpFkaRbWGLYkvb6lVVprLZfQzry Sotw== X-Gm-Message-State: ALoCoQmxhtVIbJ/F8r9+KLCFNrhPFb9uqUpBA+8iVJ1Et24DTm+DFUEnhxxV0dGeLFwwucFlNq80 X-Received: by 10.68.129.68 with SMTP id nu4mr32984256pbb.76.1403895825112; Fri, 27 Jun 2014 12:03:45 -0700 (PDT) Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id fv2sm15950486pbd.11.2014.06.27.12.03.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 12:03:43 -0700 (PDT) From: Andy Lutomirski X-Google-Original-From: Andy Lutomirski Message-ID: <53ADC00E.4060305@mit.edu> Date: Fri, 27 Jun 2014 12:03:42 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Watson Ladd , "mrex@sap.com" References: <20140626143044.F3B0C1AD68@ld9781.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jGOiJFRsD2WKZ0DjahMJbdZ__JM Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 19:03:47 -0000 On 06/26/2014 06:23 PM, Watson Ladd wrote: > On Thu, Jun 26, 2014 at 7:30 AM, Martin Rex wrote: >> Joseph Salowey (jsalowey) wrote: >>> >>> 1. In favor of removing renegotiation >>> 2. In favor of removing renegotiation with the addition of rekey facility >>> 3. Not in favor of removing renegotiation >> >> >> (3) Leave it in the spec, Make it a true option for implementors. >> with a guidance that clients might need it for interop, but should >> play safe (and nail down identities once they're established) by default >> >> >> I never offered/exposed renegotiation at the API to application callers, >> and since January 2010, I have the server-side reject renegotiation attempts >> from clients. But the installed base of _other_ servers that use >> (or require) it is to large to be ignored, and I don't see it go away >> that easily... >> >> Everything that you change from TLSv1.0/1/2 toward v1.3 will add complexity >> and require more code. This applies not just to adding new features, but >> also to axing existing features that may be in current use. >> >> A TLSv1.3 spec that requires implementors to carefully avoid TLSv1.3 for >> a number of commonly used TLSv1.0/1/2 features may be even harder to >> sell than TLSv1.2 and IPv6. > > I think this is an excellent point: unless we are making TLS 1.3 web > only, and committing to supporting TLS 1.2 (including renegotation!) > for > a long time, we cannot ax this feature. As much as I dislike > renegotiation, it may be that we need to include it as an optional > feature if we want to replace TLS 1.2. Are there any known non-HTTP users of renegotiation for client auth that wouldn't work out of the box with unsolicited client auth during the handshake? The only compelling objection to removing renegotiation for client auth that I heard was that it would be unfortunate for TLS 1.3 to only be usable with an upgraded HTTP stack. That's not a show-stopper, but it's annoying. Allowing delayed client authentication without a new handshake would solve this problem, is cryptographically very simple*, but integrating it into the protocol might be quite complicated. * It would preclude using tricks like triple DH directly, though. --Andy From nobody Fri Jun 27 19:12:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966631A0264 for ; Fri, 27 Jun 2014 19:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz1HQn3BOJWq for ; Fri, 27 Jun 2014 19:12:00 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04641A0266 for ; Fri, 27 Jun 2014 19:11: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=uoa; t=1403921520; x=1435457520; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=IJUrcS3N7d3wnxtmccc01qO6pnvGfETG0kZ4u5G9oIU=; b=MLvznn2vccyqN5AXP7zDvEerJ+Ab0s5mi0+UGcwJAQeNafX5xNgo5br9 aNLUULeM/6/UbUFG1LwvGr2UcYG6X1JFb14l4zbP+6Gy0dMJr1k5AhmjP fkcSLw3CUlUT6Osz4MG97KmcJUU554w0YsJ1m9VDJDVYXO7z8F3g37F+g w=; X-IronPort-AV: E=Sophos;i="5.01,565,1399982400"; d="scan'208";a="260951859" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 28 Jun 2014 14:11:58 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Sat, 28 Jun 2014 14:11:57 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Call for Consensus on removal of renegotiation Thread-Index: Ac+SdlXJjTx5EP/HSwq95Cdx6M0JOQ== Date: Sat, 28 Jun 2014 02:11:56 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DED010B@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3R2t7Ao1LSReLL7t6uMvMhYLgMg Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 02:12:02 -0000 James Cloos writes:=0A= =0A= >If tls1.3 drops rekeying established sockets, then one reasonably can pred= ict=0A= >that its adoption will be limited enough that any security benefits it has= =0A= >over 1.2 will be, mostly, for naught.=0A= =0A= That's pretty speculative. My speculation is instead:=0A= =0A= If tls1.3 drops rekeying established sockets, then one reasonably can=0A= predict that people won't rekey established sockets any more.=0A= =0A= I'd say that's far more likely.=0A= =0A= Peter.=0A= From nobody Fri Jun 27 22:09:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DE21A029D for ; Fri, 27 Jun 2014 22:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zu2ZjOHi1eVG for ; Fri, 27 Jun 2014 22:09:35 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2308A1A029A for ; Fri, 27 Jun 2014 22:09:34 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s5S59OYH020301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 Jun 2014 07:09:24 +0200 (MEST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738DED010B@uxcn10-tdc06.UoA.auckland.ac.nz> To: Peter Gutmann Date: Sat, 28 Jun 2014 07:09:24 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140628050924.86D2F1AD6F@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0FJSaaPLoPbU4_w1bzh00YX1q14 Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 05:09:38 -0000 Peter Gutmann wrote: > James Cloos writes: >> >>If tls1.3 drops rekeying established sockets, then one reasonably can predict >>that its adoption will be limited enough that any security benefits it has >>over 1.2 will be, mostly, for naught. I think that TLSv1.3 will be largely ignored for many other reasons (except maybe by a few (heart)bleeding edge implementations that spend their scarce resources to implement every TLS kitchen sink rather than for quality of the stuff that is important). > > That's pretty speculative. My speculation is instead: > > If tls1.3 drops rekeying established sockets, then one reasonably can > predict that people won't rekey established sockets any more. > > I'd say that's far more likely. For the purpose of rekeying, I still think that renegotiation is a pretty good solution. I started my adventure into crypto protocols as a consumer of GSS-API and participant of the IETF CAT working group in 1995. GSS-API itself does not have renegotiation or rekeying, and back then (MIT) Kerberos 5 was the canonical GSS-API mechanism, was using (single)DES for encryption and it was enforcing a lifetime on GSS-API security contexts, deriving it from the lifetime of the Kerberos ticket that authenticated the security context. If an application wanted (a) use Kerberos 5 and (b) be able to communicate for more than 10 hours (often less, because the TGT may have been acquired a few hours ago), then a significant amount of complexity was thrown on the application to deal with this. I implemented a communication protcol for our application that will try to "transparently" replace an expiring security context with a new one, but MIT Kerberos 5 did not exactly make this easy: MIT Kerberos enforced security context expiration not just on send (gss_wrap, gss_get_mic), but also on receipt (gss_unwrap, gss_verify_mic) so that a message that was protected with only little security context lifetime left and was delayed in transport or delayed in processing on the receiver side would fail to unprotect (i.e. message lost). Most application protocols can not deal with lost data Since the security context lifetime is derived from the ticket lifetime (and service ticket lifetime derived from TGT lifetime), a security context with a longer lifetime could only be established when a new TGT was available. With MIT Kerberos, acquisition of a new TGT for a user required _manual_user_intervention_. So one's protocol layer above gssapi may want to try establishing a new security context with sufficient margin to expiration of the existing context to prevent protected messages from "expiring" in transit or on the receivers incoming message queue. Since the user may have not provided a new TGT yet, one may have to continue using the existing security context as fallback as long as it lives. The client can locally check the lifetime of his credential and avoid to insert a useless context establishment handshake that results in a new security context with not more lifetime than the existing. But when the server is the one who starts talking after a longer period of silence on an established channel, it may notice that the existing security context is close to expiration or already expired, and then needs to ask the client to try establishing a new security context before the server can convey the data under protection. Any such handshaking for the purpose of trying to replace an expiring (but not yet expired) security context needs to be performed in a fashion that is _not_ a deadly embrace, the fallback to continue using the not-yet-expired security context should be used. Microsoft implemented their own Kerberos 5 in Windows 2000, and in Windows2000 Beta3, Microsoft briefly tried to enforce security context expiration in the MIT Kerberos style. It was a pretty fierce crashing and burning of all Microsoft apps on top of SSPI. Exactly none of their apps was able to handle it. Beta3 (the last before rc1) might have been a little late to get back to the drawing board and redesign communication protocols to cope with security context roll-over. So security context expiration was disable for Win2Krc1 and was never seen again. Since all Microsoft apps are completely ignoring the various SSPI lifetimes (credentials and security context lifetime), this part is largely untested. While the info was mostly correct in Win2K, ever new Window release has added situations when bogus values are returned from SSPI. Client and Server on different machines may be told differing security context lifetimes, and there are Citrix usage scenarios when it is *IMPOSSIBLE* to create a security context that SSPI does *NOT* report as expired (via the lifetime parameter value). Not using or not being able to support a protocol feature is one thing, but over time, the credential and context lifetime reporting at SSPI for Kerberos went from OK to flaky to buggy to close-to-unusable (today). While Microsoft Kerberos has the nice capability to automatically acquire and refresh TGTs, the mechanism is flaky. Tickets may get replaced only *after* they've expired (and handshakes might get performed with expired tickets, resulting in expired security context being returned from the security context establishment handshake. In some Citrix scenarios, the reported lifetime of security contexts differ between client side and server side by the time zone difference between server and client. When the time zone difference is >= 10 hours, it is impossible to establish non-expired security contexts... Another challenge for a security context roll-over is in the Kerberos protocol itself. Authenticators have a limited lifetime (typically 5 minutes). This may be a problem for a communication link of an application that is processing stuff in batch (request pipelining) and that may exhibit response times of 10+ minutes. New requests from the network are read from the network and placed into a local message queue (so that TCP doesn't tear down the connection), but the actual processing of the message may get delayed for 10+ minutes, at which point the acceptor may be faced with an error because the authenticator has "expired". Bottom line: if renegotiation is dropped from TLSv1.3, then long-lived connections with either not rekey, i.e. kiss forward secrecy good-bye, or long-lived connections will kiss TLSv1.3 good-bye. The latter of these two options is less work and immediately available... -Martin From nobody Fri Jun 27 22:33:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0622B1A02B2 for ; Fri, 27 Jun 2014 22:33:37 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQ-a3CNGCt2C for ; Fri, 27 Jun 2014 22:33:35 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47AD11A02B0 for ; Fri, 27 Jun 2014 22:33:35 -0700 (PDT) Received: by mail-yk0-f180.google.com with SMTP id 131so3447664ykp.11 for ; Fri, 27 Jun 2014 22:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UHlXAgXq67r7RDXpFWUXBm5yeYhPJxw3k7X3jECFo9w=; b=vzf4DLbt8mA2kjZgUkbb3uC8CxuS/Tuz+22jhWQJAohzERvIH6ITQ110gQnaU4dTbO A4PK2IVbveWNfvFJ4oCCS2uLzm+u30Vx1q+uqGVdaVd77WT3cTKyMXRKhwIZrSQKsbHB mkOwtehNTu8EaJZHZJUt/FHYcYXtQFIi8irLgy6m8p4xOfSbsy1uxXVst2tKnvehua5q zyOVSOieBp7kskCoFfofFleMDUBHdZulDAhYrM/i6ndGmlsteQd1qtweLZQzksJOBi6j zgZTt6VG88RwJCRsXycB7kCt6nVPgU8n6BnBpeRmtaQADlnDtuGX38kTGBAFD/7kLF8U DFRA== MIME-Version: 1.0 X-Received: by 10.236.81.243 with SMTP id m79mr37963267yhe.36.1403933614605; Fri, 27 Jun 2014 22:33:34 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Fri, 27 Jun 2014 22:33:34 -0700 (PDT) In-Reply-To: <20140628050924.86D2F1AD6F@ld9781.wdf.sap.corp> References: <9A043F3CF02CD34C8E74AC1594475C738DED010B@uxcn10-tdc06.UoA.auckland.ac.nz> <20140628050924.86D2F1AD6F@ld9781.wdf.sap.corp> Date: Fri, 27 Jun 2014 22:33:34 -0700 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/s16MAK8AGPcxaDfDrK0GfMotaw0 Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 05:33:37 -0000 On Fri, Jun 27, 2014 at 10:09 PM, Martin Rex wrote: > Peter Gutmann wrote: >> James Cloos writes: >>> >>>If tls1.3 drops rekeying established sockets, then one reasonably can predict >>>that its adoption will be limited enough that any security benefits it has >>>over 1.2 will be, mostly, for naught. > > I think that TLSv1.3 will be largely ignored for many other reasons > (except maybe by a few (heart)bleeding edge implementations that spend > their scarce resources to implement every TLS kitchen sink rather than > for quality of the stuff that is important). Hard to say: removing one round trip doesn't need to be especially complicated: False Start demonstrated that. For the web this latency really matters, so browsers are very motivated to support TLS 1.3 Of course, only four implementations matter: one for the server, the one in Chrome, the one in Mozilla, and the one in Microsoft Windows. > > >> >> That's pretty speculative. My speculation is instead: >> >> If tls1.3 drops rekeying established sockets, then one reasonably can >> predict that people won't rekey established sockets any more. >> >> I'd say that's far more likely. > > For the purpose of rekeying, I still think that renegotiation is > a pretty good solution. Only if we tolerate the delays it introduces, and mandate significant restrictions on what can change. Interestingly some browsers seem to have already done this to fix Triple Handshake. > > > Bottom line: if renegotiation is dropped from TLSv1.3, then long-lived > connections with either not rekey, i.e. kiss forward secrecy good-bye, > or long-lived connections will kiss TLSv1.3 good-bye. > > The latter of these two options is less work and immediately available... Why are these the two options? TLS 1.3 could provide a transparent rekeying option, that unlike renegotiation doesn't require excessive round trips. Sincerely, Watson Ladd > > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sat Jun 28 00:03:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E021A02EC for ; Sat, 28 Jun 2014 00:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaqWX6Pixqt5 for ; Sat, 28 Jun 2014 00:03:53 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 902571A0269 for ; Sat, 28 Jun 2014 00:03:53 -0700 (PDT) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta12.emeryville.ca.mail.comcast.net with comcast id Kj1k1o0020EPcho01j3t4U; Sat, 28 Jun 2014 07:03:53 +0000 Received: from [192.168.1.145] ([71.202.164.227]) by omta01.emeryville.ca.mail.comcast.net with comcast id Kj3s1o00B4uhcbK8Mj3stp; Sat, 28 Jun 2014 07:03:53 +0000 Message-ID: <53AE68D8.70605@brainhub.org> Date: Sat, 28 Jun 2014 00:03:52 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <65D2FD736B6B2B48B2EAD2BD189DC9CC16B433@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: <65D2FD736B6B2B48B2EAD2BD189DC9CC16B433@LLE2K10-MBX01.mitll.ad.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403939033; bh=lb4svwOb36mhC3X3lsO0Ny0tGi/yTSwJG5lNde1/Gkw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OnAOCQ/jE/rqS+iXhp/bdWdoW94/2RkI9rCMr4tm/OpLubT/rbIx6Z74hsf9MGLtq yEh4JrrxIQyTjI3fN140WEht8lYNOFp3R1Gv3uwwEJ3JSXocqxFy1BSN/g1DoROVtw LHzMSjX8hrSg7rqgL6w16APumm50xtYiC4AXutbYW3P9wk8ckfL/zcUoS2ZmMPnQ96 YuqfpjjYNSaUuSaR4za93gH4WY4u3dEVuMUDnB9FPTINKxwOq520X/awOMG2txQAF+ NffiBhbMxkrnIhPJ8N0SvjiAeQ1RBc5bVdgCC419UO1Oh4WwnjlHG9EmLp7aWp34CQ eacT5Icw0mLAg== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yYrYRRubI6oKSCb6dvItgJnDM6A Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 07:03:55 -0000 Here is an idealistic, but not unfeasible proposal that could lead to easier/broader adoption. One way to attempt to unify the diverse world of ECC curves is to focus on the underlying field, as opposed the curve itself. Consider Fp operations with p=2^255-19 or p=2^256-189. In other words, for n={256,384,512}, chose the closest C: p=2^n-C is a prime and make this p "MUST". People who demand random primes will have to play along and accept less "randomness" in their curves. This makes it more likely that the standard bodies, including national standards, agree to commit to a unified Fp, even when they are unable to embrace a single curve. This is a more realistic goal than to expect that one curve will satisfy everybody. The performance in the Fp dominates the higher-level operation in ECC field. In software, Fp operations will be special-cased for p and various CPU architectures. It seems to me that such a fixed Fp will work as an incentive to add hardware support (for Fp). This allows the ECC code to have an interoperable, potentially hardware-assited layer, that is shared between all the curves (for the same n). While we are on this, why was the Curve25519 not made to be Curve256189? (I don't think that 19 v.s. 189 would matter on x86) I suppose that the rest of the paper carries over unchanged (other than that the choice of the floating point registers is dated by now for modern x86 CPUs.) Thank you. From nobody Sat Jun 28 03:09:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8231A0338 for ; Sat, 28 Jun 2014 03:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMjGnJ8gVNyX for ; Sat, 28 Jun 2014 03:08:39 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36CAD1A033E for ; Sat, 28 Jun 2014 03:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1403950119; x=1435486119; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=YM5F6UeiJNlmVLGd/P0gJNR/blbf8zFwGkzmhBZCXRg=; b=tfEh2S5cx7qrnAl61CCYg6PwKmDWqqr7mps9qchYicuYEAgvfsYYEbsi Ma4MyBZxV/Fbq4qN713qN8hWDukSnO1xITozW0iKuUj6U40OlHwHUIMRD vvRY5hFXBZ2cVlmW4bbKPNzPTLorKxzhvIRrhbZeP80+A2lCQ9I/1s7Kc A=; X-IronPort-AV: E=Sophos;i="5.01,566,1399982400"; d="scan'208";a="260978936" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 28 Jun 2014 22:08:35 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Sat, 28 Jun 2014 22:08:34 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Call for Consensus on removal of renegotiation Thread-Index: Ac+SuOufWK1Utn1sSoyVA6cnt2onOg== Date: Sat, 28 Jun 2014 10:08:34 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DED02F1@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/N0h6QO29Twnnw3QAiAPveN7NEe8 Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 10:08:46 -0000 Martin Rex writes:=0A= =0A= >I think that TLSv1.3 will be largely ignored for many other reasons (excep= t=0A= >maybe by a few (heart)bleeding edge implementations that spend their scarc= e=0A= >resources to implement every TLS kitchen sink rather than for quality of t= he=0A= >stuff that is important).=0A= =0A= I wish that were true. Coming from the "other standards that refer to TLS"= =0A= world (rather than the "everything's some sort of web-based app" world),=0A= people are going to require use of TLS 1.3 because 1.3 > 1.2. If you took = a=0A= spec for Xmodem with rot13 and called it TLS 1.3 then people writing things= =0A= like SCADA standards would be requiring Xmodem/rot13 in all their specs.=0A= That's why I really, really don't want to see a mountain of legacy junk=0A= dragged along into TLS 1.3 because someone's worried that someone, somewher= e=0A= may need it. I really, really don't want to have to shoehorn yet another= =0A= gratuitous rework of TLS into a Cortex M3 a year or two after I've finished= =0A= doing the last one.=0A= =0A= (Another alternative, I guess, is to create an embedded profile of TLS and= =0A= hope the standards-writers notice it before they specify the requirement to= =0A= support full TLS 1.0, TLS 1.2, TLS 1.3, and also TLS 1.4 just for luck).=0A= =0A= Peter.= From nobody Sat Jun 28 09:58:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB621A0380 for ; Sat, 28 Jun 2014 09:58: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, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQOeqNMD8n-i for ; Sat, 28 Jun 2014 09:58:24 -0700 (PDT) Received: from eu1sys200aog116.obsmtp.com (eu1sys200aog116.obsmtp.com [207.126.144.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2161A037A for ; Sat, 28 Jun 2014 09:58:23 -0700 (PDT) Received: from mail-we0-f175.google.com ([74.125.82.175]) (using TLSv1) by eu1sys200aob116.postini.com ([207.126.147.11]) with SMTP ID DSNKU670Kz4MMuI4Msb0cNezuNruhu0VzMFc@postini.com; Sat, 28 Jun 2014 16:58:24 UTC Received: by mail-we0-f175.google.com with SMTP id k48so6450251wev.34 for ; Sat, 28 Jun 2014 09:58:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=5lGwdifcUQa/bxrbCmnPX9Id9IIzBuoYav4OXMz7PrI=; b=AiT6SPjSNAa5ZyzeyLbPeR/2PnkwaEUHOfY9PueSlOXE+lasFNmGmHtV/wgnK6vLBu cPYrMQDQWd1w+v2lIc/U+zbySdJSG1eUgH1HPRbo51ESOQqSKkAxxy3Zt63kFeXpr+vx IRlYfO8AWRpYGMHEihgzdCEVI2MMNLNQc1bhHlR8qVSq0iggD249hgrdcmkHOeL1EHbp bomAoEx+rTl4urK+X6K8tcppmqLW7V/x/OzwwRhDgE+QNklGkpFO0X42MTZaTRp2X+/E P94iABRrctGKtnhoMOHGn/zo4LFWzSZeLHlVvowJiBjrM+ZVZxVyYCvlNSMerpdDotLv 2zTA== X-Gm-Message-State: ALoCoQl2BT7nJfsPomA3dn8Gi/Yf1bccVbUwj7bQkIRaJ90yApLiRbHzzW3PPYdGUGnsVhEWJL4z29EM1X3Njr3wVGHTL9Uyw44xQ26GwThElsnRBUG35vihfRo7UJ8sznQVhcvytqwB X-Received: by 10.180.82.166 with SMTP id j6mr18506250wiy.71.1403974699417; Sat, 28 Jun 2014 09:58:19 -0700 (PDT) X-Received: by 10.180.82.166 with SMTP id j6mr18506247wiy.71.1403974699336; Sat, 28 Jun 2014 09:58:19 -0700 (PDT) Received: from [192.168.1.242] ([95.144.51.46]) by mx.google.com with ESMTPSA id p3sm29026995wjw.13.2014.06.28.09.58.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Jun 2014 09:58:18 -0700 (PDT) Sender: Nigel Smart Message-ID: <53AEF428.3010302@cs.bris.ac.uk> Date: Sat, 28 Jun 2014 17:58:16 +0100 From: Nigel Smart User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iLuIHSCdPycn0HQIa-925zrSvyg Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 16:58:27 -0000 Hi > One way to attempt to unify the diverse world of ECC curves is to focus > on the underlying field, as opposed the curve itself. Consider Fp > operations with p=2^255-19 or p=2^256-189. In other words, for > n={256,384,512}, chose the closest C: p=2^n-C is a prime and make this p > "MUST". People who demand random primes will have to play along and > accept less "randomness" in their curves. Alas there could be some issues with primes close to powers of two. See our recent side channel attacks on EC-DSA with the Eurovision titles on ePrint "Just a Little Bit" etc. Such a p forces the group order to also be close to a power of two (by Hasse's Theorem). Whilst these papers show there are problems with the NIST choices in this respect, the above choices of p would be even worse. So unifying in this respect would be a bad idea IMHO. Nigel -- Prof. Nigel P. Smart | Tel +44 (0)117 9545163 Computer Science Department, | Fax +44 (0)117 9545208 Woodland Road, | Email nigel@cs.bris.ac.uk Bristol, BS8 1UB, UK | http://www.cs.bris.ac.uk~nigel From nobody Sat Jun 28 10:01:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C361A0380 for ; Sat, 28 Jun 2014 10:01: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdJatsUU_Yg8 for ; Sat, 28 Jun 2014 10:01:34 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418E21A037C for ; Sat, 28 Jun 2014 10:01:34 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id q9so3716642ykb.29 for ; Sat, 28 Jun 2014 10:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lDqI6ZLI7geF5UAvNoVdE9I7MTeebE4MKw1Tt634IFw=; b=Wu5loj94DeKN1DP6awxl737zWv528rJVbQq08gWnmb3Z4aTz3j38xxQwFeUTP43/71 9snw9fTQgufHVhD2n6GSbhzzynkdHZ/ijHodBl4uSpH4cwkVFL74nl8tFzLFMae3UHww xbQRl8gUGLUIKzysjCSaJcyQn9xYIKE4q7ERiQ/sy6aH0xbbWWpPi1FTbd7Qg/PlyZ31 kAGNdX9NvgVLRMqvE99udQl9vnFR1ZfDolwPxTS8uEAK+GWRZATd3A9RYzFRAMkXMZS9 aYByh4yVZ4VMApaO6CAJ/9f/11nmPB+Zubs+7Y/ffyz0sLp3qNO/O8OPgMvICZd8jcrK FTBw== MIME-Version: 1.0 X-Received: by 10.236.157.138 with SMTP id o10mr42928523yhk.48.1403974893519; Sat, 28 Jun 2014 10:01:33 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Sat, 28 Jun 2014 10:01:33 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Sat, 28 Jun 2014 10:01:33 -0700 (PDT) In-Reply-To: <53AEF428.3010302@cs.bris.ac.uk> References: <53AEF428.3010302@cs.bris.ac.uk> Date: Sat, 28 Jun 2014 10:01:33 -0700 Message-ID: From: Watson Ladd To: tls@ietf.org Content-Type: multipart/alternative; boundary=20cf303ea59acd482404fce8609d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gV1RtdSSsXxP7KOOdfviWvXLwi0 Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 17:01:36 -0000 --20cf303ea59acd482404fce8609d Content-Type: text/plain; charset=UTF-8 On Jun 28, 2014 9:58 AM, "Nigel Smart" wrote: > > Hi > > >> One way to attempt to unify the diverse world of ECC curves is to focus >> on the underlying field, as opposed the curve itself. Consider Fp >> operations with p=2^255-19 or p=2^256-189. In other words, for >> n={256,384,512}, chose the closest C: p=2^n-C is a prime and make this p >> "MUST". People who demand random primes will have to play along and >> accept less "randomness" in their curves. > > > Alas there could be some issues with primes close to powers of two. > See our recent side channel attacks on EC-DSA with the Eurovision > titles on ePrint "Just a Little Bit" etc. Such a p forces the > group order to also be close to a power of two (by Hasse's Theorem). > > Whilst these papers show there are problems with the NIST choices > in this respect, the above choices of p would be even worse. Simple solution: write constant time software. The principal of side channel attacks being established, one simply eliminates them all. > > So unifying in this respect would be a bad idea IMHO. > > Nigel > -- > Prof. Nigel P. Smart | Tel +44 (0)117 9545163 > Computer Science Department, | Fax +44 (0)117 9545208 > Woodland Road, | Email nigel@cs.bris.ac.uk > Bristol, BS8 1UB, UK | http://www.cs.bris.ac.uk~nigel > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --20cf303ea59acd482404fce8609d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 28, 2014 9:58 AM, "Nigel Smart" <nigel@cs.bris.ac.uk> wrote:
>
> Hi
>
>
>> One way to attempt to unify the diverse world of ECC curves is to = focus
>> on the underlying field, as opposed the curve itself. Consider Fp<= br> >> operations with p=3D2^255-19 or p=3D2^256-189. In other words, for=
>> n=3D{256,384,512}, chose the closest C: p=3D2^n-C is a prime and m= ake this p
>> "MUST". People who demand random primes will have to pla= y along and
>> accept less "randomness" in their curves.
>
>
> Alas there could be some issues with primes close to powers of two. > See our recent side channel attacks on EC-DSA with the Eurovision
> titles on ePrint "Just a Little Bit" etc. Such a p forces th= e
> group order to also be close to a power of two (by Hasse's Theorem= ).
>
> Whilst these papers show there are problems with the NIST choices
> in this respect, the above choices of p would be even worse.

Simple solution: write constant time software. The principal= of side channel attacks being established, one simply eliminates them all.=

>
> So unifying in this respect would be a bad idea IMHO.
>
> Nigel
> --
> Prof. Nigel P. Smart =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Tel +44 (0)117 9545= 163
> Computer Science Department, | Fax +44 (0)117 9545208
> Woodland Road, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Emai= l nigel@cs.bris.ac.uk
> Bristol, BS8 1UB, UK =C2=A0 =C2=A0 =C2=A0 =C2=A0 | http://www.cs.bris.ac.uk~nigel
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--20cf303ea59acd482404fce8609d-- From nobody Sat Jun 28 10:30:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56141A0384 for ; Sat, 28 Jun 2014 10:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXCBrxk5qJBZ for ; Sat, 28 Jun 2014 10:30:52 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7111A0382 for ; Sat, 28 Jun 2014 10:30:52 -0700 (PDT) Message-ID: <53AEFBC5.4000605@akr.io> Date: Sat, 28 Jun 2014 18:30:45 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <53AEF428.3010302@cs.bris.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-XSuqoQG6v_QZ7U951knMQMIkIo Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 17:30:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 28/06/2014 18:01, Watson Ladd wrote: >> See our recent side channel attacks on EC-DSA with the >> Eurovision > Simple solution: write constant time software. The principal of > side channel attacks being established, one simply eliminates them > all. And, of course, it would be remiss of me not to point out that all the good Curve25519 implementations are both fast and constant-time, the curve having been specified with the constant-time Montgomery ladder in mind in the first place. This is actually an area where 25519 wins big. (It should also be pointed out that constant-time over Weierstrass curves is possible, with enough care; see Langley/Möller/Kasper's implementation contributed to OpenSSL. I have yet to see any implementation capable of doing such a feat with arbitrary curves.) As far as code quality and reuse is concerned, what we've learned from things like Heartbleed I think is that "many eyes make bugs shallow" is only true when the eyes actually _look_ at the code. I don't think monoculture is to blame (we could just as easily have 10 bad implementations as 1), just complacency and a lack of sufficient auditing. I'd be much happier with a few implementations that everyone looks at very closely than many which aren't as well-audited. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTrvvFAAoJEOyEjtkWi2t6rxoQAKVeCkxlYZz/s5Ji1mI/s43c tPYVHycIbZkEEpLerpQpZk6XlBPgTiAwgEcBQd3P/MlZWi6N7XdvSap1WBG7S1U4 2uJyTJXlOEqZX/VJFSFX3zO/gLm+xhmanN7uoGfOoy+nf1szMbXDAJo+lmosFNzd MPGHYNI51b5dlcNQ7jYg/kUkMT5H14Wnm5EMTYsbM0iUV0hZ90lLKXvAZJh6pt8m hLFH/XDCF8KdfWFcEb/uAnYqMivxPSUl5IN87OTn4911CHIN90g8cWykXxqsXSJf bdC9fwAR4SCpCynm6MODhZlWJbteXA6gIRGZ/ynnjgcbhOE+7IYaaMuavExZQOB7 gNP3s6pcXe3xU19XIQbWTAtmXUkIBF6c0CI9PYiQFCUZDZpGx1aY4BBw0A08PYDs kkO8HA/NzhwVZU9pzF1HDaxuvfzkh7P4DVtUXNdOYPeefzOVt0ViwoGCxyaoPuZq idCEL6Ia3bZCa1OdTbOpRi/GA7T8NEZG6Wu8mL1UsY2FmfsYJgKSfpzIWa0FyGHr bg8rIPpS6HG4XXusDH2WINR6fCXYnbTKhKehXBUjnh6x6ccrGcHPX3S6kTRmISi8 tvQ+la8+ykMaDKfvEHmlTZmjl1ug4jlhwrAa62Wnz3/dkMF41PpcAHWGSnUdByFO iBpyxqrJoMGf/OhFwBka =fRNi -----END PGP SIGNATURE----- From nobody Sat Jun 28 12:58:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B371A040F for ; Sat, 28 Jun 2014 12:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bekU8ZRcIhZG for ; Sat, 28 Jun 2014 12:58:12 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF311A03E0 for ; Sat, 28 Jun 2014 12:58:11 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id im17so6063968vcb.25 for ; Sat, 28 Jun 2014 12:58:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=0UM6NOuQsNYRGfPbRZADbZP21avpnGzPcHZ5xZNEydc=; b=PRSkuzSuV0KBhU0zGc85U952b9igUQFZiLjh+jjzHylOMSlQdeRsu8sAb2Ia7TYUE0 fnM0qBDAU0W3Ldk1JarrHLOOpR1de+98dnYfBkvaBDUWjsHzKOYshe/B/EYYI6lozaDc 9rC6fV9QNdGKxbx0vNDTKQAV6hYObbkCdA1J6IBvqPc6xjtiZSrevDC7bA7KUjvhNw6c 41+fWfaFFi6EjsySXrxMhAjJMYLT7n1yhF+PMoDVzTbl5OoydapOQ4I4iMeje31ByRGm ZpKlEeaGfJYR4+8u7JybtGH3pk5qEm2l8xJMpVnWo1EONVZNl1K2dmgRlAnbP4E4ocv6 gG7Q== X-Gm-Message-State: ALoCoQmwWJUbZY4PrTIqV5DSVuWehTa/9oQaGsgxwIzYRVPabg9OSNoY07KKgCGQTWczaUd55Uqh MIME-Version: 1.0 X-Received: by 10.52.30.9 with SMTP id o9mr23263135vdh.15.1403985491077; Sat, 28 Jun 2014 12:58:11 -0700 (PDT) Received: by 10.52.120.73 with HTTP; Sat, 28 Jun 2014 12:58:10 -0700 (PDT) X-Originating-IP: [208.66.210.102] In-Reply-To: References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> Date: Sat, 28 Jun 2014 15:58:10 -0400 Message-ID: From: Steve Checkoway To: "" Content-Type: multipart/alternative; boundary=20cf3079bc7877460704fcead804 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YMY38QYuPWNs8jopg25_0aXFpP4 Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 19:58:14 -0000 --20cf3079bc7877460704fcead804 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 25, 2014 at 4:03 PM, Joseph Salowey (jsalowey) < jsalowey@cisco.com> wrote: > > > [Joe] to simplify: > > 1. In favor of removing renegotiation > 2. In favor of removing renegotiation with the addition of rekey facility > 3. Not in favor of removing renegotiation I prefer 2. -- Steve Checkoway --20cf3079bc7877460704fcead804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 25, 2014 at 4:03 PM, Joseph Salowey (jsalowey) <jsalo= wey@cisco.com> wrote:

=
[Joe] to simplify:

1. =C2=A0In favor of removing renegotiation
2. =C2=A0In favor of removing renegotiation with the addition of rekey faci= lity
3. =C2=A0Not in favor of removing renegotiation

=
I prefer 2.

--=C2=A0
Steve Checkow= ay

--20cf3079bc7877460704fcead804-- From nobody Sat Jun 28 12:59:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023E41A0411 for ; Sat, 28 Jun 2014 12:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtcPDMhUQtia for ; Sat, 28 Jun 2014 12:59:03 -0700 (PDT) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160411A03E0 for ; Sat, 28 Jun 2014 12:59:03 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id eu11so6296519pac.25 for ; Sat, 28 Jun 2014 12:59:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nQbQdWPs9TMkMWlPSkoRvGaEL2k5z3WlP0JL247h07M=; b=T8GqX+DDXgiDHBK/EzUiwyw8GpppBUPpE8Ga/4iAq+LrugFhJ7mVkUFo2n3Nk8cie/ BXOEzGApzCoc0kYQ1eqmRRTRR01JUUV8O6fKv5V4Wa4FobNzHNVxKlx8ghg2jAHPBNM5 /NCKddVHOKUBU1ZE1+qJ5uaSG6xyo8hbrqfuZ6t2yjMZKiL//mG+10tqVwXU5y2kDG8M EeagO3UBeVu4t0iLMvem/A8YyocNnUePb05qsuVdv0nyj/3Dr3YYC5Mntkw0zgxJwS4/ Pov3R/1fd1mwd8rl6IkWkveqRAPxQbCotqzrT1Yq3Aibz8NTvq7OFvkfAYXHX/fc7opm Nqcw== X-Gm-Message-State: ALoCoQmL+bi6c+nGD0lmahX1M16/2nLI/IQCzEt+RedZ0QHcM+yifomG8iIugJAQ1aGcq6jnlKcf X-Received: by 10.68.125.135 with SMTP id mq7mr40127884pbb.103.1403985542693; Sat, 28 Jun 2014 12:59:02 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:390:b4d7:6f3f:f3ac:4c6? ([2601:a:2a00:390:b4d7:6f3f:f3ac:4c6]) by mx.google.com with ESMTPSA id be7sm72128483pad.9.2014.06.28.12.59.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Jun 2014 12:59:02 -0700 (PDT) Message-ID: <53AF1E98.2080906@nthpermutation.com> Date: Sat, 28 Jun 2014 15:59:20 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "tls@ietf.org" References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> In-Reply-To: <53AD56D2.7060200@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M4HjYv2MHvv9iRqouYd8yfTKt68 Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 19:59:07 -0000 Hi - I waited about 48 hours to get most of the comments out there. With respect to Stephen's note, I mostly agree with his conclusions with respect to the current consensus within the IETF. But I did want to address one particular comment he made as well as respond to some other comments. EKR is correct that this is a larger question than TLS, unfortunately we're first up. So first on "small but vocal minority agitating": On 6/27/2014 7:34 AM, Stephen Farrell wrote: > > Also, I have to say the language in Mike's original mail was, > at best, unfortunate, e.g. "small but vocal minority agitating" > is not likely to kick off a calm reasoned debate, and is > definitely not going to help the TLS WG keep focused on its > work so I really hope folks don't respond in kind, and if the > chairs want to loudly stomp on threads with such language > (regardless of source and mostly regardless of topic) they > have my full backing. > I'm not exactly sure what Stephen is objecting to in the above. Here's what I saw from in-person and email discussions: A small group that was very vocal about throwing out anything to do with NIST/US Government crypto advocating for the use of Curve25519 as a replacement for the NIST curves and crypto and also advocating that it be the one true curve for the IETF. A larger group that was more focused on performance and security and talking about the advantages of Curve25519 and then incidentally mentioning their discomfort with the possibility of tampering on the NIST curves. (Hi Alyssa....) A slightly larger group that was "looks OK to me as an additional system" (maybe the majority of the CFRG based on transcripts?) An even larger group that was "crypto? Meh! Tell me what to use". What I didn't see was hue and cry from ACI Worldwide, American Express Company, American Financial Services Association, Bank of America, Capital One, Certicom Corporation, Citigroup, Inc., Deluxe Corporation, Diebold, Inc.,Discover Financial Services, eFunds Corporation, Federal Reserve Bank, First Data Corporation, Fiserv, Hewlett Packard, Hypercom, IBM Corporation, Ingenico, J.P. Morgan Chase & Co, KPMG LLP, MagTek, Inc., MasterCard International, National Association of Convenience Stores, National Security Agency, NCR Corporation, Savvis, SWIFT, The Clearing House, Unisys Corporation, University Bank, VeriFone, Inc., VECTORsgi, VISA, Wachovia Bank, and Wells Fargo Bank to throw out the existing EC cryptography. The above list of companies are those listed in the preface of the X9.62 ECDSA crypto standard as participants/approvers for X9 and ultimately a group like that or larger are ones that will decide whether or not specific crypto will be acceptable for the commercial community. [X9.62 ECDH had a similar group, but would have required more work on my part to edit it down to the company list] In the scheme of things, the IETF participants are - sorry - a very very small minority of the people who have to be happy with Curve25519. Unlike all the other EC stuff we do (to specifically include the brainpool curves), Curve25519 is NOT within an accepted cryptography standard. For the IETF to decide it wants to go into such business seems to be way outside our competences. My original suggestion was meant to address the "NIST curves might be booby trapped" concerns of the first two groups I note above in a way that would be acceptable to that larger commercial community and for no other reason. Going back to Stephen's comment - Stephen, would you care to craft a better description of the first group for me? I didn't mean to offend, but I seriously don't think my "language" should be "loudly stomped" and I'm unclear why you do. >>>> "IPR Issues": The specific set of IPR issues that concern me are the license and copyright with respect to DJB's basic work. Unless there is a "perpetual, paid up, world-wide, irrevocable" license for anything that he's done (or could do in this space) there are possible future issues. Something as simple as invoking the already existing copyright on the curve data could be problematic. Note that I'm not saying this will happen, or that its even contemplated, but it's a potential problem that should be resolved formally and legally. (It's possible there is such a document, but I went looking and didn't find it. Some of this is tagged "public domain" but that's probably insufficient for most lawyers). If DJB et al is willing to transfer change control/copyright/patent rights/moral rights to the IETF (via appropriate documentation), and the IETF is willing to publish an actual standard then this objection goes away. >>>>> "CFRG has selected Curve25519 as the preferred curve for the IETF" This statement was made in varying forms from "curve25519 is secure enough to be used" to "curve25519 is *the* curve for the IETF" in the discussion on this thread. From reading the jabber log reference that was provided, I'd say that the former statement is more correct than the latter, but that's based on very little documentary evidence one way or the other. In any event, there are probably a few procedural issues that need to be resolved before Curve25519 becomes "the" preferred curve and system for the IETF. First is that the CFRG is a IRTF working group and not an IETF working group. I believe that the CFRG can make recommendations, but the adoption of those recommendations as a BCP is an IETF issue. In the transcript I read, Yoav noted that a draft and RFC needed to be done. So my take on the current state is that the CFRG has decided by voice vote/hum to make some sort of recommendation, but such recommendation has not yet been formalized. Once that's done, then the IETF in the person of the SAAG, Security Area AD's and the IESG would need to take the recommendation and turn it into a BCP along with all the documentation necessary to make Curve25519 into a useable standard (e.g. draft-josefsson-*, with TLS specifics removed so the crypto can be used in a general fashion). *sigh* If the IETF is really going to get into the business of standardizing crypto, we need to get the process for doing so right the first time rather than just plugging it in to TLS and hoping we don't have to redo it over and over again. Mike From nobody Sat Jun 28 13:06:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249451A0417 for ; Sat, 28 Jun 2014 13:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MANGLED_OFF=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77MgRC5_E4dM for ; Sat, 28 Jun 2014 13:06:21 -0700 (PDT) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id BED221A0031 for ; Sat, 28 Jun 2014 13:06:21 -0700 (PDT) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta07.emeryville.ca.mail.comcast.net with comcast id Kvth1o00817UAYkA7w6M8M; Sat, 28 Jun 2014 20:06:21 +0000 Received: from [192.168.1.145] ([71.202.164.227]) by omta13.emeryville.ca.mail.comcast.net with comcast id Kw6L1o00C4uhcbK8Zw6LNd; Sat, 28 Jun 2014 20:06:21 +0000 Message-ID: <53AF203C.10902@brainhub.org> Date: Sat, 28 Jun 2014 13:06:20 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <53AEF428.3010302@cs.bris.ac.uk> In-Reply-To: <53AEF428.3010302@cs.bris.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403985981; bh=K7mzsQF/xGr20xM9eLOWtEnDZbLnf73OhtA1g2KVXMg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fv2QJi5lNUs0xnft60RR2xNL5xC5DSCn7mGtX0LyCVzQlbpu1AFkWuynPiiIXqZDo 40pB4n4Q2kXx43ar/JjiyAaHu/+ORZfzy5mSCA05Mm/YS1QkOePABU9vo2CLHGTPb/ +0uM6dCcleEqVBekF0iV6GS3+dr1fhwHV3CeBIUBEUrXUIN//TROEf2jtj0UjvlhSG r7CNJoZR8Z5H5QtbpPgCPRO7ReBIjjmBoEa8RqN9l2x6K6BIzSAPUT4YOnDnL83ANL XJ9DSbOQAz3Be4mLZqg+Sk5dz1BvmII2WdpKmvB1ZPZgbJnS4XyZSJfiKf2znahymi 24MK6RErePvBg== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G9xVNQqmsSDOH4FU-GLa0RaO7K8 Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 20:06:23 -0000 On 06/28/2014 09:58 AM, Nigel Smart wrote: > Hi > >> One way to attempt to unify the diverse world of ECC curves is to focus >> on the underlying field, as opposed the curve itself. Consider Fp >> operations with p=2^255-19 or p=2^256-189. In other words, for >> n={256,384,512}, chose the closest C: p=2^n-C is a prime and make this p >> "MUST". People who demand random primes will have to play along and >> accept less "randomness" in their curves. > > Alas there could be some issues with primes close to powers of two. > See our recent side channel attacks on EC-DSA with the Eurovision > titles on ePrint "Just a Little Bit" etc. Such a p forces the > group order to also be close to a power of two (by Hasse's Theorem). > > Whilst these papers show there are problems with the NIST choices > in this respect, the above choices of p would be even worse. > > So unifying in this respect would be a bad idea IMHO. > > Nigel The paper https://eprint.iacr.org/2014/434.pdf describes a technique to recover the bits of a secret intermediate value used in the ECDSA algorithm. These bits are in the high half of the large integer. This improved method works when EC order is close to 2^n, which is the case with F(p): p=2^n-C due to the relationship between the two per Hasse theorem. A random p will have high half of its bits random, and this will deny such an enhanced side-channel attack. A generalized pseudo-mersenne prime should help as well. The exploited side channel in the paper is provided by the ECDSA algorithm, through the ECC field scalar multiplication. In other words, we are not talking about a side channel in an implementation of an F(p) being exploited. IMO fixing the p will help with high-quality implementations of F(p). What this p is, is the question to answer based on pros and cons. p that allows faster operations is inevitably less secure because the Pollard-rho on the ECC is faster with such a p. A safest p cannot save an ECC implementation from side-channel bugs. From nobody Sat Jun 28 13:13:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CF81A0040 for ; Sat, 28 Jun 2014 13:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qgDCpJf-3KG for ; Sat, 28 Jun 2014 13:13:41 -0700 (PDT) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B791A0033 for ; Sat, 28 Jun 2014 13:13:41 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so6421256wes.21 for ; Sat, 28 Jun 2014 13:13:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iRSonF/iJpTQFFbxjmhJOrJ84b5Si1fiPXeQDFMt/Co=; b=KznDCmaZzLVV22vyDe8jObC8TmnDGNih8uLUj1uTiQUVcPPr7wNXhv4BcvQu2IQjF7 WnJIGspe71A3jB/x+GnNM+hdcAT5Sw2QHyfHHAhdJhMrgNpl+hG9hUz5WLRoTAzzcLRp ZFcibG8lGeqecz8+iV9ZX3dZlQ8IU/yjdT6urZsCpLRgEDzvefAh0//9NLtfXNbyRRBT Rv5i+U/E/isULzC7bAglOi0jrMsOB3dLUp6FfeRT7dhXJJxKp87H265bDqqiOnEPeG9q sR6vuqrr2mjAFxqHJtPf3RQx+D6PTK3zbt8s1KLw/1k2ZLvouVY2eJuaXGfk9sb+fz8i OxWg== X-Gm-Message-State: ALoCoQkA0a0R+ahhir4fiH2ErCTySt59mxxDuUAZcnj3aKDV7u9O2fIP1k4igae24IHpalqTeipw X-Received: by 10.180.81.72 with SMTP id y8mr19811567wix.7.1403986419820; Sat, 28 Jun 2014 13:13:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sat, 28 Jun 2014 13:12:59 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <53AF1E98.2080906@nthpermutation.com> References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> From: Eric Rescorla Date: Sat, 28 Jun 2014 13:12:59 -0700 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=f46d04428cf4d2c7d804fceb0fb2 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d0uDVauJrjSVnP31ktEScFrw8V0 Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 20:13:42 -0000 --f46d04428cf4d2c7d804fceb0fb2 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 28, 2014 at 12:59 PM, Michael StJohns wrote: [snip] > In any event, there are probably a few procedural issues that need to be > resolved before Curve25519 becomes "the" preferred curve and system for the > IETF. To the best of my knowledge this question is not currently on the table. Rather, the request to CFRG was to propose an additional set of curves, not to propose a set of curves to be used in preference to the existing standardized set. I suppose we could ask that question as well, but I do not believe that is the current question at hand. -Ekr --f46d04428cf4d2c7d804fceb0fb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sat, Jun 28, 2014 at 12:59 PM, Michael StJohns <msj@nthper= mutation.com> wrote:
[snip]
In any event, there are probably a few procedural issues that need to be re= solved before Curve25519 becomes "the" preferred curve and system= for the IETF.

To the best of my knowledge = this question is not currently on the
table. Rather, the request to CFRG was to propose an additional
<= div>set of curves, not to propose a set of curves to be used in preference<= /div>
to the existing standardized set. I suppose we could ask that que= stion
as well, but I do not believe that is the current question at hand.

-Ekr
=C2=A0
--f46d04428cf4d2c7d804fceb0fb2-- From nobody Sat Jun 28 13:31:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586F21A0069 for ; Sat, 28 Jun 2014 13:31:50 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgTYa35HPq1g for ; Sat, 28 Jun 2014 13:31:48 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by ietfa.amsl.com (Postfix) with ESMTP id E80401A0064 for ; Sat, 28 Jun 2014 13:31:48 -0700 (PDT) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta09.emeryville.ca.mail.comcast.net with comcast id KwKx1o0010QkzPwA9wXooU; Sat, 28 Jun 2014 20:31:48 +0000 Received: from [192.168.1.145] ([71.202.164.227]) by omta02.emeryville.ca.mail.comcast.net with comcast id KwXn1o00M4uhcbK8NwXoLX; Sat, 28 Jun 2014 20:31:48 +0000 Message-ID: <53AF2633.9000207@brainhub.org> Date: Sat, 28 Jun 2014 13:31:47 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> In-Reply-To: <53AF1E98.2080906@nthpermutation.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403987508; bh=axfYSiAviTQt5xcXUtBBSsKQAMUacSlQzrR7ji2Zx3M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rs75IoJamdo8aJBeLYssNDe/SZ3QXwj27fxrOiiRXFRCtee4UtLR8vzueFOG+1Yjy NNWcqA2wxz5gfzt5b5DtGntHdFNqKkawiZ6GcKU0qZTtq6RTJ+8pIRZd2ICzp1AgP+ kd1O3w3wOxq/2eg81FbgjrW2MPrNgUwIf5u4y2CNSTOckltlmsbNO1KIf5yjZed0BH KSDy9bONZXj3TvvlGy7H8EeCEBYzr4ZZQhHsVrokI8/lLtpzzawM4zE9sH6y16bMpX RD3bl+1eo0zBqJxM1fQhLDqFlNApSHvkzQp3MSGwmUL7lvtWMqDY1ppm2JiYz9PI3G fAOwBkJM7TfjQ== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/L5RQoW-sEV1hQsqfaFLRVmkv9q8 Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 20:31:50 -0000 On 06/28/2014 12:59 PM, Michael StJohns wrote: > > >>>> "IPR Issues": > > The specific set of IPR issues that concern me are the license and > copyright with respect to DJB's basic work. Unless there is a > "perpetual, paid up, world-wide, irrevocable" license for anything > that he's done (or could do in this space) there are possible future > issues. Something as simple as invoking the already existing > copyright on the curve data could be problematic. > > Note that I'm not saying this will happen, or that its even > contemplated, but it's a potential problem that should be resolved > formally and legally. > > (It's possible there is such a document, but I went looking and didn't > find it. Some of this is tagged "public domain" but that's probably > insufficient for most lawyers). > > If DJB et al is willing to transfer change control/copyright/patent > rights/moral rights to the IETF (via appropriate documentation), and > the IETF is willing to publish an actual standard then this objection > goes away. BTW, focusing on F(p) (which is not really an ECC) also helps with the above concerns. p = 2^n-C is free due to the following expired patent : https://www.google.com/patents/US5159632 . IMO it would appear "safer" for hardware vendors to only implement/provide optimization primitives for F(p), for a couple of specific p's. From nobody Sat Jun 28 13:32:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAD21A006D for ; Sat, 28 Jun 2014 13:32:15 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7aS-d89bKnJ for ; Sat, 28 Jun 2014 13:32:14 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594DB1A0064 for ; Sat, 28 Jun 2014 13:32:14 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c9so5651921qcz.37 for ; Sat, 28 Jun 2014 13:32:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=GQv6kCoNj/RnV77ydabAhWq5JLKgXBBlCjJ7avdlUu4=; b=NqVDJA68Hp2O5G1jf/XFCg/ZU/FGF/p09mslvSyHU4ZFSWh5OLMI7EGs4+uimxCb9a tircGqTPhf6L4JM7Nw/sYjuAyPoHNFijASlF/3TOENF7hiZ3m/ggZyepc4p0ArVKE7Hg 2CKvrnxW8khcq2VrnFtlufeqArXoozNw0AjRgUfILEa6PzJ8AXUvcz8junvVk+Tuo7R5 tNo1xCRiwcdeOzakmDSQAGP6Vr6eT5/efKxPpMl7vbLb2/J/kaFoYDwt337oNuTmfAfy Y8jjQJclA/WWegGoGeSh/fLEEP/4K5oURTb+CX6dsmOZdOTnHiGJqiaINRYfJXEPvkWF pm1A== X-Gm-Message-State: ALoCoQmxAQf4RIgj5ienItWoJHbwV1Vh7+6jylnzaOM/iEqPkhd1VPuoFqdledqTMEEWu5caQo4f X-Received: by 10.140.104.106 with SMTP id z97mr35386706qge.21.1403987533473; Sat, 28 Jun 2014 13:32:13 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:390:b4d7:6f3f:f3ac:4c6? ([2601:a:2a00:390:b4d7:6f3f:f3ac:4c6]) by mx.google.com with ESMTPSA id s8sm23295005qac.49.2014.06.28.13.32.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Jun 2014 13:32:13 -0700 (PDT) Message-ID: <53AF2660.7040206@nthpermutation.com> Date: Sat, 28 Jun 2014 16:32:32 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Eric Rescorla References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060306080707050007010705" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ciR4ymvjif9g2utVa-QI2ODNQH4 Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 20:32:15 -0000 This is a multi-part message in MIME format. --------------060306080707050007010705 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/28/2014 4:12 PM, Eric Rescorla wrote: > > > > On Sat, Jun 28, 2014 at 12:59 PM, Michael StJohns > > wrote: > [snip] > > In any event, there are probably a few procedural issues that need > to be resolved before Curve25519 becomes "the" preferred curve and > system for the IETF. > > > To the best of my knowledge this question is not currently on the > table. Rather, the request to CFRG was to propose an additional > set of curves, not to propose a set of curves to be used in preference > to the existing standardized set. I suppose we could ask that question > as well, but I do not believe that is the current question at hand. > > -Ekr I don't know the reality of what the CFRG is doing/has done absent an actual document. But that was the statement by Alyssa in her email on this thread and she referenced Rich Salz's email as saying the same thing or similar. I think what you wanted is "Acceptable for use" (MAY): I think what Rich said was "Recommended for use" (SHOULD) and I think what Alyssa said was "Preferred for use" (MUST UNLESS). So what you asked for may not be what you got. Mike --------------060306080707050007010705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 6/28/2014 4:12 PM, Eric Rescorla wrote:



On Sat, Jun 28, 2014 at 12:59 PM, Michael StJohns <msj@nthpermutation.com> wrote:
[snip]
In any event, there are probably a few procedural issues that need to be resolved before Curve25519 becomes "the" preferred curve and system for the IETF.

To the best of my knowledge this question is not currently on the
table. Rather, the request to CFRG was to propose an additional
set of curves, not to propose a set of curves to be used in preference
to the existing standardized set. I suppose we could ask that question
as well, but I do not believe that is the current question at hand.

-Ekr
 

I don't know the reality of what the CFRG is doing/has done absent an actual document.   But that was the statement by Alyssa in her email on this thread and she referenced Rich Salz's email as saying the same thing or similar.

I think what you wanted is "Acceptable for use" (MAY):  I think what Rich said was "Recommended for use" (SHOULD) and I think what Alyssa said was "Preferred for use" (MUST UNLESS).  So what you asked for may not be what you got.  

Mike



--------------060306080707050007010705-- From nobody Sat Jun 28 13:39:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392281A0078 for ; Sat, 28 Jun 2014 13:39:16 -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, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3L9fupf1cSc for ; Sat, 28 Jun 2014 13:39:14 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3741A0073 for ; Sat, 28 Jun 2014 13:39:14 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id a108so651895qge.4 for ; Sat, 28 Jun 2014 13:39:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7H6HrlNv22Dp31+oB5Kk3Vgm9HbVDvKFzW+Vcuc7dTU=; b=IiHwTSBTvwBTHFLmThQuhTiTGTCTzgPTtVofyZJUcKs39491M0OslkmHDczrtfGMrd uwKvvmxbS8mPrNDsPZLoi6dYsTVRLAkzH6niiGs1wFZXVvATQTt3qOvlYabStkPdJ2rt bl2pFUwOrnBARICVeYM68GueYmb4fimR8Rg4TKMO9ip0bLm0yXRjISwtOBaGxzllHqRA HGkxVfdR/MUIgBgwRhPksKOkT7IB70cK6/Rf3VevF00pzWkCHr3SB91gdX3a2C97caWP GacTpik0Y7OgVvCd0gWF5uLMsQoWhjFX9xhywW0Fuxw1OpfpPvaCtmI8jWgvM7vEq2mT ZPyg== X-Gm-Message-State: ALoCoQkXc4pn+CmobOXd173fZZjs1oRRa2Lno+nnqs+rxtJvV8EmE5duMPqojcM3unl9to9xVYVy X-Received: by 10.224.28.65 with SMTP id l1mr25193505qac.87.1403987953732; Sat, 28 Jun 2014 13:39:13 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:390:b4d7:6f3f:f3ac:4c6? ([2601:a:2a00:390:b4d7:6f3f:f3ac:4c6]) by mx.google.com with ESMTPSA id b51sm8878610qgd.49.2014.06.28.13.39.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Jun 2014 13:39:13 -0700 (PDT) Message-ID: <53AF2804.5080204@nthpermutation.com> Date: Sat, 28 Jun 2014 16:39:32 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <53AF2633.9000207@brainhub.org> In-Reply-To: <53AF2633.9000207@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fl9qWbJk0wHlK7xNWzO7PcoSsG0 Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 20:39:16 -0000 On 6/28/2014 4:31 PM, Andrey Jivsov wrote: > On 06/28/2014 12:59 PM, Michael StJohns wrote: >> >> >>>> "IPR Issues": >> >> The specific set of IPR issues that concern me are the license and >> copyright with respect to DJB's basic work. Unless there is a >> "perpetual, paid up, world-wide, irrevocable" license for anything >> that he's done (or could do in this space) there are possible future >> issues. Something as simple as invoking the already existing >> copyright on the curve data could be problematic. >> >> Note that I'm not saying this will happen, or that its even >> contemplated, but it's a potential problem that should be resolved >> formally and legally. >> >> (It's possible there is such a document, but I went looking and >> didn't find it. Some of this is tagged "public domain" but that's >> probably insufficient for most lawyers). >> >> If DJB et al is willing to transfer change control/copyright/patent >> rights/moral rights to the IETF (via appropriate documentation), and >> the IETF is willing to publish an actual standard then this objection >> goes away. > > BTW, focusing on F(p) (which is not really an ECC) also helps with the > above concerns. p = 2^n-C is free due to the following expired patent > : https://www.google.com/patents/US5159632 . > > IMO it would appear "safer" for hardware vendors to only > implement/provide optimization primitives for F(p), for a couple of > specific p's. If I generated parameters for F(p) and published them under normal copyright, AFAIK you couldn't use them absent a copyright license regardless of patent rights. For the existing curves, those grants of license exist in some form or another. To avoid IPR issues, you need a set of both technology (patent) rights and parameter (copyright) rights. As I said, I just want the documentation to avoid future issues. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From nobody Sat Jun 28 13:52:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4121A0085 for ; Sat, 28 Jun 2014 13:52:29 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5TZoGpCEmsj for ; Sat, 28 Jun 2014 13:52:27 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id 86B081A0084 for ; Sat, 28 Jun 2014 13:52:27 -0700 (PDT) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta13.emeryville.ca.mail.comcast.net with comcast id Kwg21o0010x6nqcADwsTsg; Sat, 28 Jun 2014 20:52:27 +0000 Received: from [192.168.1.145] ([71.202.164.227]) by omta12.emeryville.ca.mail.comcast.net with comcast id KwsS1o00G4uhcbK8YwsSYJ; Sat, 28 Jun 2014 20:52:26 +0000 Message-ID: <53AF2B0A.7030205@brainhub.org> Date: Sat, 28 Jun 2014 13:52:26 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <53AF2633.9000207@brainhub.org> <53AF2804.5080204@nthpermutation.com> In-Reply-To: <53AF2804.5080204@nthpermutation.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1403988747; bh=1t0neS9ojaunSCoUySj+ldRj4JFNqgKgN/TCzzNEh2o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qeEb7l94gsp7OVo5sAsxaZEgJNZ17HYKVp4EkaWQIhwxD0lTXwZZ2qdL8xq3e5BfI SOk4nCLyyh9AJCIMygn4o9EvrTbyc5Oy48rZnFarNsXWBlB+MfrqwwLNzVgVjHU/HD 1mTE8cnERmbEFPhxJ+hn1YpAiPO2WIL9Um13c3cq9DEWe8WyCLCYkUA2CSmf4iRsa/ mcvw+dw8OYVEkOdEJlaoVbbD7eHe/D2goMXNQUjwGAilNeNsWgWLAmzGl15K7DfBei g0TjgfYyR9RQak+RuBCIpehUtWqqYkMhCRkgLn3TD3bIuh1YJrX53ZUMaPgkSIT3XR D5aIFFHBhuoEw== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EooQoYjEj141xHAPHYPgE_fOPQQ Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 20:52:29 -0000 On 06/28/2014 01:39 PM, Michael StJohns wrote: > On 6/28/2014 4:31 PM, Andrey Jivsov wrote: >> On 06/28/2014 12:59 PM, Michael StJohns wrote: >>> >>> >>>> "IPR Issues": >>> >>> The specific set of IPR issues that concern me are the license and >>> copyright with respect to DJB's basic work. Unless there is a >>> "perpetual, paid up, world-wide, irrevocable" license for anything >>> that he's done (or could do in this space) there are possible future >>> issues. Something as simple as invoking the already existing >>> copyright on the curve data could be problematic. >>> >>> Note that I'm not saying this will happen, or that its even >>> contemplated, but it's a potential problem that should be resolved >>> formally and legally. >>> >>> (It's possible there is such a document, but I went looking and >>> didn't find it. Some of this is tagged "public domain" but that's >>> probably insufficient for most lawyers). >>> >>> If DJB et al is willing to transfer change control/copyright/patent >>> rights/moral rights to the IETF (via appropriate documentation), and >>> the IETF is willing to publish an actual standard then this >>> objection goes away. >> >> BTW, focusing on F(p) (which is not really an ECC) also helps with >> the above concerns. p = 2^n-C is free due to the following expired >> patent : https://www.google.com/patents/US5159632 . >> >> IMO it would appear "safer" for hardware vendors to only >> implement/provide optimization primitives for F(p), for a couple of >> specific p's. > > If I generated parameters for F(p) and published them under normal > copyright, AFAIK you couldn't use them absent a copyright license > regardless of patent rights. For the existing curves, those grants > of license exist in some form or another. To avoid IPR issues, you > need a set of both technology (patent) rights and parameter > (copyright) rights. > > As I said, I just want the documentation to avoid future issues. Staying within F(p), we know that 2^n - C is now free as an idea (ref. above). (There is a speculation is that P-521 was not made a part of Suite B due to that now expired patent ) It makes sense to have C smallest. C=189 for n=256 . ( As I wrote earlier, I don't see why it should be 2^255-19, but that p is selected using the same criteria ) It should be possible to find prior work by people who experimented with such primes. ( Starting from http://www.iacr.org/archive/ches2010/62250075/62250075.pdf, regarding 2^256-189, and walking back in time... ) From nobody Sat Jun 28 14:45:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D7D1A00A9 for ; Sat, 28 Jun 2014 14:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-3D_D8UbTLB for ; Sat, 28 Jun 2014 14:45:30 -0700 (PDT) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E383A1A00A8 for ; Sat, 28 Jun 2014 14:45:29 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so6476074wes.8 for ; Sat, 28 Jun 2014 14:45:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fvf5P6m8k0L4IdVZscsi8nYdBnA6jqJnesQZ101RGMc=; b=AtfdEh8EOiMq7DyqETFbP8rQSslufQHurK3Jj1OhLCyNgCrs41V5uYmu7y62ygn6Xy vH2QjZ4fBXhKK1ELcNm4SPntGp7UXVlF90BjSGoSxGY/Q1GkFI4WHsX1QsHKN3ewsOms yXbHp7e1UeRelc6kXsiZj5n2PJJKV0ideqGiL6zOwXfWdiwjW2Wbb6t+1j006SMYjt7B rkj+5CB+ebVZcCx0YQquMtqhClE+IvIorauQ+Lv4pWpXtuQ0IBokRrzslMcsnwlYwUaG 6oa+bv9qaAhtnGGItgGHRi4i86kpTWhmyEQFO9XuR1Q3LUcgpShDvEpSX7NFu6qAw+aa vElg== X-Gm-Message-State: ALoCoQlUQ8O7Z/Zzh2wXfQjO08xh2N6LWvrFDpEcJCTpSdpZbVkdsfu55qqtNt3D0LYEui2PtL/z X-Received: by 10.180.183.131 with SMTP id em3mr19834800wic.56.1403991928509; Sat, 28 Jun 2014 14:45:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sat, 28 Jun 2014 14:44:48 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <53AF2660.7040206@nthpermutation.com> References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <53AF2660.7040206@nthpermutation.com> From: Eric Rescorla Date: Sat, 28 Jun 2014 14:44:48 -0700 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=001a11c23e222aac6104fcec5855 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lTiVdlrI-8fg75I0Q36jVnTOB-o Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 21:45:32 -0000 --001a11c23e222aac6104fcec5855 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 28, 2014 at 1:32 PM, Michael StJohns wrote: > On 6/28/2014 4:12 PM, Eric Rescorla wrote: > > > > > On Sat, Jun 28, 2014 at 12:59 PM, Michael StJohns > wrote: > [snip] > >> In any event, there are probably a few procedural issues that need to be >> resolved before Curve25519 becomes "the" preferred curve and system for the >> IETF. > > > To the best of my knowledge this question is not currently on the > table. Rather, the request to CFRG was to propose an additional > set of curves, not to propose a set of curves to be used in preference > to the existing standardized set. I suppose we could ask that question > as well, but I do not believe that is the current question at hand. > > -Ekr > > > > I don't know the reality of what the CFRG is doing/has done absent an > actual document. But that was the statement by Alyssa in her email on > this thread and she referenced Rich Salz's email as saying the same thing > or similar. > > I think what you wanted is "Acceptable for use" (MAY): I think what Rich > said was "Recommended for use" (SHOULD) and I think what Alyssa said was > "Preferred for use" (MUST UNLESS). So what you asked for may not be what > you got. > Well, as you say, so far we don't have anything, however, I was on the call (and said that what TLS needed was more or less what I said in the material quoted) above and I don't remember anyone disagreeing. I didn't hear any real discussion of CFRG making a recommendation that would supplant the existing curves that have been standardized and I certainly don't think that there was any sort of consensus to do so. Again, this isn't to say that the CFRG might not wish to recommend that, but I don't believe that is the question that was asked. Since we are discussing this in the context of TLS, historically the TLS WG has not said that one ought to use a particular set of cryptographic algorithms, either at MUST *or* SHOULD level. Rather, we have decided: 1. What algorithms get code point assignments at either standards track or non-standards track levels. 2. What algorithms we require you to implement to be conformant. 3. What algorithms we recommend one not use in the future even though they have code point assignments (as in Andrei's RC4 draft). Note that these don't really fall cleanly into the MAY/SHOULD/MUST classification you suggest here, but as I say, that's our historical practice and so far I haven't heard much discussion of changing that practice for TLS. -Ekr --001a11c23e222aac6104fcec5855 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sat, Jun 28, 2014 at 1:32 PM, Michael StJohns = <msj@nthperm= utation.com> wrote:
=20 =20 =20
On 6/28/2014 4:12 PM, Eric Rescorla wrote:



On Sat, Jun 28, 2014 at 12:59 PM, Michael StJohns <msj@nthpermutation.com> wrote:
[snip]
In any event, there are probably a few procedural issues that need to be resolved before Curve25519 becomes "the&= quot; preferred curve and system for the IETF.

To the best of my knowledge this question is not currently on the
table. Rather, the request to CFRG was to propose an additional
set of curves, not to propose a set of curves to be used in preference
to the existing standardized set. I suppose we could ask that question
as well, but I do not believe that is the current question at hand.

-Ekr
=C2=A0

I don't know the reality of what the CFRG is doing/has done absent an actual document.=C2=A0=C2=A0 But that was the statement by Alyssa in= her email on this thread and she referenced Rich Salz's email as saying the same thing or similar.

I think what you wanted is "Acceptable for use" (MAY):=C2=A0 = I think what Rich said was "Recommended for use" (SHOULD) and I think what= Alyssa said was "Preferred for use" (MUST UNLESS).=C2=A0 So what you= asked for may not be what you got.=C2=A0=C2=A0

Well, as you say, so far we don't have anything, however,= I was on the
call (and said that what TLS needed was more or les= s what I said in
the material quoted) above and I don't remember anyone disagreeing= . I
didn't hear any real discussion of CFRG making a recommen= dation that would
supplant the existing curves that have been sta= ndardized and I certainly
don't think that there was any sort of consensus to do so. A= gain, this isn't
to say that the CFRG might not wish to recom= mend that, but I don't
believe that is the question that was = asked.


Since we are discussing this in the= context of TLS, historically the
TLS WG has not said that one ou= ght to use a particular set of
cryptographic algorithms, either a= t MUST *or* SHOULD level. Rather, we
have decided:

1. What algorithms get co= de point assignments at either standards track
or non-standards t= rack levels.

2. What algorithms we require you to = implement to be conformant.

3. What algorithms we recommend one not use in the futu= re even
though they have code point assignments (as in Andrei'= ;s RC4 draft).

Note that these don't really fa= ll cleanly into the MAY/SHOULD/MUST
classification you suggest here, but as I say, that's our historic= al practice
and so far I haven't heard much discussion of cha= nging that practice
for TLS.

-Ekr



--001a11c23e222aac6104fcec5855-- From nobody Sat Jun 28 15:24:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20AA1A00FF for ; Sat, 28 Jun 2014 15:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFNZqT5UJn-9 for ; Sat, 28 Jun 2014 15:24:37 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 456E81A00FB for ; Sat, 28 Jun 2014 15:24:37 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5F9AF2863E; Sat, 28 Jun 2014 22:24:36 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 4538428640; Sat, 28 Jun 2014 22:24:36 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 2CAE52038; Sat, 28 Jun 2014 22:24:36 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Sat, 28 Jun 2014 18:24:35 -0400 From: "Salz, Rich" To: Michael StJohns , "tls@ietf.org" Date: Sat, 28 Jun 2014 18:24:34 -0400 Thread-Topic: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, Thread-Index: Ac+TC295pcCKA9XnQh6uGiLv+aWDpAAE70jA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> In-Reply-To: <53AF1E98.2080906@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RqAg6NqnlDiAtmg9TEsbLunaMko Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 22:24:38 -0000 > If DJB et al is willing to transfer change control/copyright/patent right= s/moral > rights to the IETF (via appropriate documentation), and the IETF is willi= ng to > publish an actual standard then this objection goes away. Okay, I think we can knock this one off the list. Sean Turner is writing a= n RFC and Tanja (and me) will be helping. Dan gives his approval but didn't= have time to help.=20 I agree that the IETF is a small group, especially compared to ANSI X9.62 a= nd such. But that doesn't mean we can't, or shouldn't, get back into the c= rypto standardization. We have way more involved from real cryptographers = than before. > *sigh* If the IETF is really going to get into the business of standardiz= ing > crypto, we need to get the process for doing so right the first time rath= er > than just plugging it in to TLS and hoping we don't have to redo it over = and > over again. Agree. But again, it's "back into the business" Because we did it before = with TLS1, IPsec, and ECC curves therein. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Sat Jun 28 15:55:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E067C1A0194 for ; Sat, 28 Jun 2014 15:55:14 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLkmZIFVSaye for ; Sat, 28 Jun 2014 15:55:13 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F3E1A017A for ; Sat, 28 Jun 2014 15:55:12 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id j107so762401qga.3 for ; Sat, 28 Jun 2014 15:55:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=sfyiLwsLG1W4LeQPlBQCcjL79hGGDhmrysiw3rfDpyc=; b=cRzjlOgIuIjZosaQWVYPcQ3ZZN/T2yHLNYrZNsRI7xGcho1jhNyqRfrvbDK96rO2GX JILknPRAHmhVZBVqu75wad6uY7IksPRPC5kK805g3zCjAqQRdmio74H/mRNIytyc2Lz/ FxV5FS5FqYEaCkC4wWuFIoEhoUIOE5d/7WzSHONW2TqYa/2NTQ4Jwu4zCcVp2zHwHfT+ aOpYQWehQ+4410d2S9emlUoGbufuty1qVM8KxtsFrZmK2OO2PkITVIpIZtimLBl41i6Y b75pKaPNckw/1ShKWQPkjzNKraegfUWTqXgmzXjr5S74QtB6Lr42RB/jNeGxSl3Iz5Bc mKsw== X-Gm-Message-State: ALoCoQmQZC/J9DUUzkJx1HxHZO0vsceKVy95mjo63tOabUkFywlVDtuUaeXegWAJedLI3ZAKkACh X-Received: by 10.224.172.10 with SMTP id j10mr36927606qaz.46.1403996112225; Sat, 28 Jun 2014 15:55:12 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:390:b4d7:6f3f:f3ac:4c6? ([2601:a:2a00:390:b4d7:6f3f:f3ac:4c6]) by mx.google.com with ESMTPSA id r13sm51945qga.1.2014.06.28.15.55.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Jun 2014 15:55:11 -0700 (PDT) Message-ID: <53AF47E3.9020906@nthpermutation.com> Date: Sat, 28 Jun 2014 18:55:31 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Salz, Rich" , "tls@ietf.org" References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------060200000200040309010405" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Q3HWpompL8Bm3ov0svYPgRWgHUU Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 22:55:15 -0000 This is a multi-part message in MIME format. --------------060200000200040309010405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 6/28/2014 6:24 PM, Salz, Rich wrote: >> *sigh* If the IETF is really going to get into the business of standardizing >> >crypto, we need to get the process for doing so right the first time rather >> >than just plugging it in to TLS and hoping we don't have to redo it over and >> >over again. > Agree. But again, it's "back into the business" Because we did it before with TLS1, IPsec, and ECC curves therein. Um... huh? Can you provide specifics about which cryptographic algorithms we standardized? This is news to me. And I'm not talking about "here's how you use ECDSA for TLS or ECDH for for IPSEC" documents, but something comparable to SP800-56A or FIPS186-4 or X9.63. Mike --------------060200000200040309010405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 6/28/2014 6:24 PM, Salz, Rich wrote:
*sigh* If the IETF is really going to get into the business of standardizing
> crypto, we need to get the process for doing so right the first time rather
> than just plugging it in to TLS and hoping we don't have to redo it over and
> over again.

Agree.  But again, it's "back into the business"  Because we did it before with TLS1, IPsec, and ECC curves therein.

Um... huh?  Can you provide specifics about which cryptographic algorithms  we standardized?  This is news to me.

And I'm not talking about "here's how you use ECDSA for TLS or ECDH for  for IPSEC" documents, but something comparable to SP800-56A or FIPS186-4 or X9.63.

Mike

--------------060200000200040309010405-- From nobody Sat Jun 28 16:05:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715F21A01C1 for ; Sat, 28 Jun 2014 16:04:58 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id harNjQttOPod for ; Sat, 28 Jun 2014 16:04:56 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F7D1A01BE for ; Sat, 28 Jun 2014 16:04:55 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id z6so3993018yhz.14 for ; Sat, 28 Jun 2014 16:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=B3TXoFiF6xyKt+yMQshKvNubSaolluhlEWHalGq78t4=; b=mXrRhxRv+B3ka0hkxwFGrrhlbpH/HVTP+2oILComtgFAQF57l+5101sK5+wxnOEvHl dnD96OpZpCw5hJX6SP9a35gUA0xRsn5ITbLica172mhrcTorqeMd5YpMZBPX1WDbSwA5 EHuMQ36cRl9FWL9HCspr4Xg8oNdvOJTip7GRbAuj8AeaUpuCcQ7W2gppHy9KvaU3hF1C L0Qza4BggI7fEsCPPcUUt5b6OGTkUuV8pZI9vGgOW6qNDxfiwg6Bj/ctjaJfCU6+jFeR ZaYbffxYAdQeOj5W7377zPTR9prqntOsKVYcjLpXqBrZgQyg5263nle3Rla/vwnDiiQR xuFw== MIME-Version: 1.0 X-Received: by 10.236.45.10 with SMTP id o10mr43357163yhb.49.1403996694925; Sat, 28 Jun 2014 16:04:54 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Sat, 28 Jun 2014 16:04:54 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Sat, 28 Jun 2014 16:04:54 -0700 (PDT) In-Reply-To: <53AF47E3.9020906@nthpermutation.com> References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> Date: Sat, 28 Jun 2014 16:04:54 -0700 Message-ID: From: Watson Ladd To: tls@ietf.org Content-Type: multipart/alternative; boundary=089e011615fc4455ea04fced7490 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GBrexfIm7kM-VRtLEa0NF0PynfE Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 23:04:58 -0000 --089e011615fc4455ea04fced7490 Content-Type: text/plain; charset=UTF-8 On Jun 28, 2014 3:55 PM, "Michael StJohns" wrote: > > On 6/28/2014 6:24 PM, Salz, Rich wrote: >>> >>> *sigh* If the IETF is really going to get into the business of standardizing >>> > crypto, we need to get the process for doing so right the first time rather >>> > than just plugging it in to TLS and hoping we don't have to redo it over and >>> > over again. >> >> Agree. But again, it's "back into the business" Because we did it before with TLS1, IPsec, and ECC curves therein. > > > Um... huh? Can you provide specifics about which cryptographic algorithms we standardized? This is news to me. Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0 by ignoring lessons from IPSEC. > > And I'm not talking about "here's how you use ECDSA for TLS or ECDH for for IPSEC" documents, but something comparable to SP800-56A or FIPS186-4 or X9.63. What's magical about ANSI? Furthermore, we aren't developing an algorithm, but documenting one that already exists, the way RFC 6090 claimed to. There is nothing magical that makes using AES secure. You always have to know what you are doing. So I don't see picking curve25519 as inherently riskier then decisions we make every day in this WG. > > Mike > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e011615fc4455ea04fced7490 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 28, 2014 3:55 PM, "Michael StJohns" <msj@nthpermutation.com> wrote:
>
> On 6/28/2014 6:24 PM, Salz, Rich wrote:
>>>
>>> *sigh* If the IETF is really going to get into the business of= standardizing
>>> > crypto, we need to get the process for doing so right the= first time rather
>>> > than just plugging it in to TLS and hoping we don't h= ave to redo it over and
>>> > over again.
>>
>> Agree.=C2=A0 But again, it's "back into the business"= ;=C2=A0 Because we did it before with TLS1, IPsec, and ECC curves therein.<= br> >
>
> Um... huh?=C2=A0 Can you provide specifics about which cryptographic a= lgorithms=C2=A0 we standardized?=C2=A0 This is news to me.

Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0 b= y ignoring lessons from IPSEC.

>
> And I'm not talking about "here's how you use ECDSA for T= LS or ECDH for=C2=A0 for IPSEC" documents, but something comparable to= SP800-56A or FIPS186-4 or X9.63.

What's magical about ANSI? Furthermore,=C2=A0 we aren= 9;t developing an algorithm, but documenting one that already exists, the w= ay RFC 6090 claimed to.

There is nothing magical that makes using AES secure. You al= ways have to know what you are doing.

So I don't see picking curve25519 as inherently riskier = then decisions we make every day in this WG.
>
> Mike
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls
>

--089e011615fc4455ea04fced7490-- From nobody Sat Jun 28 16:36:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487A21A01E2 for ; Sat, 28 Jun 2014 16:36:16 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obyqbAoMLr4W for ; Sat, 28 Jun 2014 16:36:14 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BBCF1A01E1 for ; Sat, 28 Jun 2014 16:36:14 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id a108so717117qge.18 for ; Sat, 28 Jun 2014 16:36:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=D2Z5L9wugBcWabHb55FMyKqyzQk1TGEZXeuuEQzUua8=; b=OsIkKM9H1ro+FN0FAusFTuV5Gddg1fM7c9/TdCLooWBVHAKlQQC9ri99E648tNj0f7 ciQs6TlTBEsgV5MijMZQRuwW+Q4ObnVlBi0kCXKEkvliEqXxvk0yW8UpK7LSOJdGUN0M 4bUaRrcrmRnjlV4JR8S7AEx1Sp7GH8WFRhumSEgcvzUE54cKwvz+s9TGffGJ49GlZZJa 8KH7ekIHrpsWA8PwrRIN3YAya/XNM/Ba8vLat5wPfMiay1r5q7gAcTRxgkj/AGeaR3pz //Os7kumw3dqgdVN8MjSxCQ/oQ6XT+LQbCKSJrNtRNzSCsdBmWp7QUTGE0Wpvdjytrqv GtXg== X-Gm-Message-State: ALoCoQlJqMWMZjQEE+MBhtzvaewoJEFjjZbMrfUeynRl59d8R+vDFS3j36lDvA2dpW0QgAEQ4vHJ X-Received: by 10.224.68.2 with SMTP id t2mr47893291qai.71.1403998573443; Sat, 28 Jun 2014 16:36:13 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:390:b4d7:6f3f:f3ac:4c6? ([2601:a:2a00:390:b4d7:6f3f:f3ac:4c6]) by mx.google.com with ESMTPSA id d10sm23999437qaq.10.2014.06.28.16.36.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Jun 2014 16:36:12 -0700 (PDT) Message-ID: <53AF517F.7050504@nthpermutation.com> Date: Sat, 28 Jun 2014 19:36:31 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090108070303020007080906" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KThF1TV5fuhkJ6P-juV05BJRF84 Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 23:36:16 -0000 This is a multi-part message in MIME format. --------------090108070303020007080906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 6/28/2014 7:04 PM, Watson Ladd wrote: > > > On Jun 28, 2014 3:55 PM, "Michael StJohns" > wrote: > > > > On 6/28/2014 6:24 PM, Salz, Rich wrote: > >>> > >>> *sigh* If the IETF is really going to get into the business of > standardizing > >>> > crypto, we need to get the process for doing so right the first > time rather > >>> > than just plugging it in to TLS and hoping we don't have to redo > it over and > >>> > over again. > >> > >> Agree. But again, it's "back into the business" Because we did it > before with TLS1, IPsec, and ECC curves therein. > > > > > > Um... huh? Can you provide specifics about which cryptographic > algorithms we standardized? This is news to me. > > Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0 by ignoring > lessons from IPSEC. > > I can't find an RC4 RFC, but Camellia and HMAC are both Informational rather than Standards track. The IETF does not own change control on either of these. And since the publication of the HMAC RFC (2104), NIST has published their version of HMAC and that one seems to be the one most referenced these days. TESS, CASt-128, RC2, RC5, MD4, MD5, GOST, UMAC(??) and AES Key Wrap are also Informational RFCs. I'm sure there are a number of others, but I couldn't find any that are currently IETF standards or on the standards track. So, no, AFAIK we haven't been in the crypto standards business. Mike --------------090108070303020007080906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 6/28/2014 7:04 PM, Watson Ladd wrote:


On Jun 28, 2014 3:55 PM, "Michael StJohns" <msj@nthpermutation.com> wrote:
>
> On 6/28/2014 6:24 PM, Salz, Rich wrote:
>>>
>>> *sigh* If the IETF is really going to get into the business of standardizing
>>> > crypto, we need to get the process for doing so right the first time rather
>>> > than just plugging it in to TLS and hoping we don't have to redo it over and
>>> > over again.
>>
>> Agree.  But again, it's "back into the business"  Because we did it before with TLS1, IPsec, and ECC curves therein.
>
>
> Um... huh?  Can you provide specifics about which cryptographic algorithms  we standardized?  This is news to me.

Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0 by ignoring lessons from IPSEC.



I can't find an RC4 RFC, but Camellia and HMAC are both Informational rather than Standards track.  The IETF does not own change control on either of these.  And since the publication of the HMAC RFC (2104), NIST has published their version of HMAC and that one seems to be the one most referenced these days.

TESS, CASt-128, RC2, RC5, MD4, MD5, GOST, UMAC(??) and AES Key Wrap are also Informational RFCs.  I'm sure there are a number of others, but I couldn't find any that are currently IETF standards or on the standards track.

So, no, AFAIK we haven't been in the crypto standards business.

Mike



--------------090108070303020007080906-- From nobody Sat Jun 28 16:51:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27381A01E4 for ; Sat, 28 Jun 2014 16:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLTyRdj7ow8t for ; Sat, 28 Jun 2014 16:51:43 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8EA91A01BE for ; Sat, 28 Jun 2014 16:51:42 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id bs8so4315288wib.9 for ; Sat, 28 Jun 2014 16:51:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7Jp2XvUsF4VViVc6shyK1CM+PwLkNaYOfl45ttyp98w=; b=jMvgD96xB15tJbG9ma837VSp8yfyswA3RegDfAXXj7O01khwJPMLCSpfuuqh5JMMhH +TUz8jKQEhBr+GY5nFIi1EaS02oyXt3lVm85pARXsQhJf9pNn4U3UZ9YIp4Gned7FFxy UMK3bAOW6N3vP2kVppOt6ixuRbYsGF932y0dndHu/FrjbrdSx27wXBvwFuWLbngRQwPo RK5MPMXgw4MVayuKPVY/Owx1gr8yL+t84E+BCjCzxV5ihZWNxu+GnhPcC1W2Iz8NFNU1 b004eZMwESPTuB9fmAKbhWo1nVRFfHNKYmKoOcgBjAhTMF5l9TcjxZFyhAhD45OzIzrM Aqew== X-Gm-Message-State: ALoCoQkJGQtk27/5XbAgVl+Y1CBMyScDgBPVB8Yykj9R7apYROHnbhPc7+zbbB+rmzIpABOjYSa0 X-Received: by 10.194.48.103 with SMTP id k7mr34456172wjn.68.1403999501358; Sat, 28 Jun 2014 16:51:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sat, 28 Jun 2014 16:51:01 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <53AF517F.7050504@nthpermutation.com> References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> <53AF517F.7050504@nthpermutation.com> From: Eric Rescorla Date: Sat, 28 Jun 2014 16:51:01 -0700 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=047d7b86c8e48b2c9504fcee1b9b Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9FoLHGaA_z06NvWXozYvOMVRij4 Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 23:51:48 -0000 --047d7b86c8e48b2c9504fcee1b9b Content-Type: text/plain; charset=UTF-8 On Sat, Jun 28, 2014 at 4:36 PM, Michael StJohns wrote: > On 6/28/2014 7:04 PM, Watson Ladd wrote: > > > On Jun 28, 2014 3:55 PM, "Michael StJohns" wrote: > > > > On 6/28/2014 6:24 PM, Salz, Rich wrote: > >>> > >>> *sigh* If the IETF is really going to get into the business of > standardizing > >>> > crypto, we need to get the process for doing so right the first time > rather > >>> > than just plugging it in to TLS and hoping we don't have to redo it > over and > >>> > over again. > >> > >> Agree. But again, it's "back into the business" Because we did it > before with TLS1, IPsec, and ECC curves therein. > > > > > > Um... huh? Can you provide specifics about which cryptographic > algorithms we standardized? This is news to me. > > Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0 by ignoring > lessons from IPSEC. > > > I can't find an RC4 RFC, but Camellia and HMAC are both Informational > rather than Standards track. > I'm not sure why this is a relevant distinction. These documents are published by IETF and we make normative references to them in Standards Track documents. See, for instance: http://datatracker.ietf.org/doc/rfc2104/referencedby/ > The IETF does not own change control on either of these. > How does this matter? Unlike protocols, cryptographic algorithms aren't really versioned. If we wanted to do a new version of HMAC, we would presumably call it HMAC-2 or something. What's needed is a stable reference. -Ekr --047d7b86c8e48b2c9504fcee1b9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sat, Jun 28, 2014 at 4:36 PM, Michael StJohns = <msj@nthperm= utation.com> wrote:
=20 =20 =20
I can't find an RC4 RFC, but Camellia and HMAC are both Informational rather than Standards track.=C2=A0

Standards Track documents. See, for instance:

http://datatracker.ietf.org/doc/rfc2104/referencedby/

=C2=A0
The IETF does not own change control on either of these.

How does this matter? Unlike protocols, cryptographic algorithms aren'= ;t
really versioned. If we wanted to do a new version of HMAC, we= would
presumably call it HMAC-2 or something. What's needed is a stable<= /div>
reference.

-Ekr
=C2=A0
--047d7b86c8e48b2c9504fcee1b9b-- From nobody Sun Jun 29 04:47:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA031A0467 for ; Sun, 29 Jun 2014 04:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhZClNfqYW7Z for ; Sun, 29 Jun 2014 04:47:24 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 1605B1A0347 for ; Sun, 29 Jun 2014 04:47:23 -0700 (PDT) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 29 Jun 2014 07:47:23 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0174.001; Sun, 29 Jun 2014 07:47:22 -0400 From: Dan Brown To: "tls@ietf.org" Thread-Topic: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, Thread-Index: Ac+Tj+NMpz9/fRpLQkOEH6a3FPqHJw== Date: Sun, 29 Jun 2014 11:47:22 +0000 Message-ID: <20140629114721.22319253.31253.15976@certicom.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============0206733533==" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LPpWfUqql9GyHbH9BPUPZMRDD_Y Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 11:47:27 -0000 --===============0206733533== Content-Type: multipart/alternative; boundary="===============1740275944==" MIME-Version: 1.0 --===============1740275944== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Tm90IHN1cmUgYnV0IFdlaWVyc3RyYXNzIHZlcnNpb24gb2YgQ3VydmUyNTUxOSBtYXnigI4gYmUg YSBNQVkgaW4gRklQUyAxODYtNCwgQU5TSSBYOS42Mi82MywgSUVFRSAxMzYzLCBTRUMxLiBJIGNh biBjaGVjayBuZXh0IHdlZWsuIEJlY2F1c2UgbWFqb3Igc2VjdXJpdHkgcHJvcGVydGllcyBsaWtl IGhhcmQgRExQIGFyZSBwcmVzZXJ2ZWQgYmV0d2VlbiB0aGUgdHdvIHZlcnNpb25zLCB0aG9zZSBT RE9zIGVmZmVjdGl2ZWx5IGhhdmUgbm8gbWFqb3Igc2VjdXJpdHkgY29uY2VybnMgd2l0aCBDdXJ2 ZTI1NTE5IC4gT25seSB0aGUgU3VpdGUgQiBhbmQgTklTVC9DU0VDIEZJUFMgMTQwLSogQ0FWUCBt aWdodCBuYXJyb3cgdGhlIGN1cnZlIHNldCBhbGxvd2VkIGVub3VnaCB0byBleGNsdWRlIHRoZSBX ZWllcnN0cmFzcyBlcXVpdmFsZW50IG9mIEN1cnZlMjU1MTkuwqAKCkRpZG4ndCBJRVRGLCBtYXli ZSBQS0lYLCBvcHQgZm9yIGEgTVVTVCBvbiBuYW1lZCBjdXJ2ZXMgb25seT8gVGhhdCB3YXMgZm9y IGludGVyb3BlcmFiaWxpdHkgcmVhc29ucywgcmlnaHQ/IEFnYWluLCBJIGNhbiBjaGVjayBuZXh0 IHdlZWsuCgpUaGUgcmVhc29uIEknbSBvZmZlcmluZyB0aGlzIGluZm8gbm93IGV2ZW4gdGhvdWdo IEknbSBub3QgMTAwJSBzdXJlLCBpcyB0aGF0IEkgc2VlIHNvbWUgYXJndW1lbnRzIGhlcmUgY29u dHJhc3RpbmcgQU5TSSBhbmQgSUVURiwgc28gSSdtIGFkdmlzaW5nIHRob3NlIGFyZ3VlcnMgdG8g YmUgc3VyZSB0byBrbm93IHdoYXQgdGhvc2Ugc3BlY3MgZG8gb3IgaGF2ZSBkb25lLgoKTXkgcGVy c29uYWwgdmlldyBpcyB0aGF0IEN1cnZlMjU1MTkgc2VjdXJpdHkgc2hvdWxkIGJlIGdvb2Qgb3Zl cmFsbCwgYWN0dWFsbHkgwqBiZXR0ZXIgdGhhbiBQMjU2IGluIGEgZmV3IGFzcGVjdHMsIGJ1dCBz bGlnaHRseSB3b3JzZSBpbiBvdGhlcnMsIHNvIG5vdCB0aGVvcmV0aWNhbGx5IG9wdGltYWwgc2Vj dXJpdHkuwqAKCkNlcnRpY29tIGhhcyBhIHZhcmlldHkgb2bigI4gSVBSLCBhbmQgaGFzIG1hZGUg c2V2ZXJhbCBkZWNsYXJhdGlvbnMgYW5kIGxldHRlcnMgb2YgYXNzdXJhbmNlIHRvIElFVEYgYW5k IHRvIG90aGVyIFNET3MuIE15IGd1ZXNzIGlzIHRoYXQgYW55IElQUiB0aGF0IG1pZ2h0IHBvc3Np Ymx5IHBlcnRhaW4gdG8gQ3VydmUyNTUxOSwgaGFzIGFscmVhZHkgYmVlbiBkZWNsYXJlZCB0byBJ RVRGLCBhdCBsZWFzdCB0byB0aGUgVExTIFdHLiBDZXJ0aWNvbSBpcyByZXZpZXdpbmcgdGhpcywg YnV0IHNpbmNlIE1hdHQgQ2FtcGFnbmEgbGVmdCwgd2UndmUgbGFnZ2VkIGEgbGl0dGxlIG9uIElQ UiBzdHVmZiwgc29ycnkuCgpCZXN0IHJlZ2FyZHMsIAoKLS0gRGFuCkZyb206IFdhdHNvbiBMYWRk ClNlbnQ6IFNhdHVyZGF5LCBKdW5lIDI4LCAyMDE0IDc6MDUgUE0KVG86IHRsc0BpZXRmLm9yZwpT dWJqZWN0OiBSZTogW1RMU10gT24gQ3VydmUyNTUxOSBhbmQgb3RoZXIgcG9zc2liaWxpdGllcyAo ZS5nLiBpZXRmMjU2cCwgaWV0ZjM4NHAsIGlldGY1MjFwLAoKCk9uIEp1biAyOCwgMjAxNCAzOjU1 IFBNLCAiTWljaGFlbCBTdEpvaG5zIiA8bXNqQG50aHBlcm11dGF0aW9uLmNvbT4gd3JvdGU6Cj4K PiBPbiA2LzI4LzIwMTQgNjoyNCBQTSwgU2FseiwgUmljaCB3cm90ZToKPj4+Cj4+PiAqc2lnaCog SWYgdGhlIElFVEYgaXMgcmVhbGx5IGdvaW5nIHRvIGdldCBpbnRvIHRoZSBidXNpbmVzcyBvZiBz dGFuZGFyZGl6aW5nCj4+PiA+IGNyeXB0bywgd2UgbmVlZCB0byBnZXQgdGhlIHByb2Nlc3MgZm9y IGRvaW5nIHNvIHJpZ2h0IHRoZSBmaXJzdCB0aW1lIHJhdGhlcgo+Pj4gPiB0aGFuIGp1c3QgcGx1 Z2dpbmcgaXQgaW4gdG8gVExTIGFuZCBob3Bpbmcgd2UgZG9uJ3QgaGF2ZSB0byByZWRvIGl0IG92 ZXIgYW5kCj4+PiA+IG92ZXIgYWdhaW4uCj4+Cj4+IEFncmVlLsKgIEJ1dCBhZ2FpbiwgaXQncyAi YmFjayBpbnRvIHRoZSBidXNpbmVzcyLCoCBCZWNhdXNlIHdlIGRpZCBpdCBiZWZvcmUgd2l0aCBU TFMxLCBJUHNlYywgYW5kIEVDQyBjdXJ2ZXMgdGhlcmVpbi4KPgo+Cj4gVW0uLi4gaHVoP8KgIENh biB5b3UgcHJvdmlkZSBzcGVjaWZpY3MgYWJvdXQgd2hpY2ggY3J5cHRvZ3JhcGhpYyBhbGdvcml0 aG1zwqAgd2Ugc3RhbmRhcmRpemVkP8KgIFRoaXMgaXMgbmV3cyB0byBtZS4KCkNhbWVsbGlhLCBS QzQsIEhNQUMuIE9mIGNvdXJzZSB3ZSBzdGlsbCBzY3Jld2VkIHVwIFRMUyAxLjAgYnkgaWdub3Jp bmcgbGVzc29ucyBmcm9tIElQU0VDLgoKPgo+IEFuZCBJJ20gbm90IHRhbGtpbmcgYWJvdXQgImhl cmUncyBob3cgeW91IHVzZSBFQ0RTQSBmb3IgVExTIG9yIEVDREggZm9ywqAgZm9yIElQU0VDIiBk b2N1bWVudHMsIGJ1dCBzb21ldGhpbmcgY29tcGFyYWJsZSB0byBTUDgwMC01NkEgb3IgRklQUzE4 Ni00IG9yIFg5LjYzLgoKV2hhdCdzIG1hZ2ljYWwgYWJvdXQgQU5TST8gRnVydGhlcm1vcmUswqAg d2UgYXJlbid0IGRldmVsb3BpbmcgYW4gYWxnb3JpdGhtLCBidXQgZG9jdW1lbnRpbmcgb25lIHRo YXQgYWxyZWFkeSBleGlzdHMsIHRoZSB3YXkgUkZDIDYwOTAgY2xhaW1lZCB0by4KClRoZXJlIGlz IG5vdGhpbmcgbWFnaWNhbCB0aGF0IG1ha2VzIHVzaW5nIEFFUyBzZWN1cmUuIFlvdSBhbHdheXMg aGF2ZSB0byBrbm93IHdoYXQgeW91IGFyZSBkb2luZy4KClNvIEkgZG9uJ3Qgc2VlIHBpY2tpbmcg Y3VydmUyNTUxOSBhcyBpbmhlcmVudGx5IHJpc2tpZXIgdGhlbiBkZWNpc2lvbnMgd2UgbWFrZSBl dmVyeSBkYXkgaW4gdGhpcyBXRy4KPgo+IE1pa2UKPgo+Cj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPiBUTFMgbWFpbGluZyBsaXN0Cj4gVExTQGlldGYu b3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMKPgoK --===============1740275944== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
Not sure but Weierstrass version of Curve25519 may=E2=80=8E b= e a MAY in FIPS 186-4, ANSI X9.62/63, IEEE 1363, SEC1. I can check next wee= k. Because major security properties like hard DLP are preserved between th= e two versions, those SDOs effectively have no major security concerns with= Curve25519 . Only the Suite B and NIST/CSEC FIPS 140-* CAVP might narrow t= he curve set allowed enough to exclude the Weierstrass equivalent of Curve2= 5519. 

Didn't IETF, maybe PKIX, op= t for a MUST on named curves only? That was for interoperability reasons, r= ight? Again, I can check next week.

= The reason I'm offering this info now even though I'm not 100% sure, is tha= t I see some arguments here contrasting ANSI and IETF, so I'm advising thos= e arguers to be sure to know what those specs do or have done.
=

My personal view is that Curve25519 security sho= uld be good overall, actually  better than P256 in a few aspects, but = slightly worse in others, so not theoretically optimal security. 

Certicom has a variety of=E2=80=8E = IPR, and has made several declarations and letters of assurance to IETF and= to other SDOs. My guess is that any IPR that might possibly pertain to Cur= ve25519, has already been declared to IETF, at least to the TLS WG. Certico= m is reviewing this, but since Matt Campagna left, we've lagged a little on= IPR stuff, sorry.
= =

= =
Best regards,
<= br>-- Dan
= =
From= : Watson Ladd
Sent: Saturday, June 28, 2014 7:05 PM
To: tls@ietf.org
Subject: Re: [TLS] On Curv= e25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,


On Jun 28, 2014 3:55 PM, "Michael StJohns" <msj@nthpermutation.com> wrote:
>
> On 6/28/2014 6:24 PM, Salz, Rich wrote:
>>>
>>> *sigh* If the IETF is really going to get into the business of= standardizing
>>> > crypto, we need to get the process for doing so right the= first time rather
>>> > than just plugging it in to TLS and hoping we don't have = to redo it over and
>>> > over again.
>>
>> Agree.  But again, it's "back into the business"  Becaus= e we did it before with TLS1, IPsec, and ECC curves therein.
>
>
> Um... huh?  Can you provide specifics about which cryptographic a= lgorithms  we standardized?  This is news to me.

Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0 b= y ignoring lessons from IPSEC.

>
> And I'm not talking about "here's how you use ECDSA for TLS or ECDH fo= r  for IPSEC" documents, but something comparable to SP800-56A or FIPS= 186-4 or X9.63.

What's magical about ANSI? Furthermore,  we aren't deve= loping an algorithm, but documenting one that already exists, the way RFC 6= 090 claimed to.

There is nothing magical that makes using AES secure. You al= ways have to know what you are doing.

So I don't see picking curve25519 as inherently riskier then= decisions we make every day in this WG.
>
> Mike
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


--===============1740275944==-- --===============0206733533== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCTAHBgUrDgMCGjCABgkqhkiG9w0BBwEAAKCCDSYwggaPMIIF d6ADAgECAgptqd1HAAQAAAVqMA0GCSqGSIb3DQEBBQUAMFAxEzARBgoJkiaJk/IsZAEZFgNuZXQx EzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJvcmRpbmF0ZSBDQSBNQ0EwMllL RjAeFw0xNDA1MTQxNDM2MzhaFw0xNTA1MTQxNDM2MzhaMIGkMRMwEQYKCZImiZPyLGQBGRYDbmV0 MRMwEQYKCZImiZPyLGQBGRYDcmltMQ0wCwYDVQQLEwRBTUVSMQswCQYDVQQLEwJDQTEUMBIGA1UE CxMLTWlzc2lzc2F1Z2ExDjAMBgNVBAsTBVVzZXJzMRIwEAYDVQQDEwlEYW4gQnJvd24xIjAgBgkq hkiG9w0BCQEWE2Ricm93bkBjZXJ0aWNvbS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AOeGGgTmotlA0vPS6BzGw3AuPnPHRJeU6ZCVs9Jrqo51z+saUmKgc6LbMPUqTw9/9MBfA8++2YZG DfAQ0hdEQHbZn1yl3uNLUJB6KZTeKaLPY5wWVuXvB7k2VJBFQv6u239/fXLJKcTLfTAPd+ILwa0p NUDW0dw+x6t+LeGzh10lAgMBAAGjggOYMIIDlDALBgNVHQ8EBAMCBaAwRAYJKoZIhvcNAQkPBDcw NTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMBcG CSsGAQQBgjcUAgQKHggAVQBzAGUAcjApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYI KwYBBQUHAwIwQQYDVR0RBDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNk YnJvd25AY2VydGljb20uY29tMB0GA1UdDgQWBBRXRa7o6+S8jBmtx5dVODE45RLX7zAfBgNVHSME GDAWgBTm268lUmBC9I2CNVRdgOuGoazv3DCCATEGA1UdHwSCASgwggEkMIIBIKCCARygggEYhoHL bGRhcDovLy9DTj1SSU0lMjBTdWJvcmRpbmF0ZSUyMENBJTIwTUNBMDJZS0YsQ049TUNBMDJZS0Ys Q049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3Vy YXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/ b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGSGh0dHA6Ly9tY2EwMnlrZi5yaW0ubmV0 L0NlcnRFbnJvbGwvUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAyWUtGLmNybDCCAUEGCCsG AQUFBwEBBIIBMzCCAS8wgcIGCCsGAQUFBzAChoG1bGRhcDovLy9DTj1SSU0lMjBTdWJvcmRpbmF0 ZSUyMENBJTIwTUNBMDJZS0YsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jQUNlcnRpZmljYXRl P2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBoBggrBgEFBQcwAoZcaHR0 cDovL21jYTAyeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9NQ0EwMllLRi5yaW0ubmV0X1JJTSUyMFN1 Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwMllLRig0KS5jcnQwDQYJKoZIhvcNAQEFBQADggEBAHLQZIa8 qzIefgvvGIjq0fMYvhtTZFMnHzS7s+H2HUMxTQfclsckbNitMnZdF+T2V3o4WyIn9HRaMmsZ4YPw +YWH3hiIV3wDhRtthKTCVl1Tmr6mC8bJZ3Nnp4oVgGHFpIz3xOrX91zF5KHRZDGLxHfqhY/HlL8W 23EdXQaogRTTQ3CpQCp/6BJaf4iPy41BjBG/rSXR7bbBhMb0M0ndc8JNVOnDop2A/NmNPMwOW89/ JeWxNvqZZn19xEPLwimAPeabIBoN4bH359edLJqWOx3hDxkWYfb4JRn4tsJzKmP0IDvqrO/Hajvw tW3t6rkFN1h0OmHGa9yT9UXO8o++iu4wggaPMIIFd6ADAgECAgptqd1HAAQAAAVqMA0GCSqGSIb3 DQEBBQUAMFAxEzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNV BAMTG1JJTSBTdWJvcmRpbmF0ZSBDQSBNQ0EwMllLRjAeFw0xNDA1MTQxNDM2MzhaFw0xNTA1MTQx NDM2MzhaMIGkMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMQ0wCwYD VQQLEwRBTUVSMQswCQYDVQQLEwJDQTEUMBIGA1UECxMLTWlzc2lzc2F1Z2ExDjAMBgNVBAsTBVVz ZXJzMRIwEAYDVQQDEwlEYW4gQnJvd24xIjAgBgkqhkiG9w0BCQEWE2Ricm93bkBjZXJ0aWNvbS5j b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOeGGgTmotlA0vPS6BzGw3AuPnPHRJeU6ZCV s9Jrqo51z+saUmKgc6LbMPUqTw9/9MBfA8++2YZGDfAQ0hdEQHbZn1yl3uNLUJB6KZTeKaLPY5wW VuXvB7k2VJBFQv6u239/fXLJKcTLfTAPd+ILwa0pNUDW0dw+x6t+LeGzh10lAgMBAAGjggOYMIID lDALBgNVHQ8EBAMCBaAwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcN AwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMBcGCSsGAQQBgjcUAgQKHggAVQBzAGUAcjApBgNV HSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0RBDowOKAhBgorBgEE AYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20uY29tMB0GA1UdDgQW BBRXRa7o6+S8jBmtx5dVODE45RLX7zAfBgNVHSMEGDAWgBTm268lUmBC9I2CNVRdgOuGoazv3DCC ATEGA1UdHwSCASgwggEkMIIBIKCCARygggEYhoHLbGRhcDovLy9DTj1SSU0lMjBTdWJvcmRpbmF0 ZSUyMENBJTIwTUNBMDJZS0YsQ049TUNBMDJZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNl cnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9j ZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9u UG9pbnSGSGh0dHA6Ly9tY2EwMnlrZi5yaW0ubmV0L0NlcnRFbnJvbGwvUklNJTIwU3Vib3JkaW5h dGUlMjBDQSUyME1DQTAyWUtGLmNybDCCAUEGCCsGAQUFBwEBBIIBMzCCAS8wgcIGCCsGAQUFBzAC hoG1bGRhcDovLy9DTj1SSU0lMjBTdWJvcmRpbmF0ZSUyMENBJTIwTUNBMDJZS0YsQ049QUlBLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9 d2luZG93cyxEQz1sb2NhbD9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTBoBggrBgEFBQcwAoZcaHR0cDovL21jYTAyeWtmLnJpbS5uZXQvQ2VydEVu cm9sbC9NQ0EwMllLRi5yaW0ubmV0X1JJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwMllLRig0 KS5jcnQwDQYJKoZIhvcNAQEFBQADggEBAHLQZIa8qzIefgvvGIjq0fMYvhtTZFMnHzS7s+H2HUMx TQfclsckbNitMnZdF+T2V3o4WyIn9HRaMmsZ4YPw+YWH3hiIV3wDhRtthKTCVl1Tmr6mC8bJZ3Nn p4oVgGHFpIz3xOrX91zF5KHRZDGLxHfqhY/HlL8W23EdXQaogRTTQ3CpQCp/6BJaf4iPy41BjBG/ rSXR7bbBhMb0M0ndc8JNVOnDop2A/NmNPMwOW89/JeWxNvqZZn19xEPLwimAPeabIBoN4bH359ed LJqWOx3hDxkWYfb4JRn4tsJzKmP0IDvqrO/HajvwtW3t6rkFN1h0OmHGa9yT9UXO8o++iu4xggFf MIIBWwIBATBeMFAxEzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAi BgNVBAMTG1JJTSBTdWJvcmRpbmF0ZSBDQSBNQ0EwMllLRgIKbandRwAEAAAFajAHBgUrDgMCGqBd MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDYyOTExNDcxOVow IwYJKoZIhvcNAQkEMRYEFI2jRexpbCy/jz2oQesFM545fVUQMAsGCSqGSIb3DQEBBQSBgLGywgjR n3FGVrPGtiGl6O7h5z5LWorqoeVZrE7ZCQXneywWDZMJdNJli2EDv2GpWtOVnES2c8si52SVZps6 YCDuDNkQer75bCrQQ7KI6+nKUubCKKPYdNvXeoOHc+4UReH1JQJB2bj4jds/7shhUiJcFhRy2KGl k15q9FDvX87QAAAAAAAA --===============0206733533==-- From nobody Sun Jun 29 05:24:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC861A0467 for ; Sun, 29 Jun 2014 05:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8nrBuIP0fem for ; Sun, 29 Jun 2014 05:24:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D31511A002F for ; Sun, 29 Jun 2014 05:24:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E2385BE53; Sun, 29 Jun 2014 13:24:08 +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 TrycJSsQARlU; Sun, 29 Jun 2014 13:24:07 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.54.97]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D5BD3BE24; Sun, 29 Jun 2014 13:24:07 +0100 (IST) Message-ID: <53B00567.2030601@cs.tcd.ie> Date: Sun, 29 Jun 2014 13:24:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael StJohns , "tls@ietf.org" References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> In-Reply-To: <53AF1E98.2080906@nthpermutation.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_DVPqA_jqAgQ7gh0KJq1EIv7BB8 Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 12:24:13 -0000 Mike, On 28/06/14 20:59, Michael StJohns wrote: > > I'm not exactly sure what Stephen is objecting to in the above. Objecting is the wrong word, I commented that your language was unfortunate, at best. Reasons: 1) most of this thread is off topic for TLS and on topic for CFRG as has been said, I'd expect someone familiar with the topic to know that, and someone unfamiliar with the topic to begin with a lot less aggression - you did neither 2) starting an off-topic thread by calling some IETF participants "agitators" is definitely undesirably aggressive and IMO close to being disruptive You can reply with as many words as you like, but I think the above will remain the case, so I hope that no more discussion of this aspect is needed. S. From nobody Sun Jun 29 07:35:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6141A0537 for ; Sun, 29 Jun 2014 07:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VJibLkW23bj for ; Sun, 29 Jun 2014 07:35:25 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82BA71A052E for ; Sun, 29 Jun 2014 07:35:25 -0700 (PDT) Message-ID: <53B02420.8010309@akr.io> Date: Sun, 29 Jun 2014 15:35:12 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fXBHpD5SP_yOvVPURus0TTSPuxM Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 14:35:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 25/06/2014 21:03, Joseph Salowey (jsalowey) wrote: > [Joe] to simplify: I support 2: In favor of removing renegotiation with the addition of rekey. TLS <=1.2 renegotiation is hairy - but though it's not the most commonly-deployed profile right now, rekeying is needed (for large traffic volumes/long-lived connections, and potentially for 'ratcheting' the forward-security of connections?), as is client-certificate authentication. Happily, there are better ways of doing both of these than the current renegotiation flow - so we can remove renegotiation as it stands, and address these use-cases with better methods. If we remove it otherwise, some people who need TLS won't be able to use TLS 1.3, and I suspect that will be a barrier to adoption we don't want. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTsCQfAAoJEOyEjtkWi2t6xHoP/irmk1gJwFUoVRhqObWAHzVu Swl9Xk3B2fTzCpCn7yf+jojW1E/xh2lchN49UQ6Tdk4f3KboDCBFs/ebn/iObxUT nZL5AGoBI+vTsozX4/zVynHn/TmGhxMrGGl6TsH1M/aQ9jBPpsqgLCHmMGytqjcH Ui35qhy5QVsYkP3g4CSt581cuaW9gtXCzv/6x4f4kyb7Uvs54zk2W4ANvpFeVADY zJfKd6ov2zHcP19AaC5/yaej7SBelo34mD4ftcmHnG+TemwyB9pt41wGotI/2aRL KriC5haFEHBvM0kid6knNHJsOuvtzJr0eFPC9Hq4Ma2XLee8WJmMqJ4IPf8cDtYp tr6MVrZJcAWxyPFrzud/NnOba5Pycbw7Uvm1vzBH1ZmTjk/v6tDf/wUHlW6wtNdX ltAIh/IgnRlz0V++xqtGyvxJiJx/Uy03VznubgJTYqdhyr44foKxCNcWgPYrBgTE A736zZyBIk/3oU4lmmZ1nmnzKSCHxlqL/fdaOPGLiRaPidehLsDrE8U9odc3CNac vJHBwNLuKA8bB9gT0QfgpTYaoL9GzCZAbGl1szRC3LSTEuFYzwTF+bxMOJ0ysJu2 UXT7v21UNEVyxsbHtrTncREsnPuQc/UMyT7jyhul/4bBpEujkwYS9cQ9s1HqdMRL P9QFewjaup48ez6Fg9rp =lM/d -----END PGP SIGNATURE----- From nobody Sun Jun 29 12:28:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FBF1A02F6 for ; Sun, 29 Jun 2014 12:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rk836wQdYmWb for ; Sun, 29 Jun 2014 12:28:48 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4DE1A02F3 for ; Sun, 29 Jun 2014 12:28:47 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id dc16so5804054qab.15 for ; Sun, 29 Jun 2014 12:28:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=J5VK7Mzudbj1SqKzUDdiKFfe9UAOO4dVNV+frTKOY6M=; b=dyXZeOsKqyGTMh81dRawb+cPYQFXqGMYdfvNnN+uH1Q/V9at+/PRNHcOEvNOEVpkOK BBn0LVB0Xm/1e5YZZml9exwCZDPHEZMydAfpMPQHFpjMf8LM9EUDIBydnkkoofvVp+5J yC7HhDaouEMyEi7bcZuWxDkH90Bg04aIeiDvyWcc5IYL+M8qhbUQIZiP2awlo33dO0VS rX5CSe9thtAFoe2Umy4bJdkd9dJX2Wv1tuvUV6YM1+EWS6TrpCUNCzoc3bYN+FI2h/7W fgE++ik+8BUyfVQ1jFmtM1uCYWwCrH/PvXwuVh7zzO39Fjf+royCDZ557peI5zuuOyXU deGw== X-Gm-Message-State: ALoCoQkQjfwq+G4tIs8NFM+KzBXdCyjz6eYlRuer+nTPEvUHjFB8O/zcXoS6VFWfWlAGq5LuPzpA X-Received: by 10.224.76.1 with SMTP id a1mr55081665qak.4.1404070126982; Sun, 29 Jun 2014 12:28:46 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:390:b4d7:6f3f:f3ac:4c6? ([2601:a:2a00:390:b4d7:6f3f:f3ac:4c6]) by mx.google.com with ESMTPSA id b10sm10694470qgf.7.2014.06.29.12.28.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Jun 2014 12:28:46 -0700 (PDT) Message-ID: <53B068ED.8090304@nthpermutation.com> Date: Sun, 29 Jun 2014 15:28:45 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , "tls@ietf.org" References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <53B00567.2030601@cs.tcd.ie> In-Reply-To: <53B00567.2030601@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------090304000000050809050702" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/s4pcJZL2I5JDPRaOFiylQxTyWeQ Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 19:28:50 -0000 This is a multi-part message in MIME format. --------------090304000000050809050702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 6/29/2014 8:24 AM, Stephen Farrell wrote: > Mike, > > On 28/06/14 20:59, Michael StJohns wrote: >> I'm not exactly sure what Stephen is objecting to in the above. > Objecting is the wrong word, I commented that your language > was unfortunate, at best. And then followed up with a command to "stomp on threads with such language" - hard not to take that as an objection. > > Reasons: > > 1) most of this thread is off topic for TLS and on topic for > CFRG as has been said, I'd expect someone familiar with the > topic to know that, and someone unfamiliar with the topic to > begin with a lot less aggression - you did neither I asked a simple question about alternatives to Curve25519 because there have been repeated (I've got 208 messages including this thread) messages ON THIS WORKING GROUP about the use of Curve25519. Why this question is any more off-topic than those is unclear. Why you believe my question was aggressive is unclear to me. Why you believe that I'm unfamiliar with the topic is also unclear (I'm unfamiliar, due to lack of documentation as to the CFRG's exact and final recommendation with respect to Curve25519, I'm familiar with most of the arguments for the curve, and familiar with the differences in supporting documentation and standards from existing curves and curve generation systems). > > 2) starting an off-topic thread by calling some IETF participants > "agitators" is definitely undesirably aggressive and IMO close to > being disruptive You get to have your own opinions, but try and leave the facts intact. What I said was "There's been a small but vocal minority agitating for the adoption of Curve25519". This is not the same as calling them agitators and I'll thank you not to put words in my mouth. It turns out that the intransitive verb "agitating" and the noun "agitator" have different nuanced meanings probably leading to your confusion. The former tends to imply "arousing interest enthusiastically" and is a neutral term. "Agitator" is a neutral to negative term depending on context. A simple pass by Merrium-Webster gets: > to try to get people to support or oppose something and > > intransitive verb > *:* to attempt to arouse public feeling The related none for "agitate" is "agitation" not "agitator". Agitator gets you: > : a person who tries to get people angry or upset so that they will > support an effort to change a government, company, etc. and > /a/ *:* one who stirs up public feeling on controversial issues > I tend to use English with fair precision. I could have used "advocating for" but there was a lot more lobbying going on than that word implies. In any event, you're taking or implying offense where none was meant. Mike > > You can reply with as many words as you like, but I think the > above will remain the case, so I hope that no more discussion > of this aspect is needed. > > S. --------------090304000000050809050702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 6/29/2014 8:24 AM, Stephen Farrell wrote:
Mike,

On 28/06/14 20:59, Michael StJohns wrote:

I'm not exactly sure what Stephen is objecting to in the above.

Objecting is the wrong word, I commented that your language
was unfortunate, at best.
And then followed up with a command to "stomp on threads with such language" - hard not to take that as an objection.


Reasons:

1) most of this thread is off topic for TLS and on topic for
CFRG as has been said, I'd expect someone familiar with the
topic to know that, and someone unfamiliar with the topic to
begin with a lot less aggression - you did neither

I asked a simple question about alternatives to Curve25519 because there have been repeated (I've got 208 messages including this thread) messages ON THIS WORKING GROUP about the use of Curve25519.  Why this question is any more off-topic than those is unclear.

 Why you believe my question was aggressive is unclear to me.  Why you believe that I'm unfamiliar with the topic is also unclear (I'm unfamiliar, due to lack of documentation as to the CFRG's exact and final recommendation with respect to Curve25519, I'm familiar with most of the arguments for the curve,  and familiar with the differences in supporting documentation and standards from existing curves and curve generation systems). 



2) starting an off-topic thread by calling some IETF participants
"agitators" is definitely undesirably aggressive and IMO close to
being disruptive
You get to have your own opinions, but try and leave the facts intact.

What I said was "There's been a small but vocal minority agitating for the adoption of Curve25519".  This is not the same as calling them agitators and I'll thank you not to put words in my mouth. 

It turns out that the intransitive verb "agitating" and the noun "agitator" have different nuanced meanings probably leading to your confusion.    The former tends to imply "arousing interest enthusiastically" and is a neutral term.  "Agitator" is a neutral to negative term depending on context.   A simple pass by Merrium-Webster gets:

to try to get people to support or oppose something

and

intransitive verb
:  to attempt to arouse public feeling <agitated for better schools>

The related none for "agitate" is "agitation" not "agitator".

Agitator gets you:
: a person who tries to get people angry or upset so that they will support an effort to change a government, company, etc.
and
a :  one who stirs up public feeling on controversial issues <political agitators>

I tend to use English with fair precision.  I could have used "advocating for" but there was a lot more lobbying going on than that word implies.

In any event, you're taking or implying offense where none was meant. 

Mike



You can reply with as many words as you like, but I think the
above will remain the case, so I hope that no more discussion
of this aspect is needed.

S.

--------------090304000000050809050702-- From nobody Sun Jun 29 13:25:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEE61A0300 for ; Sun, 29 Jun 2014 13:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FMn4yVbSwUk for ; Sun, 29 Jun 2014 13:25:39 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0340B1A02FA for ; Sun, 29 Jun 2014 13:25:38 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l6so6188590qcy.4 for ; Sun, 29 Jun 2014 13:25:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=FH75UWlw6YLE634LGeOcQeNGx0UR9R7hwe3Y4vfXn4c=; b=Vh4PeO4zkQA1hgxeAreptdnml1MjGmCnHuobUw4J0AyRDH31QWko6L5Cl+u/nV3ee1 a4izDdwKZ81FwiI5wDIRugB+o6z43znH+tZATS6pOlMWwTkf1Xb4np4j0eDafgt60gSO Ux1WWR6MXBYV5rWEqUZftICkwFZs2/tMUhuK91F3bUfb1RT3u7ojE6eIHAJKF+zze47H ZfB33gvTurVonet51vRHY7R7YNGaApdzGJW98BlWLzIzZvp3mXgpn8623cfxksq+KV2X ieC/6nJZbKiD9KtMAgezl+XwDAKS+TG1+ePVBM4gVsP+zU+pgNqEdWDWNMWOjggMY4M6 v/8A== X-Gm-Message-State: ALoCoQkvl0lChoBg1Xvvfwl+C1cczVsg41U115dura9z0HtKJQGaDuvxHwro8aWPK45O6L/xPq3g X-Received: by 10.224.124.17 with SMTP id s17mr55389104qar.64.1404073537542; Sun, 29 Jun 2014 13:25:37 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:390:b4d7:6f3f:f3ac:4c6? ([2601:a:2a00:390:b4d7:6f3f:f3ac:4c6]) by mx.google.com with ESMTPSA id z14sm28408746qaw.7.2014.06.29.13.25.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Jun 2014 13:25:37 -0700 (PDT) Message-ID: <53B07640.2050000@nthpermutation.com> Date: Sun, 29 Jun 2014 16:25:36 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Eric Rescorla References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> <53AF517F.7050504@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010607070300020105070909" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rxXoJWrx1ZZEfhX8FjuJ-8x0O1o Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 20:25:42 -0000 This is a multi-part message in MIME format. --------------010607070300020105070909 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit In line below. On 6/28/2014 7:51 PM, Eric Rescorla wrote: > > > > On Sat, Jun 28, 2014 at 4:36 PM, Michael StJohns > > wrote: > > On 6/28/2014 7:04 PM, Watson Ladd wrote: >> >> >> On Jun 28, 2014 3:55 PM, "Michael StJohns" >> > wrote: >> > >> > On 6/28/2014 6:24 PM, Salz, Rich wrote: >> >>> >> >>> *sigh* If the IETF is really going to get into the business >> of standardizing >> >>> > crypto, we need to get the process for doing so right the >> first time rather >> >>> > than just plugging it in to TLS and hoping we don't have to >> redo it over and >> >>> > over again. >> >> >> >> Agree. But again, it's "back into the business" Because we >> did it before with TLS1, IPsec, and ECC curves therein. >> > >> > >> > Um... huh? Can you provide specifics about which cryptographic >> algorithms we standardized? This is news to me. >> >> Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0 by >> ignoring lessons from IPSEC. >> >> > > I can't find an RC4 RFC, but Camellia and HMAC are both > Informational rather than Standards track. > > > I'm not sure why this is a relevant distinction. These documents are > published by IETF and we make normative references to them in > Standards Track documents. See, for instance: > > http://datatracker.ietf.org/doc/rfc2104/referencedby/ Hi Ekr - thanks for the question. I think the question you're asking is "Why is the distinction between Internet Standard and informational RFC relevant to the use of Curve25519"? That's the one I'll try and respond to. Let me know if I got the question wrong. Fact: Almost any one who wants to can publish an Informational RFC. Fact: Informational RFCs are not Internet Standards. They may be products of the IETF, but do not have to be. They tend to be evaluated less strenuously than standards track RFCs. Fact: Every single cryptographic standard that the IETF has published as an RFC has been Informational. None of them appear to be products of the IETF, but I could have missed one. Fact: The IETF has made no claim as to the strength of viability of crypto published as Informational RFCs. E.g. we're just a user of cryptography, not an originator. Observation: The Curve25519 documents could have been published as Informational along the same basis as above. Some of them may still be. Observation: The CFRG was asked to comment on Curve25519 - specifically to give a recommendation. Observation: At least one person on this email thread (and others elsewhere) have used the phrase "standardize Curve25519" - another used the word "preferred". Tentative Theory: There is some desire to publish Curve25519 as an IETF Standards track document. That is to give Curve25519 the mantle of "cryptography acceptable to the IETF". Implication: The IETF will have to make some pronouncement or assurance as to the viability of Curve25519 to the wider world. The IETF will have to maintain the Curve25519 standard. That last implication is new for the IETF. AFAIK, each and every cryptographic algorithm and mode documented by the IETF has an owner elsewhere and such claims of assurance are made there and maintenance and changes are done there. We are not - at least at this time - a cryptographic standards body. The change to become one should be intentional, rational and measured. If I am in fact misreading the tea leaves, and a Curve25519 cryptographic standard is to be published to the IETF as a DJB contribution and Informational and not a product of the IETF, then there are no implications and I'll leave this in peace. But anecdotal evidence suggests that this is in doubt. > > > The IETF does not own change control on either of these. > > > How does this matter? Unlike protocols, cryptographic algorithms aren't > really versioned. If we wanted to do a new version of HMAC, we would > presumably call it HMAC-2 or something. What's needed is a stable > reference. Cryptographic algorithms are not versioned - mostly (Although see co-factor changes to ECDH for example), but Cryptographic Standards certainly are. RSA has gone through 5 or 6 versions, FIPS186 is now "-4", etc. The algorithm part of a cryptographic standard is usually the least controversial and most stable part of the standard. The hard stuff is the translation and representation language (for example the argument about Curve25519 with respect to big or little endian representation of the big integers). There are also sometimes enhancements or new guidance's that can be added: For example key pair generation for EC key pairs in F(p) - one version is to randomly generate a number in the interval [1..P), another one is to randomly generate a number in 2^(n+64) and take that mod P. In short, the algorithm is just a small part of the standard. The cryptographic standard has to give us (the IETF) an interface we can use to the cryptographic algorithm. If that standard is not an IETF standard, then we take what we're given and hope it meets our needs. I find the fact that the current TLS curve25519 draft directly references DJB's paper problematic as the paper is missing even the basics necessary for what I would consider a cryptographic standard. DJB's paper is equivalent to no more than section 5 of the RSA 2.2 http://www.emc.com/emc-plus/rsa-labs/pkcs/files/h11300-wp-pkcs-1v2-2-rsa-cryptography-standard.pdf standard. What's needed is a document that fills in the rest and that the TLS (and IPSEC and SMime and... can reference) and it's unclear if we have the time, resources or desire to do this. So yes, I think the question of IETF standard or Informational RFC is relevant. Mike > > -Ekr --------------010607070300020105070909 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
In line below.

On 6/28/2014 7:51 PM, Eric Rescorla wrote:



On Sat, Jun 28, 2014 at 4:36 PM, Michael StJohns <msj@nthpermutation.com> wrote:
On 6/28/2014 7:04 PM, Watson Ladd wrote:


On Jun 28, 2014 3:55 PM, "Michael StJohns" <msj@nthpermutation.com> wrote:
>
> On 6/28/2014 6:24 PM, Salz, Rich wrote:
>>>
>>> *sigh* If the IETF is really going to get into the business of standardizing
>>> > crypto, we need to get the process for doing so right the first time rather
>>> > than just plugging it in to TLS and hoping we don't have to redo it over and
>>> > over again.
>>
>> Agree.  But again, it's "back into the business"  Because we did it before with TLS1, IPsec, and ECC curves therein.
>
>
> Um... huh?  Can you provide specifics about which cryptographic algorithms  we standardized?  This is news to me.

Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0 by ignoring lessons from IPSEC.



I can't find an RC4 RFC, but Camellia and HMAC are both Informational rather than Standards track. 

I'm not sure why this is a relevant distinction. These documents are
published by IETF and we make normative references to them in
Standards Track documents. See, for instance:


Hi Ekr - thanks for the question.


I think the question you're asking is "Why is the distinction between Internet Standard and informational RFC relevant to the use of Curve25519"?  That's the one I'll try and respond to.  Let me know if I got the question wrong.

Fact: Almost any one who wants to can publish an Informational RFC.
Fact: Informational RFCs are not Internet Standards.  They may be products of the IETF, but do not have to be.  They tend to be evaluated less strenuously than standards track RFCs.
Fact:  Every single cryptographic standard that the IETF has published as an RFC has been Informational.  None of them appear to be products of the IETF, but I could have missed one. 
Fact:  The IETF has made no claim as to the strength of viability of crypto published as Informational RFCs.  E.g. we're just a user of cryptography, not an originator.

Observation:  The Curve25519 documents could have been published as Informational along the same basis as above.  Some of them may still be.
Observation:  The CFRG was asked to comment on Curve25519 - specifically to give a recommendation.
Observation:  At least one person on this email thread (and others elsewhere) have used the phrase "standardize Curve25519" - another used the word "preferred".

Tentative Theory: There is some desire to publish Curve25519 as an IETF Standards track document.  That is to give Curve25519 the mantle of "cryptography acceptable to the IETF".

Implication: The IETF will have to make some pronouncement or assurance as to the viability of Curve25519 to the wider world.  The IETF will have to maintain the Curve25519 standard.

That last implication is new for the IETF.  AFAIK, each and every cryptographic algorithm and mode documented by the IETF has an owner elsewhere and such claims of assurance are made there and maintenance and changes are done there.  We are not - at least at this time - a cryptographic standards body.  The change to become one should be intentional, rational and measured.

If I am in fact misreading the tea leaves, and a Curve25519 cryptographic standard is to be published to the IETF as a DJB contribution and Informational and not a product of the IETF, then there are no implications and I'll leave this in peace.  But anecdotal evidence suggests that this is in doubt.


 
The IETF does not own change control on either of these.

How does this matter? Unlike protocols, cryptographic algorithms aren't
really versioned. If we wanted to do a new version of HMAC, we would
presumably call it HMAC-2 or something. What's needed is a stable
reference.

Cryptographic algorithms are not versioned - mostly  (Although see co-factor changes to ECDH for example), but Cryptographic Standards certainly are.  RSA has gone through 5 or 6 versions, FIPS186 is now "-4", etc.

The algorithm part of a cryptographic standard is usually the least controversial and most stable part of the standard.  The hard stuff is the translation and representation language (for example the argument about Curve25519 with respect to big or little endian representation of the big integers).  There are also sometimes enhancements or new guidance's that can be added:  For example key pair generation for EC key pairs in F(p) - one version is to randomly generate a number in the interval [1..P), another one is to randomly generate a number in 2^(n+64) and take that mod P.

In short, the algorithm is just a small part of the standard.

The cryptographic standard has to give us (the IETF) an interface we can use to the cryptographic algorithm.    If that standard is not an IETF standard, then we take what we're given and hope it meets our needs.  

I find the fact that the current TLS curve25519 draft directly references DJB's paper problematic as the paper is missing even the basics necessary for what I would consider a cryptographic standard.   DJB's paper is equivalent to no more than section 5 of the RSA 2.2 http://www.emc.com/emc-plus/rsa-labs/pkcs/files/h11300-wp-pkcs-1v2-2-rsa-cryptography-standard.pdf standard.  What's needed is a document that fills in the rest and that the TLS (and IPSEC and SMime and... can reference) and it's unclear if we have the time, resources or desire to do this.

So yes, I think the question of IETF standard or Informational RFC is relevant.

Mike



-Ekr
 

--------------010607070300020105070909-- From nobody Sun Jun 29 13:45:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4301A0031 for ; Sun, 29 Jun 2014 13:45:29 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QeStvsmy7dD for ; Sun, 29 Jun 2014 13:45:28 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0731A001E for ; Sun, 29 Jun 2014 13:45:27 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id x3so6416070qcv.10 for ; Sun, 29 Jun 2014 13:45:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=fSSaCupIB9UJI/RGIJKL0YSug6+hyXLaCc9Y078qkrU=; b=BXCBessCzVe8G2F863CL3ojcHKIGXE4PBhoz5V8VRoSmuq7rcXWSVonNJ2TPSdlxYY wzVXAvTfnc6j1l4enW7tFZexERGzaxogGqdW4M9qIBgL0ECs3g2sDvUFFyiYVIpfjyjq nh1Pqfteho+wwXUpJhnQL8MMSSwA/CqBRGwYm3dwzl2KGYgYVeMVuUlBZGGShnI75TAy w3Tn3TKEyDzcm94mr3N6Z00AvfM6IGUc+eZUf2S7A5MiKabA2UvFgPmz9IUmhoRMmIJ/ D9hvLyv34BnRdqE+bNS+w5xdYe9OgvzHhum0ulPpxx0DGDE3CZqEvddiS5Yr9r9C9Yf/ avDg== X-Gm-Message-State: ALoCoQlcjE2lUU6RQInZfQx49dg47a8B3ZAhS3lGwJO97/AcBE9wQOUNvvvI+oa4Clrgh7Hmbvj8 X-Received: by 10.224.119.198 with SMTP id a6mr55379925qar.39.1404074726761; Sun, 29 Jun 2014 13:45:26 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:390:b4d7:6f3f:f3ac:4c6? ([2601:a:2a00:390:b4d7:6f3f:f3ac:4c6]) by mx.google.com with ESMTPSA id d3sm28453443qad.43.2014.06.29.13.45.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Jun 2014 13:45:26 -0700 (PDT) Message-ID: <53B07AE5.5090304@nthpermutation.com> Date: Sun, 29 Jun 2014 16:45:25 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000208010700010502000709" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/812kSnmOkszr8WhucpYqv8i8YQA Subject: Re: [TLS] Does anyone still want dh_rsa and dh_dss? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 20:45:29 -0000 This is a multi-part message in MIME format. --------------000208010700010502000709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 6/26/2014 12:14 PM, Eric Rescorla wrote: > We've already removed static RSA for TLS 1.3 but we didn't > emove dh_rsa and dh_dss (as opposed to dhe_rsa and > dhe_dss). It seems like the arguments for removing static > RSA apply even more strongly here. > > Is there any reason to retain these in TLS 1.3? Would it be more appropriate to ask this in a more crypto-neutral manner? E.g. We've removed Public Key Transport as a valid mechanism for pre-master setup. So instead maybe ask this as "Should we remove all non-ephemeral key agreement mechanisms?" Or is there some reason to retain non-ephemeral ECDH vice non-ephemeral DH? Mike > > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------000208010700010502000709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 6/26/2014 12:14 PM, Eric Rescorla wrote:
We've already removed static RSA for TLS 1.3 but we didn't 
emove dh_rsa and dh_dss (as opposed to dhe_rsa and
dhe_dss). It seems like the arguments for removing static
RSA apply even more strongly here.

Is there any reason to retain these in TLS 1.3?

Would it be more appropriate to ask this in  a more crypto-neutral manner?    E.g. We've removed Public Key Transport as a valid mechanism for pre-master setup.  So instead maybe ask this as "Should we remove all non-ephemeral key agreement mechanisms?"

Or is there some reason to retain non-ephemeral ECDH vice non-ephemeral DH?

Mike



-Ekr



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

--------------000208010700010502000709-- From nobody Sun Jun 29 13:55:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C591A001E for ; Sun, 29 Jun 2014 13:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIDfPQxyZqBB for ; Sun, 29 Jun 2014 13:54:59 -0700 (PDT) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7B481A0015 for ; Sun, 29 Jun 2014 13:54:58 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so7393050wes.7 for ; Sun, 29 Jun 2014 13:54:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dYyUsqemVErhGaXAaBT1KpmT9OBnrnYJIhQ2g0G0+To=; b=iNOcWCTGeKbE4FWOX9mFpoiughjQxlSbjZGwYJkyR3jl2tcIHEi3CFslIsDbv2Kn2k VhswzxtrfUpiSrhu5L4lRq0hZ7Fx12IL8nza2MOUyGkOlQof7EcJ+eWtZ6mbDQO78nCg CB0WgF9T01GDnRMmX6skfCZ9QnRCDPg2i6MUFGJyrnDcTpr6rjeKgJbwWiexOkUjgeq6 xqIAg/85Cg6qk2KAQuA6XMjNZysiJtR+eL2XnKy5ccaDXSM2JDgdG1MhZwB7DxQcUltP pkL1Vv+ccoogFID+uHM8S5s8ceh9wz6fq2kBZVhReQwEHVxJg6H4YAfra0tRbGb/ZBf8 tmTA== X-Gm-Message-State: ALoCoQlnM97Xpqi8TrsHPxaTOHH6WJ+JQTVjHpjLUhhAEgqVGdccIa5TVqB0q+G3l3ADvVEpu1EM X-Received: by 10.194.10.130 with SMTP id i2mr40374249wjb.70.1404075297340; Sun, 29 Jun 2014 13:54:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.57.202 with HTTP; Sun, 29 Jun 2014 13:54:17 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <53B07AE5.5090304@nthpermutation.com> References: <53B07AE5.5090304@nthpermutation.com> From: Eric Rescorla Date: Sun, 29 Jun 2014 13:54:17 -0700 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=047d7b45058658639504fcffc1a2 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5za1SWCBo8EkBB3MzACXAH_pb4g Cc: "tls@ietf.org" Subject: Re: [TLS] Does anyone still want dh_rsa and dh_dss? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 20:55:00 -0000 --047d7b45058658639504fcffc1a2 Content-Type: text/plain; charset=UTF-8 On Sun, Jun 29, 2014 at 1:45 PM, Michael StJohns wrote: > On 6/26/2014 12:14 PM, Eric Rescorla wrote: > > We've already removed static RSA for TLS 1.3 but we didn't > emove dh_rsa and dh_dss (as opposed to dhe_rsa and > dhe_dss). It seems like the arguments for removing static > RSA apply even more strongly here. > > Is there any reason to retain these in TLS 1.3? > > > Would it be more appropriate to ask this in a more crypto-neutral > manner? E.g. We've removed Public Key Transport as a valid mechanism for > pre-master setup. So instead maybe ask this as "Should we remove all > non-ephemeral key agreement mechanisms?" > > Or is there some reason to retain non-ephemeral ECDH vice non-ephemeral DH? > Not that I know of, it's just that I was working through the TLS spec and the ECDHE code points don't appear there, so I didn't think of it. -Ekr Mike > > > > -Ekr > > > > _______________________________________________ > TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --047d7b45058658639504fcffc1a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, Jun 29, 2014 at 1:45 PM, Michael StJohns = <msj@nthperm= utation.com> wrote:
=20 =20 =20
On 6/26/2014 12:14 PM, Eric Rescorla wrote:
We've already removed static RSA for TLS 1.3 but= we didn't=C2=A0
emove dh_rsa and dh_dss (as opposed to dhe_rsa and
dhe_dss). It seems like the arguments for removing static
RSA apply even more strongly here.

Is there any reason to retain these in TLS 1.3?

Would it be more appropriate to ask this in=C2=A0 a more crypto-neutral manner?=C2=A0=C2=A0=C2=A0 E.g. We've removed Public Key Transport a= s a valid mechanism for pre-master setup.=C2=A0 So instead maybe ask this as "Should we remove all non-ephemeral key agreement mechanisms?"= ;

Or is there some reason to retain non-ephemeral ECDH vice non-ephemeral DH?

Not that I = know of, it's just that I was working through the TLS spec and
the ECDHE code points don't appear there, so I didn't think =C2= =A0of it.

-Ekr


Mike



-Ekr



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


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


--047d7b45058658639504fcffc1a2-- From nobody Sun Jun 29 13:55:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19921A0032 for ; Sun, 29 Jun 2014 13:55: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VRhxp3t0A6j for ; Sun, 29 Jun 2014 13:55:08 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D063A1A0025 for ; Sun, 29 Jun 2014 13:55:07 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 79so4149581ykr.14 for ; Sun, 29 Jun 2014 13:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MR58lnRiQRsvRpiuo1CZ0H+exT0RsW8t19Guued9JU4=; b=WMpn3N3nVSOkPuxr4Iok9IpfcbM1pekYGxdIDDNwJ6KguQS7ZR94fnlYPphZxVHnxi cYR79EzkthYtT3LFsuJ/41bA5HPct0v7sUG9VOh2heYtpOzjgBvT52cysLcTPwoxgAl2 8lSWpYVNu8BK0FHOSKRrsXVxbR7G4jPccRU1np37P4SCILZ7MSGpKrZPI+wlhEXmeioQ trlMbZOIpGugpFudUbaReNs/JTK+6iB/giiZ6VeK3ZO2CFQ31fGwpINcLEdw/vK5Hml6 zRU3l7BURoLn5C8tBJ+2P/m7IUhEPKZV+zLVUsZBf6MfcE0P//HgLDvyy6umTAZTJFwq SnSQ== MIME-Version: 1.0 X-Received: by 10.236.103.135 with SMTP id f7mr6306708yhg.102.1404075307101; Sun, 29 Jun 2014 13:55:07 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Sun, 29 Jun 2014 13:55:07 -0700 (PDT) In-Reply-To: <53B07AE5.5090304@nthpermutation.com> References: <53B07AE5.5090304@nthpermutation.com> Date: Sun, 29 Jun 2014 13:55:07 -0700 Message-ID: From: Watson Ladd To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/55PBe1HltXBgYFdDMpUC9fgyRiI Cc: "tls@ietf.org" Subject: Re: [TLS] Does anyone still want dh_rsa and dh_dss? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 20:55:09 -0000 On Sun, Jun 29, 2014 at 1:45 PM, Michael StJohns wrote: > On 6/26/2014 12:14 PM, Eric Rescorla wrote: > > We've already removed static RSA for TLS 1.3 but we didn't > emove dh_rsa and dh_dss (as opposed to dhe_rsa and > dhe_dss). It seems like the arguments for removing static > RSA apply even more strongly here. > > Is there any reason to retain these in TLS 1.3? > > > Would it be more appropriate to ask this in a more crypto-neutral manner? > E.g. We've removed Public Key Transport as a valid mechanism for pre-master > setup. So instead maybe ask this as "Should we remove all non-ephemeral key > agreement mechanisms?" > > Or is there some reason to retain non-ephemeral ECDH vice non-ephemeral DH? Yes, there is potentially. With DH on genus 0 we need to restrict parameter choices. Existing certificates probably don't fit into that framework, so won't work. However, I do think we should chuck both out because they are not forward secure. Sincerely, Watson Ladd > > Mike > > > > -Ekr > > > > _______________________________________________ > 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 > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Jun 29 13:55:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21861A0301 for ; Sun, 29 Jun 2014 13:55:35 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id codhJVpC6X7k for ; Sun, 29 Jun 2014 13:55:35 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48F81A0041 for ; Sun, 29 Jun 2014 13:55:34 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 20so4161490yks.38 for ; Sun, 29 Jun 2014 13:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=uvSNj+HcvNLvQYza+6NRcsZrtwR9sQGYUXAVyTETaIs=; b=AEq77i6AHC/Vv1IOMaFcYaTU2vFxMTkunT7HBKha8O0prcNNlJyizM8CEw1QmNenvH THu3XKzBFEzgpVs5YJHcWfL3rxqukMZo7zZOGNXjCmXzdkjtKLXe/AMfaHHH5dnN5M1q Ze4X7ESP7MbjU3sKVQjK55WB00PmHDgGgxdpSh7sA5vkxtZOFZAwLCCbhFBdv3hlFpj6 Ha7OgwebDNymzeu32TPTI82M37CTzWB7uUvNSxbXZ+rjwqfX05CpdpIcse7fDnhiwaqm kXT2CzyiiWezsA7+3wGOBhyxpr9rHK9k6dIQ4F+0LmneA1h6aLUaB6sAY6hB6HgAvPjp Y17g== MIME-Version: 1.0 X-Received: by 10.236.229.133 with SMTP id h5mr52958795yhq.64.1404075334228; Sun, 29 Jun 2014 13:55:34 -0700 (PDT) Received: by 10.170.163.134 with HTTP; Sun, 29 Jun 2014 13:55:34 -0700 (PDT) Date: Sun, 29 Jun 2014 13:55:34 -0700 Message-ID: From: Chay Moua To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e0160c36a88e33d04fcffc388 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nb5SjrPvLSXrcpTehAWlaFjr5Gw Subject: [TLS] (no subject) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 20:55:35 -0000 --089e0160c36a88e33d04fcffc388 Content-Type: text/plain; charset=UTF-8 I do -- Sent from Gmail Mobile --089e0160c36a88e33d04fcffc388 Content-Type: text/html; charset=UTF-8 I do

--
Sent from Gmail Mobile
--089e0160c36a88e33d04fcffc388-- From nobody Sun Jun 29 14:30:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5021D1A0027 for ; Sun, 29 Jun 2014 14:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRtEjkMf-6a3 for ; Sun, 29 Jun 2014 14:30:27 -0700 (PDT) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89C2F1A0026 for ; Sun, 29 Jun 2014 14:30:26 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so7235348wes.15 for ; Sun, 29 Jun 2014 14:30:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Hp+cGrOPJexdnZydCcfyo2z4NyRDuAMrLx8s2/b5WVc=; b=DvqHh+hVGuWBWA7c3LhwmKKkFOqJqtAjRnIZz4JFfROfVd8gESSVhXVKF7u5uigYq5 dS1agegpei/ZIqDdQjmSI5SJqFQRJlWonK4b47tuva7h4Piuzm7kx23MxxtbQnB5XaVC LEt5vWGs7KJBYJKmIFwXuZvfb0Ijllq0hS+2fAThnzB7UShHjEV26ajgl0ktQm0NZK6E zTLLIKbTvit872g4kMA5LtAdc5OmPJBzAFUCDYLCuSPHG+x6E7aqmHSw0nPqXCf7xw/R 9+7+7lCYeiFmQLI1exv0tdZ/MZSNgddTW56EGQzFfoXWV5OFQs1fsBV56PVJyudZe528 bKDQ== X-Gm-Message-State: ALoCoQkw/t6X2ijdRgMx7x5zC77vGcctYzNyuSomTL+viuiJdbwu1jUvu1Q86yjZExSa+/I/N4PT X-Received: by 10.180.81.72 with SMTP id y8mr25284771wix.7.1404077425078; Sun, 29 Jun 2014 14:30:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.57.202 with HTTP; Sun, 29 Jun 2014 14:29:44 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <53B07640.2050000@nthpermutation.com> References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> <53AF517F.7050504@nthpermutation.com> <53B07640.2050000@nthpermutation.com> From: Eric Rescorla Date: Sun, 29 Jun 2014 14:29:44 -0700 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=f46d04428cf428cf6504fd0040dc Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aFwai4CyW8Mc0pXFlAKbyTGMwtE Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 21:30:29 -0000 --f46d04428cf428cf6504fd0040dc Content-Type: text/plain; charset=UTF-8 On Sun, Jun 29, 2014 at 1:25 PM, Michael StJohns wrote: > In line below. > > > On 6/28/2014 7:51 PM, Eric Rescorla wrote: > > > > > On Sat, Jun 28, 2014 at 4:36 PM, Michael StJohns > wrote: > >> On 6/28/2014 7:04 PM, Watson Ladd wrote: >> >> >> On Jun 28, 2014 3:55 PM, "Michael StJohns" >> wrote: >> > >> > On 6/28/2014 6:24 PM, Salz, Rich wrote: >> >>> >> >>> *sigh* If the IETF is really going to get into the business of >> standardizing >> >>> > crypto, we need to get the process for doing so right the first >> time rather >> >>> > than just plugging it in to TLS and hoping we don't have to redo it >> over and >> >>> > over again. >> >> >> >> Agree. But again, it's "back into the business" Because we did it >> before with TLS1, IPsec, and ECC curves therein. >> > >> > >> > Um... huh? Can you provide specifics about which cryptographic >> algorithms we standardized? This is news to me. >> >> Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0 by ignoring >> lessons from IPSEC. >> >> >> I can't find an RC4 RFC, but Camellia and HMAC are both Informational >> rather than Standards track. >> > > I'm not sure why this is a relevant distinction. These documents are > published by IETF and we make normative references to them in > Standards Track documents. See, for instance: > > http://datatracker.ietf.org/doc/rfc2104/referencedby/ > > > Hi Ekr - thanks for the question. > > > I think the question you're asking is "Why is the distinction between > Internet Standard and informational RFC relevant to the use of > Curve25519"? That's the one I'll try and respond to. Let me know if I got > the question wrong. > Sure, we can take it as that question. > Fact: Almost any one who wants to can publish an Informational RFC. > Fact: Informational RFCs are not Internet Standards. They may be products > of the IETF, but do not have to be. They tend to be evaluated less > strenuously than standards track RFCs. > Fact: Every single cryptographic standard that the IETF has published as > an RFC has been Informational. None of them appear to be products of the > IETF, but I could have missed one. > Fact: The IETF has made no claim as to the strength of viability of > crypto published as Informational RFCs. E.g. we're just a user of > cryptography, not an originator. > > Observation: The Curve25519 documents could have been published as > Informational along the same basis as above. Some of them may still be. > Observation: The CFRG was asked to comment on Curve25519 - specifically > to give a recommendation. > Observation: At least one person on this email thread (and others > elsewhere) have used the phrase "standardize Curve25519" - another used the > word "preferred". > > Tentative Theory: There is some desire to publish Curve25519 as an IETF > Standards track document. That is to give Curve25519 the mantle of > "cryptography acceptable to the IETF". > This is where you lost me. Consider the following sequence of events: 1. Someone publishes a Curve25519 Informational RFC. 2. The CFRG sends the IETF a message saying "We think the Curve25519 is a good curve and the IETF should adopt it for use in IETF protocols" (presumably in more formal language). 3. The TLS WG publishes a standards track document (assuming for the moment that we believe that we are going to adopt any standards track ECC cipher suites) which refers to the RFC published in #1. To the best of my knowledge, there isn't any procedural problem with doing this and it would be effectively what we did with, for instance, HMAC. Do you believe that the IETF made some statements about the quality of HMAC by publishing RFC 2104 and including HMAC in our protocols? > That last implication is new for the IETF. AFAIK, each and every > cryptographic algorithm and mode documented by the IETF has an owner > elsewhere and such claims of assurance are made there and maintenance and > changes are done there. > Can you tell me who that someone else is for HMAC or RC4? -Ekr --f46d04428cf428cf6504fd0040dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, Jun 29, 2014 at 1:25 PM, Michael StJohns = <msj@nthperm= utation.com> wrote:
=20 =20 =20
In line below.


On 6/28/2014 7:51 PM, Eric Rescorla wrote:



On Sat, Jun 28, 2014 at 4:36 PM, Michael StJohns <msj@nthpermutation.com> wrote:
On 6/28/2014 7:04 PM, Watson Ladd wrote:


On Jun 28, 2014 3:55 PM, "Michael StJohns" = <msj@nthperm= utation.com> wrote:
>
> On 6/28/2014 6:24 PM, Salz, Rich wrote:
>>>
>>> *sigh* If the IETF is really going to get into the business of standardizing
>>> > crypto, we need to get the process for doing so right the first time rather
>>> > than just plugging it in to TLS and hoping we don't have to redo it over and
>>> > over again.
>>
>> Agree.=C2=A0 But again, it's "back = into the business"=C2=A0 Because we did it before with TL= S1, IPsec, and ECC curves therein.
>
>
> Um... huh?=C2=A0 Can you provide specifics about which cryptographic algorithms=C2=A0 we standardized?= =C2=A0 This is news to me.

Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0 by ignoring lessons from IPSEC.


I can't find an RC4 RFC, but Camellia and HMAC are both Informational rather than Standards track.=C2=A0

I'm not sure why this is a relevant distinction. These documents are
published by IETF and we make normative references to them in
Standards Track documents. See, for instance:


Hi Ekr - thanks for the question.


I think the question you're asking is "Why is the distinction between Internet Standard and informational RFC relevant to the use of Curve25519"?=C2=A0 That's the one I'll try and respond = to.=C2=A0 Let me know if I got the question wrong.

=
Sure, we can take it as that question.

=C2=A0=
Fact: Almost any one who wants to can publish an Informational RFC.
Fact: Informational RFCs are not Internet Standards.=C2=A0 They may be products of the IETF, but do not have to be.=C2=A0 They tend to be evaluated less strenuously than standards track RFCs.
Fact:=C2=A0 Every single cryptographic standard that the IETF has published as an RFC has been Informational.=C2=A0 None of them appear t= o be products of the IETF, but I could have missed one.=C2=A0
Fact:=C2=A0 The IETF has made no claim as to the strength of viability = of crypto published as Informational RFCs.=C2=A0 E.g. we're just a use= r of cryptography, not an originator.

Observation:=C2=A0 The Curve25519 documents could have been published a= s Informational along the same basis as above.=C2=A0 Some of them may sti= ll be.
Observation:=C2=A0 The CFRG was asked to comment on Curve25519 - specifically to give a recommendation.
Observation:=C2=A0 At least one person on this email thread (and others elsewhere) have used the phrase "standardize Curve25519" - an= other used the word "preferred".

Tentative Theory: There is some desire to publish Curve25519 as an IETF Standards track document.=C2=A0 That is to give Curve25519 the mantle of "cryptography acceptable to the IETF".

This is where you lost me. Consider the follo= wing sequence of events:

1. Someone publishes a Cu= rve25519 Informational RFC.
2. The CFRG sends the IETF a message saying "We think the Curve25= 519
is a good curve and the IETF should adopt it for use in IETF = protocols"
(presumably in more formal language).
3. The TLS WG publishes a standards track document (assuming for
= the moment that we believe that we are going to adopt any standards
track ECC cipher suites) which refers to the RFC published in #1.

To the best of my knowledge, there isn't any proced= ural problem with
doing this and it would be effectively what we = did with, for instance, HMAC.
Do you believe that the IETF made s= ome statements about the quality
of HMAC by publishing RFC 2104 and including HMAC in our protocols?



That last implication is new for the IETF.=C2=A0 AFAIK, each and every cryptographic algorithm and mode documented by the IETF has an owner elsewhere and such claims of assurance are made there and maintenance and changes are done there.=C2=A0
Can you tell me who that someone else is for HMAC or RC4?

-Ekr
=C2=A0


--f46d04428cf428cf6504fd0040dc-- From nobody Sun Jun 29 15:49:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852C31A0045 for ; Sun, 29 Jun 2014 15:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsllU8tQPrn1 for ; Sun, 29 Jun 2014 15:49:14 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19801A0043 for ; Sun, 29 Jun 2014 15:49:14 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s5TMnCYI083401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 29 Jun 2014 15:49:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: <53B068ED.8090304@nthpermutation.com> Date: Sun, 29 Jun 2014 15:49:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <90D7CCDF-5076-441F-98BB-1BE1A3936E56@vpnc.org> References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <53B00567.2030601@cs.tcd.ie> <53B068ED.8090304@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/i03-C2pI4g-NlaH0Mfwfhol-DAU Cc: "tls@ietf.org" Subject: [TLS] On counting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 22:49:15 -0000 On Jun 29, 2014, at 12:28 PM, Michael StJohns = wrote: > You get to have your own opinions, but try and leave the facts intact. >=20 > What I said was "There's been a small but vocal minority agitating for = the adoption of Curve25519". How is the phrase "small but vocal minority agitating" a fact? If you = are comparing the number of people seeking to have Curve25519 adopted = versus the number seeking to not have it adopted, the first group is = actually larger than the second. If you are saying that only people who = are speaking on the list want to have Curve25519 be adopted and everyone = else doesn't and thus the first group is a small minority, that's a = gross assumption, not a fact. You have been active in the IETF long = enough to know that many people stay silent not because they agree with = the way things are, but because they are sick of the tone of the = discussion. The fact is that the CFRG believes that Curve25519 is good enough for = adoption in IETF standards. It's fine if you disagree, but if you want = to try to be fact-based, stick to facts that you can back up. --Paul Hoffman= From nobody Sun Jun 29 16:27:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB851A004A for ; Sun, 29 Jun 2014 16:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcvmIWQsJsxB for ; Sun, 29 Jun 2014 16:26:59 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id B5CAA1A0049 for ; Sun, 29 Jun 2014 16:26:59 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5638B482CC; Sun, 29 Jun 2014 23:26:59 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 4AFEA482CA; Sun, 29 Jun 2014 23:26:59 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 25F2B98045; Sun, 29 Jun 2014 23:26:59 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Sun, 29 Jun 2014 19:26:58 -0400 From: "Salz, Rich" To: Eric Rescorla , Michael StJohns Date: Sun, 29 Jun 2014 19:26:55 -0400 Thread-Topic: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, Thread-Index: Ac+T4WNnTZn1ZvCKR4mNvngnklI1iAAEBUpQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA76@USMBX1.msg.corp.akamai.com> References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> <53AF517F.7050504@nthpermutation.com> <53B07640.2050000@nthpermutation.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA76USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UYrrF3fSKwJflKzvgCJrxYWSITo Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 23:27:01 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA76USMBX1msgcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgSSByZWNhbGwsIFJDNCBhbHNvIGhhZCBzb21lIHNwZWNpYWwgaXNzdWVzIHRoYXQgd2UgdHVy bmVkIGEgYmxpbmQgZXllIHRvbywgbGlrZSBiZWluZyBjYWxsZWQg4oCcQVJDNOKAnSBmb3Igc29t ZSB0aW1lLg0KDQpQZXJoYXBzIHNvbWVvbmUgZGlyZWN0bHkgaW52b2x2ZWQgY2FuIHJlZnJlc2gg bXkgbWVtb3J5Pw0KDQogICAgICAgICAgICAgICAgL3IkDQoNCi0tDQpQcmluY2lwYWwgU2VjdXJp dHkgRW5naW5lZXINCkFrYW1haSBUZWNobm9sb2dpZXMsIENhbWJyaWRnZSwgTUENCklNOiByc2Fs ekBqYWJiZXIubWU8bWFpbHRvOnJzYWx6QGphYmJlci5tZT47IFR3aXR0ZXI6IFJpY2hTYWx6DQo= --_000_2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA76USMBX1msgcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9o ZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdv cmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5BcyBJ IHJlY2FsbCwgUkM0IGFsc28gaGFkIHNvbWUgc3BlY2lhbCBpc3N1ZXMgdGhhdCB3ZSB0dXJuZWQg YSBibGluZCBleWUgdG9vLCBsaWtlIGJlaW5nIGNhbGxlZCDigJxBUkM04oCdIGZvciBzb21lIHRp bWUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QZXJoYXBzIHNvbWVvbmUgZGlyZWN0bHkgaW52b2x2ZWQg Y2FuIHJlZnJlc2ggbXkgbWVtb3J5PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+wqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIC9yJDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS3CoCA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UHJpbmNp cGFsIFNlY3VyaXR5IEVuZ2luZWVyPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFrYW1haSBUZWNobm9sb2dpZXMsIENhbWJyaWRn ZSwgTUE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+SU06IDxhIGhyZWY9Im1haWx0bzpyc2FsekBqYWJiZXIubWUiPjxzcGFuIHN0 eWxlPSdjb2xvcjpibHVlJz5yc2FsekBqYWJiZXIubWU8L3NwYW4+PC9hPjsgVHdpdHRlcjogUmlj aFNhbHo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA76USMBX1msgcorp_-- From nobody Sun Jun 29 17:03:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552DE1A0063 for ; Sun, 29 Jun 2014 17:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3lXPI1JyYop for ; Sun, 29 Jun 2014 17:03:26 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8371A004E for ; Sun, 29 Jun 2014 17:03:25 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id f51so1340009qge.25 for ; Sun, 29 Jun 2014 17:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamcaudill.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mb+tdZu+eaRcNlW5tzQZB730vveqcsFtpYsWRQlfQ70=; b=hf6dIpP3FKS6q4QB25x3HVfieGF847vWXKDC7GKApOabN/nM1EjJ5ssZWmIFQ3nb+I YrM201BaknG0LqoU+UKlOR7k0ucggoo5suxiyjZ5cT7D1g68rMLY06HavG0MZfTFKXyz DK3Y7FtlPjO4Mtt7r9Hlj3YUdWUjSxUrvM02I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=mb+tdZu+eaRcNlW5tzQZB730vveqcsFtpYsWRQlfQ70=; b=Cog3E8Hr7I/+6Ba0gPe10wuHDDqoDFpZfe1KQO/hxOscqM6GGdAbgr4BWeKlTp9FiQ YLZhesKfsyqW3KvcDEMFLn/kEo1sUaw07m383EhuU2y8taKLBwJmCrJW6hufaQvUJsaK UdIK1n0W5A8iTsqTr3hwZ82QQoy4EqyPJ4MnFnpgnBGj2M8lFphxTjudgOtcUwzj+ZV9 kOpUjIBpH47kd2bfH+NQ5STtklgd3VB+zjZrXQEctfX7g0YHdqcQeMWcEVWJL5iiBBzV T+PaNSDWmOF5Tl+hTgtPJpQGpFU8z/uTh2Pqq0YPzVaBIfgqr1+rWUay6dGTu2DoCKEq wrkA== X-Gm-Message-State: ALoCoQnOPVsm6d8kCzMXbOZM1GEWHmmXPb73/wK1UxT+nb6ww0sLdtSeHAzZg1N7hmupABcAq3G4 X-Received: by 10.140.25.142 with SMTP id 14mr34260899qgt.62.1404086605096; Sun, 29 Jun 2014 17:03:25 -0700 (PDT) Received: from [10.0.0.4] (c-50-142-69-73.hsd1.tn.comcast.net. [50.142.69.73]) by mx.google.com with ESMTPSA id x9sm29191371qas.26.2014.06.29.17.03.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Jun 2014 17:03:24 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Adam Caudill In-Reply-To: <90D7CCDF-5076-441F-98BB-1BE1A3936E56@vpnc.org> Date: Sun, 29 Jun 2014 20:03:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <254A2793-6856-458A-A10C-FCDE85973E7B@adamcaudill.com> References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <53B00567.2030601@cs.tcd.ie> <53B068ED.8090304@nthpermutation.com> <90D7CCDF-5076-441F-98BB-1BE1A3936E56@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xFZqAE7RWRm_LvIQZcLDeG662ho Cc: "tls@ietf.org" Subject: Re: [TLS] On counting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 00:03:27 -0000 On Jun 29, 2014, at 6:49 PM, Paul Hoffman wrote: > If you are saying that only people who are speaking on the list want = to have Curve25519 be adopted and everyone else doesn't and thus the = first group is a small minority, that's a gross assumption, not a fact. = You have been active in the IETF long enough to know that many people = stay silent not because they agree with the way things are, but because = they are sick of the tone of the discussion. There are certainly more people that want to see curve25519 adopted than = those that are speaking up; myself included. I wouldn=92t advocate = requiring it, but there are cases where it would be useful. If it makes = sense for an implementation, implement it, if not, don=92t - but there=92s= no reason to prevent it from being used in the cases where it would add = value. It performs well, it=92s generally accepted to be secure - = otherwise I=92m sure the reaction from the CFRG would have been quite = different. This isn=92t just about being non-NIST, it has real value from a = performance and implementation perspective. Personally, I see no reason = not to adopt it - though I wouldn=92t go so far as to require it be = implemented (though I think it should be in many cases), or state that = it should be a preferred option. --=20 Adam Caudill From nobody Sun Jun 29 17:05:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43241A0064 for ; Sun, 29 Jun 2014 17:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17yZg_693hio for ; Sun, 29 Jun 2014 17:05:54 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E3B1A0063 for ; Sun, 29 Jun 2014 17:05:54 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s5U05oxu086114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 29 Jun 2014 17:05:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA76@USMBX1.msg.corp.akamai.com> Date: Sun, 29 Jun 2014 17:05:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9F01B489-83A3-40A2-B0DA-57776DD59F5F@vpnc.org> References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> <53AF517F.7050504@nthpermutation.com> <53B07640.2050000@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA76@USMBX1.msg.corp.akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tKAglmnL_FyuWGAxQfsTnCh5GIQ Cc: "tls@ietf.org" Subject: [TLS] Off-topic: RC4 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 00:05:55 -0000 On Jun 29, 2014, at 4:26 PM, Salz, Rich wrote: > As I recall, RC4 also had some special issues that we turned a blind = eye too, like being called =93ARC4=94 for some time. > =20 > Perhaps someone directly involved can refresh my memory? It was maybe a copyright issue about the source code, but definitely a = trademark issue on the hame, so someone did a clean-source = reimplementation and gave it a new name. ARC4 and RC4 were shown to = interoperate fully. --Paul Hoffman= From nobody Sun Jun 29 17:14:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163771A0066 for ; Sun, 29 Jun 2014 17:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSk3qg8mRaje for ; Sun, 29 Jun 2014 17:14:08 -0700 (PDT) Received: from p3plsmtpa08-09.prod.phx3.secureserver.net (p3plsmtpa08-09.prod.phx3.secureserver.net [173.201.193.110]) by ietfa.amsl.com (Postfix) with ESMTP id B5C651A0063 for ; Sun, 29 Jun 2014 17:14:08 -0700 (PDT) Received: from spectre ([173.8.184.78]) by p3plsmtpa08-09.prod.phx3.secureserver.net with id LQE31o00A1huGat01QE3hW; Sun, 29 Jun 2014 17:14:08 -0700 From: "Peter Yee" To: "'Paul Hoffman'" , "'Salz, Rich'" References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> <53AF517F.7050504@nthpermutation.com> <53B07640.2050000@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA76@USMBX1.msg.corp.akamai.com> <9F01B489-83A3-40A2-B0DA-57776DD59F5F@vpnc.org> In-Reply-To: <9F01B489-83A3-40A2-B0DA-57776DD59F5F@vpnc.org> Date: Sun, 29 Jun 2014 17:14:02 -0700 Message-ID: <033601cf93f8$357d4b90$a077e2b0$@akayla.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG3LtzZPN+yKx26iaA20cdcvjvnkwLMNFk1AqKlRX0BqJ27FAG85ePIAcWNS0QBKdCxzQGNN03YAUqh/1wBgbRiBQMJ0HjyAmrDiKoCbmaXnZr5kC+A Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hb379lCIEY5boths1b5t0SvDEFQ Cc: tls@ietf.org Subject: Re: [TLS] Off-topic: RC4 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 00:14:10 -0000 I think the Wikipedia entry does a decent job of describing the situation: http://en.wikipedia.org/wiki/Rc4#History -Peter Yee -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Sunday, June 29, 2014 5:06 PM To: Salz, Rich Cc: tls@ietf.org Subject: [TLS] Off-topic: RC4 On Jun 29, 2014, at 4:26 PM, Salz, Rich wrote: > As I recall, RC4 also had some special issues that we turned a blind eye too, like being called "ARC4" for some time. > > Perhaps someone directly involved can refresh my memory? It was maybe a copyright issue about the source code, but definitely a trademark issue on the hame, so someone did a clean-source reimplementation and gave it a new name. ARC4 and RC4 were shown to interoperate fully. --Paul Hoffman _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Sun Jun 29 20:12:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6621A0100 for ; Sun, 29 Jun 2014 20:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omXAVLzfBhP1 for ; Sun, 29 Jun 2014 20:12:35 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1471A00FF for ; Sun, 29 Jun 2014 20:12:34 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9CFFC482B5; Mon, 30 Jun 2014 03:12:34 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 87C54482B4; Mon, 30 Jun 2014 03:12:34 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 5A34F9803D; Mon, 30 Jun 2014 03:12:34 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Sun, 29 Jun 2014 23:12:33 -0400 From: "Salz, Rich" To: Michael StJohns , Eric Rescorla Date: Sun, 29 Jun 2014 23:12:32 -0400 Thread-Topic: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, Thread-Index: Ac+T2FHjkHpuLs2/QW+KuP9wo9clfwAN7FUw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95@USMBX1.msg.corp.akamai.com> References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> <53AF517F.7050504@nthpermutation.com> <53B07640.2050000@nthpermutation.com> In-Reply-To: <53B07640.2050000@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gJHheUo3CiSQ7sop5RX71b02ah8 Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 03:12:36 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95USMBX1msgcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEltcGxpY2F0aW9uOiBUaGUgSUVURiB3aWxsIGhhdmUgdG8gbWFrZSBzb21lIHByb25vdW5j ZW1lbnQgb3IgYXNzdXJhbmNlIGFzIHRvIHRoZSB2aWFiaWxpdHkgb2YgQ3VydmUyNTUxOSB0byB0 aGUgd2lkZXIgd29ybGQuICBUaGUgSUVURiB3aWxsIGhhdmUgdG8gbWFpbnRhaW4gdGhlIEN1cnZl MjU1MTkgc3RhbmRhcmQuDQoNCk1pa2UsIEkga25vdyB5b3XigJl2ZSBiZWVuIGludm9sdmVkIGlu IHRoaXMgc3R1ZmYgc2luY2UgYmVmb3JlIHRoaXMgc3R1ZmYgZXhpc3RlZCDimLosIGJ1dCBJIGRv buKAmXQgdW5kZXJzdGFuZCB0aGlzLiBXaHkgZG8gd2UgaGF2ZSB0byBtYWtlIGFueSBhc3N1cmFu Y2UgYWJvdXQgYW55dGhpbmcgb3RoZXIgdGhhbiDigJhoZXJlIGlzIGhvdyB0byBpbnRlcm9wZXJh dGUgdXNpbmcgMjU1MTkgaW4gVExT4oCZPw0KDQpXZeKAmXJlIG5vdCBkZWZpbmluZyBhIHN0YW5k YXJkLCB3ZeKAmXJlIG5vdCBhc3N1cmluZyB0aGUgd29ybGQgYWJvdXQgYW55dGhpbmcuIFdl4oCZ bGwgaGF2ZSBhbiBSRkMgdGhhdCBzYXlzIOKAnGhlcmXigJlzICBob3cgdG8gZG8gdGhlIG1hdGgg Zm9yIDI1NTE5IGFuZCBvdGhlciB0aGluZ3MgbmVlZGVkIHRvIGludGVyb3BlcmF0ZeKAnSBhbmQg d2XigJlsbCBoYXZlIG90aGVyIFJGQ+KAmXMgdGhhdCBzYXkg4oCcaGVyZeKAmXMgaG93IHRvIHVz ZSB0aGF0IGN1cnZlIGluIHRoaXMgcHJvdG9jb2wu4oCdDQoNCldoeSBkb2VzIGl0IG5lZWQgdG8g YmUgbW9yZSB0aGFuIHRoYXQ/ICBJIGtub3cgdGhhdCBJIGFtIG5vdCBhbG9uZSBpbiB0aGlzIGNv bmZ1c2lvbi4NCg0KICAgICAgICAgICAgICAgIC9yJA0KDQotLQ0KUHJpbmNpcGFsIFNlY3VyaXR5 IEVuZ2luZWVyDQpBa2FtYWkgVGVjaG5vbG9naWVzLCBDYW1icmlkZ2UsIE1BDQpJTTogcnNhbHpA amFiYmVyLm1lPG1haWx0bzpyc2FsekBqYWJiZXIubWU+OyBUd2l0dGVyOiBSaWNoU2Fseg0K --_000_2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95USMBX1msgcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0K CWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGlu Ow0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xv cjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7 bXNvLWxpc3QtaWQ6MTIxNzA4NTgyNTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6LTEwMDgxODc2NDIgLTExOTk2ODE4MzQgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo2Ow0KCW1zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjpibGFjazt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGJnY29sb3I9d2hp dGUgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rp b24xPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OldpbmdkaW5ncyc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+w5g8 c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7IDwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5JbXBsaWNhdGlvbjogVGhlIElFVEYgd2lsbCBoYXZlIHRv IG1ha2Ugc29tZSBwcm9ub3VuY2VtZW50IG9yIGFzc3VyYW5jZSBhcyB0byB0aGUgdmlhYmlsaXR5 IG9mIEN1cnZlMjU1MTkgdG8gdGhlIHdpZGVyIHdvcmxkLiZuYnNwOyBUaGUgSUVURiB3aWxsIGhh dmUgdG8gbWFpbnRhaW4gdGhlIEN1cnZlMjU1MTkgc3RhbmRhcmQuPGJyPjxicj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5NaWtlLCBJIGtub3cgeW914oCZdmUgYmVlbiBpbnZvbHZlZCBp biB0aGlzIHN0dWZmIHNpbmNlIGJlZm9yZSB0aGlzIHN0dWZmIGV4aXN0ZWQgPC9zcGFuPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0 OTdEJz5KPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LCBidXQgSSBkb27igJl0IHVuZGVy c3RhbmQgdGhpcy4gV2h5IGRvIHdlIGhhdmUgdG8gbWFrZSBhbnkgYXNzdXJhbmNlIGFib3V0IGFu eXRoaW5nIG90aGVyIHRoYW4g4oCYaGVyZSBpcyBob3cgdG8gaW50ZXJvcGVyYXRlIHVzaW5nIDI1 NTE5IGluIFRMU+KAmT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldl4oCZcmUgbm90IGRlZmluaW5nIGEg c3RhbmRhcmQsIHdl4oCZcmUgbm90IGFzc3VyaW5nIHRoZSB3b3JsZCBhYm91dCBhbnl0aGluZy4g V2XigJlsbCBoYXZlIGFuIFJGQyB0aGF0IHNheXMg4oCcaGVyZeKAmXMgwqBob3cgdG8gZG8gdGhl IG1hdGggZm9yIDI1NTE5IGFuZCBvdGhlciB0aGluZ3MgbmVlZGVkIHRvIGludGVyb3BlcmF0ZeKA nSBhbmQgd2XigJlsbCBoYXZlIG90aGVyIFJGQ+KAmXMgdGhhdCBzYXkg4oCcaGVyZeKAmXMgaG93 IHRvIHVzZSB0aGF0IGN1cnZlIGluIHRoaXMgcHJvdG9jb2wu4oCdPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5XaHkgZG9lcyBpdCBuZWVkIHRvIGJlIG1vcmUgdGhhbiB0aGF0P8KgIEkga25vdyB0aGF0IEkg YW0gbm90IGFsb25lIGluIHRoaXMgY29uZnVzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIC9yJDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLcKg IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5QcmluY2lwYWwgU2VjdXJpdHkgRW5naW5lZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QWthbWFpIFRlY2hub2xv Z2llcywgQ2FtYnJpZGdlLCBNQTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JTTogPGEgaHJlZj0ibWFpbHRvOnJzYWx6QGphYmJl ci5tZSI+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUnPnJzYWx6QGphYmJlci5tZTwvc3Bhbj48L2E+ OyBUd2l0dGVyOiBSaWNoU2FsejxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jv ZHk+PC9odG1sPg== --_000_2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95USMBX1msgcorp_-- From nobody Sun Jun 29 21:36:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D411A0162 for ; Sun, 29 Jun 2014 21:36: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWA79TjMrU5u for ; Sun, 29 Jun 2014 21:36:06 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85EAB1A014B for ; Sun, 29 Jun 2014 21:36:06 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id q9so4368758ykb.29 for ; Sun, 29 Jun 2014 21:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tKRxo/nZSzZate3o7K2Y6DAEacjE8FS/EJcYXQHXyQ4=; b=mJ5Outlbp34TeMZliyRfvMCkRsPiFK9bErSDpteSZxeGo0hPQJ4Gcqf/ZyZsImI6Fh mqDxaDwszH02aQ6t/E4NzFnwj47GudiujL3WRcK0PBcDbv5Pnkm3ChT4oFuZh+8MJDG1 vjwRwQxAcNcHTD5En0oJ+FMwC5Jvfgq8qRSbiSJq65QXepFt5e5bEmrhVX9LABDFPc1T ZSv4frxVN5GL4zIWAdNVeKFSeI3zjnCDLiuc0QinuGHU0nAy5uAAp7xzVhj/9FL0hqCh w2NqgljVFAu2iEd6eqOK6l4xRUyFX/EMIgtSqjhfjbwknhuGIN3GJPrkrv5TQTMINI9g LYeA== MIME-Version: 1.0 X-Received: by 10.236.172.161 with SMTP id t21mr55795875yhl.65.1404102965705; Sun, 29 Jun 2014 21:36:05 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Sun, 29 Jun 2014 21:36:05 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95@USMBX1.msg.corp.akamai.com> References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> <53AF517F.7050504@nthpermutation.com> <53B07640.2050000@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95@USMBX1.msg.corp.akamai.com> Date: Sun, 29 Jun 2014 21:36:05 -0700 Message-ID: From: Watson Ladd To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GF-cAeWsErEmQ-yTsSE76YBxNvA Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 04:36:08 -0000 On Sun, Jun 29, 2014 at 8:12 PM, Salz, Rich wrote: > =C3=98 Implication: The IETF will have to make some pronouncement or ass= urance > as to the viability of Curve25519 to the wider world. The IETF will have= to > maintain the Curve25519 standard. > > Mike, I know you=E2=80=99ve been involved in this stuff since before this= stuff > existed J, but I don=E2=80=99t understand this. Why do we have to make an= y assurance > about anything other than =E2=80=98here is how to interoperate using 2551= 9 in TLS=E2=80=99? No, we are defining a standard, and we are making assurances. Let's not kid ourselves: SPF might say experimental, but if you try to send mail without it, you'll find out just how much of a standard it is. As for making assurances, if someday a massive break is discovered in TLS 1.3 because we neglected cryptographic knowledge, we will rightfully be blamed for it. If 25519 was ROT13, a proposal to include it would rightfully be laughed out of this WG. We've established the principle, now we're just haggling over its limits. Sincerely, Watson Ladd > > > > We=E2=80=99re not defining a standard, we=E2=80=99re not assuring the wor= ld about anything. > We=E2=80=99ll have an RFC that says =E2=80=9Chere=E2=80=99s how to do th= e math for 25519 and other > things needed to interoperate=E2=80=9D and we=E2=80=99ll have other RFC= =E2=80=99s that say =E2=80=9Chere=E2=80=99s > how to use that curve in this protocol.=E2=80=9D > > > > Why does it need to be more than that? I know that I am not alone in thi= s > confusion. > > > > /r$ > > > > -- > > Principal Security Engineer > > Akamai Technologies, Cambridge, MA > > IM: rsalz@jabber.me; Twitter: RichSalz > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From SRS0=ovrA=33=acm.org=bmoeller@srs.kundenserver.de Mon Jun 30 00:34:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590D31A019C for ; Mon, 30 Jun 2014 00:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.721 X-Spam-Level: * X-Spam-Status: No, score=1.721 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrhBfedFwWSC for ; Mon, 30 Jun 2014 00:34:29 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A281A0198 for ; Mon, 30 Jun 2014 00:34:28 -0700 (PDT) Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0MNtFb-1Wza2M3o9z-007XnE; Mon, 30 Jun 2014 09:34:26 +0200 Received: by mail-yh0-f44.google.com with SMTP id f10so4608045yha.3 for ; Mon, 30 Jun 2014 00:34:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.39.100 with SMTP id c64mr9994368yhb.103.1404113664816; Mon, 30 Jun 2014 00:34:24 -0700 (PDT) Received: by 10.170.83.215 with HTTP; Mon, 30 Jun 2014 00:34:24 -0700 (PDT) Date: Mon, 30 Jun 2014 09:34:24 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1137f868373c5404fd08b0b9 X-Provags-ID: V02:K0:fMNrUJv85zBUCTonI1A3XY+ucd3h9i1QCDc9hNsmQFX Il0NREjJNlaRJtGbuyXxiSVd7qN+La3+qnKcvBJgVKZottlpKD NRGzVqlZLp9gTZ6UhKsulgM/jDzCj+6DAX7IRWeBzfK/W1LG4C 3ob3D3poctAn9bJwj8j/ADXObkeQaardo6IsgyY3WlGc9VvjXs eXWUMYyWy5z/uxW0JEXaUEf46w6c6BT+2Ll7zyTpexH9c4+Ryg +nqefKvBHjiiWH1RMmsFr3j+obPIvrj0Ti2s4PIZrbxBiOvnRX 2HRiku4zLS35XgdEUswOh/g3Uy7cAztLUBdxYDhwYsFmbj1dU5 tsfcW2M4zdfxpW9iOzjrPgJkyB7Pc/2DhsTPJduzhA1RrHVAxG BuJWmXUuO/WfM5zr/zy0M6xeH+k4w8mizFVDK9OPzt1+37DOU7 G2ASk Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OUtlC4fbP9GKa8NyZlcKVjR696E Subject: Re: [TLS] Curve25519 and TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 07:35:33 -0000 --001a1137f868373c5404fd08b0b9 Content-Type: text/plain; charset=UTF-8 [Resending my earlier message because apparently it hadn't made it to the list. If you read the quotes in Watson's reply to this, there's nothing new here.] ---------- Forwarded message ---------- From: Bodo Moeller Date: 2014-06-26 10:18 GMT+02:00 Subject: Re: [TLS] Curve25519 and TLS To: Watson Ladd Cc: "tls@ietf.org" Watson Ladd : TLS with ECC computes the premaster secret as H(abg) where g is the > generator of the group, and a and b are the ephemeral exponents. > Because of protocol weaknesses, this premaster secret must be > "contributory": neither side can be allowed to dictate it. > [...] > The solution is to follow the advice on contributory behaviour and > disallow a fixed list of public keys, namely those of small order. > Good point. Given that the cofactor present in your secret key guarantees that you'll end up in a prime-order group (regardless of how the peer's input was chosen), I think you'd rather want to check the ECDH result instead of checking against that larger blacklist of public keys. Alternatively we can compute the premaster secret as the hash of H(ag > | bg | abg): I have not yet confirmed that this solves the problem. > Hm, this looks like something that rather belongs into the premaster secret => master secret step. If you have this there (such as when you're using the proposed Extended Master Secret Extension [draft-bhargavan-tls-session-hash-00]), including the public keys here too would be redundant. If you'd normally be doing a public-key check or an ECDH result check, you could just skip this check if the protocol no longer has a need for such protection. In contrast, if you hash those additional inputs when computing the premaster secret, that's not something you could remove without affecting compatibility. (On the flip site, of course, if an implementation omits a check that's necessary for security reasons in the protocol that you're using, you wouldn't normally notice interoperability problems as a result. In contrast, if the protocol has those additional hash inputs, implementations couldn't get that wrong without failing to interoperate with others. However, there are many other more complex essential security checks that we trust implementations to get right, so the extra protocol complexity for this particular case doesn't seem warranted.) Bodo --001a1137f868373c5404fd08b0b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Resending my earlier message because apparently it hadn&#= 39;t made it to the list. If you read the quotes in Watson's reply to t= his, there's nothing new here.]


= ---------- Forwarded message ----------
From: Bodo Moeller <= bmoeller@acm.org>
Date= : 2014-06-26 10:18 GMT+02:00
Subject: Re: [TLS] Curve25519 and TLS
To= : Watson Ladd <watsonbladd@gmai= l.com>
Cc: "tls@ietf.org" <tls@ietf.org>


=
Watson Ladd <wat= sonbladd@gmail.com>:

TLS with ECC computes the premaster secret as H(abg) where g is the
generator of the group, and a and b are the ephemeral exponents.
Because of protocol weaknesses, this premaster secret must be
"contributory": neither side can be allowed to dictate it.
=C2=A0
[...]=C2=A0
The solution is to follow the advice on contributory behaviour and
disallow a fixed list of public keys, namely those of small order.

Good point. =C2=A0Given that the cofactor= present in your secret key guarantees that you'll end up in a prime-or= der group (regardless of how the peer's input was chosen), I think you&= #39;d rather want to check the ECDH result instead of checking against that= larger blacklist of public keys.

Alternatively we can compute the premaster secret as the hash of H(ag
| bg | abg): I have not yet confirmed that this solves the problem.

Hm, this looks like something that rathe= r belongs into the premaster secret =3D> master secret step. =C2=A0If yo= u have this there (such as when you're using the proposed Extended Mast= er Secret Extension [draft-bhargavan-tls-session-hash-00]), including the p= ublic keys here too would be redundant. =C2=A0If you'd normally be doin= g a public-key check or an ECDH result check, you could just skip this chec= k if the protocol no longer has a need for such protection. =C2=A0In contra= st, if you hash those additional inputs when computing the premaster secret= , that's not something you could remove without affecting compatibility= .

(On the flip site, of course, if an implementation omit= s a check that's necessary for security reasons in the protocol that yo= u're using, you wouldn't normally notice interoperability problems = as a result. =C2=A0In contrast, if the protocol has those additional hash i= nputs, implementations couldn't get that wrong without failing to inter= operate with others. =C2=A0However, there are many other more complex essen= tial security checks that we trust implementations to get right, so the ext= ra protocol complexity for this particular case doesn't seem warranted.= )

Bodo


--001a1137f868373c5404fd08b0b9-- From nobody Mon Jun 30 00:58:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23301A002D; Mon, 30 Jun 2014 00:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9Zs7nrdIwgj; Mon, 30 Jun 2014 00:58:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242CF1A001C; Mon, 30 Jun 2014 00:58:15 -0700 (PDT) Received: from BL2PR03MB242.namprd03.prod.outlook.com (10.255.231.18) by BL2PR03MB242.namprd03.prod.outlook.com (10.255.231.18) with Microsoft SMTP Server (TLS) id 15.0.974.11; Mon, 30 Jun 2014 07:58:13 +0000 Received: from BL2PR03MB242.namprd03.prod.outlook.com ([169.254.8.49]) by BL2PR03MB242.namprd03.prod.outlook.com ([169.254.8.49]) with mapi id 15.00.0974.002; Mon, 30 Jun 2014 07:58:13 +0000 From: Brian LaMacchia To: "cfrg@ietf.org" , "tls@ietf.org" Thread-Topic: Announcing the availability of the MSR Elliptic Curve Cryptography Library for NUMS Curves Thread-Index: Ac+ULptlErlgH8vFSUux7ZRAEp5kVg== Date: Mon, 30 Jun 2014 07:58:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [63.229.5.96] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(164054003)(2656002)(85852003)(31966008)(4396001)(74502001)(81342001)(92566001)(20776003)(46102001)(33646001)(76576001)(15975445006)(21056001)(76482001)(74662001)(54356999)(15202345003)(80022001)(50986999)(81542001)(74316001)(99396002)(64706001)(79102001)(66066001)(86362001)(99286002)(77982001)(87936001)(106356001)(101416001)(95666004)(85306003)(105586002)(77096002)(83322001)(19580395003)(19580405001)(83072002)(107886001)(229853001)(107046002)(42262001)(24736002)(9853045004); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB242; H:BL2PR03MB242.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DgfVtrx3kCARjdGzuOYxU5Zwuok Subject: [TLS] Announcing the availability of the MSR Elliptic Curve Cryptography Library for NUMS Curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 07:58:19 -0000 Dear members of the IRTF CFRG and the IETF TLS WG, On behalf of the Microsoft Research ECCLib Project, I am pleased to announc= e the first release of the Microsoft Research Elliptic Curve Cryptography L= ibrary (ECCLib) for NUMS ("Nothing Up My Sleeve") curves. We are releasing= ECCLib under the Apache 2.0 License. Here is a link to the project page a= nd download location: http://research.microsoft.com/en-us/projects/nums/ =20 The MSR ECCLib is an efficient cryptography library that provides functions= for computing essential elliptic curve operations on a new set of high-sec= urity curves as previously described in [1] and presented at the CFRG Sprin= g 2014 Interim Meeting (see [2] for a copy of the slides from that presenta= tion). All computations in ECCLib on secret data exhibit regular, constant= -time execution, providing protection against timing and cache attacks. ECCLib supports six high-security elliptic curves proposed in [1], which co= ver three security levels (128-, 192-, and 256-bit security) and two curve = models. The curves have a very simple and deterministic generation with min= imal room for parameter manipulation. ECCLib includes all the ECC function= s necessary to implement most popular elliptic curve-based schemes. In part= icular, ECCLib supports the computation of scalar multiplication for the si= x curves above in three variants:=20 1. Variable-base scalar multiplication (e.g., this is used for computing t= he shared key in the Diffie-Hellman key exchange). 2. Fixed-base scalar multiplication (e.g., this is used for key generation= in the Diffie-Hellman key exchange). 3. Double-scalar multiplication. This operation is typically used for veri= fying signatures.=20 =20 As both the CFRG and the TLS WG are currently considering additional curves= for elliptic curve cryptography, we hope that this contribution (in additi= on to the technical paper previously presented) will further a thoughtful d= iscussion concerning what new curves CFRG should recommend and TLS should c= onsider for inclusion. We welcome questions/comments/feedback on this libr= ary; please send them to msrsc@microsoft.com. Please Note: the version of ECCLib that we are releasing today is for x64 p= latforms with AVX and builds with the Microsoft Visual Studio toolchain. W= e are actively working on both a version that builds with GCC and also a po= rtable C version and hope to add these to the release in the near future. Thanks, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 --bal [1] Joppe W. Bos, Craig Costello, Patrick Longa and Michael Naehrig, "Selec= ting Elliptic Curves for Cryptography: An Efficiency and Security Analysis"= , Cryptology ePrint Archive: Report 2014/130. Available at: http://eprint.i= acr.org/2014/130=20 [2] http://patricklonga.webs.com/Presentation_CFRG_Selecting_Elliptic_Curve= s_for_Cryptography.pdf From nobody Mon Jun 30 01:54:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1551A01A7 for ; Mon, 30 Jun 2014 01:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjyZZKgfP-8L for ; Mon, 30 Jun 2014 01:54:11 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89CD51A0079 for ; Mon, 30 Jun 2014 01:54:11 -0700 (PDT) Received: from mail-yk0-f181.google.com (mail-yk0-f181.google.com [209.85.160.181]) by mrelayeu.kundenserver.de (node=mreue004) with ESMTP (Nemesis) id 0LnX58-1WRwwp0bXC-00hbJj; Mon, 30 Jun 2014 10:54:09 +0200 Received: by mail-yk0-f181.google.com with SMTP id 9so4405540ykp.26 for ; Mon, 30 Jun 2014 01:54:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.223.229 with SMTP id v95mr1850989yhp.128.1404118447742; Mon, 30 Jun 2014 01:54:07 -0700 (PDT) Received: by 10.170.83.215 with HTTP; Mon, 30 Jun 2014 01:54:07 -0700 (PDT) In-Reply-To: References: <53B07AE5.5090304@nthpermutation.com> Date: Mon, 30 Jun 2014 10:54:07 +0200 Message-ID: From: Bodo Moeller To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c1ecbe4ce30404fd09cdb8 X-Provags-ID: V02:K0:c2L7aIEyqYP7aMrdW6Fb72zsfcOjCbEM2tm+GJw+kIM llarEGWSweHgWBNEKyqFRZPqtPiQhgK9jRNz33HtnZhe27uEgy hyZE2V3hdA6DOnyMK5LZQt7YedtCx5n+rAnHn2viGC6sWppfhy cQdcFVbgbHNtHqirx9yXs+NDEIm239t8y6HelJstCePdQlcI25 ZeYRjyvWmAtvfLP8rWoSO+V+SOUly+lt7iFtOeu4plV4dXyS3t 7l5KD3kkfSEv7ceYTsVyEQQGRgkRtBR2F9a6LYXfUNl89xMHu7 UNecRAO5Ch4WWA/3vPWgyI5eJ1VAXMPFv8Wuyax59JY9npij+1 ljuYP29CIX5c94H9rAFLhrgKddXLmuxQKw1/c5LSGGBFFJ6bZ7 GvE7WFPahoXY6QnVuHJmTaefVSzwYAbKHG3w2DGycVInPYVnxy vi81f Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bVh45CZtNJv6FYcqc8Bg9E2CJEY Cc: "tls@ietf.org" Subject: Re: [TLS] Does anyone still want dh_rsa and dh_dss? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 08:54:12 -0000 --001a11c1ecbe4ce30404fd09cdb8 Content-Type: text/plain; charset=UTF-8 > > We've already removed static RSA for TLS 1.3 but we didn't >> emove dh_rsa and dh_dss (as opposed to dhe_rsa and >> dhe_dss). It seems like the arguments for removing static >> RSA apply even more strongly here. >> >> Is there any reason to retain these in TLS 1.3? >> >> > [...] is there some reason to retain non-ephemeral ECDH vice non-ephemeral >> DH? >> > > Not that I know of, it's just that I was working through the TLS spec and > the ECDHE code points don't appear there, so I didn't think of it. > I agree to throwing out all of these. (From a practical point of view, there probably are more ECC certificates that *could*, in theory, be used for static ECDH than there are DH certificates, but I don't see a good reason to support that in the protocol. As I see it, non-ephemeral ECDH was essentially for "feature parity" with non-ephemeral DH.) Bodo --001a11c1ecbe4ce30404fd09cdb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We've already r= emoved static RSA for TLS 1.3 but we didn't=C2=A0
emove dh_rsa and dh_dss (as opposed to dhe_rsa and
dhe_dss). It seems like the arguments for removing static
RSA apply even more strongly here.

Is there any reason to retain these in TLS 1.3?
=C2=A0
[= ...] is there some reason to retain non-ephemeral ECDH vice non-ephemeral DH?
=C2=A0
Not that I know of, i= t's just that I was working through the TLS spec and
the ECDH= E code points don't appear there, so I didn't think =C2=A0of it.

I agree to throwing out = all of these.

(From a practical point of view, the= re probably are more ECC certificates that *could*, in theory, be used for = static ECDH than there are DH certificates, but I don't see a good reas= on to support that in the protocol. As I see it, non-ephemeral ECDH was ess= entially for "feature parity" with non-ephemeral DH.)

Bodo

--001a11c1ecbe4ce30404fd09cdb8-- From nobody Mon Jun 30 06:41:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209731A031B for ; Mon, 30 Jun 2014 06:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-RIr3TgFFp6 for ; Mon, 30 Jun 2014 06:41:00 -0700 (PDT) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B811A030D for ; Mon, 30 Jun 2014 06:41:00 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jw12so8206947veb.11 for ; Mon, 30 Jun 2014 06:40:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ysf1eqoUE5n8JV4KIzPMDX/Bsry7UjQ0/Y13do63828=; b=XgJSSJFApOGzJAt/vJtr+wTW5iZWG9N117XqpbgtecuWy8DGtvnlYKdYTGq3PV5D5q 1GVGGmnk5Ou1ovW1PndUIJNeXryZsUohMZgOzIhc5L8IVTOYWJc080R7Nz/kJ97oQu5o nSz7hx7fVJgmUGjoZFI+FzCqoDrocw7+pXDVFi1sq6R1sbegpaVSJwkNVpK8wkOFwkBf NvLHiIrU4aO/SlaCv1CBV22AZ+tNXhE2rpITTqFOgbIe+915cdRovjDQZojNF/mAZgxX foS6YRQcMcKY20JHdFavrJiOGoZL6+OAmUgqj2GfUKQyT3PTWqo4q+FcIJXgMnW3AxX0 zJVA== X-Gm-Message-State: ALoCoQldToiQp8n5evtwogl+p6P5veebMcrJWT3cBb5ecSR8ZcascSZ6oOtOF6YG6qoo0/MGTDxv MIME-Version: 1.0 X-Received: by 10.52.120.109 with SMTP id lb13mr582870vdb.53.1404135659451; Mon, 30 Jun 2014 06:40:59 -0700 (PDT) Received: by 10.52.120.73 with HTTP; Mon, 30 Jun 2014 06:40:59 -0700 (PDT) X-Originating-IP: [132.162.120.50] In-Reply-To: References: Date: Mon, 30 Jun 2014 09:40:59 -0400 Message-ID: From: Steve Checkoway To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e013a0f2232cb8a04fd0dcfb3 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GgOnkybWbsM4ksT3oyHfUvnP5-k Subject: Re: [TLS] Does anyone still want dh_rsa and dh_dss? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 13:41:02 -0000 --089e013a0f2232cb8a04fd0dcfb3 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 26, 2014 at 1:32 PM, Adam Langley wrote: > On Thu, Jun 26, 2014 at 9:14 AM, Eric Rescorla wrote: > > Is there any reason to retain these in TLS 1.3? > > I don't believe so. (Additionally, I would drop DSS completely.) > +1 -- Steve Checkoway --089e013a0f2232cb8a04fd0dcfb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Jun 26, 2014 at 1:32 PM, Adam Langley <agl@imperialviolet.org= > wrote:
On Thu, Jun 26, 2014 at 9:14= AM, Eric Rescorla <ekr@rtfm.com>= wrote:
> Is there any reason to retain these in TLS 1.3?

I don't believe so. (Additionally, I would drop DSS completely.)<= br>
<= div>=C2=A0
+1

--
Steve Checkoway
--089e013a0f2232cb8a04fd0dcfb3-- From nobody Mon Jun 30 06:53:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7901A0354 for ; Mon, 30 Jun 2014 06:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEHZhTmKCnD3 for ; Mon, 30 Jun 2014 06:53:45 -0700 (PDT) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159D81A034F for ; Mon, 30 Jun 2014 06:53:45 -0700 (PDT) Received: from [10.169.30.97] (85-76-48-154-nat.elisa-mobile.fi [85.76.48.154]) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 050DD400B7; Mon, 30 Jun 2014 16:53:37 +0300 (EEST) Content-Type: multipart/alternative; boundary=Apple-Mail-CB9E77FF-039A-48B2-859B-5BCF6A166617 Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= X-Mailer: iPhone Mail (11D201) In-Reply-To: Date: Mon, 30 Jun 2014 16:53:36 +0300 Content-Transfer-Encoding: 7bit Message-Id: <79DBF34B-6D1B-4343-A79E-74B85A919A89@iki.fi> References: <53B07AE5.5090304@nthpermutation.com> To: Bodo Moeller Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nc37swb_c4YXC4lJf9dr0j0BZbo Cc: "tls@ietf.org" Subject: Re: [TLS] Does anyone still want dh_rsa and dh_dss? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 13:53:47 -0000 --Apple-Mail-CB9E77FF-039A-48B2-859B-5BCF6A166617 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 30.6.2014, at 11.54, Bodo Moeller wrote: >>>> We've already removed static RSA for TLS 1.3 but we didn't=20 >>>> emove dh_rsa and dh_dss (as opposed to dhe_rsa and >>>> dhe_dss). It seems like the arguments for removing static >>>> RSA apply even more strongly here. >>>>=20 >>>> Is there any reason to retain these in TLS 1.3? > =20 >>> [...] is there some reason to retain non-ephemeral ECDH vice non-eph= emeral DH? > =20 >> Not that I know of, it's just that I was working through the TLS spec and= >> the ECDHE code points don't appear there, so I didn't think of it. >=20 > I agree to throwing out all of these. +1 Juho --Apple-Mail-CB9E77FF-039A-48B2-859B-5BCF6A166617 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 30.6.2014, at 11.54, Bodo Moeller <bmoeller@acm.org> wrote:

We've already removed static RSA for TLS 1.3 but we didn't 
emove dh_rsa and dh_dss (as opposed to dhe_rsa and
dhe_dss). It seems like the arguments for removing static
RSA apply even more strongly here.

Is there any reason to retain these in TLS 1.3?
 
[...] is there some reason to retain non-ephemeral ECDH vice non-ephemeral DH?
 
Not that I know of, it's just that I was working through the TLS spec and
the ECDHE code points don't appear there, so I didn't think  of it.

I agree to throwing out all of these.

+1


Juho

--Apple-Mail-CB9E77FF-039A-48B2-859B-5BCF6A166617-- From nobody Mon Jun 30 08:11:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A151A0022 for ; Mon, 30 Jun 2014 08:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QeuItU0EUIC for ; Mon, 30 Jun 2014 08:11:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E2A1A037F for ; Mon, 30 Jun 2014 08:11:47 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s5UFBj87023718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 30 Jun 2014 08:11:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: <20140623170420.18078.60604.idtracker@ietfa.amsl.com> Date: Mon, 30 Jun 2014 08:11:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3A4C6E35-6C0F-4B16-8C8C-52F397FC0962@vpnc.org> References: <20140623170420.18078.60604.idtracker@ietfa.amsl.com> To: tls@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XUXXhJARPmTBJE1BMMG1huzKoe4 Subject: Re: [TLS] TLS Working Group Interim Meeting, July 20, 2014 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 15:11:52 -0000 The WG has 6 hours scheduled for Sunday, 1.5 hours on Monday, and 1 hour = on Thursday. Is there an agenda for what will be discussed in each = segment of those 8.5 hours? --Paul Hoffman= From nobody Mon Jun 30 09:02:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6691A0392 for ; Mon, 30 Jun 2014 09:02:15 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci0U6ygl7GIN for ; Mon, 30 Jun 2014 09:02:12 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066691A0389 for ; Mon, 30 Jun 2014 09:02:11 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id i13so6441458qae.5 for ; Mon, 30 Jun 2014 09:02:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=65gqcrlQVpjHwpI48vktt9hDPCfkLIufKLswXASiy5U=; b=hMPZnZcUOqJkBydUb/aEKg7QiyqI4btVSknpBqxWz1BSFHC+e+qV88tr768m6bWPRK Tlc8PETidaSErttQj3eA/tqJNoG4AszF6Ci0qhS6lFVZRyHyQ1jd0K3G1M/Tuc7+o45O Q/VkgYzxzq///OwuXW2QxtA1Al/nOuWabomszraKOwdHo1+iFFkHu3eeog7uRHoITXfG VS3cqEBF23TyU/UkXK7iNAUDsoPKTS/HP3tzDh2AhRec28Y2edcNefPMCZmm/SZKhNtM 8qJiHciZN8a0LPqj0odlqfdY4E0FPFth8+rhEYuXKrt3Jyxb2GWdaNc+zw5fS+gAMa7S 2FaA== X-Gm-Message-State: ALoCoQk6cr7sTegB46vFrg6lnyRMLQD1dH8PopnPOoGKJrzW3iNo7eyjmrTVcxqFSlWJFriAoesj X-Received: by 10.140.26.201 with SMTP id 67mr59805256qgv.51.1404144130892; Mon, 30 Jun 2014 09:02:10 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:390:b4d7:6f3f:f3ac:4c6? ([2601:a:2a00:390:b4d7:6f3f:f3ac:4c6]) by mx.google.com with ESMTPSA id x1sm32634838qaj.19.2014.06.30.09.02.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 09:02:10 -0700 (PDT) Message-ID: <53B18A01.7070101@nthpermutation.com> Date: Mon, 30 Jun 2014 12:02:09 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Eric Rescorla References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> <53AF517F.7050504@nthpermutation.com> <53B07640.2050000@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090704070701000209010603" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DVHNbvAbhYgKobFCXocUjqiSlHU Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 16:02:16 -0000 This is a multi-part message in MIME format. --------------090704070701000209010603 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/29/2014 5:29 PM, Eric Rescorla wrote: > > > > On Sun, Jun 29, 2014 at 1:25 PM, Michael StJohns > > wrote: > > In line below. > > > On 6/28/2014 7:51 PM, Eric Rescorla wrote: >> >> >> >> On Sat, Jun 28, 2014 at 4:36 PM, Michael StJohns >> > wrote: >> >> On 6/28/2014 7:04 PM, Watson Ladd wrote: >>> >>> >>> On Jun 28, 2014 3:55 PM, "Michael StJohns" >>> > wrote: >>> > >>> > On 6/28/2014 6:24 PM, Salz, Rich wrote: >>> >>> >>> >>> *sigh* If the IETF is really going to get into the >>> business of standardizing >>> >>> > crypto, we need to get the process for doing so right >>> the first time rather >>> >>> > than just plugging it in to TLS and hoping we don't >>> have to redo it over and >>> >>> > over again. >>> >> >>> >> Agree. But again, it's "back into the business" Because >>> we did it before with TLS1, IPsec, and ECC curves therein. >>> > >>> > >>> > Um... huh? Can you provide specifics about which >>> cryptographic algorithms we standardized? This is news to me. >>> >>> Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0 >>> by ignoring lessons from IPSEC. >>> >>> >> >> I can't find an RC4 RFC, but Camellia and HMAC are both >> Informational rather than Standards track. >> >> >> I'm not sure why this is a relevant distinction. These documents are >> published by IETF and we make normative references to them in >> Standards Track documents. See, for instance: >> >> http://datatracker.ietf.org/doc/rfc2104/referencedby/ > > Hi Ekr - thanks for the question. > > > I think the question you're asking is "Why is the distinction > between Internet Standard and informational RFC relevant to the > use of Curve25519"? That's the one I'll try and respond to. Let > me know if I got the question wrong. > > > Sure, we can take it as that question. > > Fact: Almost any one who wants to can publish an Informational RFC. > Fact: Informational RFCs are not Internet Standards. They may be > products of the IETF, but do not have to be. They tend to be > evaluated less strenuously than standards track RFCs. > Fact: Every single cryptographic standard that the IETF has > published as an RFC has been Informational. None of them appear > to be products of the IETF, but I could have missed one. > Fact: The IETF has made no claim as to the strength of viability > of crypto published as Informational RFCs. E.g. we're just a user > of cryptography, not an originator. > > Observation: The Curve25519 documents could have been published > as Informational along the same basis as above. Some of them may > still be. > Observation: The CFRG was asked to comment on Curve25519 - > specifically to give a recommendation. > Observation: At least one person on this email thread (and others > elsewhere) have used the phrase "standardize Curve25519" - another > used the word "preferred". > > Tentative Theory: There is some desire to publish Curve25519 as an > IETF Standards track document. That is to give Curve25519 the > mantle of "cryptography acceptable to the IETF". > > Sorry - delete from "That is to give..." - this was a bad edit. I not actually sure what that last sentence was supposed to be. > This is where you lost me. Consider the following sequence of events: > > 1. Someone publishes a Curve25519 Informational RFC. > 2. The CFRG sends the IETF a message saying "We think the Curve25519 > is a good curve and the IETF should adopt it for use in IETF protocols" > (presumably in more formal language). > 3. The TLS WG publishes a standards track document (assuming for > the moment that we believe that we are going to adopt any standards > track ECC cipher suites) which refers to the RFC published in #1. > > To the best of my knowledge, there isn't any procedural problem with > doing this and it would be effectively what we did with, for instance, > HMAC. I thought I covered this by: > If I am in fact misreading the tea leaves, and a Curve25519 > cryptographic standard is to be published to the IETF as a DJB > contribution and Informational and not a product of the IETF, then > there are no implications and I'll leave this in peace. But anecdotal > evidence suggests that this is in doubt. What DJB has written is the basic algorithm. What needs to be written is the adaptation of that algorithm into a form that provides "enough detail to ensure interoperability between different implementations" [quote from RFC2040 on RC5]. My belief is that document should not be solely a TLS document. If that document is written as an external DJB document and we reference it for TLS, that's fine - that's what we did with HMAC. If instead we choose to write that document as a product and standard of the IETF, that's a whole different matter. If we choose to "prefer" it then that's an even more interesting matter. Up to this point the IETF hasn't "owned" a cryptographic standard. Creating an IETF standard based on Curve25519, if that happens, will be an endorsement, however indirect, of the underlying cryptographic constructs by the IETF. > Do you believe that the IETF made some statements about the quality > of HMAC by publishing RFC 2104 and including HMAC in our protocols? > No. But HMAC was simply a re-publication by the authors to allow for better access by implementers, not an IETF standard. Also, HMAC was more of a cryptographic mode rather than a cryptographic standard - the security of the mode was based on assumptions of the underlying hash(es) - less fundamental analysis was required so our use of it wasn't suspect. > > > That last implication is new for the IETF. AFAIK, each and every > cryptographic algorithm and mode documented by the IETF has an > owner elsewhere and such claims of assurance are made there and > maintenance and changes are done there. > > > Can you tell me who that someone else is for HMAC or RC4? At the time of publication, HMAC was the product of its authors and a republication of: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.134.8430. These days its part and parcel of FIPS198. With respect to RC4, I can't find that the IETF ever published an RFC documenting RC4 - but in any case it was a Ron Rivest trade secret that leaked and which Ron's been nice about letting us use - I'm not sure of its current legal status. OTOH, Rivest did author RFC2040 on RC5 and RC5 modes. It has this line in it: "This memo is a restatement of existing published material. " Later, Mike --------------090704070701000209010603 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 6/29/2014 5:29 PM, Eric Rescorla wrote:



On Sun, Jun 29, 2014 at 1:25 PM, Michael StJohns <msj@nthpermutation.com> wrote:
In line below.


On 6/28/2014 7:51 PM, Eric Rescorla wrote:



On Sat, Jun 28, 2014 at 4:36 PM, Michael StJohns <msj@nthpermutation.com> wrote:
On 6/28/2014 7:04 PM, Watson Ladd wrote:


On Jun 28, 2014 3:55 PM, "Michael StJohns" <msj@nthpermutation.com> wrote:
>
> On 6/28/2014 6:24 PM, Salz, Rich wrote:
>>>
>>> *sigh* If the IETF is really going to get into the business of standardizing
>>> > crypto, we need to get the process for doing so right the first time rather
>>> > than just plugging it in to TLS and hoping we don't have to redo it over and
>>> > over again.
>>
>> Agree.  But again, it's "back into the business"  Because we did it before with TLS1, IPsec, and ECC curves therein.
>
>
> Um... huh?  Can you provide specifics about which cryptographic algorithms  we standardized?  This is news to me.

Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0 by ignoring lessons from IPSEC.



I can't find an RC4 RFC, but Camellia and HMAC are both Informational rather than Standards track. 

I'm not sure why this is a relevant distinction. These documents are
published by IETF and we make normative references to them in
Standards Track documents. See, for instance:


Hi Ekr - thanks for the question.


I think the question you're asking is "Why is the distinction between Internet Standard and informational RFC relevant to the use of Curve25519"?  That's the one I'll try and respond to.  Let me know if I got the question wrong.

Sure, we can take it as that question.

 
Fact: Almost any one who wants to can publish an Informational RFC.
Fact: Informational RFCs are not Internet Standards.  They may be products of the IETF, but do not have to be.  They tend to be evaluated less strenuously than standards track RFCs.
Fact:  Every single cryptographic standard that the IETF has published as an RFC has been Informational.  None of them appear to be products of the IETF, but I could have missed one. 
Fact:  The IETF has made no claim as to the strength of viability of crypto published as Informational RFCs.  E.g. we're just a user of cryptography, not an originator.

Observation:  The Curve25519 documents could have been published as Informational along the same basis as above.  Some of them may still be.
Observation:  The CFRG was asked to comment on Curve25519 - specifically to give a recommendation.
Observation:  At least one person on this email thread (and others elsewhere) have used the phrase "standardize Curve25519" - another used the word "preferred".

Tentative Theory: There is some desire to publish Curve25519 as an IETF Standards track document.  That is to give Curve25519 the mantle of "cryptography acceptable to the IETF".

Sorry - delete from "That is to give..." - this was a bad edit.  I not actually sure what that last sentence was supposed to be.

This is where you lost me. Consider the following sequence of events:

1. Someone publishes a Curve25519 Informational RFC.
2. The CFRG sends the IETF a message saying "We think the Curve25519
is a good curve and the IETF should adopt it for use in IETF protocols"
(presumably in more formal language).
3. The TLS WG publishes a standards track document (assuming for
the moment that we believe that we are going to adopt any standards
track ECC cipher suites) which refers to the RFC published in #1.

To the best of my knowledge, there isn't any procedural problem with
doing this and it would be effectively what we did with, for instance, HMAC.

I thought I covered this by:
If I am in fact misreading the tea leaves, and a Curve25519 cryptographic standard is to be published to the IETF as a DJB contribution and Informational and not a product of the IETF, then there are no implications and I'll leave this in peace.  But anecdotal evidence suggests that this is in doubt.

What DJB has written is the basic algorithm.  What needs to be written is the adaptation of that algorithm into a form that provides "enough detail to ensure interoperability between different implementations" [quote from RFC2040 on RC5].  My belief is that document should not be solely a TLS document.   If that document is written as an external DJB document and we reference it for TLS, that's fine - that's what we did with HMAC.   If instead we choose to write that document as a product and standard of the IETF, that's a whole different matter.  If we choose to "prefer" it then that's an even more interesting matter.

Up to this point the IETF hasn't "owned" a cryptographic standard.  Creating an IETF standard based on Curve25519, if that happens,  will be an endorsement, however indirect, of the underlying cryptographic constructs by the IETF.


Do you believe that the IETF made some statements about the quality
of HMAC by publishing RFC 2104 and including HMAC in our protocols?


No.  But HMAC was simply a re-publication by the authors to allow for better access by implementers, not an IETF standard.   Also, HMAC was more of a cryptographic mode rather than a cryptographic standard - the security of the mode was based on assumptions of the underlying hash(es) - less fundamental analysis was required so our use of it wasn't suspect.




That last implication is new for the IETF.  AFAIK, each and every cryptographic algorithm and mode documented by the IETF has an owner elsewhere and such claims of assurance are made there and maintenance and changes are done there. 

Can you tell me who that someone else is for HMAC or RC4?

At the time of publication, HMAC was the product of its authors and a republication of:  http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.134.8430.   These days its part and parcel of FIPS198. 

With respect to RC4, I can't find that the IETF ever published an RFC documenting RC4 - but in any case it was a Ron Rivest trade secret that leaked and which Ron's been nice about letting us use - I'm not sure of its current legal status.   OTOH, Rivest did author  RFC2040 on RC5 and RC5 modes.   It has this line in it: "This memo is a restatement of existing published material. "


Later, Mike

--------------090704070701000209010603-- From nobody Mon Jun 30 09:32:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FBC1A03C3 for ; Mon, 30 Jun 2014 09:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RL4OiFs2BaSw for ; Mon, 30 Jun 2014 09:32:06 -0700 (PDT) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6CB1A03C6 for ; Mon, 30 Jun 2014 09:31:37 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id x13so7132696qcv.19 for ; Mon, 30 Jun 2014 09:31:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oj1eaIbpfA2VHEvOziswoWbaTfbiBcWBo9SD5Aahrhg=; b=KwoKCaw3NljxmndE7Fi7H5XQHmmnKxg62A5ajmlnk8YHpxj6TnXQxXqf4X18z2a4Fl 3cwFGEdLW05MFLTLI6ObJuE9waZxIjVMIHdpIujwjfm/a9Z2ghTVVjZZE6QbDMFMkfgx 3XGkUCtR5s7ecFzXfna7EI3poHsGbwby7ePdBU5I8LRurURgfbOZ1MfoQCFJ1+WaSZzp WnAq0B5mAsZgQI/yCIOuxXSaycUwZ6MmYa41F+IH+YXZnzrNm540olDlBHmzlRH1DDXk Zbg6L6XAqqTSbJhDigBj5xe7BF/VPgk+pRhRSMsfonMnK2UVy+YTs9gBknNjJy4TXzTw AfYg== X-Gm-Message-State: ALoCoQkF+DETpZvts1P0Eo4pr2uN59vUsc7L28N8HroNJ5T82ECQiCIYpQYUz+0r69rTeKp1ZD/W X-Received: by 10.140.101.86 with SMTP id t80mr33088221qge.108.1404145896891; Mon, 30 Jun 2014 09:31:36 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:390:b4d7:6f3f:f3ac:4c6? ([2601:a:2a00:390:b4d7:6f3f:f3ac:4c6]) by mx.google.com with ESMTPSA id y81sm12413283qgd.13.2014.06.30.09.31.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 09:31:36 -0700 (PDT) Message-ID: <53B190E7.6050800@nthpermutation.com> Date: Mon, 30 Jun 2014 12:31:35 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Watson Ladd , "Salz, Rich" References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> <53AF517F.7050504@nthpermutation.com> <53B07640.2050000@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95@USMBX1.msg.corp.akamai.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gPgyUqZrCe5U-ZArFSeP5mENGn8 Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 16:32:07 -0000 Two opposing views on whether Curve25519 is destined for IETF standardization status.... and hence some of my confusion. Rich - "here’s how to do the math for 25519 and other things needed to interoperate" is sort of the definition of what a cryptographic standard is - only question is whether its an externally owned/maintained document offered as an Informational RFC or an IETF standards track document. If the latter, then the standard (and indirectly the math) gets an IETF imprimatur and we haven't offered those - yet - for cryptographic standards. Mike On 6/30/2014 12:36 AM, Watson Ladd wrote: > On Sun, Jun 29, 2014 at 8:12 PM, Salz, Rich wrote: >> Ø Implication: The IETF will have to make some pronouncement or assurance >> as to the viability of Curve25519 to the wider world. The IETF will have to >> maintain the Curve25519 standard. >> >> Mike, I know you’ve been involved in this stuff since before this stuff >> existed J, but I don’t understand this. Why do we have to make any assurance >> about anything other than ‘here is how to interoperate using 25519 in TLS’? > No, we are defining a standard, and we are making assurances. Let's > not kid ourselves: SPF might say experimental, but if you try to send > mail without it, you'll find out just how much of a standard it is. As > for making assurances, if someday a massive break is discovered in TLS > 1.3 because we neglected cryptographic knowledge, we will rightfully > be blamed for it. > > If 25519 was ROT13, a proposal to include it would rightfully be > laughed out of this WG. We've established the principle, now we're > just haggling over its limits. > > Sincerely, > Watson Ladd > >> >> >> We’re not defining a standard, we’re not assuring the world about anything. >> We’ll have an RFC that says “here’s how to do the math for 25519 and other >> things needed to interoperate” and we’ll have other RFC’s that say “here’s >> how to use that curve in this protocol.” >> >> >> >> Why does it need to be more than that? I know that I am not alone in this >> confusion. >> >> >> >> /r$ >> >> >> >> -- >> >> Principal Security Engineer >> >> Akamai Technologies, Cambridge, MA >> >> IM: rsalz@jabber.me; Twitter: RichSalz >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > From nobody Mon Jun 30 09:45:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716D81A03B9 for ; Mon, 30 Jun 2014 09:45: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3WiKs_meIg1 for ; Mon, 30 Jun 2014 09:45:43 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A311A03B5 for ; Mon, 30 Jun 2014 09:45:32 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id a41so5069910yho.11 for ; Mon, 30 Jun 2014 09:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=1KUDv67UXo8x42TQSn3kd4DtCcWmgS5Tfw0p4kOU3kA=; b=py0GsLwj/m/7WNTbfbZBFUMYFKL8FHnPfmXY4Ht4bpoJzmP69XZnZZLmTQ3nxiW1jV W1Lar2M4X4jGXFItXe+DjH/12uvpaBF98l/rK/F0+CfHpkMriVCYyGCjujqJ3gnGWXIp nbhj84E+aXEjX40k+JKQ9FBUAWmx3VSeuC4tglP0VWiGHc8LGropGunZxk4kxtJlrEoI VaCHA8x+H7h7jIC3vafY5zr6GT5jk7HsM/667bXj8OLr5jTOHdZXSOLKbGSr83haFxDm 8co29Cb0/khbXFs+2NAcBzQp0vzqQx05gDJiJVoZFmtMnsoKsfsha0SM3S3cj2mKjJlu Ivqw== MIME-Version: 1.0 X-Received: by 10.236.152.169 with SMTP id d29mr14968803yhk.83.1404146731698; Mon, 30 Jun 2014 09:45:31 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Mon, 30 Jun 2014 09:45:31 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Mon, 30 Jun 2014 09:45:31 -0700 (PDT) In-Reply-To: <53B190E7.6050800@nthpermutation.com> References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> <53AF517F.7050504@nthpermutation.com> <53B07640.2050000@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95@USMBX1.msg.corp.akamai.com> <53B190E7.6050800@nthpermutation.com> Date: Mon, 30 Jun 2014 09:45:31 -0700 Message-ID: From: Watson Ladd To: tls@ietf.org Content-Type: multipart/alternative; boundary=20cf3040ede827d29004fd106377 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SM2yujXgMsY2cjkk80NpjbGSUeY Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 16:45:47 -0000 --20cf3040ede827d29004fd106377 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jun 30, 2014 9:31 AM, "Michael StJohns" wrote: > > Two opposing views on whether Curve25519 is destined for IETF standardization status.... and hence some of my confusion. > > Rich - "here=E2=80=99s how to do the math for 25519 and other things need= ed to interoperate" is sort of the definition of what a cryptographic standard is - only question is whether its an externally owned/maintained document offered as an Informational RFC or an IETF standards track document. If the latter, then the standard (and indirectly the math) gets an IETF imprimatur and we haven't offered those - yet - for cryptographic standards= . Okay, we publish it as informational. But wait, that's being done by the CFRG. So what is the problem here? We haven't done it before is not much of a problem. We do update informational RFCs: I think you are reading far more into the distinction vis a vis IETF inolvement then actually exists. > > Mike > > > > > On 6/30/2014 12:36 AM, Watson Ladd wrote: >> >> On Sun, Jun 29, 2014 at 8:12 PM, Salz, Rich wrote: >>> >>> =C3=98 Implication: The IETF will have to make some pronouncement or assurance >>> as to the viability of Curve25519 to the wider world. The IETF will have to >>> maintain the Curve25519 standard. >>> >>> Mike, I know you=E2=80=99ve been involved in this stuff since before th= is stuff >>> existed J, but I don=E2=80=99t understand this. Why do we have to make = any assurance >>> about anything other than =E2=80=98here is how to interoperate using 25= 519 in TLS=E2=80=99? >> >> No, we are defining a standard, and we are making assurances. Let's >> not kid ourselves: SPF might say experimental, but if you try to send >> mail without it, you'll find out just how much of a standard it is. As >> for making assurances, if someday a massive break is discovered in TLS >> 1.3 because we neglected cryptographic knowledge, we will rightfully >> be blamed for it. >> >> If 25519 was ROT13, a proposal to include it would rightfully be >> laughed out of this WG. We've established the principle, now we're >> just haggling over its limits. >> >> Sincerely, >> Watson Ladd >> >>> >>> >>> We=E2=80=99re not defining a standard, we=E2=80=99re not assuring the w= orld about anything. >>> We=E2=80=99ll have an RFC that says =E2=80=9Chere=E2=80=99s how to do = the math for 25519 and other >>> things needed to interoperate=E2=80=9D and we=E2=80=99ll have other RFC= =E2=80=99s that say =E2=80=9Chere=E2=80=99s >>> how to use that curve in this protocol.=E2=80=9D >>> >>> >>> >>> Why does it need to be more than that? I know that I am not alone in this >>> confusion. >>> >>> >>> >>> /r$ >>> >>> >>> >>> -- >>> >>> Principal Security Engineer >>> >>> Akamai Technologies, Cambridge, MA >>> >>> IM: rsalz@jabber.me; Twitter: RichSalz >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> > --20cf3040ede827d29004fd106377 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 30, 2014 9:31 AM, "Michael StJohns" <msj@nthpermutation.com> wrote:
>
> Two opposing views on whether Curve25519 is destined for IETF standard= ization status.... and hence some of my confusion.
>
> Rich - "here=E2=80=99s how to do the math for 25519 and other thi= ngs needed to interoperate" is sort of the definition of what a crypto= graphic standard is - only question is whether its an externally owned/main= tained document offered as an Informational RFC or an IETF standards track = document. =C2=A0If the latter, then the standard =C2=A0(and indirectly the = math) gets an IETF imprimatur and we haven't offered those - yet - for = cryptographic standards.

Okay, we publish it as informational. But wait, that's b= eing done by the CFRG. So what is the problem here? We haven't done it = before is not much of a problem.

We do update informational RFCs: I think you are reading far= more into the distinction vis a vis IETF inolvement then actually exists.<= br> >
> Mike
>
>
>
>
> On 6/30/2014 12:36 AM, Watson Ladd wrote:
>>
>> On Sun, Jun 29, 2014 at 8:12 PM, Salz, Rich <rsalz@akamai.com> wrote:
>>>
>>> =C3=98 =C2=A0Implication: The IETF will have to make some pron= ouncement or assurance
>>> as to the viability of Curve25519 to the wider world. =C2=A0Th= e IETF will have to
>>> maintain the Curve25519 standard.
>>>
>>> Mike, I know you=E2=80=99ve been involved in this stuff since = before this stuff
>>> existed J, but I don=E2=80=99t understand this. Why do we have= to make any assurance
>>> about anything other than =E2=80=98here is how to interoperate= using 25519 in TLS=E2=80=99?
>>
>> No, we are defining a standard, and we are making assurances. Let&= #39;s
>> not kid ourselves: SPF might say experimental, but if you try to s= end
>> mail without it, you'll find out just how much of a standard i= t is. As
>> for making assurances, if someday a massive break is discovered in= TLS
>> 1.3 because we neglected cryptographic knowledge, we will rightful= ly
>> be blamed for it.
>>
>> If 25519 was ROT13, a proposal to include it would rightfully be >> laughed out of this WG. We've established the principle, now w= e're
>> just haggling over its limits.
>>
>> Sincerely,
>> Watson Ladd
>>
>>>
>>>
>>> We=E2=80=99re not defining a standard, we=E2=80=99re not assur= ing the world about anything.
>>> We=E2=80=99ll have an RFC that says =E2=80=9Chere=E2=80=99s = =C2=A0how to do the math for 25519 and other
>>> things needed to interoperate=E2=80=9D and we=E2=80=99ll have = other RFC=E2=80=99s that say =E2=80=9Chere=E2=80=99s
>>> how to use that curve in this protocol.=E2=80=9D
>>>
>>>
>>>
>>> Why does it need to be more than that? =C2=A0I know that I am = not alone in this
>>> confusion.
>>>
>>>
>>>
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= /r$
>>>
>>>
>>>
>>> --
>>>
>>> Principal Security Engineer
>>>
>>> Akamai Technologies, Cambridge, MA
>>>
>>> IM: rsalz@jabber.me; Tw= itter: RichSalz
>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://= www.ietf.org/mailman/listinfo/tls
>>>
>>
>>
>

--20cf3040ede827d29004fd106377-- From nobody Mon Jun 30 11:13:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10091A03E5 for ; Mon, 30 Jun 2014 11:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9NPg-4O6MPK for ; Mon, 30 Jun 2014 11:13:17 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4201A042D for ; Mon, 30 Jun 2014 11:13:08 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A686B16560A; Mon, 30 Jun 2014 18:13:07 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 9BD071655D4; Mon, 30 Jun 2014 18:13:07 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 805E81E03D; Mon, 30 Jun 2014 18:13:07 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Mon, 30 Jun 2014 14:13:07 -0400 From: "Salz, Rich" To: Michael StJohns , Watson Ladd Date: Mon, 30 Jun 2014 14:13:06 -0400 Thread-Topic: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, Thread-Index: Ac+UgMX7vMFeUWjBQb+BAxYhdMDWbwADap3g Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFD52@USMBX1.msg.corp.akamai.com> References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> <53AF517F.7050504@nthpermutation.com> <53B07640.2050000@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95@USMBX1.msg.corp.akamai.com> <53B190E7.6050800@nthpermutation.com> In-Reply-To: <53B190E7.6050800@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wy-cVyYfsJeT3ash4DqlM8XHkLo Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 18:13:20 -0000 U28gb24gdGhlIG9uZSBzaWRlLCBmb2xrcyBhdCB0aGUgQ0ZSRyBtZWV0aW5nIGFuZCBzdWNoIHNh aWQgdGhleSB3YW50IGFuIElFVEYgUkZDIGRvY3VtZW50IG9uIGhvdyB0byB1c2UgYW5kIHJlcHJl c2VudCAyNTUxOS4gIFRoYXQgdGhlIGV4dGVybmFsIGRvY3VtZW50cyBhcmVuJ3QgZW5vdWdoLg0K DQpPbiB0aGUgb3RoZXIgc2lkZSwgeW91IGFyZSBzYXlpbmcgIm5vIGhhbGYgbWVhc3VyZSIgYW5k IHRoYXQgaWYgd2Ugc3BlY2lmeSBob3cgdG8gaW1wbGVtZW50IGFuZCB1c2UgMjU1MTksIHRoZW4g d2UgYXJlIHdyaXRpbmcgYSBjcnlwdG8gc3RhbmRhcmQgYW5kIHdlJ3ZlIG5ldmVyIGRvbmUgdGhh dCBiZWZvcmUuDQoNCkRvIEkgaGF2ZSB0aGF0IHJpZ2h0Pw0KDQpJZiB5ZXMsIHRoZW4gbXkgcmVw bHkgaXMgInNvIHdoYXQuIiAgTm9ib2R5J3MgYXNraW5nIHRoZSBJRVRGLCBsaXR0bGUgbW9yZSB0 aGFuIGEgY29sbGVjdGlvbiBvZiBtYWlsaW5nIGxpc3RzLCB0byB0YWtlIGxpYWJpbGl0eSBzaG91 bGQgMjU1MTkgYmUgY3JhY2tlZCBvciBoYXZlIGEgYmFjayBkb29yLg0KDQpXaGF0ZXZlci4gIEFu Z2VscyBvbiB0aGUgaGVhZCBvZiBhIHBpbi4NCgkvciQNCg0KLS0gIA0KUHJpbmNpcGFsIFNlY3Vy aXR5IEVuZ2luZWVyDQpBa2FtYWkgVGVjaG5vbG9naWVzLCBDYW1icmlkZ2UsIE1BDQpJTTogcnNh bHpAamFiYmVyLm1lOyBUd2l0dGVyOiBSaWNoU2Fseg0KDQo= From nobody Mon Jun 30 12:16:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03291A0416 for ; Mon, 30 Jun 2014 12:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV6PnKJsjKoH for ; Mon, 30 Jun 2014 12:16:18 -0700 (PDT) Received: from eu1sys200aog133.obsmtp.com (eu1sys200aog133.obsmtp.com [207.126.144.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E11341A03C6 for ; Mon, 30 Jun 2014 12:16:17 -0700 (PDT) Received: from mail-wg0-f51.google.com ([74.125.82.51]) (using TLSv1) by eu1sys200aob133.postini.com ([207.126.147.11]) with SMTP ID DSNKU7G3fWxboGEpuFJt1lzMkM8KcZU7kgwf@postini.com; Mon, 30 Jun 2014 19:16:18 UTC Received: by mail-wg0-f51.google.com with SMTP id x12so8413788wgg.34 for ; Mon, 30 Jun 2014 12:16:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=SjHB7p0aj2mgpRvsziDwDYVPfDG1PZKUts+w8S0wnNY=; b=C8xVl84kyqhhx7KkNwYLEykvDsORrZ0xHBK2BzgS6citTflHP+0sRmoztQgC/e/yYj J3TQYd7eM2pYuBteOMO13vwCgqdh4646SFrE9YwzcYbNo50MiIIAEk4ubU63kXM2OV0b xyERkZ/7VmYgZieCGG1qPs4xzh2xjWUcjVznQEMgP4slmNHtPL8kvXY1VXR+3ewzhKcw EVA1y8Fll4nrAcZIPWi3pee/DqjREJQsVziGkEN7Xc7c273YhJbc544+sxiBc1/Dm8UQ tj5aShM/gcn8SyxGsgdCP3PF6HSflv39VavAKQoBlGQ6KK49ktsdYxK4h/abSghNRHOh uDCg== X-Gm-Message-State: ALoCoQmK4VKRSVLfeq6KDWjYyv4oc1+fLaSz65GGy9DXChbsdMK89VMVdlF3VVyUUoIY2Vz8BDRzn7GWLBgtWmKnr1e1tYIVRw+uzkGp6PLQhM5XUJxELE7w6iZ1aPpr2okYwMcej28I X-Received: by 10.194.22.201 with SMTP id g9mr5654731wjf.98.1404155773615; Mon, 30 Jun 2014 12:16:13 -0700 (PDT) X-Received: by 10.194.22.201 with SMTP id g9mr5654722wjf.98.1404155773502; Mon, 30 Jun 2014 12:16:13 -0700 (PDT) Received: from [192.168.1.78] (host86-159-137-103.range86-159.btcentralplus.com. [86.159.137.103]) by mx.google.com with ESMTPSA id fw4sm34458524wib.19.2014.06.30.12.16.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 12:16:12 -0700 (PDT) Sender: Nigel Smart Message-ID: <53B1B77C.2060201@cs.bris.ac.uk> Date: Mon, 30 Jun 2014 20:16:12 +0100 From: Nigel Smart User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: TLS@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xlggnqsnXRDXTfxvrPSQoXiHlgo Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 19:16:20 -0000 > Nobody's asking the IETF, little more than a collection of mailing lists, to take liability should 25519 be cracked or have a back door. What's the difference between defining a cryptographic protocol (i.e. TLS 1.3) which could have lots of problems/be cracked/have a back door; and defining a cryptographic algorithm which could have lots of problems/be cracked/have a back door? Experience shows us that defining cryptographic protocols (key agreement/secure channels) is more prone to problems than defining cryptographic primtives (AES, ECC). If IETF is just a collection of mailing lists, and no one takes responsibility for the security implications of the security bits in it, then what is the point of TLS 1.3? - But then again the collection of mailing lists is what resulted in TLS 1.2 So in some sense TLS 1.3 is to correct the output of a collection of mailing lists which produced TLS 1.2 :-) My personal opinion is that the IETF should use i) Externally validated cryptographic primitives (i.e. AES, SHA-3, specific ECC choices etc). ii) Externally validated cryptographic protocols (i.e. throw out most of existing TLS methodology). Finding external validation of protocols is however currently a problem. Since TLS 1.3 is meant to offer a key agreement protocol and a secure channel protocol; and there are very few standards for such things. Now 25519 is both. It is a cryptographic primitives (a specific elliptic curve) AND an associated protocol (the specific form of key agreement protocol which uses the said curve). Given neither have any form of external validation I do not think IETF should use them. Nigel From nobody Mon Jun 30 13:59:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4089E1A0300 for ; Mon, 30 Jun 2014 13:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6me9z4Vto7y for ; Mon, 30 Jun 2014 13:59:07 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12C81A00DB for ; Mon, 30 Jun 2014 13:59:05 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id m5so6816112qaj.37 for ; Mon, 30 Jun 2014 13:59:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=S79On4TsMNvoxHHfyvddQskCVEfOL0v8sDBo7ws9xeY=; b=Tfkm/3QIBXgLGxKAHrFftqjZ+bKKpon2i+n+Qn7I04W3KpmVBJVTv5HFecMZvKSyb0 PuGc29A1zSfafNOEwWR75BTeHAq6SkvVqcDySBgL81tPbclWgRS7rb6p4BxvUKTZA9GB SNI3b3+3/ASYl+s878ByEYUoinu9OCMOReYY4gAcNDzQXHxvR1ymfzbBcpn2RmP8c/yt bFg4sSLoDjQpCX07LX2HHWVYIYnZTOjS7mg7xC71SHenH9YGMxDWlKDOIskRnIVhd2Y+ 2BMhzh2rEMmxsUTyehlXt/je4z/m8ZdfAafT+d+Cpl8/kmw4m79UrwuUgK8nliRO/hG5 zauA== X-Gm-Message-State: ALoCoQmtAmnhRYcgI9M5kzoGfQRazt70l3h8JRm0vM+ybOz2bSN0lCaWlY8IZW2mZFERAl3Ai3Lx X-Received: by 10.224.72.13 with SMTP id k13mr65720759qaj.54.1404161945174; Mon, 30 Jun 2014 13:59:05 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:390:b4d7:6f3f:f3ac:4c6? ([2601:a:2a00:390:b4d7:6f3f:f3ac:4c6]) by mx.google.com with ESMTPSA id a3sm9235358qaa.37.2014.06.30.13.59.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 13:59:04 -0700 (PDT) Message-ID: <53B1CF98.6010304@nthpermutation.com> Date: Mon, 30 Jun 2014 16:59:04 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Salz, Rich" , Watson Ladd References: <53AC97B8.2080909@nthpermutation.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> <53AF517F.7050504@nthpermutation.com> <53B07640.2050000@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95@USMBX1.msg.corp.akamai.com> <53B190E7.6050800@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFD52@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFD52@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wx9jku43rAeKhAqG7wUmCPEKl6k Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 standardization X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 20:59:08 -0000 Someplace in the middle of all this the question I asked seems to have gotten lost. Basically, "would generating IETF curves obviate the need for Curve25519 or others?" which I would say got answered "no". The rest of all this is a side show with how Curve25519 gets into the IETF toolkit. 'nuff said. On 6/30/2014 2:13 PM, Salz, Rich wrote: > So on the one side, folks at the CFRG meeting and such said they want an IETF RFC document on how to use and represent 25519. That the external documents aren't enough. > > On the other side, you are saying "no half measure" and that if we specify how to implement and use 25519, then we are writing a crypto standard and we've never done that before. > > Do I have that right? I would agree with "need a document to represent and use 25519", its who said that and how it was said that I'm unclear on. That document will have the form of a crypto standard irrespective of who writes it. If it gets published like each and every other RFC we've done on crypto - as Informational and externally originated, then it isn't anything new. If we run it through our standards process, then it is. > > If yes, then my reply is "so what." Nobody's asking the IETF, little more than a collection of mailing lists, to take liability should 25519 be cracked or have a back door. I actually used the word "assurance". Standards bodies don't get stuck with liability per se. The IETF has an open process, scope of expertise and a reasonable commercial and international reputation. Putting the IETF stamp of approval (in the form of placing it on the standards track) on a specific cryptographic algorithm and its associated standards lends that reputation to the standard more or less with a hit to the reputation if there's a failure. If we want to begin doing this for cryptography in general, then we need to understand the real-world implications, both of the endorsement and possible failures. Mike From nobody Mon Jun 30 14:20:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0BE1A0ACF for ; Mon, 30 Jun 2014 14:20:30 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOOlLs1HwH1a for ; Mon, 30 Jun 2014 14:20:30 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBAC31A0AA2 for ; Mon, 30 Jun 2014 14:20:29 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id f51so2514307qge.36 for ; Mon, 30 Jun 2014 14:20:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RXg7Pl8uPpfKhj0h4Aqs2tLhEjsD1O4N+fFvC8zC/1U=; b=K4cSKDJtthQV24Ldnp/ath+hWerSlRShoIyOGJdFKWLp1CJ5lUkIj+l0Rzu3Gr2jyU cTklHf6ZNqjWDXGVPxaHYN3db3ObuQLlKnSdJZTcEOhtLRddJa3h/driUHkOuCD+Ottv 3D1oOenFvrG9IMDWNnV+tQ50wixkkgLCH4H+kVP75X1UO/To1fOck4t9RABrfvn03ZDP OR0H044p16q8Wb2l6w3e20FepzcI83gQ0ZAaX/CFhMUeRPN9NuKndPxA8PiQRayDnKbg rbfUF/qD9Zcgy9YX9+IoAaEmnZ8eIRwJbqGor9fryieSuJdVLJhedEXCJr3JUg3/0oZ0 otZA== X-Gm-Message-State: ALoCoQmf4pU+gRNVobXhFnXtWbsfUV/W80d512eB2dyqVykduREh4MemG/lFAMyL8MB1s5E9EVxu X-Received: by 10.140.31.119 with SMTP id e110mr61004898qge.74.1404163228917; Mon, 30 Jun 2014 14:20:28 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:390:b4d7:6f3f:f3ac:4c6? ([2601:a:2a00:390:b4d7:6f3f:f3ac:4c6]) by mx.google.com with ESMTPSA id b49sm2795935qgb.27.2014.06.30.14.20.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 14:20:28 -0700 (PDT) Message-ID: <53B1D49D.10404@nthpermutation.com> Date: Mon, 30 Jun 2014 17:20:29 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <53B1B77C.2060201@cs.bris.ac.uk> In-Reply-To: <53B1B77C.2060201@cs.bris.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DY6BS1WvPevgtMDFmNApz2zJP50 Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 21:20:31 -0000 On 6/30/2014 3:16 PM, Nigel Smart wrote: > What's the difference between defining a cryptographic protocol (i.e. > TLS 1.3) > which could have lots of problems/be cracked/have a back door; and > defining > a cryptographic algorithm which could have lots of problems/be > cracked/have > a back door? Experience shows us that defining cryptographic protocols > (key agreement/secure channels) is more prone to problems than defining > cryptographic primtives (AES, ECC). If the math is insecure then the cryptographic standard is insecure as is everything that depends on it. If the cryptographic standard is insecure then the cryptographic protocols are insecure (but hopefully you can plug in something else - e.g. DES vs AES). If the cryptographic protocol is insecure then the applications are insecure (but hopefully you can plug in something else e.g. TLS1.0 vs TLS1.1 vs TLS1.2 vs ??). Oh yeah - if the implementation is insecure, it doesn't really matter whether or not you got everything else right. So the difference is really about what depends on the protocol vs the standard vs the math, and you get more dependencies the closer you are to the math. I tend to agree with you about the problems with defining crypto protocols, but at least they are*protocols* which is somewhat within the IETF's scope of expertise. They're also a lot easier for the non-crypto-math people to get their heads around. Crafting a cryptographic protocol is still a specialty expertise though. At least TLS13 will have *lots* of eyes on it. Given the huge set of plugin cryptography in TLS, hopefully at least some of it will be secure enough. Mike From nobody Mon Jun 30 15:21:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70611A0AF4 for ; Mon, 30 Jun 2014 15:21:35 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGAWgvOlVjL4 for ; Mon, 30 Jun 2014 15:21:34 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD961A0ADE for ; Mon, 30 Jun 2014 15:21:33 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c9so7833837qcz.0 for ; Mon, 30 Jun 2014 15:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jmgj9EQW+px68b0LLUpS6RokNuHotcBWp9p7Mie5Ygo=; b=vNZhzYiXfrG6sGcMaoauU5NANGp1VGRTzFZJkVLIBVFeTdj2bqPj1ZSCL0A8FBWdGs temrz80LocSnsE7EWd8sM+iqwxVuepiqfyOKYvUZVAd2IlmQVvl3sJp2wwwWvQMn/NTr 8ocIqCs+JAqRHvlhEWLEqk+YGY+aD9mjHfACJvKiu0YSXra/TEnwvZTWj7TE2eEgaPo8 9pDCZ1k0gKchxp2CvZlL3JZSzgoTJODjdfA022nb/oTFQINHHsFiY4Ed0o29fRMvwxjI gDQvYd/O5IrTV+rRxyxTfVFBZApcv/4+Bb1ZkC2bBW+Vn/zG97MGFmhj51TUH4OvHm7y /SRQ== MIME-Version: 1.0 X-Received: by 10.140.47.48 with SMTP id l45mr24121308qga.24.1404166892952; Mon, 30 Jun 2014 15:21:32 -0700 (PDT) Received: by 10.140.27.173 with HTTP; Mon, 30 Jun 2014 15:21:32 -0700 (PDT) Received: by 10.140.27.173 with HTTP; Mon, 30 Jun 2014 15:21:32 -0700 (PDT) In-Reply-To: <53B1D49D.10404@nthpermutation.com> References: <53B1B77C.2060201@cs.bris.ac.uk> <53B1D49D.10404@nthpermutation.com> Date: Mon, 30 Jun 2014 15:21:32 -0700 Message-ID: From: Watson Ladd To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a11c16606dc235704fd1514ed Archived-At: http://mailarchive.ietf.org/arch/msg/tls/E60m5L30j_Ilyhi1IFqmlI7915Q Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 22:21:35 -0000 --001a11c16606dc235704fd1514ed Content-Type: text/plain; charset=UTF-8 On Jun 30, 2014 2:20 PM, "Michael StJohns" wrote: > > On 6/30/2014 3:16 PM, Nigel Smart wrote: >> >> What's the difference between defining a cryptographic protocol (i.e. TLS 1.3) >> which could have lots of problems/be cracked/have a back door; and defining >> a cryptographic algorithm which could have lots of problems/be cracked/have >> a back door? Experience shows us that defining cryptographic protocols >> (key agreement/secure channels) is more prone to problems than defining >> cryptographic primtives (AES, ECC). > > > If the math is insecure then the cryptographic standard is insecure as is everything that depends on it. > > If the cryptographic standard is insecure then the cryptographic protocols are insecure (but hopefully you can plug in something else - e.g. DES vs AES). > > If the cryptographic protocol is insecure then the applications are insecure (but hopefully you can plug in something else e.g. TLS1.0 vs TLS1.1 vs TLS1.2 vs ??). > > Oh yeah - if the implementation is insecure, it doesn't really matter whether or not you got everything else right. > > So the difference is really about what depends on the protocol vs the standard vs the math, and you get more dependencies the closer you are to the math. > > I tend to agree with you about the problems with defining crypto protocols, but at least they are*protocols* which is somewhat within the IETF's scope of expertise. They're also a lot easier for the non-crypto-math people to get their heads around. Not really: TLS 1.0 had an obvious flaw, BEAST. Kerberos went through 5 versions, each one broken before the next. However easily it looks to understand, you didn't find Triple Handshake. Did you really understand TLS, or just think you did? Crafting a cryptographic protocol is still a specialty expertise though. At least TLS13 will have *lots* of eyes on it. Given the huge set of plugin cryptography in TLS, hopefully at least some of it will be secure enough. Any improvement won't come from lots of eyes. It will come from a few cryptographers sitting down and ripping stuff to shreds. Plugin cryptography hasn't made it easy to kill RC4. Sincerely, Watson Ladd > > Mike > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a11c16606dc235704fd1514ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 30, 2014 2:20 PM, "Michael StJohns" <msj@nthpermutation.com> wrote:
>
> On 6/30/2014 3:16 PM, Nigel Smart wrote:
>>
>> What's the difference between defining a cryptographic protoco= l (i.e. TLS 1.3)
>> which could have lots of problems/be cracked/have a back door; and= defining
>> a cryptographic algorithm which could have lots of problems/be cra= cked/have
>> a back door? Experience shows us that defining cryptographic proto= cols
>> (key agreement/secure channels) is more prone to problems than def= ining
>> cryptographic primtives (AES, ECC).
>
>
> If the math is insecure then the cryptographic standard is insecure as= is everything that depends on it.
>
> If the cryptographic standard is insecure then the cryptographic proto= cols are insecure (but hopefully you can plug in something else - e.g. DES = vs AES).
>
> If the cryptographic protocol is insecure then the applications are in= secure (but hopefully you can plug in something else e.g. =C2=A0TLS1.0 vs T= LS1.1 vs TLS1.2 vs ??).
>
> Oh yeah - if the implementation is insecure, it doesn't really mat= ter whether or not you got everything else right.
>
> So the difference is really about what depends on the protocol vs the = standard vs the math, and you get more dependencies the closer you are to t= he math.
>
> I tend to agree with you about the problems with defining crypto proto= cols, but at least they are*protocols* which is somewhat within the IETF= 9;s scope of expertise. =C2=A0They're also a lot easier for the non-cry= pto-math people to get their heads around. =C2=A0

Not really: TLS 1.0 had an obvious flaw, BEAST. Kerberos wen= t through 5 versions, each one broken before the next. However easily it lo= oks to understand,=C2=A0 you didn't find Triple Handshake. Did you real= ly understand TLS, or just think you did?

Crafting a cryptographic protocol is still a specialty exper= tise though. =C2=A0At least TLS13 will have *lots* of eyes on it. =C2=A0Giv= en the huge set of plugin cryptography in TLS, hopefully at least some of i= t will be secure enough.

Any improvement won't come from lots of eyes. It will co= me from a few cryptographers sitting down and ripping stuff to shreds.

Plugin cryptography hasn't made it easy to kill RC4.
Sincerely,
Watson Ladd
>
> Mike
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--001a11c16606dc235704fd1514ed--