From simon@josefsson.org Fri Apr 1 01:40:04 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8980D3A65A5 for ; Fri, 1 Apr 2011 01:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.435 X-Spam-Level: X-Spam-Status: No, score=-103.435 tagged_above=-999 required=5 tests=[AWL=-0.836, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vdc0LSU6WOFZ for ; Fri, 1 Apr 2011 01:40:03 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id C8E723A63CB for ; Fri, 1 Apr 2011 01:40:02 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p318fYit026433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 1 Apr 2011 10:41:35 +0200 X-Hashcash: 1:22:110401:tls@ietf.org::lnCPbrb7HzkIKy2S:Duny From: Simon Josefsson To: tls@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Fri, 01 Apr 2011 10:41:34 +0200 Message-ID: <87ipuycqip.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Subject: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:40:04 -0000 Hi, I want to explain again what I (unsuccessfully) tried to raise during the presentation. First it helps to recall the protocol flow with TLS-in-EAP, from the document: Client Server ------ ------ ClientHello(*) --------> ServerHello(*) (Certificate) ServerKeyExchange EapMsg(Identity-Request) <-------- ServerHelloDone ClientKeyExchange (CertificateVerify) ChangeCipherSpec InterimAuth EapMsg(Identity-Reply) --------> ChangeCipherSpec InterimAuth EapMsg(GPSK-Request) <-------- EapMsg(GPSK-Reply) --------> EapMsg(GPSK-Request) <-------- EapMsg(GPSK-Reply) --------> EapMsg(Success) <-------- Finished Finished --------> Note that the "Finished" messages are not sent until AFTER the EAP exchange. This means that the "tls-unique" channel binding (which refers to the Finished messages) is not available to the EAP mechanism. That means that the EAP mechanism is not able to channel bind to TLS using "tls-unique", which results in weaker than necessary authentication as far as I can see. Do you see the problem now? I see a few solutions: 1) Specify that when EAP-in-TLS is used, the "tls-unique" channel binding should use the "InterimAuth" message instead of the "Finished" message. 2) Specify a channel binding for TLS that doesn't use the "Finished" message. 3) Specify that you always need to complete a full TLS handshake first, and then re-handshake and do the EAP handshake during that phase. There may be other solutions. At this point I don't have an opinion on what is a good way to resolve this. /Simon From ynir@checkpoint.com Fri Apr 1 03:50:38 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D6C3A67D3 for ; Fri, 1 Apr 2011 03:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9ktAqs-uiJF for ; Fri, 1 Apr 2011 03:50:37 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id A00E13A67E1 for ; Fri, 1 Apr 2011 03:50:36 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p31AqE58015534; Fri, 1 Apr 2011 13:52:14 +0300 X-CheckPoint: {4D95BC4F-2-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 1 Apr 2011 13:52:15 +0300 From: Yoav Nir To: Simon Josefsson Date: Fri, 1 Apr 2011 13:52:13 +0300 Thread-Topic: [TLS] EAP-in-TLS and channel bindings Thread-Index: AcvwWtwjk1iqfN3vSlefg7fOSUy53Q== Message-ID: References: <87ipuycqip.fsf@latte.josefsson.org> In-Reply-To: <87ipuycqip.fsf@latte.josefsson.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 Cc: "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 10:50:38 -0000 Hi Simon See below. On Apr 1, 2011, at 11:41 AM, Simon Josefsson wrote: > Hi, >=20 > I want to explain again what I (unsuccessfully) tried to raise during > the presentation. First it helps to recall the protocol flow with > TLS-in-EAP, from the document: >=20 > Client Server > ------ ------ >=20 > ClientHello(*) --------> > ServerHello(*) > (Certificate) > ServerKeyExchange > EapMsg(Identity-Request) > <-------- ServerHelloDone > ClientKeyExchange > (CertificateVerify) > ChangeCipherSpec > InterimAuth > EapMsg(Identity-Reply) --------> > ChangeCipherSpec > InterimAuth > EapMsg(GPSK-Request) > <-------- > EapMsg(GPSK-Reply) --------> > EapMsg(GPSK-Request) > <-------- > EapMsg(GPSK-Reply) --------> > EapMsg(Success) > <-------- Finished > Finished --------> >=20 > Note that the "Finished" messages are not sent until AFTER the EAP > exchange. This means that the "tls-unique" channel binding (which > refers to the Finished messages) is not available to the EAP mechanism. > That means that the EAP mechanism is not able to channel bind to TLS > using "tls-unique", which results in weaker than necessary > authentication as far as I can see. >=20 > Do you see the problem now? I'm not sure that I do. While I understand an application using the tls-uni= que channel binding, I don't understand what an EAP method would do with th= e channel binding.=20 The Finished message calculation incorporates the MSK from the EAP method, = and that binds the tls-unique that is available to applications to the auth= entication. >=20 > I see a few solutions: >=20 > 1) Specify that when EAP-in-TLS is used, the "tls-unique" channel > binding should use the "InterimAuth" message instead of the "Finished" > message. But the actual authentication happens after the InterimAuth, so that struct= is not bound to the authentication. >=20 > 2) Specify a channel binding for TLS that doesn't use the "Finished" > message. >=20 > 3) Specify that you always need to complete a full TLS handshake first, > and then re-handshake and do the EAP handshake during that phase. Interestingly, this is the way it's usually done with certificates in the w= eb browser case, so I would expect that this would be the way to use TLS-EA= P as well. Authentication happens only in the https://www.example.com/login= .html and after that we use anonymous TLS and session cookies. Since the ge= t happens after the first handshake, the server sends a HelloRequest after = it gets the "GET login.html" message. But I don't understand why it's nece= ssary for security. >=20 > There may be other solutions. At this point I don't have an opinion on > what is a good way to resolve this. >=20 > /Simon > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > Scanned by Check Point Total Security Gateway. From nico@cryptonector.com Fri Apr 1 16:54:46 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379173A69B4 for ; Fri, 1 Apr 2011 16:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRFs3ET5TAGh for ; Fri, 1 Apr 2011 16:54:44 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by core3.amsl.com (Postfix) with ESMTP id 7280428C114 for ; Fri, 1 Apr 2011 16:54:44 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 1C6E32C806B for ; Fri, 1 Apr 2011 16:56:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=XLUwN4R2tQv0dSaSXpO2KRMcqO0a/6Wq5QGx0bhFU8fe uy022OQ6BiRJjAf3RaVHOCvL0P9hRO30zPJVI4AJmgPasCLw2B8oQU+20kjxm0/B PNwN0Ltv5fpzQqCIM5Xn0WPiRiC3+TitoDhT0DWX/Ecw22H/TJaOuS4txixo1SM= 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=A6suox7IRS1cKkA/nTQJR8dO4G0=; b=sjicbw89hV3 zTO2/lpXKE6Ogw9JoSVwk9RScKNk6D5tRNj+UeVv8yMswj/K/gxdoxcZ+Lc6nOx3 9222yO25OYFzPJzaPZLyc/a44BZaVgM5DePJnS1c56p9Se4/ycF8wWBtgyR2Q16S Pq1vgvbLi2Xg15SxdY2UAO4yHMVq9TwI= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id D86A42C8058 for ; Fri, 1 Apr 2011 16:56:24 -0700 (PDT) Received: by vws12 with SMTP id 12so3643744vws.31 for ; Fri, 01 Apr 2011 16:56:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.200 with SMTP id 8mr671291vdg.70.1301701880152; Fri, 01 Apr 2011 16:51:20 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Fri, 1 Apr 2011 16:51:20 -0700 (PDT) In-Reply-To: <87ipuycqip.fsf@latte.josefsson.org> References: <87ipuycqip.fsf@latte.josefsson.org> Date: Fri, 1 Apr 2011 18:51:20 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 23:54:46 -0000 On Fri, Apr 1, 2011 at 3:41 AM, Simon Josefsson wrote= : > I want to explain again what I (unsuccessfully) tried to raise during > the presentation. =C2=A0First it helps to recall the protocol flow with > TLS-in-EAP, from the document: > > [...] > > Note that the "Finished" messages are not sent until AFTER the EAP > exchange. =C2=A0This means that the "tls-unique" channel binding (which > refers to the Finished messages) is not available to the EAP mechanism. > That means that the EAP mechanism is not able to channel bind to TLS > using "tls-unique", which results in weaker than necessary > authentication as far as I can see. > [...] > I see a few solutions: > > 1) Specify that when EAP-in-TLS is used, the "tls-unique" channel > binding should use the "InterimAuth" message instead of the "Finished" > message. > > 2) Specify a channel binding for TLS that doesn't use the "Finished" > message. > > 3) Specify that you always need to complete a full TLS handshake first, > and then re-handshake and do the EAP handshake during that phase. > > There may be other solutions. =C2=A0At this point I don't have an opinion= on > what is a good way to resolve this. The situation here is not that different to past proposals to do GSS-API authentication in TLS. And the objections to using EAP in TLS must be similar to the objections to using GSS in TLS -- objections I myself have. I strongly encourage the proponents to look at draft-williams-tls-sasl-opt-04, which is my proposed solution for mixing SASL/GSS-API and TLS in a round-trip optimal way (though it could be further optimized by adding an optimistic GSS mechanism selection and using MIC tokens to do the channel binding). I believe the same approach ought to work equally well for EAP. The nice thing about my proposal is that it makes no changes to TLS -- it uses TLS extensions, but it does not change the TLS state machine. Nico -- From simon@josefsson.org Sat Apr 2 00:15:26 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 016B93A6A49 for ; Sat, 2 Apr 2011 00:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JI8iKQb1J0F for ; Sat, 2 Apr 2011 00:15:25 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id C84403A69EC for ; Sat, 2 Apr 2011 00:15:24 -0700 (PDT) Received: from latte.josefsson.org (m90-133-243-209.cust.tele2.se [90.133.243.209]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p327GTbM024304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 2 Apr 2011 09:16:44 +0200 From: Simon Josefsson To: Nico Williams References: <87ipuycqip.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110402:nico@cryptonector.com::r/mmx8pjwZZryYAF:AGZ+ X-Hashcash: 1:22:110402:tls@ietf.org::I74L1An001hTDgRz:POr5 Date: Sat, 02 Apr 2011 09:16:26 +0200 In-Reply-To: (Nico Williams's message of "Fri, 1 Apr 2011 18:51:20 -0500") Message-ID: <8739m1qg1h.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 07:15:26 -0000 Nico Williams writes: > I strongly encourage the proponents to look at > draft-williams-tls-sasl-opt-04 +1. Your document has the channel binding discussion I was looking for in EAP-in-TLS. /Simon From ynir@checkpoint.com Sat Apr 2 10:58:37 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B65E328C136 for ; Sat, 2 Apr 2011 10:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGS9hIR6uVd8 for ; Sat, 2 Apr 2011 10:58:36 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 2A1EB3A6874 for ; Sat, 2 Apr 2011 10:58:35 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p32I084p010513; Sat, 2 Apr 2011 21:00:08 +0300 X-CheckPoint: {4D977211-0-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 2 Apr 2011 21:00:08 +0300 From: Yoav Nir To: Nico Williams Date: Sat, 2 Apr 2011 21:00:07 +0300 Thread-Topic: [TLS] EAP-in-TLS and channel bindings Thread-Index: AcvxX81eHoHNeJLQQCORS8DgYQft/Q== Message-ID: References: <87ipuycqip.fsf@latte.josefsson.org> 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 Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 17:58:37 -0000 On Apr 2, 2011, at 2:51 AM, Nico Williams wrote: >=20 > The situation here is not that different to past proposals to do > GSS-API authentication in TLS. And the objections to using EAP in TLS > must be similar to the objections to using GSS in TLS -- objections I > myself have. >=20 > I strongly encourage the proponents to look at > draft-williams-tls-sasl-opt-04, which is my proposed solution for > mixing SASL/GSS-API and TLS in a round-trip optimal way (though it > could be further optimized by adding an optimistic GSS mechanism > selection and using MIC tokens to do the channel binding). I believe > the same approach ought to work equally well for EAP. The nice thing > about my proposal is that it makes no changes to TLS -- it uses TLS > extensions, but it does not change the TLS state machine. Hi Nico, Thanks for this. One of our earlier versions of our proposal looked like th= is: Client Server ------ ------ ClientHello(*) --------> ServerHello(*) (Certificate) ServerKeyExchange EapMsg(Identity-Request) <-------- ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished EapMsg(Identity-Reply) --------> ChangeCipherSpec Finished EapMsg(GPSK-Request) <-------- EapMsg(GPSK-Reply) --------> EapMsg(GPSK-Request) <-------- EapMsg(GPSK-Reply) --------> EapMsg(Success) <-------- EAP-Finished EAP-Finished --------> The only difference is that InterimAuth is renamed to "Finished", and the l= ast handshake message is renamed to "EAP-Finished". Putting it like this, i= t looks very much like figure 2 in your draft. The reason we chose to go wi= th InterimAuth in the middle rather EAP-Finished in the end was because the= usual semantic for "Finished" is that the application data follows, while = we consider the EAP part to be an extension of the handshake that precedes = application data. In your draft, the SASL authentication is sent as data. EAP methods have no use for the tls-unique channel binding. However, I thin= k that whether the EAP message is sent as a handshake message or as applica= tion data, the calculation of tls-unique needs to change in case of EAP aut= hentication. Do you think a good value for it would be to take the tls-uniq= ue used for the Finished (or "interimAuth") record, concatenate the MSK fro= m EAP, and hash them together? If a proposal like this is more palatable to the group (and doesn't change = the state machine as much), I think this can be worked out. Yoav From nico@cryptonector.com Sun Apr 3 21:34:28 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A9628C0F3 for ; Sun, 3 Apr 2011 21:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZCHkDalwQAp for ; Sun, 3 Apr 2011 21:34:27 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id 5D8CA28C0E6 for ; Sun, 3 Apr 2011 21:34:27 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 314AA1005D for ; Sun, 3 Apr 2011 21:36:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=dxrkDkLjMSEmZLoBtXvqmUNs2TJLAshIOie/XKmDpOoQ tkdBVx9M/WUvgH/prpE35U8ko7tlNcwUietKA6Btv/xo8ZATtYFNQIJyBiaroBrk Ps7sziCT5uhWBQ0LWw+R/ge7sHYLgVaozeIDRXpSNNSTNbWGJy7gc3FUjP504ro= 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=D/bBdpHEnkhVnxDkdR10D6Sx048=; b=MY3OqLK5uCE bXGCmH2v2en1L+GBqutc3RM2UxdRy7LqEj7s36UsXNoPasnWiNosXQv62XaJCVe2 GZ4Ej7078j7Udzu1aSonmEpPDjIhFmnywjfrOt24PQDyf55ApoEOa+UszojdDhBu gol5tEuPKRgCO1WOTAOLPhvaeosdtocU= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id F35BC10059 for ; Sun, 3 Apr 2011 21:36:08 -0700 (PDT) Received: by vxg33 with SMTP id 33so4637345vxg.31 for ; Sun, 03 Apr 2011 21:36:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.68.65 with SMTP id u1mr3518596vdt.310.1301891768433; Sun, 03 Apr 2011 21:36:08 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Sun, 3 Apr 2011 21:36:08 -0700 (PDT) In-Reply-To: References: <87ipuycqip.fsf@latte.josefsson.org> Date: Sun, 3 Apr 2011 23:36:08 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 04:34:28 -0000 On Sat, Apr 2, 2011 at 1:00 PM, Yoav Nir wrote: > Thanks for this. One of our earlier versions of our proposal looked like = this: > > [...] > > The only difference is that InterimAuth is renamed to "Finished", and the= last handshake message is renamed to "EAP-Finished". Putting it like this,= it looks very much like figure 2 in your draft. The reason we chose to go = with InterimAuth in the middle rather EAP-Finished in the end was because t= he usual semantic for "Finished" is that the application data follows, whil= e we consider the EAP part to be an extension of the handshake that precede= s application data. In your draft, the SASL authentication is sent as data. Indeed! This is very much like my proposal. The key is that the round-trips required by EAP beyond those required by TLS do not hold up the end of the TLS handshake. The application can negotiate the use of EAP in this way via a Hello extensions and then the application can hold off the start of the normal application data protocol until after the EAP (or GSS, or SASL, or whatever) exchange completes. I believe none of the normal objections to earlier proposals apply to such a design because a) only normal TLS extension slots are used, b) the TLS state machine is not changed, only the application protocol is changed. In fact, no changes should be needed to any TLS implementation that provides the necessary extensions hooks, and this is a critical feature. > EAP methods have no use for the tls-unique channel binding. However, I th= ink that whether the EAP message is sent as a handshake message or as appli= cation data, the calculation of tls-unique needs to change in case of EAP a= uthentication. Do you think a good value for it would be to take the tls-un= ique used for the Finished (or "interimAuth") record, concatenate the MSK f= rom EAP, and hash them together? I'm not sure that EAP has no use for tls-unique here... Suppose you're talking to an MITM (see the Comodo CA compromise...). Don't you want to make sure that they are not able to cut-n-paste the EAP exchange to the real service?? I would think that you do! In EAP this would be called "cryptographic binding", not "channel binding" -- we have a sad terminology issue :( > If a proposal like this is more palatable to the group (and doesn't chang= e the state machine as much), I think this can be worked out. I have found it very difficult to elicit approving noises from the TLS WG, but as you know it's quite simple to get the WG to make negative noises. I'm not sure how you'd go about getting approving noises other than to push through and see what happens as your I-D progresses. However, as I said, the key test of whether your proposal plays well with TLS will be whether you need to make any changes to TLS itself. If you can avoid TLS changes (to the spec, to implementations [except for the purpose of adding TLS functionality already specified]) then you're golden. I'd go further: your work wouldn't even fall under the TLS WG charter (though you'd still want to give the WG's participants an opportunity to review your I-D). In other words: just adjust back to the protocol design described above and in my I-D and move forward towards publication. Nico -- From mike-list@pobox.com Sun Apr 3 21:53:55 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1E303A6912 for ; Sun, 3 Apr 2011 21:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAMwmiwvM1Mn for ; Sun, 3 Apr 2011 21:53:54 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 566CA3A68BC for ; Sun, 3 Apr 2011 21:53:54 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id B0D2C5547; Mon, 4 Apr 2011 00:57:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=F16d/Q6fLfkD 7K+7FDY8X5xgFiA=; b=rYroBxIZ5FeCwc148GKYcAHOiZi0GkqrR3w/D2nArHuQ jwwW6lUMv/Vr8guvkTZUZyH7466N1qW3ca+aJqSmtmjAD3PsVwqE7xLAXgDWfSQk qkrxNhT0Icnd4oApKbcp3sJlfmwhrllCjUXyoqK7DNeEQLfKBfNQ42bFtIZtFbc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=vpH3HN PXT+ZEfeC664MINJUxSBL28YB5ySLfL2eHaz0iS81q/BfBytfyozSNqy/0MxHU79 NvGzbHJXz70ndBfLPUciaA7lMoAffDnezRh2ug0KjPO2f9UAMuNWdd0GANjLRrML qqLYPNXvf1mw3EaY5M17XDDQFLXq5qIXvGcKw= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 7E90B5544; Mon, 4 Apr 2011 00:57:24 -0400 (EDT) Received: from iMac.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 3C7EF5542; Mon, 4 Apr 2011 00:57:19 -0400 (EDT) Message-ID: <4D994F3E.3070202@pobox.com> Date: Sun, 03 Apr 2011 21:55:26 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nico Williams References: <87ipuycqip.fsf@latte.josefsson.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 07FF14CC-5E78-11E0-91B1-E8AB60295C12-38729857!a-pb-sasl-sd.pobox.com Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 04:53:56 -0000 I admit to not knowing what EAP-TLS is, but from reading this message it seems like the EAP exchange could maybe benefit from defining a new record type. Perhaps that's already what's done? Or is there a reason to not do that? Mike Nico Williams wrote: > On Sat, Apr 2, 2011 at 1:00 PM, Yoav Nir wrote: >> Thanks for this. One of our earlier versions of our proposal looked like this: >> >> [...] >> >> The only difference is that InterimAuth is renamed to "Finished", and the last handshake message is renamed to "EAP-Finished". Putting it like this, it looks very much like figure 2 in your draft. The reason we chose to go with InterimAuth in the middle rather EAP-Finished in the end was because the usual semantic for "Finished" is that the application data follows, while we consider the EAP part to be an extension of the handshake that precedes application data. In your draft, the SASL authentication is sent as data. > > Indeed! This is very much like my proposal. The key is that the > round-trips required by EAP beyond those required by TLS do not hold > up the end of the TLS handshake. The application can negotiate the > use of EAP in this way via a Hello extensions and then the application > can hold off the start of the normal application data protocol until > after the EAP (or GSS, or SASL, or whatever) exchange completes. > > I believe none of the normal objections to earlier proposals apply to > such a design because a) only normal TLS extension slots are used, b) > the TLS state machine is not changed, only the application protocol is > changed. In fact, no changes should be needed to any TLS > implementation that provides the necessary extensions hooks, and this > is a critical feature. > >> EAP methods have no use for the tls-unique channel binding. However, I think that whether the EAP message is sent as a handshake message or as application data, the calculation of tls-unique needs to change in case of EAP authentication. Do you think a good value for it would be to take the tls-unique used for the Finished (or "interimAuth") record, concatenate the MSK from EAP, and hash them together? > > I'm not sure that EAP has no use for tls-unique here... Suppose > you're talking to an MITM (see the Comodo CA compromise...). Don't > you want to make sure that they are not able to cut-n-paste the EAP > exchange to the real service?? I would think that you do! In EAP > this would be called "cryptographic binding", not "channel binding" -- > we have a sad terminology issue :( > >> If a proposal like this is more palatable to the group (and doesn't change the state machine as much), I think this can be worked out. > > I have found it very difficult to elicit approving noises from the TLS > WG, but as you know it's quite simple to get the WG to make negative > noises. I'm not sure how you'd go about getting approving noises > other than to push through and see what happens as your I-D > progresses. > > However, as I said, the key test of whether your proposal plays well > with TLS will be whether you need to make any changes to TLS itself. > If you can avoid TLS changes (to the spec, to implementations [except > for the purpose of adding TLS functionality already specified]) then > you're golden. I'd go further: your work wouldn't even fall under the > TLS WG charter (though you'd still want to give the WG's participants > an opportunity to review your I-D). In other words: just adjust back > to the protocol design described above and in my I-D and move forward > towards publication. > > Nico From nico@cryptonector.com Sun Apr 3 22:07:38 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D24B3A691F for ; Sun, 3 Apr 2011 22:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3AFekhEWNXS for ; Sun, 3 Apr 2011 22:07:37 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id 8B0B63A68BC for ; Sun, 3 Apr 2011 22:07:37 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 9E9CB202018 for ; Sun, 3 Apr 2011 22:09:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=vHkjI0GfE/hHPJyeX87M30kGm1z/bcZ3rKv99C0JtxBo jdid2ykt/PC/cYuEXZGI0hatTUM68PyDnY8GFeeJAVEz8Tf8/MdVcBFxesJjBFnN tY6UIU/pHORTetBBeoTX32xHr0lvRdullDVVUWllqQZqYKGugkA/Cqa9AvR82LQ= 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=jl2mnpWLmV2SyClcY97AbyZk6ME=; b=qiGoNR2iGnW UP0Oa5W5H6Ni869ZBevVE0rvK7h5v2pHaPMs8BEUa0g7Bf2ZErXpG7HoiBnKLhho 7CW9N6ho+2IJlCzvkroRe35P6U1X+LKGsHI+dMVs1uRJHZI0CnHud/KvW85wSArN Ps2lfNjLw7sQbCxHLNBUZvh5sJluSHPc= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 6D712202017 for ; Sun, 3 Apr 2011 22:09:19 -0700 (PDT) Received: by vws12 with SMTP id 12so4640261vws.31 for ; Sun, 03 Apr 2011 22:09:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.68.65 with SMTP id u1mr3548474vdt.310.1301893758817; Sun, 03 Apr 2011 22:09:18 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Sun, 3 Apr 2011 22:09:18 -0700 (PDT) In-Reply-To: <4D994F3E.3070202@pobox.com> References: <87ipuycqip.fsf@latte.josefsson.org> <4D994F3E.3070202@pobox.com> Date: Mon, 4 Apr 2011 00:09:18 -0500 Message-ID: From: Nico Williams To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 05:07:38 -0000 On Sun, Apr 3, 2011 at 11:55 PM, Michael D'Errico wro= te: > I admit to not knowing what EAP-TLS is, but from reading this message > it seems like the EAP exchange could maybe benefit from defining a new > record type. =C2=A0Perhaps that's already what's done? =C2=A0Or is there = a reason > to not do that? It's completely unnecessary. Imagine that you have an application that uses TLS to which you're adding some feature, and this feature requires three round-trips at the beginning, and suppose further more that there's nothing wrong, security-wise[*], with doing some or all of those round-trips without the protection of TLS. That's pretty much the situation here (the number of round-trips may vary in the actual case at hand). The obvious thing to do then is to piggy-back the first two round-trips of this application protocol feature, as well as the negotiation of it. on the TLS handshake. That's it, that's all Yoav wants to do, and it's all I want to do. Since we're talking about an application feature, there's no need to define a new record type. Defining a new record type would only slow things down. HOWEVER, if we had N such features to piggy-back on the TLS handshake in parallel, then we'd need some additional framing -- such framing would still not, IMO, rise to the level of a new record type, but it would be desirable to standardize on such framing in one place (TLS) than in many (one per-application protocol). (I don't think we'll have N>1 such extensions in use concurrently, and I don't think it'd be a tragedy if we ended up with many such framing specs.) [*] These exchanges do get integrity protection via the Finished messages; they just don't get confidentiality protection unless they are done in a the handshakes of TLS renegotiations. The reason it's safe to not provide the same level of protection to this feature as to the rest of the application will almost always be because either a) this feature negotiates features that are not security-sensitive and/or b) this feature is an authentication feature distinct from, but bound to, TLS. Nico -- From ynir@checkpoint.com Sun Apr 3 23:43:03 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3E953A69E3 for ; Sun, 3 Apr 2011 23:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRgk-iqpAmCL for ; Sun, 3 Apr 2011 23:43:02 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 591263A693C for ; Sun, 3 Apr 2011 23:43:02 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p346ibVV015206; Mon, 4 Apr 2011 09:44:37 +0300 X-CheckPoint: {4D9976B6-1-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 4 Apr 2011 09:44:37 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 4 Apr 2011 08:44:37 +0200 From: Yoav Nir To: Nico Williams Date: Mon, 4 Apr 2011 08:44:29 +0200 Thread-Topic: [TLS] EAP-in-TLS and channel bindings Thread-Index: Acvyk8NAgUcYgVs7QBGrJyEZptqOHw== Message-ID: References: <87ipuycqip.fsf@latte.josefsson.org> 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 Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 06:43:03 -0000 On Apr 4, 2011, at 7:36 AM, Nico Williams wrote: > On Sat, Apr 2, 2011 at 1:00 PM, Yoav Nir wrote: >> Thanks for this. One of our earlier versions of our proposal looked like= this: >>=20 >> [...] >>=20 >> The only difference is that InterimAuth is renamed to "Finished", and th= e last handshake message is renamed to "EAP-Finished". Putting it like this= , it looks very much like figure 2 in your draft. The reason we chose to go= with InterimAuth in the middle rather EAP-Finished in the end was because = the usual semantic for "Finished" is that the application data follows, whi= le we consider the EAP part to be an extension of the handshake that preced= es application data. In your draft, the SASL authentication is sent as data= . >=20 > Indeed! This is very much like my proposal. The key is that the > round-trips required by EAP beyond those required by TLS do not hold > up the end of the TLS handshake. The application can negotiate the > use of EAP in this way via a Hello extensions and then the application > can hold off the start of the normal application data protocol until > after the EAP (or GSS, or SASL, or whatever) exchange completes. One of our design goals is to make password authentication part of the TLS = handshake, just as certificate authentication is. After the handshake compl= etes, the TLS library gives the server application an API to get the DN pre= sented in the certificate that the client used. We would have liked to have= a similar (or the same) API for password authentication. In other words, I= don't want EAP, GSS or SASL to be implemented by the application, but by t= he infrastructure. Having said that, a particular library can expose the same APIs to the appl= ication even if some of the records that it generates are "application data= " records rather than handshake. The question of what kind of record carrie= s the EAP and EAP-finished is independent of the question of separation bet= ween library and application. >=20 > I believe none of the normal objections to earlier proposals apply to > such a design because a) only normal TLS extension slots are used, b) > the TLS state machine is not changed, only the application protocol is > changed. In fact, no changes should be needed to any TLS > implementation that provides the necessary extensions hooks, and this > is a critical feature. I'm not sure how the state machine is not changed just because the "Finishe= d" message precedes the EAP. You still can't get real application data out = before the EAP has concluded successfully, so the state machine has to acco= unt for that. >=20 >> EAP methods have no use for the tls-unique channel binding. However, I t= hink that whether the EAP message is sent as a handshake message or as appl= ication data, the calculation of tls-unique needs to change in case of EAP = authentication. Do you think a good value for it would be to take the tls-u= nique used for the Finished (or "interimAuth") record, concatenate the MSK = from EAP, and hash them together? >=20 > I'm not sure that EAP has no use for tls-unique here... Suppose > you're talking to an MITM (see the Comodo CA compromise...). Don't > you want to make sure that they are not able to cut-n-paste the EAP > exchange to the real service?? I would think that you do! In EAP > this would be called "cryptographic binding", not "channel binding" -- > we have a sad terminology issue :( Some EAP methods, especially the good ones, have some random values in them= , so they're protected against cut-and-paste. The security considerations s= hould state why it's a good idea to use such methods. >=20 >> If a proposal like this is more palatable to the group (and doesn't chan= ge the state machine as much), I think this can be worked out. >=20 > I have found it very difficult to elicit approving noises from the TLS > WG, but as you know it's quite simple to get the WG to make negative > noises. I'm not sure how you'd go about getting approving noises > other than to push through and see what happens as your I-D > progresses. >=20 > However, as I said, the key test of whether your proposal plays well > with TLS will be whether you need to make any changes to TLS itself. > If you can avoid TLS changes (to the spec, to implementations [except > for the purpose of adding TLS functionality already specified]) then > you're golden. I'd go further: your work wouldn't even fall under the > TLS WG charter (though you'd still want to give the WG's participants > an opportunity to review your I-D). In other words: just adjust back > to the protocol design described above and in my I-D and move forward > towards publication. >=20 > Nico > -- From mike-list@pobox.com Sun Apr 3 23:58:30 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D1D3A6911 for ; Sun, 3 Apr 2011 23:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LFWt9JKr09u for ; Sun, 3 Apr 2011 23:58:23 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id C23FD3A691F for ; Sun, 3 Apr 2011 23:58:23 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 365735E61; Mon, 4 Apr 2011 03:01:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=nq3wmtrs6NFz 9A3nbq9vmOevtZo=; b=vJvGA2aK2syzsCmqyzCeaDAShETk7XVRtDRw+V9QuCjU AU7BmOvSY8Pzc6Pd2EvD6iFJW/zPXMj/OJDmTnvqWJRHRH7k8uSKTCXN6t8MSbHs 7QXmzx89vNNtEuHZG/frf+SEYS+gYbRkERORyzIM8NQJ657NYMJfiP2iy2f7jGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=K/QFAY 9jObWsxa94c+o5rO1pRFBibxwOefCEErTf85xUw6ayOkk2nKMEfm8TGfLfgKRK6q B8y6y20z8EV/k/XN/QfL+uvg08wjQqUVf7+M8sq8qxhsAY+dpgtuE1uIwsb+r2xq kLGIlaS6aJJ9MIXK3kpqh7INm4BYF+NDdaHT4= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 05CF05E59; Mon, 4 Apr 2011 03:01:54 -0400 (EDT) Received: from iMac.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id EE59B5E56; Mon, 4 Apr 2011 03:01:49 -0400 (EDT) Message-ID: <4D996C6C.7060609@pobox.com> Date: Sun, 03 Apr 2011 23:59:56 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Yoav Nir References: <87ipuycqip.fsf@latte.josefsson.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 6C2AC78C-5E89-11E0-B156-E8AB60295C12-38729857!a-pb-sasl-sd.pobox.com Cc: "tls@ietf.org" , Simon Josefsson Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 06:58:30 -0000 Yoav Nir wrote: > > One of our design goals is to make password authentication part of the TLS handshake, just as certificate authentication is. Forgive me if this is another stupid question, but have you looked at the Secure Remote Password (SRP) cipher suites in RFC 5054? Mike From ynir@checkpoint.com Mon Apr 4 00:15:21 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97FDE3A691B for ; Mon, 4 Apr 2011 00:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.557 X-Spam-Level: X-Spam-Status: No, score=-10.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ie--wuGpEuDR for ; Mon, 4 Apr 2011 00:15:20 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 4E46A3A6919 for ; Mon, 4 Apr 2011 00:15:20 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p347GwGW019733; Mon, 4 Apr 2011 10:16:58 +0300 X-CheckPoint: {4D997E4B-2-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 4 Apr 2011 10:16:58 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 4 Apr 2011 09:16:58 +0200 From: Yoav Nir To: "'Michael D'Errico'" Date: Mon, 4 Apr 2011 09:16:57 +0200 Thread-Topic: [TLS] EAP-in-TLS and channel bindings Thread-Index: Acvyle+fJQTxsle8SZKUcbp7hHUxlAAAh9xg Message-ID: <006FEB08D9C6444AB014105C9AEB133F013ABE025DF8@il-ex01.ad.checkpoint.com> References: <87ipuycqip.fsf@latte.josefsson.org> <4D996C6C.7060609@pobox.com> In-Reply-To: <4D996C6C.7060609@pobox.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 Cc: "tls@ietf.org" , Simon Josefsson Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 07:15:21 -0000 Sure, but those require the verifiers (salted hashes of the passwords) to b= e stored on the TLS server.=20 I don't think there's a good way to get TLS-SRP to work with a backend AAA = server. -----Original Message----- From: Michael D'Errico [mailto:mike-list@pobox.com]=20 Sent: 04 April 2011 10:00 To: Yoav Nir Cc: Nico Williams; Simon Josefsson; tls@ietf.org Subject: Re: [TLS] EAP-in-TLS and channel bindings Yoav Nir wrote: >=20 > One of our design goals is to make password authentication part of the TL= S handshake, just as certificate authentication is. Forgive me if this is another stupid question, but have you looked at the S= ecure Remote Password (SRP) cipher suites in RFC 5054? Mike From nico@cryptonector.com Mon Apr 4 00:24:37 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243663A691A for ; Mon, 4 Apr 2011 00:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.417 X-Spam-Level: X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_11=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc6of5DFvvqf for ; Mon, 4 Apr 2011 00:24:31 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id 297633A691C for ; Mon, 4 Apr 2011 00:24:31 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 5ED6635005B for ; Mon, 4 Apr 2011 00:26:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=CgeUAtSWA+30nhQMI4kx1b/um3+0ZENUhIZwzq9xaCfK UkkJ2pw8ueydzo1HxCcq3yIlypX0ji+9fpIP4WnkREyjeIZmVVoD8RfTqlzqLqVx tq9oDO97omKJQ1TgfAHnlYBSIFG105ih7FA5USkwVrC9q53GDasaM55qZGkyYdA= 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=2ABXQFvQ6O0GGwL8hhJRMOhEnow=; b=BkOF36uJ0Ad tIvOAyUuS5wLdh8+1GMLp3N7iyNwoE1J1fK8tnxPNudqBR9IieC8BOCPrAIjceYJ KhcIL342MzX6Ux413I4+Pqs0cJ8gUBVG/o1Jhn4JeNslOVdnhT0IOTNh/lNTN69Z aYTsPYDj1OWAnu/gCnx/hC/NRgINIncQ= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 2B5B2350058 for ; Mon, 4 Apr 2011 00:26:13 -0700 (PDT) Received: by vxg33 with SMTP id 33so4704477vxg.31 for ; Mon, 04 Apr 2011 00:26:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.176.134 with SMTP id ci6mr9257972vdc.190.1301901972291; Mon, 04 Apr 2011 00:26:12 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Mon, 4 Apr 2011 00:26:12 -0700 (PDT) In-Reply-To: References: <87ipuycqip.fsf@latte.josefsson.org> Date: Mon, 4 Apr 2011 02:26:12 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 07:24:37 -0000 On Mon, Apr 4, 2011 at 1:44 AM, Yoav Nir wrote: > On Apr 4, 2011, at 7:36 AM, Nico Williams wrote: >> On Sat, Apr 2, 2011 at 1:00 PM, Yoav Nir wrote: >>> Thanks for this. One of our earlier versions of our proposal looked lik= e this: >>> >>> [...] >> >> Indeed! =C2=A0This is very much like my proposal. =C2=A0The key is that = the >> round-trips required by EAP beyond those required by TLS do not hold >> up the end of the TLS handshake. =C2=A0The application can negotiate the >> use of EAP in this way via a Hello extensions and then the application >> can hold off the start of the normal application data protocol until >> after the EAP (or GSS, or SASL, or whatever) exchange completes. > > One of our design goals is to make password authentication part of the TL= S handshake, just as certificate authentication is. After the handshake com= pletes, the TLS library gives the server application an API to get the DN p= resented in the certificate that the client used. We would have liked to ha= ve a similar (or the same) API for password authentication. In other words,= I don't want EAP, GSS or SASL to be implemented by the application, but by= the infrastructure. I understand the urge to make this transparent to TLS applications. Nothing stops you from achieving that in spite of the protocol being designed to as to not modify TLS proper. That is, you could choose to implement your original approach, the one that resembles mine, such that your TLS library does all the work without the application having to know (though, of course, if you have to prompt the user you'll need to find a way, and that might mean having the application provide callback functions/closures for that purpose, or you might prompt out of band via a pop-up dialog). But in terms of not upsetting the TLS apple cart, the best way to achieve that appears to be to follow an approach that makes no changes to TLS proper. I'm not sure that I agree that the TLS state machine is so precious that it must be preserved at all costs -- I'm only pointing out that this appears to be paramount to many people you'd need to reach consensus. I suspect that the TLS state machine is important because assumptions about it are burned into some TLS API designs, concentrators, ... This is another reason to want standard abstract APIs: so that actual APIs are designed to a pattern that provides extensibility instead of leaving us stuck with an extremely constraining set of TLS handshake patterns. > Having said that, a particular library can expose the same APIs to the ap= plication even if some of the records that it generates are "application da= ta" records rather than handshake. The question of what kind of record carr= ies the EAP and EAP-finished is independent of the question of separation b= etween library and application. Exactly! I'm calling these additional messages "application messages", but in fact they are perfect candidates for abstracting in a common library, preferably the TLS library itself. > I'm not sure how the state machine is not changed just because the "Finis= hed" message precedes the EAP. You still can't get real application data ou= t before the EAP has concluded successfully, so the state machine has to ac= count for that. Yeah, but not the TLS state machine. Rather, the state machine of your protocol. >> I'm not sure that EAP has no use for tls-unique here... =C2=A0Suppose >> you're talking to an MITM (see the Comodo CA compromise...). =C2=A0Don't >> you want to make sure that they are not able to cut-n-paste the EAP >> exchange to the real service?? =C2=A0I would think that you do! =C2=A0In= EAP >> this would be called "cryptographic binding", not "channel binding" -- >> we have a sad terminology issue :( > > Some EAP methods, especially the good ones, have some random values in th= em, so they're protected against cut-and-paste. The security considerations= should state why it's a good idea to use such methods. I'm not seeing that. Let's say we have a client C, an MITM M, a server S, and a AAA server A. So we have C<->M<->S and C<=3DM<->S=3D>A. M terminates a TLS connection to C and is the client of a TLS connection to S, and M relays all other messages (including the TLS extensions for carrying EAP messages) between C and S until the point where the EAP exchange is complete, and then M closes the connection to C. From that point on M pretends to be the user authenticated by EAP. To prevent that attack we have to do something such as a) change the keying of TLS, or b) demonstrate to C and S that they have the same TLS connection. We can't do (a) because you might not be able to change keying until after some point in the EAP exchanges that is past the TLS ChangeCipherSpec and Finished message exchanges, and you can't delay those TLS messages because you can't change the TLS state machine. That leaves you with (b). Nico -- From nico@cryptonector.com Mon Apr 4 00:34:10 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5CF53A6922 for ; Mon, 4 Apr 2011 00:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96nOrcoZfNJW for ; Mon, 4 Apr 2011 00:34:04 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id 324B73A6911 for ; Mon, 4 Apr 2011 00:34:04 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id A580C1B405F for ; Mon, 4 Apr 2011 00:35:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=GvnERTeZc9nFFrlBKD5Ik ySh4Ix/hspbLgsMuSlp2RR5bviY55mAhYOGzQgoj5JjMoQINVT6e4O+6ueWDc2a+ tTGr+7aYb0pDz+eFRePyuEJviUz088E0gKZ1/9wmwOPZ19JbbxzwrU9X4QK9ZwDE 72amqHEpC7abQIYAvzet08= 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; s=cryptonector.com; bh=2oM8NCxtSgW0eNNE9TDW lbJW8dQ=; b=yySy6pvXXuCGoabP3eoFBBid6SyBC0V0G1EVRRORh8DMICLDQXUg Ks04WHiLQ/fwibsOrRwDaw4Vp6PeTSLbtZG681w6W4N/sQDItkIQRigKa8pTIWO7 CJzG0B68nSaxDeqN900NV8XFOmik9dF3tkutJsg+f+EyX2AwiUWhptk= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 768761B4059 for ; Mon, 4 Apr 2011 00:35:46 -0700 (PDT) Received: by vxg33 with SMTP id 33so4709228vxg.31 for ; Mon, 04 Apr 2011 00:35:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.169.39 with SMTP id ab7mr9107061vdc.230.1301902545882; Mon, 04 Apr 2011 00:35:45 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Mon, 4 Apr 2011 00:35:45 -0700 (PDT) In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F013ABE025DF8@il-ex01.ad.checkpoint.com> References: <87ipuycqip.fsf@latte.josefsson.org> <4D996C6C.7060609@pobox.com> <006FEB08D9C6444AB014105C9AEB133F013ABE025DF8@il-ex01.ad.checkpoint.com> Date: Mon, 4 Apr 2011 02:35:45 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 07:34:11 -0000 On Mon, Apr 4, 2011 at 2:16 AM, Yoav Nir wrote: > Sure, but those require the verifiers (salted hashes of the passwords) to be stored on the TLS server. > > I don't think there's a good way to get TLS-SRP to work with a backend AAA server. I think it's doable IF you have AAA support for SRP verifiers. But most folks who have AAA infrastructures don't have SRP verifiers. One could simply acquire those verifiers over time as users change their passwords, but that is a big barrier to adoption. The principle I like to hold, regarding authentication infrastructures, is this: we should enable you to use, in Internet protocols, whatever authentication infrastructure you have already deployed. Corollary: we should not force anyone to deploy any particular authentication infrastructure, much less N different ones (one for each Internet protocol). Some people have Kerberos infrastructures, some have AAA, some have PKIX (and smartcards), some have any two or all three of those; our protocols should work in all those cases. Nico -- From nico@cryptonector.com Mon Apr 4 00:40:33 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D2E93A692D for ; Mon, 4 Apr 2011 00:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.409 X-Spam-Level: X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_11=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tKcSN7JzfJp for ; Mon, 4 Apr 2011 00:40:27 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id 5450428C0E4 for ; Mon, 4 Apr 2011 00:40:27 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id BACB0674058 for ; Mon, 4 Apr 2011 00:42:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=n5i2fAnEfx7CK6tginDqtitPsUuoXdG6LFBcp2dbDGms lweK6iybl1z/owAtQ+O+mi9bpXY7MNrxXQ8h6HLzldO93I/AKHyO0qPrOW1/OF+E AhvQ98PHjBSQOMjSb0I/FJwNQwmve5YkF+8ZMggSLXTuYCQ+g+bXiU6zJAH1o0Y= 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=+OYryxBeURkWoLKZ/GFuIXMVCCM=; b=P263yjEXwN8 jQJlpxghxwgAc5c7o4TTts94iHTc/oOsvUjCr55e8F91mZPcSI/NGcVLc//ZmNRw iiVXbPiSBuYcEg1HfrHjzFgp6Mm2W9siX9tBbY6TJvuvPFxAzBFVFAiDbOY6nHcs mZm8NQ8Z4Bao+cX9tPiqsEacM1hDchgU= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 97C1C674057 for ; Mon, 4 Apr 2011 00:42:09 -0700 (PDT) Received: by vws12 with SMTP id 12so4704011vws.31 for ; Mon, 04 Apr 2011 00:42:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.18 with SMTP id bk18mr9104820vdb.270.1301902928772; Mon, 04 Apr 2011 00:42:08 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Mon, 4 Apr 2011 00:42:08 -0700 (PDT) In-Reply-To: References: <87ipuycqip.fsf@latte.josefsson.org> Date: Mon, 4 Apr 2011 02:42:08 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 07:40:33 -0000 On Mon, Apr 4, 2011 at 2:26 AM, Nico Williams wrote= : > On Mon, Apr 4, 2011 at 1:44 AM, Yoav Nir wrote: >>> I'm not sure that EAP has no use for tls-unique here... =C2=A0Suppose >>> you're talking to an MITM (see the Comodo CA compromise...). =C2=A0Don'= t >>> you want to make sure that they are not able to cut-n-paste the EAP >>> exchange to the real service?? =C2=A0I would think that you do! =C2=A0I= n EAP >>> this would be called "cryptographic binding", not "channel binding" -- >>> we have a sad terminology issue :( >> >> Some EAP methods, especially the good ones, have some random values in t= hem, so they're protected against cut-and-paste. The security consideration= s should state why it's a good idea to use such methods. > > I'm not seeing that. =C2=A0Let's say we have a client C, an MITM M, a > server S, and a AAA server A. =C2=A0So we have C<->M<->S and C<=3DM<->S= =3D>A. > M terminates a TLS connection to C and is the client of a TLS > connection to S, and M relays all other messages (including the TLS > extensions for carrying EAP messages) between C and S until the point > where the EAP exchange is complete, and then M closes the connection > to C. =C2=A0From that point on M pretends to be the user authenticated by > EAP. > > To prevent that attack we have to do something such as a) change the > keying of TLS, or b) demonstrate to C and S that they have the same > TLS connection. =C2=A0We can't do (a) because you might not be able to > change keying until after some point in the EAP exchanges that is past > the TLS ChangeCipherSpec and Finished =C2=A0message exchanges, and you > can't delay those TLS messages because you can't change the TLS state > machine. =C2=A0That leaves you with (b). BTW, this is properly the province of RFC5056 channel binding. That's because you have a secure channel (TLS) and authentication above it (EAP), and you want the channel to speak for the authenticated parties, which is precisely what RFC5056 channel binding is all about. Also, you should go look at ABFAB WG. ABFAB is working on an EAP-based mechanism for the GSS-API (they have much running code too, so it's not pie in the sky). Combined with draft-williams-tls-sasl-opt, ABFAB would give you pretty much the same exact thing you're trying to accomplish :) Nico -- From simon@josefsson.org Mon Apr 4 02:47:45 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67FAF3A6956 for ; Mon, 4 Apr 2011 02:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.379 X-Spam-Level: X-Spam-Status: No, score=-103.379 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn8IgYACiTtm for ; Mon, 4 Apr 2011 02:47:44 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id E4F4F3A6954 for ; Mon, 4 Apr 2011 02:47:43 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p349jLQn029777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 Apr 2011 11:45:24 +0200 From: Simon Josefsson To: Nico Williams References: <87ipuycqip.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110404:ynir@checkpoint.com::E8oP7akGVahpQ0p8:6itx X-Hashcash: 1:22:110404:tls@ietf.org::0Jj7xNoswImYHfkh:9F2k X-Hashcash: 1:22:110404:nico@cryptonector.com::+1OHFAnjRz4klewv:FY85 Date: Mon, 04 Apr 2011 11:45:21 +0200 In-Reply-To: (Nico Williams's message of "Mon, 4 Apr 2011 02:26:12 -0500") Message-ID: <87lizqz6xa.fsf_-_@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: "tls@ietf.org" Subject: [TLS] Modifying the TLS state machine X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 09:47:45 -0000 Nico Williams writes: > But in terms of not upsetting the TLS apple cart, the best way to > achieve that appears to be to follow an approach that makes no changes > to TLS proper. I'm not sure that I agree that the TLS state machine > is so precious that it must be preserved at all costs -- I'm only > pointing out that this appears to be paramount to many people you'd > need to reach consensus. I suspect that the TLS state machine is > important because assumptions about it are burned into some TLS API > designs, concentrators, ... I'd wish I understood the argument against modifying the state machine better. As an implementer, I don't see any problem making the change. As far as I understood EKR at the meeting, his concern was not based on implementation arguments. Still, given Nico's proposal, which does not affect the state machine, it seems we could implement support SASL and probably also EAP in TLS without state machine modifications. /Simon From ynir@checkpoint.com Mon Apr 4 04:28:37 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C789B3A6983 for ; Mon, 4 Apr 2011 04:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.558 X-Spam-Level: X-Spam-Status: No, score=-10.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2YAYiPmUvDA for ; Mon, 4 Apr 2011 04:28:37 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id BC1DD3A697D for ; Mon, 4 Apr 2011 04:28:36 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p34BU9Vl002982; Mon, 4 Apr 2011 14:30:09 +0300 X-CheckPoint: {4D99B9A0-11-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 4 Apr 2011 14:30:09 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 4 Apr 2011 13:30:08 +0200 From: Yoav Nir To: Simon Josefsson Date: Mon, 4 Apr 2011 13:30:08 +0200 Thread-Topic: Modifying the TLS state machine Thread-Index: Acvyu6a+dRLpDFijSNi7sM4SlTKPcw== Message-ID: <1911C941-1CAE-49E7-9B9F-2FCE6D0A0EB9@checkpoint.com> References: <87ipuycqip.fsf@latte.josefsson.org> <87lizqz6xa.fsf_-_@latte.josefsson.org> In-Reply-To: <87lizqz6xa.fsf_-_@latte.josefsson.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 Cc: "tls@ietf.org" Subject: Re: [TLS] Modifying the TLS state machine X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 11:28:38 -0000 On Apr 4, 2011, at 12:45 PM, Simon Josefsson wrote: > Nico Williams writes: >=20 >> But in terms of not upsetting the TLS apple cart, the best way to >> achieve that appears to be to follow an approach that makes no changes >> to TLS proper. I'm not sure that I agree that the TLS state machine >> is so precious that it must be preserved at all costs -- I'm only >> pointing out that this appears to be paramount to many people you'd >> need to reach consensus. I suspect that the TLS state machine is >> important because assumptions about it are burned into some TLS API >> designs, concentrators, ...=20 >=20 > I'd wish I understood the argument against modifying the state machine > better. As an implementer, I don't see any problem making the change. > As far as I understood EKR at the meeting, his concern was not based on > implementation arguments. Me neither > Still, given Nico's proposal, which does not affect the state machine, > it seems we could implement support SASL and probably also EAP in TLS > without state machine modifications. I don't know. If I call OpenSSL or GnuTLS or SChannel to perform a TLS hand= shake with password authentication, and it does the TLS handshake followed = by an EAP exchange before returning to the application, then somewhere a st= ate machine has changed. It doesn't really matter if the EAP messages are s= end as handshake records or "application data" records. Either way there ha= s to be a state machine that takes care of requests and responses. It may be that for some implementations it separates nicely into a TLS stat= e machine, and then an EAP state machine, with some big state machine that = controls how one state machine is used before the other. But this is not th= e case for all implementations, and it's not necessarily the cleanest way t= o implement this either.= From nico@cryptonector.com Mon Apr 4 05:33:59 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19D0A28C100 for ; Mon, 4 Apr 2011 05:33:59 -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=[AWL=0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aIXrbrB61w6 for ; Mon, 4 Apr 2011 05:33:52 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id AB62D3A67D1 for ; Mon, 4 Apr 2011 05:33:52 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id E1D5343807E for ; Mon, 4 Apr 2011 05:35:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=g0Um5dK0R02KndowToZwB +HY6vtwI8UAsdEi9GuN0xzs54iIF8/cH9HQEiNQHRjKubQmc0Zj3RR9VUhApijE2 c0++VYv3x8Y7wUaCwv+RHmW9U5LSfBp7R7fAoAIVogzZXAQc6c2w7WFDy5034maW XrR/72BshZqnxedUSF4YwU= 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; s=cryptonector.com; bh=RM6buCDbUP4hTF8joubg FdBDRos=; b=NsVxw6zne9VmfE6FcWJDvTtPyigVTOCgw8YJiX/BflxJMwKNr8wk 3dC3s2Yz1EKRlDdRnwKJSQ7XX+BhdLGQjtZK2i5RHjdKviit4JTuqGQzBpZkBtVZ SDJ7QsVC4Ig3rtVDy2PsH+lUU+bQDys5gA10UmzfKqhT2TI39bp027o= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id B691543807C for ; Mon, 4 Apr 2011 05:35:34 -0700 (PDT) Received: by vws12 with SMTP id 12so4877656vws.31 for ; Mon, 04 Apr 2011 05:35:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.176.134 with SMTP id ci6mr9684477vdc.190.1301920533942; Mon, 04 Apr 2011 05:35:33 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Mon, 4 Apr 2011 05:35:33 -0700 (PDT) In-Reply-To: <1911C941-1CAE-49E7-9B9F-2FCE6D0A0EB9@checkpoint.com> References: <87ipuycqip.fsf@latte.josefsson.org> <87lizqz6xa.fsf_-_@latte.josefsson.org> <1911C941-1CAE-49E7-9B9F-2FCE6D0A0EB9@checkpoint.com> Date: Mon, 4 Apr 2011 07:35:33 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Modifying the TLS state machine X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 12:33:59 -0000 Personally, I'd just modify TLS. It may be that today attitudes have changed regarding such changes. A few years ago when Stefan was pushing TLS-GSS there was a lot of resistance on state machine change grounds -- at least as far as I recall, and that's what I based my I-D and some of my comments on your proposal. (The CB-related comments, however, are not related to TLS change machince change resistance.) BTW, by state machine I'm referring to the number of round-trips and expectations of when the exchange is complete. In SASL and the GSS-API, for example, the state machine allows for a variable number of round-trips -- applications should not assume any particular number. In TLS the number of round-trips has always been 1.5 or 2, depending on context (session resumption vs. not). This difference means that one could have designed TLS APIs such that the addition of round-trips could not be made without changing the applications that use those APIs, but then the obvious thing to do is to not negotiate state-machine-changing extensions to TLS when using such APIs. So I'll admit that I'm also baffled by the unchanging state machine restriction; it may be that I just never understood it properly. EKR? Can you shed some light on this? Nico -- From ekr@rtfm.com Mon Apr 4 07:55:00 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8962B28C107 for ; Mon, 4 Apr 2011 07:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.948 X-Spam-Level: X-Spam-Status: No, score=-102.948 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGYUVyThhyrR for ; Mon, 4 Apr 2011 07:55:00 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id E518528C104 for ; Mon, 4 Apr 2011 07:54:59 -0700 (PDT) Received: by iye19 with SMTP id 19so7073617iye.31 for ; Mon, 04 Apr 2011 07:56:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.167.9 with SMTP id q9mr4964179icy.238.1301929002335; Mon, 04 Apr 2011 07:56:42 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Mon, 4 Apr 2011 07:56:42 -0700 (PDT) In-Reply-To: <87lizqz6xa.fsf_-_@latte.josefsson.org> References: <87ipuycqip.fsf@latte.josefsson.org> <87lizqz6xa.fsf_-_@latte.josefsson.org> Date: Mon, 4 Apr 2011 07:56:42 -0700 Message-ID: From: Eric Rescorla To: Simon Josefsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] Modifying the TLS state machine X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 14:55:00 -0000 On Mon, Apr 4, 2011 at 2:45 AM, Simon Josefsson wrote= : > Nico Williams writes: > >> But in terms of not upsetting the TLS apple cart, the best way to >> achieve that appears to be to follow an approach that makes no changes >> to TLS proper. =A0I'm not sure that I agree that the TLS state machine >> is so precious that it must be preserved at all costs -- I'm only >> pointing out that this appears to be paramount to many people you'd >> need to reach consensus. =A0I suspect that the TLS state machine is >> important because assumptions about it are burned into some TLS API >> designs, concentrators, ... > > I'd wish I understood the argument against modifying the state machine > better. =A0As an implementer, I don't see any problem making the change. > As far as I understood EKR at the meeting, his concern was not based on > implementation arguments. No, it's based on layer separation and cleanliness of protocol analysis. TLS is a relatively straightforward protocol with a state machine which is easy to analyze. (and there has been a huge amount of analysis on it) and yet even so we got it partly wrong as the renegotiation issue shows. Interlacing the TLS state machine with the EAP state machine as you propose complicates it and makes analysis much harder. As there's no compelling reason to do so, we shouldn't. > Still, given Nico's proposal, which does not affect the state machine, > it seems we could implement support SASL and probably also EAP in TLS > without state machine modifications. Agreed. -Ekr From yaronf.ietf@gmail.com Mon Apr 4 08:14:00 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 625853A69EF for ; Mon, 4 Apr 2011 08:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RPEmZTUA82M for ; Mon, 4 Apr 2011 08:13:53 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5793F3A6941 for ; Mon, 4 Apr 2011 08:13:53 -0700 (PDT) Received: by bwz13 with SMTP id 13so4497227bwz.31 for ; Mon, 04 Apr 2011 08:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=U8kumFoxBaAgevuvD4gCwzrIxht1DDYVhBnasezdJeA=; b=UEbSQJ6kr8VhTuzPlvoBC4Fj82EAega4eDTbvPFQS1+8epFIp0H51zEyuPVULYadsz NsY4eI+XtIrxPpTMWe7LvFOzmDUYKrh+0JNADCE/9qwo0y7Nyg/IDYBKCTSl0bYl+K5T 3Kj8HKrxOYIGVa174PjyhRp21UX+/fdFrCC74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=lc5N5Wkl9VjYUeqpvt44lWiUAaf/FxcTRTWDMHOHmIllBo4H7m8876bGmxBJvK/sXt K+twoXd33Y+aOg+TfhR/3ALVkYhlele4BnmpqeCFrnwKsy6pi54JKSUjYjZ3D20VOtHI 4Uy34iogXPszmNjN1J/3IVb/dunmOnG/Rr/Mc= Received: by 10.204.114.144 with SMTP id e16mr4494830bkq.119.1301930135281; Mon, 04 Apr 2011 08:15:35 -0700 (PDT) Received: from [192.168.200.100] (192.117.8.42.static.012.net.il [192.117.8.42]) by mx.google.com with ESMTPS id x6sm3161751bkv.12.2011.04.04.08.15.33 (version=SSLv3 cipher=OTHER); Mon, 04 Apr 2011 08:15:34 -0700 (PDT) Message-ID: <4D99E094.3090800@gmail.com> Date: Mon, 04 Apr 2011 18:15:32 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 15:14:00 -0000 Also, EAP as a generic infrastructure is making steady (albeit slow) progress with channel bindings and the NEA work. And it provides two recently published password-based protocols: https://tools.ietf.org/html/rfc6124 and http://tools.ietf.org/html/rfc5931. Thanks, Yaron > > Message: 1 > Date: Mon, 4 Apr 2011 09:16:57 +0200 > From: Yoav Nir > Subject: Re: [TLS] EAP-in-TLS and channel bindings > To: "'Michael D'Errico'" > Cc: "tls@ietf.org", Simon Josefsson > > Message-ID: > <006FEB08D9C6444AB014105C9AEB133F013ABE025DF8@il-ex01.ad.checkpoint.com> > > Content-Type: text/plain; charset="us-ascii" > > Sure, but those require the verifiers (salted hashes of the passwords) to be stored on the TLS server. > > I don't think there's a good way to get TLS-SRP to work with a backend AAA server. > > -----Original Message----- > From: Michael D'Errico [mailto:mike-list@pobox.com] > Sent: 04 April 2011 10:00 > To: Yoav Nir > Cc: Nico Williams; Simon Josefsson; tls@ietf.org > Subject: Re: [TLS] EAP-in-TLS and channel bindings > > Yoav Nir wrote: >> >> One of our design goals is to make password authentication part of the TLS handshake, just as certificate authentication is. > > Forgive me if this is another stupid question, but have you looked at the Secure Remote Password (SRP) cipher suites in RFC 5054? > > Mike > > > ------------------------------ From n.mavrogiannopoulos@gmail.com Mon Apr 4 08:19:44 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3187828C11C for ; Mon, 4 Apr 2011 08:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qn+EUXJ7imhw for ; Mon, 4 Apr 2011 08:19:43 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E50DC28C114 for ; Mon, 4 Apr 2011 08:19:42 -0700 (PDT) Received: by wwa36 with SMTP id 36so4574452wwa.13 for ; Mon, 04 Apr 2011 08:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=SREd+m6Xt5T8XreC7DLAPJEFVnYIEVcBMZPKM8tRKvs=; b=Y+BeNJxX2Fjyobi/gltqBDCI0dhVW5xjBgL/mKIs6RyvjEVlYA1uq+5F1EAfEyy8O5 8xzpTijcr0vAGk2lzb4qThnIXY/MYGZZ2pD8NMvDtwZvdQ3PXgfse4XVaavH26JZzUyr bPKiV1JVxtJ/yRrWjytSxvw7o0RoEN02Sfvdk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=UJnbg1EWjgETzs1OL3k5fr2UU2HemPqSiEWUe4RV+ShXODYiGzYD+RRy6dklAMeqHg 5AKrz+ATY4EoTeCr7BHrhoYJ13Vuo9JbcUyvnPS3p/r6ekcZSylz2FNtuVRRi1b3sEGr GZ1YysPxtk0i6Vve+WMYyQ4m6rt7PiaU3KNpg= Received: by 10.227.28.154 with SMTP id m26mr7172958wbc.216.1301930484817; Mon, 04 Apr 2011 08:21:24 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id h11sm2973243wbc.60.2011.04.04.08.21.21 (version=SSLv3 cipher=OTHER); Mon, 04 Apr 2011 08:21:22 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4D99E1F0.2060107@gnutls.org> Date: Mon, 04 Apr 2011 17:21:20 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Eric Rescorla References: <87ipuycqip.fsf@latte.josefsson.org> <87lizqz6xa.fsf_-_@latte.josefsson.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Modifying the TLS state machine X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 15:19:44 -0000 On 04/04/2011 04:56 PM, Eric Rescorla wrote: >> I'd wish I understood the argument against modifying the state machine >> better. As an implementer, I don't see any problem making the change. >> As far as I understood EKR at the meeting, his concern was not based on >> implementation arguments. > No, it's based on layer separation and cleanliness of protocol analysis. > TLS is a relatively straightforward protocol with a state machine which is > easy to analyze. (and there has been a huge amount of analysis on it) > and yet even so we got it partly wrong as the renegotiation issue shows. > Interlacing the TLS state machine with the EAP state > machine as you propose complicates it and makes analysis much harder. > As there's no compelling reason to do so, we shouldn't. I doubt that the existing analysis of TLS would apply to such a modification as EAP-TLS. Moreover there are so many EAP mechanisms that an analysis of such a modification would not be possible for all possible cases. regards, Nikos From ekr@rtfm.com Mon Apr 4 08:34:26 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A96FE3A69FB for ; Mon, 4 Apr 2011 08:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTAxIuhBfgPd for ; Mon, 4 Apr 2011 08:34:26 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 112003A69FA for ; Mon, 4 Apr 2011 08:34:26 -0700 (PDT) Received: by iye19 with SMTP id 19so7113664iye.31 for ; Mon, 04 Apr 2011 08:36:08 -0700 (PDT) Received: by 10.231.194.156 with SMTP id dy28mr7590276ibb.48.1301931368433; Mon, 04 Apr 2011 08:36:08 -0700 (PDT) Received: from [192.168.1.107] (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by mx.google.com with ESMTPS id g16sm3827655ibb.3.2011.04.04.08.34.27 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 08:34:28 -0700 (PDT) References: <87ipuycqip.fsf@latte.josefsson.org> <87lizqz6xa.fsf_-_@latte.josefsson.org> <4D99E1F0.2060107@gnutls.org> In-Reply-To: <4D99E1F0.2060107@gnutls.org> Mime-Version: 1.0 (iPhone Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8G4) From: Eric Rescorla Date: Mon, 4 Apr 2011 08:34:23 -0700 To: Nikos Mavrogiannopoulos Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Modifying the TLS state machine X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 15:34:26 -0000 On Apr 4, 2011, at 8:21, Nikos Mavrogiannopoulos wrote: > On 04/04/2011 04:56 PM, Eric Rescorla wrote: >=20 >>> I'd wish I understood the argument against modifying the state machine >>> better. As an implementer, I don't see any problem making the change. >>> As far as I understood EKR at the meeting, his concern was not based on >>> implementation arguments. >> No, it's based on layer separation and cleanliness of protocol analysis. >> TLS is a relatively straightforward protocol with a state machine which i= s >> easy to analyze. (and there has been a huge amount of analysis on it) >> and yet even so we got it partly wrong as the renegotiation issue shows. >> Interlacing the TLS state machine with the EAP state >> machine as you propose complicates it and makes analysis much harder. >> As there's no compelling reason to do so, we shouldn't. >=20 > I doubt that the existing analysis of TLS would apply to such > a modification as EAP-TLS. Moreover there are so many EAP mechanisms > that an analysis of such a modification would not be possible for all > possible cases. I certainly agree with this but that seems to me to be an argument for keepi= ng these mechanisms separate and composing them with channel bindings Ekr= From n.mavrogiannopoulos@gmail.com Mon Apr 4 08:38:12 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C95F28C118 for ; Mon, 4 Apr 2011 08:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARfEYsky70ox for ; Mon, 4 Apr 2011 08:38:11 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 84A0228C100 for ; Mon, 4 Apr 2011 08:38:11 -0700 (PDT) Received: by wwa36 with SMTP id 36so4591240wwa.13 for ; Mon, 04 Apr 2011 08:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=PRR0IF8KYoqsRCUqqFuORhugOi88Eudjc9wnMzRBzvU=; b=xfB0oNhG+0JbeFitRKyrIkIQUVa/LanMVYjjZOiD9HGtt03w4uSJkAaJXVH9u7vIec r0iTZX1SLbHZxLrBeU1sJjLM4kGcWh6ULjrPnv7J4mxm7x/TYN6fZ02yJ/mSsIwxy7dk 71ic85F1aNofMrwmUciZ6DnaMver9fy2HE6As= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=SBc02EN5X0eds02dAgtoqccrHPFK9mdm7UY+g1Y2TdMy88D7yrtBWaClJ4G8dxOlyP rj1ligddp6x/+/p0Yt6aXdj+7WM2ct5ziz7S9GosYYjYB4J+U6KDI7ssPhOW/NqhTKOL ZcTadBhXgrad/FXNRm/pVublKZjjlNz5+jRUQ= Received: by 10.216.18.194 with SMTP id l44mr4198485wel.87.1301931593420; Mon, 04 Apr 2011 08:39:53 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id f30sm2317394wef.7.2011.04.04.08.39.50 (version=SSLv3 cipher=OTHER); Mon, 04 Apr 2011 08:39:52 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4D99E646.5040305@gnutls.org> Date: Mon, 04 Apr 2011 17:39:50 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Eric Rescorla References: <87ipuycqip.fsf@latte.josefsson.org> <87lizqz6xa.fsf_-_@latte.josefsson.org> <4D99E1F0.2060107@gnutls.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Modifying the TLS state machine X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 15:38:12 -0000 On 04/04/2011 05:34 PM, Eric Rescorla wrote: >>> No, it's based on layer separation and cleanliness of protocol analysis. >>> TLS is a relatively straightforward protocol with a state machine which is >>> easy to analyze. (and there has been a huge amount of analysis on it) >>> and yet even so we got it partly wrong as the renegotiation issue shows. >>> Interlacing the TLS state machine with the EAP state >>> machine as you propose complicates it and makes analysis much harder. >>> As there's no compelling reason to do so, we shouldn't. >> >> I doubt that the existing analysis of TLS would apply to such >> a modification as EAP-TLS. Moreover there are so many EAP mechanisms >> that an analysis of such a modification would not be possible for all >> possible cases. > I certainly agree with this but that seems to me to be an argument for keeping these mechanisms separate and composing them with channel bindings Totally agree. regards, Nikos From nico@cryptonector.com Mon Apr 4 09:22:33 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44803A69CA for ; Mon, 4 Apr 2011 09:22:33 -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=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEd6Ue8LihHC for ; Mon, 4 Apr 2011 09:22:26 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (jankymail-mx1.g.dreamhost.com [208.97.132.126]) by core3.amsl.com (Postfix) with ESMTP id 7CFB33A69CC for ; Mon, 4 Apr 2011 09:22:26 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 61A182F4075 for ; Mon, 4 Apr 2011 09:24:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=uKdNotAdmWLM+I8PA5XQ5KTwMQtUMVcRAFaov6DuCWZT cVA8WEVKRllMP2+hbUuUEiEkk0laa+HSs8MazCWZRdc5ut20syDI0ejvU4F1os3b KRoKaVd552AeJyfpbyKzBkq/wYnkNlwNBoLudgCxMpthZMJT3rezDIZp9LyhrTM= 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=r54OBm0ULgzFGQ/YeylmV2sTNUo=; b=dYnIPG4Hu1a Q+us5zJ73YF4CWwaSIJHiMHy+M6MYQ1VrWZKuKpqNaEVu0LA4grZeOUno1iHAHXZ AwgEdocRV/R10RwVOtbhw4NgHSXp1v0wUzF12tlPV1dg82Z4Wl5i2TbZqwx0Mmef kRr/Yb972xa8Uk+/b1Ph31HS3vyspmk4= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 3E7872F4057 for ; Mon, 4 Apr 2011 09:24:04 -0700 (PDT) Received: by vxg33 with SMTP id 33so5108323vxg.31 for ; Mon, 04 Apr 2011 09:24:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.177.233 with SMTP id ct9mr9927599vdc.110.1301934243675; Mon, 04 Apr 2011 09:24:03 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Mon, 4 Apr 2011 09:24:03 -0700 (PDT) In-Reply-To: References: <87ipuycqip.fsf@latte.josefsson.org> <87lizqz6xa.fsf_-_@latte.josefsson.org> Date: Mon, 4 Apr 2011 11:24:03 -0500 Message-ID: From: Nico Williams To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Modifying the TLS state machine X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:22:33 -0000 On Mon, Apr 4, 2011 at 9:56 AM, Eric Rescorla wrote: > On Mon, Apr 4, 2011 at 2:45 AM, Simon Josefsson wro= te: >> Nico Williams writes: >> >>> But in terms of not upsetting the TLS apple cart, the best way to >>> achieve that appears to be to follow an approach that makes no changes >>> to TLS proper. =C2=A0I'm not sure that I agree that the TLS state machi= ne >>> is so precious that it must be preserved at all costs -- I'm only >>> pointing out that this appears to be paramount to many people you'd >>> need to reach consensus. =C2=A0I suspect that the TLS state machine is >>> important because assumptions about it are burned into some TLS API >>> designs, concentrators, ... >> >> I'd wish I understood the argument against modifying the state machine >> better. =C2=A0As an implementer, I don't see any problem making the chan= ge. >> As far as I understood EKR at the meeting, his concern was not based on >> implementation arguments. > > No, it's based on layer separation and cleanliness of protocol analysis. > TLS is a relatively straightforward protocol with a state machine which i= s > easy to analyze. (and there has been a huge amount of analysis on it) > and yet even so we got it partly wrong as the renegotiation issue shows. > Interlacing the TLS state machine with the EAP state > machine as you propose complicates it and makes analysis much harder. OK, this is good. It's not about round-trips, but about security analysis. In that case my approach to this problem is clean, or so I hope you'd agree. (In my approach the only "interlacing" is in the form of channel binding, and everything else is just an optimization. The only odd thing is the application protocol early start part, but surely you don't think that's a big deal, right?) >> Still, given Nico's proposal, which does not affect the state machine, >> it seems we could implement support SASL and probably also EAP in TLS >> without state machine modifications. > > Agreed. Is that an endorsement of my approach in draft-williams-tls-sasl-opt? Nico -- From nico@cryptonector.com Mon Apr 4 09:23:54 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377B53A69DA for ; Mon, 4 Apr 2011 09:23:54 -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=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKyWT7lCjc-J for ; Mon, 4 Apr 2011 09:23:47 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (jankymail-mx1.g.dreamhost.com [208.97.132.126]) by core3.amsl.com (Postfix) with ESMTP id B62073A683C for ; Mon, 4 Apr 2011 09:23:47 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 682D47E4073 for ; Mon, 4 Apr 2011 09:25:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=sJpKZVTVMJ5pd9ZTZZLZi Ww11dY+lKkwIQZlc5veGKW6+o7ykHUaqFNkHo9Ah9coltnWb8X0HjaCvyFId3gbQ zdTEDUlHeNYxOfSCC2Y2PWIOk24jDIb3BMOmU6oBZJ9HfnK6HW9Fbj9kkkrNgvwp 6KExQMt70dYr8D7HjO9wWk= 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; s=cryptonector.com; bh=noAids6LdMpS4qxzL2u1 vqO3XFE=; b=gzArYWoUXIz91UDdx+dx7FK/P5Gen77a0znAYpqjfPUCArMnCde9 2Wze3HD66M6u6WJ4Doi+i4IK3Y07GS2Gk5BYg3cKOMmWMBPHaf+1Zeyg17pOMRkm qiX1ZKCYxS3EUWcHdYN3/4YDrUuvWs8Ru59EutqYPaUb2oWvlbJ+er4= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 311037E405D for ; Mon, 4 Apr 2011 09:25:29 -0700 (PDT) Received: by vxg33 with SMTP id 33so5109588vxg.31 for ; Mon, 04 Apr 2011 09:25:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.177.233 with SMTP id ct9mr9929827vdc.110.1301934329175; Mon, 04 Apr 2011 09:25:29 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Mon, 4 Apr 2011 09:25:29 -0700 (PDT) In-Reply-To: References: <87ipuycqip.fsf@latte.josefsson.org> <87lizqz6xa.fsf_-_@latte.josefsson.org> <4D99E1F0.2060107@gnutls.org> Date: Mon, 4 Apr 2011 11:25:29 -0500 Message-ID: From: Nico Williams To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Modifying the TLS state machine X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:23:54 -0000 On Mon, Apr 4, 2011 at 10:34 AM, Eric Rescorla wrote: > On Apr 4, 2011, at 8:21, Nikos Mavrogiannopoulos wrote: >> I doubt that the existing analysis of TLS would apply to such >> a modification as EAP-TLS. Moreover there are so many EAP mechanisms >> that an analysis of such a modification would not be possible for all >> possible cases. > > I certainly agree with this but that seems to me to be an argument for keeping these mechanisms separate and composing them with channel bindings +1. But note that composition via channel binding does not imply that one cannot extend existing TLS implementations to do all this under the covers. Nico -- From mrex@sap.com Mon Apr 4 18:18:41 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21A5E3A682C for ; Mon, 4 Apr 2011 18:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.222 X-Spam-Level: X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdQrAA8Di-Hm for ; Mon, 4 Apr 2011 18:18:40 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 3C8DD3A6817 for ; Mon, 4 Apr 2011 18:18:39 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p351KJiR024458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2011 03:20:19 +0200 (MEST) From: Martin Rex Message-Id: <201104050120.p351KIYn007940@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 5 Apr 2011 03:20:18 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Apr 4, 11 07:56:42 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: simon@josefsson.org, tls@ietf.org Subject: Re: [TLS] Modifying the TLS state machine X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 01:18:41 -0000 Eric Rescorla wrote: > > Simon Josefsson wrote: > > > > I'd wish I understood the argument against modifying the state machine > > better.  As an implementer, I don't see any problem making the change. > > As far as I understood EKR at the meeting, his concern was not based on > > implementation arguments. > > No, it's based on layer separation and cleanliness of protocol analysis. > TLS is a relatively straightforward protocol with a state machine which is > easy to analyze. (and there has been a huge amount of analysis on it) The problem is that it hardly scales if everyone redefines the TLS state machine to his liking. In the first generation, folks modify "the original state machine". Then you want to use two such "enhancements" and start wondering, how they intermix (since they're both defined for the original state machine and not for use with "enhanced" state machines. And the next time around that TLS WG itself wants to add handshake messages, they have to address not only the original state machines, but also all of the "enhancements", their interference with each other and interference of the other enhancements with the new TLS WG enhancements. That is going to be a pretty big mess. > > and yet even so we got it partly wrong as the renegotiation issue shows. The renegotiation issue was more of an undocumented limitation of the protocol where the apps folks (= the TLS callers) boldly assumed a feature that didn't exist in TLS. Retrofitting secure renegotiation into the SSLv3&TLS protocol seemed like the most sensible approach to fixing the issue. -Martin From pgut001@cs.auckland.ac.nz Tue Apr 5 04:28:13 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6006A28C0FC for ; Tue, 5 Apr 2011 04:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Spta2kS32nVF for ; Tue, 5 Apr 2011 04:28:06 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 8FDD128C0F4 for ; Tue, 5 Apr 2011 04:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1302002990; x=1333538990; h=message-id:date:from:to:subject:mime-version: content-transfer-encoding; z=Message-ID:=20<20110405232948.inrkf05c84kgcosw@webmail.c s.auckland.ac.nz>|Date:=20Tue,=2005=20Apr=202011=2023:29: 48=20+1200|From:=20Peter=20Gutmann=20|To:=20tls@ietf.org|Subject:=20Re:=20[TLS]=20DSS =20with=20other=20than=20SHA-1=20algorithms|MIME-Version: =201.0|Content-Transfer-Encoding:=207bit; bh=SiFtz1x9dAclJKS5jyLmZVaCCHwIXjfxHJAPBwTVKjo=; b=umcBmDrqEiVkgPUE7Rv/N6ELojV6+/Wd19pdXexRbrAc6f9RvknkSRsF IcrDMD6mCOWiCdhAmajVVp23Z6QjDm/ThlvxeZzFctOkXdC2Wc2sdHfQP fTTcHnQ6Dhz3f0lppSaCrCVWCpl1iux0Mvdd6EqSvsQRHKhawtzWmQGqr s=; X-IronPort-AV: E=Sophos;i="4.63,303,1299409200"; d="scan'208";a="55238915" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Apr 2011 23:29:48 +1200 Received: from webcluster2.sit.auckland.ac.nz ([130.216.33.143] helo=eris.cs.auckland.ac.nz) by mf1.fos.auckland.ac.nz with esmtp (Exim 4.69) (envelope-from ) id 1Q74SC-0006OB-Hl for tls@ietf.org; Tue, 05 Apr 2011 23:29:48 +1200 Received: from 202-169-221-129.worldnet.co.nz (202-169-221-129.worldnet.co.nz [202.169.221.129]) by webmail.cs.auckland.ac.nz (Horde) with HTTP for ; Tue, 05 Apr 2011 23:29:48 +1200 Message-ID: <20110405232948.inrkf05c84kgcosw@webmail.cs.auckland.ac.nz> Date: Tue, 05 Apr 2011 23:29:48 +1200 From: Peter Gutmann To: tls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.1) X-Originating-IP: 202.169.221.129 Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 11:28:13 -0000 Some time ago I wrote: >Not really, use of DSA server certs is practically nonexistent (anyone want >to trawl through the EFF cert database to count them?) and use of "DSA2" >(i.e. > 1 kbit key) certs AFAIK *is* nonexistent, Someone has now gone through the EFF cert database and counted the number of DSA certs present on publicly-visible servers. In the entire world, there are exactly twenty-five of them (and some of these, I'm guessing, are test certs/servers). In contrast, there are several million RSA certs. So not only is "DSA2" nonexistent, but for all intents and purposes DSA is nonexistent as well. Peter. From pgut001@cs.auckland.ac.nz Tue Apr 5 04:46:46 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33BFD3A692E for ; Tue, 5 Apr 2011 04:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4svMmGqNn42 for ; Tue, 5 Apr 2011 04:46:38 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 4773B3A67B3 for ; Tue, 5 Apr 2011 04:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1302004102; x=1333540102; h=message-id:date:from:to:subject:mime-version: content-transfer-encoding; z=Message-ID:=20<20110405234820.45jm1j2pa8804w04@webmail.c s.auckland.ac.nz>|Date:=20Tue,=2005=20Apr=202011=2023:48: 20=20+1200|From:=20Peter=20Gutmann=20|To:=20tls@ietf.org|Subject:=20Re:=20[TLS]=20TLS =20v1.2=20performance=20(was=20Re:=20TLSv1.2=20with=20DSA =20client|MIME-Version:=201.0|Content-Transfer-Encoding: =207bit; bh=PMYKMGlIIaGq1zqRF9z7AIoLbHRlR+QXnklVWnklNF0=; b=aLwvCrbc3A3fU6eZNLD+zu1fVcgsu9TLynM1r3WyjS5gHJvPscvU53HG LfX7OY9oUUpiPzRA5QjSh7cQBeTWe9dBc90Op49IOlGvrjIpk+kN3/8HD 2KPBr5RuLGVlw2ysF72uUw0KBlFS67ifXJGIv6uJMjLMo7ZFqpVZOGJrX A=; X-IronPort-AV: E=Sophos;i="4.63,303,1299409200"; d="scan'208";a="55239832" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Apr 2011 23:48:21 +1200 Received: from webcluster2.sit.auckland.ac.nz ([130.216.33.143] helo=eris.cs.auckland.ac.nz) by mf1.fos.auckland.ac.nz with esmtp (Exim 4.69) (envelope-from ) id 1Q74k8-0006xj-JL for tls@ietf.org; Tue, 05 Apr 2011 23:48:21 +1200 Received: from 202-169-221-129.worldnet.co.nz (202-169-221-129.worldnet.co.nz [202.169.221.129]) by webmail.cs.auckland.ac.nz (Horde) with HTTP for ; Tue, 05 Apr 2011 23:48:20 +1200 Message-ID: <20110405234820.45jm1j2pa8804w04@webmail.cs.auckland.ac.nz> Date: Tue, 05 Apr 2011 23:48:20 +1200 From: Peter Gutmann To: tls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.1) X-Originating-IP: 202.169.221.129 Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 11:46:46 -0000 I wrote: >Just out of interest, how are other implementers dealing with this? I looked >at that requirement in the spec, decided it was totally crazy, and ignored >it. So far I haven't found any other TLS 1.2 implementation (of the very few >that are around) that has any problems with this, so my guess is everyone >else is ignoring it as well. The informal straw poll (some on-list, most off-list) indicated that no (known) implementation actually paid any attention to this requirement, for reasons already pointed out in the original thread. So I think we definitely need an update to the TLS 1.2 spec. >(There are a couple of other things in there that are completely nuts as >well, if we could document the general consensus on what to ignore it might >help other implementers who, God help us, decide to try and follow the spec). I finally got around to typing up the issues and suggested solutions: -- Snip -- TLS 1.2 problems Issue: The already-covered problem with requiring that all certs in the cert chain match what's in the signature_algorithm extension. Solution: Remove this requirement from the spec, everyone is ignoring it anyway, and all it does is hurt interoperability. Issue: When sending the list of supported signature and hash algorithms, the name used throughout the text is SignatureAndHashAlgorithm. This is incorrect, since what's sent is actually HashAndSignatureAlgorithm. Solution: Either rename SignatureAndHashAlgorithm to HashAndSignatureAlgorithm or reverse the order of the parameters being sent to match the name. Issue: Handling of ECC is a mess. The IPsec guys found out the hard way with IKEv1 that for interoperability you need a small, fixed number of suites, not a 52-page Chinese menu that no two parties can agree on. TLS seems to have gone in the opposite direction, with so many options available for ECC that they're a serious pain to deal with. I've found this when interop-testing against some of the ECC test servers that are up, you have to really, really carefully choose what you send to the server, if you start getting flexible with options then the other side typically disconnects, or can't complete the handshake with various buggy behaviours (return an SSLv3 alert for a TLS 1.2 handshake, continuing with a TLS 1.1 handshake unless you manage to guess the one specific combination of ECC parameters that the other side wants to see, and other oddness). ECC is actually so complex that it deserves an entire subsection for itself. Sub-issue: The overall suite chosen can be retroactively modified by ECC parameters sent later in the handshake, so when choosing a suite you have to remember not only the main suite but also one (or possibly more) backup suites to fall back on if a later ECC parameter means you can't use your first choice. Solution: Select a few fixed, complete suites (rather than entire areas of operation, with details to be sorted out later at the committee meeting) and specify those as suites, with no further post-modification via ECC parameters necessary. For example I've found that absolutely everything can do P256/SHA256/AES, so that even if I simply ignore every one of the ECC parameters I can still connect by always choosing this combination, which means that implementations are already using de facto fixed suites anyway. So adding the fixed suites: TLS_P256_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 = 168 TLS_P384_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 = 169 TLS_P256_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 = 170 TLS_P384_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 = 171 TLS_P256_ECDHE_PSK_WITH_AES_128_CBC_SHA256 = 172 TLS_P384_ECDHE_PSK_WITH_AES_256_CBC_SHA384 = 173 to cover the common usage cases should keep about 99% of users happy while using just one fifth of the number of ECC suites we already have now (and that's before the infinite variety of parameter options come into play). If anyone really wants to make a fashion statement using Brainpool curves or something else bizarre, they can use the parameterised way of doing things, and good luck to them with getting anything else to talk to them. Sub-issue: Another example of unnecessary flexibility is the way supported curves are handled. For example if I want to use ECDH-P256 with ECDSA-P521 then I have to specify, and the other side has to verify, groups of algorithms (and eventually, hashes) rather than just one. The result is the combinatorial explosion of algorithms that made IKE such fun to get going. Just for yucks I tried some odd combinations with one or two existing test servers. The ones that didn't simply disconnect couldn't complete the handshake, except for one (semi-private) implementation. This indicates that if anyone did actually take advantage of the flexibility being provided, the chances of any kind of interoperability are... low. Solution: See previous, define some fixed suites with a single set of common parameters, and if anyone wants to get exotic they're welcome to everything they get. Sub-issue: Because of the complexity of the ECC negotiation, it's quite possible that the two sides can't agree on any common parameters, and continue on with a standard (non-ECC) suite that they can agree on. So the user specifies ECC as their preferred suite(s), the negotiation completes securely, but they're not using ECC. Since negotiation always ends up proceeding with a non-ECC suite, the ECC option may as well not be there. Solution: Again, the fixed-suite approach would help address this, since you're more likely to reach agreement on how to continue. Alternatively, provide an extension to say "must negotiate ECC, otherwise the connect attempt fails". This needs more investigation, the real problem here is Ian Grigg's "There is only one cipher suite and that is Suite #1", i.e. you can have a thousand suites in your handshake but the only one that matters is the first in the list because things never get beyond that. Issue: Because you don't know which hash algorithm will end up being used, you need to either buffer arbitrary amounts of handshake data or speculatively run multiple hashes in parallel, one for each algorithm you support, depending on what ends up being negotiated. This issue has been discussed before on the list as well. Solution: Yet again, the fixed-suite approach addresses this, if you're doing (say) TLS_P256_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 then you only need to run a SHA256 hash. (What I've been doing, at least in the server, is to send out a cert-request containing the single de facto hash algorithm that I use anyway, either SHA256 or SHA384 depending on the key size, forcing the client to adapt. This is effective in fixing the problem, but certainly not the way the mechanism is meant to be used: /* In other words although it was planned as a means of indicating the server's capabilities, it actually acts as a mechanism for keeping the client-auth process sane */ So that's about it, in total there are really only three changes: - Drop the signature_algorithm -> cert requirement, which breaks the protocol and which everyone ignores anyway. - Rename SignatureAndHashAlgorithm to HashAndSignatureAlgorithm to match what's actually being send. - Provide six fixed suites for ECC to get rid of a whole host of ECC-related problems. Peter. From iesg-secretary@ietf.org Tue Apr 5 09:49:09 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224DF28C128; Tue, 5 Apr 2011 09:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuihg4Jnh6rC; Tue, 5 Apr 2011 09:49:08 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727173A6960; Tue, 5 Apr 2011 09:49:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce , tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110405164908.25229.95269.idtracker@localhost> Date: Tue, 05 Apr 2011 09:49:08 -0700 Subject: [TLS] Last Call: (The SSL Protocol Version 3.0) to Historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list 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: Tue, 05 Apr 2011 16:49:09 -0000 The IESG has received a request from an individual submitter to consider the following document: - 'The SSL Protocol Version 3.0' as a Historic 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 2011-05-03. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-mavrogiannopoulos-ssl-version3/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-mavrogiannopoulos-ssl-version3/ No IPR declarations have been submitted directly on this I-D. From ekr@rtfm.com Tue Apr 5 09:56:04 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F46728C104 for ; Tue, 5 Apr 2011 09:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS47At7qPpit for ; Tue, 5 Apr 2011 09:56:03 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 9145B3A6962 for ; Tue, 5 Apr 2011 09:56:03 -0700 (PDT) Received: by iye19 with SMTP id 19so710502iye.31 for ; Tue, 05 Apr 2011 09:57:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.60.205 with SMTP id wt13mr1527755icb.253.1302022665267; Tue, 05 Apr 2011 09:57:45 -0700 (PDT) Received: by 10.42.241.5 with HTTP; Tue, 5 Apr 2011 09:57:45 -0700 (PDT) In-Reply-To: <20110405164908.25229.95269.idtracker@localhost> References: <20110405164908.25229.95269.idtracker@localhost> Date: Tue, 5 Apr 2011 09:57:45 -0700 Message-ID: From: Eric Rescorla To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [TLS] Last Call: (The SSL Protocol Version 3.0) to Historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 16:56:04 -0000 TLS WG, This document will be Historic, but it still would be good if people could read it and determine whether they are happy with it. Best, -Ekr On Tue, Apr 5, 2011 at 9:49 AM, The IESG wrote: > > The IESG has received a request from an individual submitter to consider > the following document: > - 'The SSL Protocol Version 3.0' > =A0 as a Historic > > 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 2011-05-03. 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. > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-mavrogiannopoulos-ssl-version3/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-mavrogiannopoulos-ssl-version3/ > > > > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From mike-list@pobox.com Tue Apr 5 10:03:57 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E5F128C11F for ; Tue, 5 Apr 2011 10:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRJChjbbTR4a for ; Tue, 5 Apr 2011 10:03:56 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 695A73A6969 for ; Tue, 5 Apr 2011 10:03:56 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 4DEAC3658; Tue, 5 Apr 2011 13:07:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=voFEQNAziAbY 1Lq4PQIV0h8Ghh4=; b=cfmWObhmrpe6PoQSsO7dq+D2ESmghHSONqP7WIaRh5Bi qChJnkaHddX1VihLUjn0yzdTwsQGhxxHoJV6TYSbOdCMqGsNJ5hDem47925eWioG tT3x3nLmRiYqIAN8QkSBOMsG5ilpCFQNBdAvnRaMMXKDXXouCdIeKbXgJuBSssM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=u5/bzQ ujN53p8S4mOI3/CxEYwUcyCeVbxGPbDJCpZByXlkzRquljjW8+6Eda+AxFMXZ9HL 4iXoH+4uSZMJ+t2a/bobfCZgKBjvIGGmRPaq0XkIeO3JE+2JsNo+YCQf8AMy2z4l vJhS74IzG49cUCqeVYx6Hcz81wVfykR+yFsYA= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 3441D3657; Tue, 5 Apr 2011 13:07:30 -0400 (EDT) Received: from iMac.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 90FCA3656; Tue, 5 Apr 2011 13:07:28 -0400 (EDT) Message-ID: <4D9B4BDE.5010509@pobox.com> Date: Tue, 05 Apr 2011 10:05:34 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Peter Gutmann References: <20110405234820.45jm1j2pa8804w04@webmail.cs.auckland.ac.nz> In-Reply-To: <20110405234820.45jm1j2pa8804w04@webmail.cs.auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 30A15A72-5FA7-11E0-AE47-E8AB60295C12-38729857!a-pb-sasl-sd.pobox.com Cc: tls@ietf.org Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 17:03:57 -0000 Peter Gutmann wrote: > > Issue: When sending the list of supported signature and hash algorithms, the > name used throughout the text is SignatureAndHashAlgorithm. This is incorrect, > since what's sent is actually HashAndSignatureAlgorithm. > > Solution: Either rename SignatureAndHashAlgorithm to HashAndSignatureAlgorithm > or reverse the order of the parameters being sent to match the name. It would be impossible to switch the order of the parameters sent on the wire at this point, so simply renaming the structure is all we can do. I support the name change. Mike From tom@voltage.com Tue Apr 5 14:52:31 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B7C3A67D8 for ; Tue, 5 Apr 2011 14:52:31 -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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJt933jemj42 for ; Tue, 5 Apr 2011 14:52:29 -0700 (PDT) Received: from mail.voltage.com (mail.voltage.com [71.6.108.2]) by core3.amsl.com (Postfix) with ESMTP id 987473A67AA for ; Tue, 5 Apr 2011 14:52:29 -0700 (PDT) Received: from pps.filterd (mail [127.0.0.1]) by mail.voltage.com (8.14.3/8.14.3) with SMTP id p35LsCFJ027084 for ; Tue, 5 Apr 2011 14:54:12 -0700 Received: from hqmailsvr01.voltage.com (hqmailsvr01.voltage.com [172.16.0.22]) by mail.voltage.com with ESMTP id vfh3fgxb9-1 for ; Tue, 05 Apr 2011 14:54:12 -0700 Received: from hqmailsvr01.voltage.com ([172.16.0.22]) by hqmailsvr01.voltage.com ([172.16.0.22]) with mapi; Tue, 5 Apr 2011 14:54:13 -0700 From: Tom Wu To: "tls@ietf.org" Date: Tue, 5 Apr 2011 14:54:09 -0700 Thread-Topic: Re: [TLS] EAP-in-TLS and channel bindings Thread-Index: Acvz2/20NWzeZVs3T5Wl4DK6otGs+A== Message-ID: 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-04-05_09:2011-04-05, 2011-04-05, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1104050165 Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 21:54:05 -0000 > On Mon, Apr 4, 2011 at 2:16 AM, Yoav Nir wrote: > > Sure, but those require the verifiers (salted hashes of the passwords) = to be stored on the TLS server. > > > > I don't think there's a good way to get TLS-SRP to work with a backend = AAA server. > > I think it's doable IF you have AAA support for SRP verifiers. But > most folks who have AAA infrastructures don't have SRP verifiers. One > could simply acquire those verifiers over time as users change their > passwords, but that is a big barrier to adoption. >From Yaron Sheffer: > Also, EAP as a generic infrastructure is making steady (albeit slow) prog= ress with channel bindings and the NEA work. And it provides two recently p= ublished password-based protocols: https://tools.ietf.org/html/rfc6124 and = http://tools.ietf.org/html/rfc5931. These messages seem to imply that TLS-SRP won't play well with backend AAA = servers while RFC6124 (EAP-EKE) and RFC5931 (EAP-pwd) would, but this isn't= really true; all strong password protocols need the server to know the pas= sword, or some function of it, while the protocol is being negotiated. If = I'm missing something, please let me know. Tom From ynir@checkpoint.com Wed Apr 6 01:57:59 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E260D3A6849 for ; Wed, 6 Apr 2011 01:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.559 X-Spam-Level: X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFjcZaDVtwB3 for ; Wed, 6 Apr 2011 01:57:58 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 505EE3A681D for ; Wed, 6 Apr 2011 01:57:58 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p368xdCe018975; Wed, 6 Apr 2011 11:59:39 +0300 X-CheckPoint: {4D9C3950-10-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 6 Apr 2011 11:59:39 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 6 Apr 2011 10:59:39 +0200 From: Yoav Nir To: "'Tom Wu'" , "tls@ietf.org" Date: Wed, 6 Apr 2011 10:59:38 +0200 Thread-Topic: Re: [TLS] EAP-in-TLS and channel bindings Thread-Index: Acvz2/20NWzeZVs3T5Wl4DK6otGs+AAXGtXg Message-ID: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.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 Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 08:58:00 -0000 Hi Tom. There is no problem with SRP vs EKE or pwd. The problem is that AAA servers= work either with plain passwords (the web server sends the password in an = "access-request" and the AAA server returns an "access-accept") or using EA= P. If someone were to pick up James Carlson's work and create an EAP-SRP m= ethod, it would work just as well. Yoav -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Tom W= u Sent: 06 April 2011 00:54 To: tls@ietf.org Subject: Re: [TLS] EAP-in-TLS and channel bindings > On Mon, Apr 4, 2011 at 2:16 AM, Yoav Nir wrote: > > Sure, but those require the verifiers (salted hashes of the passwords) = to be stored on the TLS server. > > > > I don't think there's a good way to get TLS-SRP to work with a backend = AAA server. > > I think it's doable IF you have AAA support for SRP verifiers. But=20 > most folks who have AAA infrastructures don't have SRP verifiers. One=20 > could simply acquire those verifiers over time as users change their=20 > passwords, but that is a big barrier to adoption. >From Yaron Sheffer: > Also, EAP as a generic infrastructure is making steady (albeit slow) prog= ress with channel bindings and the NEA work. And it provides two recently p= ublished password-based protocols: https://tools.ietf.org/html/rfc6124 and = http://tools.ietf.org/html/rfc5931. These messages seem to imply that TLS-SRP won't play well with backend AAA = servers while RFC6124 (EAP-EKE) and RFC5931 (EAP-pwd) would, but this isn't= really true; all strong password protocols need the server to know the pas= sword, or some function of it, while the protocol is being negotiated. If = I'm missing something, please let me know. Tom From tom@voltage.com Wed Apr 6 05:48:14 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 262B43A6987 for ; Wed, 6 Apr 2011 05:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.676, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AU6nkTwb1t6y for ; Wed, 6 Apr 2011 05:48:12 -0700 (PDT) Received: from mail.voltage.com (mail.voltage.com [71.6.108.2]) by core3.amsl.com (Postfix) with ESMTP id 9E2993A694D for ; Wed, 6 Apr 2011 05:48:12 -0700 (PDT) Received: from pps.filterd (mail [127.0.0.1]) by mail.voltage.com (8.14.3/8.14.3) with SMTP id p36CkoGV005243; Wed, 6 Apr 2011 05:49:46 -0700 Received: from hqmailsvr01.voltage.com (hqmailsvr01.voltage.com [172.16.0.22]) by mail.voltage.com with ESMTP id vgnqar38g-1; Wed, 06 Apr 2011 05:49:46 -0700 Received: from hqmailsvr01.voltage.com ([172.16.0.22]) by hqmailsvr01.voltage.com ([172.16.0.22]) with mapi; Wed, 6 Apr 2011 05:49:46 -0700 From: Tom Wu To: Yoav Nir , "tls@ietf.org" Date: Wed, 6 Apr 2011 05:49:43 -0700 Thread-Topic: Re: [TLS] EAP-in-TLS and channel bindings Thread-Index: Acvz2/20NWzeZVs3T5Wl4DK6otGs+AAXGtXgAAfF5hA= Message-ID: References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-04-06_04:2011-04-06, 2011-04-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1104060049 Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 12:48:14 -0000 But if we start out by assuming that existing AAA deployments don't have SR= P verifiers, we must also assume that they don't have EAP-pwd or EAP-EKE pa= ssword data either, so they cannot use any of those strong password protoco= ls right away. Going forward, AAA infrastructures can add support for SRP verifiers just l= ike they can for EAP-pwd or EAP-EKE password data. In that case, given tha= t complexity is the enemy of security, I'd say that's a good reason to pref= er the simpler TLS-SRP handshake. Tom -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com]=20 Sent: Wednesday, April 06, 2011 2:00 AM To: Tom Wu; tls@ietf.org Subject: RE: Re: [TLS] EAP-in-TLS and channel bindings Hi Tom. There is no problem with SRP vs EKE or pwd. The problem is that AAA servers= work either with plain passwords (the web server sends the password in an = "access-request" and the AAA server returns an "access-accept") or using EA= P. If someone were to pick up James Carlson's work and create an EAP-SRP m= ethod, it would work just as well. Yoav -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Tom W= u Sent: 06 April 2011 00:54 To: tls@ietf.org Subject: Re: [TLS] EAP-in-TLS and channel bindings > On Mon, Apr 4, 2011 at 2:16 AM, Yoav Nir wrote: > > Sure, but those require the verifiers (salted hashes of the passwords) = to be stored on the TLS server. > > > > I don't think there's a good way to get TLS-SRP to work with a backend = AAA server. > > I think it's doable IF you have AAA support for SRP verifiers. But=20 > most folks who have AAA infrastructures don't have SRP verifiers. One=20 > could simply acquire those verifiers over time as users change their=20 > passwords, but that is a big barrier to adoption. >From Yaron Sheffer: > Also, EAP as a generic infrastructure is making steady (albeit slow) prog= ress with channel bindings and the NEA work. And it provides two recently p= ublished password-based protocols: https://tools.ietf.org/html/rfc6124 and = http://tools.ietf.org/html/rfc5931. These messages seem to imply that TLS-SRP won't play well with backend AAA = servers while RFC6124 (EAP-EKE) and RFC5931 (EAP-pwd) would, but this isn't= really true; all strong password protocols need the server to know the pas= sword, or some function of it, while the protocol is being negotiated. If = I'm missing something, please let me know. Tom From nico@cryptonector.com Wed Apr 6 05:57:32 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811AD28C0F7 for ; Wed, 6 Apr 2011 05:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQU6hfXDvz6Z for ; Wed, 6 Apr 2011 05:57:31 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id C044628C0F6 for ; Wed, 6 Apr 2011 05:57:31 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 88ACD21DE71 for ; Wed, 6 Apr 2011 05:59:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=AX2QNOnEDptNFFlSGSdaAj0Nc7GIzxZ3vKwgKKMZtoxe /aW3TtXKYyqpm/LCtwx63sDE0PuWDGX/8KVLOdWL7H+4urBP7gXVeyEG6xSvk4g6 y8HoQv9jpY4wxLfGDVg4vyCbCUE3eHoVK2SJI4g/N53ETb0km0/DmE34ncdONFs= 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=FJNOgXIDjBWJF+5uA88wqt48Tg4=; b=DWKlq7WqSKs cNdEpqFbG4yidFeyAWMOEuurWt51VwWNA8G+tWMEe4vP9SFNh+DHfp6u00Y6irnj GuP4BUDZM93Xtt7Lj+2VuzhB7YsxESW5qwLh8l2D+TdEOnicD9n6fSQ/nAX8911s /7QJs07C/evuoVaM2aTq7DjESZUwGWpY= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 4702021DE6F for ; Wed, 6 Apr 2011 05:59:15 -0700 (PDT) Received: by vws12 with SMTP id 12so1318222vws.31 for ; Wed, 06 Apr 2011 05:59:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.74.106 with SMTP id s10mr1297384vdv.150.1302094754585; Wed, 06 Apr 2011 05:59:14 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Wed, 6 Apr 2011 05:59:14 -0700 (PDT) In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.com> Date: Wed, 6 Apr 2011 07:59:14 -0500 Message-ID: From: Nico Williams To: Tom Wu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 12:57:32 -0000 On Wed, Apr 6, 2011 at 7:49 AM, Tom Wu wrote: > But if we start out by assuming that existing AAA deployments don't have = SRP verifiers, we must also assume that they don't have EAP-pwd or EAP-EKE = password data either, so they cannot use any of those strong password proto= cols right away. > > Going forward, AAA infrastructures can add support for SRP verifiers just= like they can for EAP-pwd or EAP-EKE password data. =C2=A0In that case, gi= ven that complexity is the enemy of security, I'd say that's a good reason = to prefer the simpler TLS-SRP handshake. As I explained: the point is to allow people to use what they have. TLS-SRP does not do that. EAP-in-TLS does. Nico -- From ynir@checkpoint.com Wed Apr 6 06:48:48 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6B13A693E for ; Wed, 6 Apr 2011 06:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.56 X-Spam-Level: X-Spam-Status: No, score=-10.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwGetHEH4FAD for ; Wed, 6 Apr 2011 06:48:47 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id EE9CB3A6935 for ; Wed, 6 Apr 2011 06:48:46 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p36DoScV012791; Wed, 6 Apr 2011 16:50:28 +0300 X-CheckPoint: {4D9C7D78-9-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 6 Apr 2011 16:50:28 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 6 Apr 2011 15:50:28 +0200 From: Yoav Nir To: "'Tom Wu'" , "tls@ietf.org" Date: Wed, 6 Apr 2011 15:50:27 +0200 Thread-Topic: Re: [TLS] EAP-in-TLS and channel bindings Thread-Index: Acvz2/20NWzeZVs3T5Wl4DK6otGs+AAXGtXgAAfF5hAAAh6EMA== Message-ID: <006FEB08D9C6444AB014105C9AEB133F013ABE025E04@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.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 Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 13:48:48 -0000 I don't think AAA deployments are going to send SRP verifiers to the server= s. They implement a pluginnable platform for all kinds of EAP methods, and = you can use any EAP method that you have a plug-in for. Using EAP with RADI= US is defined in RFC 4072. Microsoft AAA server comes with EAP-MSChapv2, EAP-TLS, EAP-PEAP and optiona= lly EAP-SecurID. Of these, only EAP-MSChapv2 and EAP-SecurID make sense in = the TLS context. If somebody writes plug-ins for EAP-EKE, EAP-Pwd and EAP-= SRP (if this is ever defined), that would work as well. Adding SRP verifiers without EAP requires an extension to RADIUS (or DIAMET= ER), and that's an issue for a different working group. So I agree that TLS-SRP is simpler and requires less round-trips. But I don= 't see how to make it work with existing AAA servers. Yoav -----Original Message----- From: Tom Wu [mailto:tom@voltage.com]=20 Sent: 06 April 2011 15:50 To: Yoav Nir; tls@ietf.org Subject: RE: Re: [TLS] EAP-in-TLS and channel bindings But if we start out by assuming that existing AAA deployments don't have SR= P verifiers, we must also assume that they don't have EAP-pwd or EAP-EKE pa= ssword data either, so they cannot use any of those strong password protoco= ls right away. Going forward, AAA infrastructures can add support for SRP verifiers just l= ike they can for EAP-pwd or EAP-EKE password data. In that case, given tha= t complexity is the enemy of security, I'd say that's a good reason to pref= er the simpler TLS-SRP handshake. Tom -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Wednesday, April 06, 2011 2:00 AM To: Tom Wu; tls@ietf.org Subject: RE: Re: [TLS] EAP-in-TLS and channel bindings Hi Tom. There is no problem with SRP vs EKE or pwd. The problem is that AAA servers= work either with plain passwords (the web server sends the password in an = "access-request" and the AAA server returns an "access-accept") or using EA= P. If someone were to pick up James Carlson's work and create an EAP-SRP m= ethod, it would work just as well. Yoav -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Tom W= u Sent: 06 April 2011 00:54 To: tls@ietf.org Subject: Re: [TLS] EAP-in-TLS and channel bindings > On Mon, Apr 4, 2011 at 2:16 AM, Yoav Nir wrote: > > Sure, but those require the verifiers (salted hashes of the passwords) = to be stored on the TLS server. > > > > I don't think there's a good way to get TLS-SRP to work with a backend = AAA server. > > I think it's doable IF you have AAA support for SRP verifiers. But=20 > most folks who have AAA infrastructures don't have SRP verifiers. One=20 > could simply acquire those verifiers over time as users change their=20 > passwords, but that is a big barrier to adoption. >From Yaron Sheffer: > Also, EAP as a generic infrastructure is making steady (albeit slow) prog= ress with channel bindings and the NEA work. And it provides two recently p= ublished password-based protocols: https://tools.ietf.org/html/rfc6124 and = http://tools.ietf.org/html/rfc5931. These messages seem to imply that TLS-SRP won't play well with backend AAA = servers while RFC6124 (EAP-EKE) and RFC5931 (EAP-pwd) would, but this isn't= really true; all strong password protocols need the server to know the pas= sword, or some function of it, while the protocol is being negotiated. If = I'm missing something, please let me know. Tom Scanned by Check Point Total Security Gateway. From tom@voltage.com Wed Apr 6 06:49:27 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92ACB3A67B2 for ; Wed, 6 Apr 2011 06:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-b-uzF-r2AU for ; Wed, 6 Apr 2011 06:49:26 -0700 (PDT) Received: from mail.voltage.com (mail.voltage.com [71.6.108.2]) by core3.amsl.com (Postfix) with ESMTP id 9F12D3A69C6 for ; Wed, 6 Apr 2011 06:49:26 -0700 (PDT) Received: from pps.filterd (mail [127.0.0.1]) by mail.voltage.com (8.14.3/8.14.3) with SMTP id p36Dl35x015599; Wed, 6 Apr 2011 06:51:01 -0700 Received: from hqmailsvr01.voltage.com (hqmailsvr01.voltage.com [172.16.0.22]) by mail.voltage.com with ESMTP id vgnqar4fj-1; Wed, 06 Apr 2011 06:51:01 -0700 Received: from hqmailsvr01.voltage.com ([172.16.0.22]) by hqmailsvr01.voltage.com ([172.16.0.22]) with mapi; Wed, 6 Apr 2011 06:51:01 -0700 From: Tom Wu To: Nico Williams Date: Wed, 6 Apr 2011 06:50:59 -0700 Thread-Topic: [TLS] EAP-in-TLS and channel bindings Thread-Index: Acv0Wm9mxxVo0anBRrubd4jZ6MBZVwABU5+w Message-ID: References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-04-06_04:2011-04-06, 2011-04-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=1 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1104060059 Cc: "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 13:49:27 -0000 PiBBcyBJIGV4cGxhaW5lZDogdGhlIHBvaW50IGlzIHRvIGFsbG93IHBlb3BsZSB0byB1c2Ugd2hh dCB0aGV5IGhhdmUuDQo+IFRMUy1TUlAgZG9lcyBub3QgZG8gdGhhdC4gIEVBUC1pbi1UTFMgZG9l cy4NCg0KTm8sIG5vdCBmb3Igc3Ryb25nIHBhc3N3b3JkIHByb3RvY29scyBpdCBkb2Vzbid0LiAg SWYgSSBkb24ndCBoYXZlIEFBQSBzdXBwb3J0IGZvciBFQVAtRUtFIG9yIEVBUC1wd2QgcGFzc3dv cmQgZGF0YSwgSSBjYW4ndCB1c2UgZWl0aGVyIG9mIHRoZW0uDQoNClRvIHVzZSBFQVAtcHdkIGFu ZCBFQVAtRUtFLCBJIG5lZWQgdG8gd2FpdCBmb3IgbXkgQUFBIGJhY2tlbmQgdG8gc3VwcG9ydCBF S0UvcHdkIHBhc3N3b3JkIGRhdGEsIHBsdXMgSSBuZWVkIHRvIHdhaXQgZm9yIG15IFRMUyBzdGFj ayB0byBhZG9wdCBFQVAtaW4tVExTLiAgVG8gdXNlIFRMUy1TUlAsIEkgbmVlZCB0byB3YWl0IGZv ciBteSBBQUEgYmFja2VuZCB0byBzdXBwb3J0IFNSUCB2ZXJpZmllcnMsIGFuZCB0aGVuIEknbSBk b25lLCBzaW5jZSBteSBUTFMgc3RhY2sgbW9zdCBsaWtlbHkgYWxyZWFkeSBoYXMgVExTLVNSUCBz dXBwb3J0LiAgSSBzdXBwb3NlIGl0IGFsbCBkZXBlbmRzIG9uIHdoaWNoIHBhcnRzIG9mIHRoZSB1 c2VyJ3MgZW52aXJvbm1lbnQgeW91IGFzc3VtZSBhcmUgZml4ZWQgYW5kIHdoaWNoIG9uZXMgY2Fu IGJlIHVwZ3JhZGVkLg0KDQpUb20NCg== From ynir@checkpoint.com Wed Apr 6 06:51:53 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0507A3A6938 for ; Wed, 6 Apr 2011 06:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.56 X-Spam-Level: X-Spam-Status: No, score=-10.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNcM6zKdn4NB for ; Wed, 6 Apr 2011 06:51:52 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 1619F3A67B2 for ; Wed, 6 Apr 2011 06:51:51 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p36DrW4w013301; Wed, 6 Apr 2011 16:53:32 +0300 X-CheckPoint: {4D9C7E30-12-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 6 Apr 2011 16:53:32 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 6 Apr 2011 15:53:32 +0200 From: Yoav Nir To: "'Tom Wu'" , Nico Williams Date: Wed, 6 Apr 2011 15:53:30 +0200 Thread-Topic: [TLS] EAP-in-TLS and channel bindings Thread-Index: Acv0Wm9mxxVo0anBRrubd4jZ6MBZVwABU5+wAACBg4A= Message-ID: <006FEB08D9C6444AB014105C9AEB133F013ABE025E05@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.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 Cc: "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 13:51:53 -0000 I agree that if I were implementing EAP-in-TLS now, it would be more about = EAP-MSChapv2 than any of the good methods. Still, writing a plug-in for a Microsoft AAA server and for Windows XP/7 is= well-documented, and can be done without any further standards action.=20 -----Original Message----- From: Tom Wu [mailto:tom@voltage.com]=20 Sent: 06 April 2011 16:51 To: Nico Williams Cc: Yoav Nir; tls@ietf.org Subject: RE: [TLS] EAP-in-TLS and channel bindings > As I explained: the point is to allow people to use what they have. > TLS-SRP does not do that. EAP-in-TLS does. No, not for strong password protocols it doesn't. If I don't have AAA supp= ort for EAP-EKE or EAP-pwd password data, I can't use either of them. To use EAP-pwd and EAP-EKE, I need to wait for my AAA backend to support EK= E/pwd password data, plus I need to wait for my TLS stack to adopt EAP-in-T= LS. To use TLS-SRP, I need to wait for my AAA backend to support SRP verif= iers, and then I'm done, since my TLS stack most likely already has TLS-SRP= support. I suppose it all depends on which parts of the user's environmen= t you assume are fixed and which ones can be upgraded. Tom =04 jy u $> :-jT r ! =1A= From nico@cryptonector.com Wed Apr 6 07:41:55 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3411428C0F3 for ; Wed, 6 Apr 2011 07:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9b3Vus9xkTGI for ; Wed, 6 Apr 2011 07:41:54 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 95A4828C0DB for ; Wed, 6 Apr 2011 07:41:54 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 97BBF59805F for ; Wed, 6 Apr 2011 07:43:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=aZrYNhV7Tm07eo6Cw+bry VkbPG9FEduKLduGm2v6Sk4l8AuhohNmYb/oFwohNkT2ajgxQXY1GAChlbIVRUozP 4wzsM0wsPkQFVu9fNyGPA9kbj6PfETt+zVud1s1cUfXS28UXhMVt8WHIl1lfrxrr 5auA+x46dkgJnsgAxDT2ko= 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; s=cryptonector.com; bh=B/u8d3gKSBUChUsw/LO+ coY9AuI=; b=DyZVNFcMJAlBvT7LPqwiRTlZALAyoiDf3iAqjqkTWnhkCt7nL2Ax WVptBmy7W8tKj8IoQR5pYSHxN++GQE/cuz9m45mNOWqOfCYO/+tV+ooKAo163DLt 8L8ok+i2R3CQqwjeOilVI5jsJU+qckKM30baUyDP4H127fCFHcmnhvM= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 6B835598057 for ; Wed, 6 Apr 2011 07:43:38 -0700 (PDT) Received: by vxg33 with SMTP id 33so1415728vxg.31 for ; Wed, 06 Apr 2011 07:43:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.18 with SMTP id bk18mr1458410vdb.270.1302101017851; Wed, 06 Apr 2011 07:43:37 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Wed, 6 Apr 2011 07:43:37 -0700 (PDT) In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F013ABE025E04@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.com> <006FEB08D9C6444AB014105C9AEB133F013ABE025E04@il-ex01.ad.checkpoint.com> Date: Wed, 6 Apr 2011 09:43:37 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 14:41:55 -0000 On Wed, Apr 6, 2011 at 8:50 AM, Yoav Nir wrote: > I don't think AAA deployments are going to send SRP verifiers to the servers. They implement a pluginnable platform for all kinds of EAP methods, and you can use any EAP method that you have a plug-in for. Using EAP with RADIUS is defined in RFC 4072. Great point. Password verifiers _are_ security-sensitive. Nico -- From nico@cryptonector.com Wed Apr 6 07:46:37 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CB8428C10C for ; Wed, 6 Apr 2011 07:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPy3HV4n9D2o for ; Wed, 6 Apr 2011 07:46:36 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id AC87A28C103 for ; Wed, 6 Apr 2011 07:46:36 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id C4BB654077 for ; Wed, 6 Apr 2011 07:48:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=TokbKA2lHAROcIGEy5uP28o+5F8O4egO7FIBrsAVpSF/ 0ZELDdKOsRuGApafFogDjxcaJSVUK8uQd66N8UIJSKobF/pgvFSsQCKZo3af6IG6 +WvaYPbOnvWFpjlKkKkVgCgq6xwMlUblz56bceYjk8tYm7TgW55kJc3yjVNDcFQ= 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=Uya2BbEGCjM/DZdo8FNszyEFOxU=; b=fhJxpjzCeQR UlUTBIu9L0kKeksCucd8S/Pfbo6L8q1dQflzZoacCxu9BvbsZXomQQzyiBK5bFgD XE6/V021pseVioUh5Nq600kYumGVwqR+Tc+nlTdQgHLdAkROsxAtoAoBWQpus3Lb kfuQjkuZjo7XY6+zhFGPcZbd8ifH9QFk= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 92B7954075 for ; Wed, 6 Apr 2011 07:48:20 -0700 (PDT) Received: by vxg33 with SMTP id 33so1421374vxg.31 for ; Wed, 06 Apr 2011 07:48:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.200 with SMTP id 8mr1572050vdg.70.1302101299888; Wed, 06 Apr 2011 07:48:19 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Wed, 6 Apr 2011 07:48:19 -0700 (PDT) In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.com> Date: Wed, 6 Apr 2011 09:48:19 -0500 Message-ID: From: Nico Williams To: Tom Wu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 14:46:37 -0000 On Wed, Apr 6, 2011 at 8:50 AM, Tom Wu wrote: >> As I explained: the point is to allow people to use what they have. >> TLS-SRP does not do that. =C2=A0EAP-in-TLS does. > > No, not for strong password protocols it doesn't. =C2=A0If I don't have A= AA support for EAP-EKE or EAP-pwd password data, I can't use either of them= . You might have AAA support but not have verifiers, and you could acquire verifiers slowly, over time, as users change their passwords. Also, ZKPPs benefit primarily those who can't bootstrap trust into the devices where the passwords are typed in. In many enterprises that's not an issue. And then there's the ZKPP password verifiers being security-sensitive (since they are subject to off-line dictionary attacks), so giving every TLS server access to those is a non-starter. You _should_ want EAP-in-TLS for that reason alone! Nico -- From evnikita2@gmail.com Wed Apr 6 07:42:00 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5510528C105; Wed, 6 Apr 2011 07:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHYmvmhRVMjn; Wed, 6 Apr 2011 07:41:59 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 22C7F28C103; Wed, 6 Apr 2011 07:41:58 -0700 (PDT) Received: by bwz13 with SMTP id 13so1374583bwz.31 for ; Wed, 06 Apr 2011 07:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:reply-to:user-agent :mime-version:to:cc:subject:content-type; bh=gu9kDo23kN3DYT/9wL9hdavxuna3uNZUmrFdqZTTCMA=; b=d+ItRgu0XrQJqvJ1SkhV4YPj/zlaF8OqTx3JdLPAvNkfHEsVBnFnwA1uxKPX7118d2 HPZ3LRc13FvxOBVjjqytt27TZV6BfNuMZw3/gsebjl0mGgZ4qXRZawpR+/caihR7pwT5 c91hH56rCCryhXaEKUhUqlDdNZjeqlZz/4Mrg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :content-type; b=q/me3P9LGMZ4ZxbQ/8F2veTQymvGMDPLxYmaMHLG4uTzGLMlqEaomoV51cmI6rp5FO KcbgJa+0rA5+0aw8DuGqx3zk3gjJfg00XxP+lpqEFFkMUl8nM+iE4W61Xxfvh7WVkIuJ UPf8EeQp2KmvUDw/kIFK4EzuKKi1/eB9+X0rc= Received: by 10.204.34.73 with SMTP id k9mr985088bkd.189.1302101022285; Wed, 06 Apr 2011 07:43:42 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id q18sm400730bka.15.2011.04.06.07.43.40 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 07:43:41 -0700 (PDT) Message-ID: <4D9C7C41.2050200@gmail.com> Date: Wed, 06 Apr 2011 17:44:17 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "uri-review@ietf.org" , ietf-pop3ext@imc.org, tls@ietf.org Content-Type: multipart/alternative; boundary="------------050102050104080407070903" X-Mailman-Approved-At: Wed, 06 Apr 2011 08:31:17 -0700 Subject: [TLS] Review request for draft-yevstifeyev-pops-uri-scheme X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: draft-yevstifeyev-pops-uri-scheme@tools.ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 14:42:00 -0000 This is a multi-part message in MIME format. --------------050102050104080407070903 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello all, I'm writing to request the review and comments on draft-yevstifeyev-pops-uri-scheme, that can be found here: http://tools.ietf.org/html/draft-yevstifeyev-pops-uri-scheme-03 This document specifies the pop3s (POP3 over TLS) protocol, that has been in wide use for quite a long time. It also defines the new 'pops' URI scheme, used for referencing POP3 mailboxes accessible via pop3s protocol. Please provide your comments sent to draft-yevstifeyev-pops-uri-scheme@tools.ietf.org and copied to tls@ietf.org, ietf-pop3ext@imc.org and uri-review@ietf.org. (Just use 'Reply all' to answer this message.) Thanks, Mykyta Yevstifeyev --------------050102050104080407070903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello all,

I'm writing to request the review and comments on draft-yevstifeyev-pops-uri-scheme, that can be found here:

http://tools.ietf.org/html/draft-yevstifeyev-pops-uri-scheme-03

This document specifies the pop3s (POP3 over TLS) protocol, that has been in wide use for quite a long time.  It also defines the new 'pops' URI scheme, used for referencing POP3 mailboxes accessible via pop3s protocol.

Please provide your comments sent to draft-yevstifeyev-pops-uri-scheme@tools.ietf.org and copied to tls@ietf.org, ietf-pop3ext@imc.org and uri-review@ietf.org.  (Just use 'Reply all' to answer this message.)

Thanks,
Mykyta Yevstifeyev
 --------------050102050104080407070903-- From hovav@eng.ucsd.edu Wed Apr 6 16:44:02 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C999F3A6820 for ; Wed, 6 Apr 2011 16:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aFZ0t7d1YcJ for ; Wed, 6 Apr 2011 16:44:02 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 4489D3A6801 for ; Wed, 6 Apr 2011 16:44:02 -0700 (PDT) Received: by pvh1 with SMTP id 1so919800pvh.31 for ; Wed, 06 Apr 2011 16:45:46 -0700 (PDT) Received: by 10.143.154.1 with SMTP id g1mr194015wfo.362.1302133546056; Wed, 06 Apr 2011 16:45:46 -0700 (PDT) MIME-Version: 1.0 Sender: hovav@eng.ucsd.edu Received: by 10.68.41.193 with HTTP; Wed, 6 Apr 2011 16:45:25 -0700 (PDT) In-Reply-To: <20110405232948.inrkf05c84kgcosw@webmail.cs.auckland.ac.nz> References: <20110405232948.inrkf05c84kgcosw@webmail.cs.auckland.ac.nz> From: Hovav Shacham Date: Wed, 6 Apr 2011 16:45:25 -0700 X-Google-Sender-Auth: ynFIk78FYtWELReUqlKs-8bKWGQ Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001636e0a87c767b4604a04897cd Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 23:44:02 -0000 --001636e0a87c767b4604a04897cd Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 5, 2011 at 4:29 AM, Peter Gutmann wrote: > So not only is "DSA2" nonexistent, but for all intents and purposes DSA is > nonexistent as well. > How about we remove DSA support from TLS, then? -hs. --001636e0a87c767b4604a04897cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Apr 5, 2011 at 4:29 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
So not=A0only is "DSA2" nonexistent, but for all intents and purp= oses DSA is
nonexistent as well.

How about we remov= e DSA support from TLS, then?

-hs.
--001636e0a87c767b4604a04897cd-- From pgut001@login01.cs.auckland.ac.nz Wed Apr 6 20:48:22 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636EA3A69A4 for ; Wed, 6 Apr 2011 20:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aTRWpNugnur for ; Wed, 6 Apr 2011 20:48:20 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 932253A69A7 for ; Wed, 6 Apr 2011 20:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1302148205; x=1333684205; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20hovav@cs.ucsd.edu,=20tls@ietf.org|Subject:=20Re: =20[TLS]=20DSS=20with=20other=20than=20SHA-1=20algorithms |In-Reply-To:=20|Message-Id:=20|Date:=20Thu,=2007=20Apr=202011=2015:50:01 =20+1200; bh=RRzRd0Fd0chhmc/q4srkGNFhX4EN6Y9Qr4xFkDKeHI4=; b=LucqTfeolgwu7i4gxGm9wGTrdAi071lgHQjrPXFn7Q8wnpLHTjdJfDbR zUFkxJ4P5wQBdBHqwkvzVnoVnDqml19OLkVjbrCXF9p2gIxX7rLk7PX1l x02gYdnpQhhIJGVl8yaKkN0XBDSrtXVbmOMMYuyLVwZ0mPEzs5tdQozPg A=; X-IronPort-AV: E=Sophos;i="4.63,314,1299409200"; d="scan'208";a="55643713" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Apr 2011 15:50:02 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q7gEM-0006cq-GO; Thu, 07 Apr 2011 15:50:02 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q7gEL-0001Q1-Vi; Thu, 07 Apr 2011 15:50:01 +1200 From: Peter Gutmann To: hovav@cs.ucsd.edu, tls@ietf.org In-Reply-To: Message-Id: Date: Thu, 07 Apr 2011 15:50:01 +1200 Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 03:48:22 -0000 Hovav Shacham writes: >How about we remove DSA support from TLS, then? Possibly a bit extreme, but we could at least mark it "historical" or "deprecated" or something. In fact we could do that for an awful lot of existing cipher suites. Note that this isn't changing the standard in any way, it's just documenting what's already the norm among implementations. If a cipher suite's been in there for ten years and there are, approximately, zero cases of it being used, then saying "Don't bother with this one" in order to help guide implementers seems sensible. Peter. From simon@josefsson.org Wed Apr 6 23:14:37 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CB0D3A6863 for ; Wed, 6 Apr 2011 23:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.147 X-Spam-Level: X-Spam-Status: No, score=-103.147 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0AHf9filrWJ for ; Wed, 6 Apr 2011 23:14:36 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id B44923A680B for ; Wed, 6 Apr 2011 23:14:35 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p376FGYf031601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Apr 2011 08:15:19 +0200 From: Simon Josefsson To: Peter Gutmann References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110407:tls@ietf.org::8hKmi8+WHjaDCg9Z:1Frr X-Hashcash: 1:22:110407:pgut001@cs.auckland.ac.nz::6I/OCHLKR0C3U5Us:2vgp X-Hashcash: 1:22:110407:hovav@cs.ucsd.edu::bCrn7eZ1Xk2E416u:JlRo Date: Thu, 07 Apr 2011 08:15:16 +0200 In-Reply-To: (Peter Gutmann's message of "Thu, 07 Apr 2011 15:50:01 +1200") Message-ID: <878vvmy4cr.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 06:14:37 -0000 Peter Gutmann writes: > Hovav Shacham writes: > >>How about we remove DSA support from TLS, then? > > Possibly a bit extreme, but we could at least mark it "historical" or > "deprecated" or something. In fact we could do that for an awful lot of > existing cipher suites. Note that this isn't changing the standard in any > way, it's just documenting what's already the norm among implementations. If > a cipher suite's been in there for ten years and there are, approximately, > zero cases of it being used, then saying "Don't bother with this one" in order > to help guide implementers seems sensible. Unfortunately I think DSA is still mandatory-to-implement in some protocols. That makes it a bit more complicated, but still doable. /Simon From n.mavrogiannopoulos@gmail.com Thu Apr 7 00:53:52 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597873A69F6 for ; Thu, 7 Apr 2011 00:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hq1JSNfwunFM for ; Thu, 7 Apr 2011 00:53:51 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 7F68D3A67F3 for ; Thu, 7 Apr 2011 00:53:51 -0700 (PDT) Received: by wwa36 with SMTP id 36so1894787wwa.13 for ; Thu, 07 Apr 2011 00:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=364Bnnlcw4GJNixVi5dLt0lEV76GC6hJSVva5FRa58w=; b=bFXpSuaPoX7A0wsiXPbzoZNEj9iBn88PrF9OSmClOQKt1MdZEWvP0qFSaXIJLxTeLy 3nSoJNITAPJPGNKo5GrLhm2LdFlYHZl4JJyYW8FaRvyGAEEj1uK3q5Zfav9BxGcLEtJG AQZuChNUBtmG8aTwgHRnaDqmbaynKz8nJH93A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=DnBQV9uDo7GYyBDzUfcULPm9MItkr8xKmsRDbfOWQAFbxLokKGatFfay7ANEyZBFUZ +yMBgfYPu/J0pdbGb6eQh8JZTy6oh+Uz7rPLQSc+1v+RqAeakTaf8JXfCuFlZYIfuarD A4Z3zHJxDK/8oolv4SZEZtLhpchz6hKkRxHG0= Received: by 10.216.82.142 with SMTP id o14mr489599wee.114.1302162934495; Thu, 07 Apr 2011 00:55:34 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id j49sm665304wer.14.2011.04.07.00.55.31 (version=SSLv3 cipher=OTHER); Thu, 07 Apr 2011 00:55:32 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4D9D6DF2.4070801@gnutls.org> Date: Thu, 07 Apr 2011 09:55:30 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Yoav Nir References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.com> <006FEB08D9C6444AB014105C9AEB133F013ABE025E05@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F013ABE025E05@il-ex01.ad.checkpoint.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 07:53:52 -0000 On 04/06/2011 03:53 PM, Yoav Nir wrote: > I agree that if I were implementing EAP-in-TLS now, it would be more > about EAP-MSChapv2 than any of the good methods. Then it looks more that EAP-in-TLS is to be used as a by-pass method to include weak authentication algorithms, that would have never be approved by this WG. regards, Nikos From ynir@checkpoint.com Thu Apr 7 11:07:10 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065EF28C0E4 for ; Thu, 7 Apr 2011 11:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWYQMY0-0DWx for ; Thu, 7 Apr 2011 11:07:09 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 0BFBD28C0DB for ; Thu, 7 Apr 2011 11:07:08 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p37I8VBt026787; Thu, 7 Apr 2011 21:08:31 +0300 X-CheckPoint: {4D9E0B6D-E-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 7 Apr 2011 21:08:31 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 7 Apr 2011 20:08:31 +0200 From: Yoav Nir To: Nikos Mavrogiannopoulos Date: Thu, 7 Apr 2011 20:08:29 +0200 Thread-Topic: [TLS] EAP-in-TLS and channel bindings Thread-Index: Acv1Tsz3xBpSrlkwS5SBO7fQlJDevg== Message-ID: <48F16295-4EC7-4C7F-938A-D56D97EB2412@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.com> <006FEB08D9C6444AB014105C9AEB133F013ABE025E05@il-ex01.ad.checkpoint.com> <4D9D6DF2.4070801@gnutls.org> In-Reply-To: <4D9D6DF2.4070801@gnutls.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 Cc: "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 18:07:10 -0000 On Apr 7, 2011, at 10:55 AM, Nikos Mavrogiannopoulos wrote: > On 04/06/2011 03:53 PM, Yoav Nir wrote: >=20 >> I agree that if I were implementing EAP-in-TLS now, it would be more >> about EAP-MSChapv2 than any of the good methods. >=20 > Then it looks more that EAP-in-TLS is to be used as a by-pass method to > include weak authentication algorithms, that would have never be > approved by this WG. I don't see why. EAP-MSChapv2 is in wide use, and is not considered broken = when used inside an encrypted transport like TLS or IKE. Also, creating EAP-EKE/PWD/SRP plug-ins for AAA servers is well documented,= and does not require work by any IETF working group. Yoav= From n.mavrogiannopoulos@gmail.com Fri Apr 8 08:44:22 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99C713A6905 for ; Fri, 8 Apr 2011 08:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96axrL7d1-0R for ; Fri, 8 Apr 2011 08:44:21 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 350F33A6819 for ; Fri, 8 Apr 2011 08:44:20 -0700 (PDT) Received: by wwa36 with SMTP id 36so3098867wwa.13 for ; Fri, 08 Apr 2011 08:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=QixBc9P67Iw/D6xFfS+WFLnBoTouT9sjPdnAQ9QFArM=; b=oqYa2R8l4ftjT9nxX6whiJTI6akwhsrF+7/1ZagbxyzmOKF+Gx+rW+XbYS3ditT0Nc Iud4A2axGD0oLy6s72AKIGCbHM+EykQprTjNXffhtOQwspafSX14IYqjB4S7aILNFSn+ cCqXGvR9YXHbw5aq5JF3y6wZSfLIEOZOIY1RI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=KrwlQFtt4Ih/9nui91L19sXmAqQHBzL38L2dhevUvECeUeGiwuKN1opp6l10INoHiA 8qnHx1la7FRpNz2JtkB6Cl+8wDFnC9EAUatBblZ8QVJPkkh1sTPvyFJK9eFogzPiemCz WrGPmyAckrDKuIoD0nUhy1M/2eOPqurd/buhY= Received: by 10.227.21.217 with SMTP id k25mr2379483wbb.135.1302277565780; Fri, 08 Apr 2011 08:46:05 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id e13sm1787402wbi.6.2011.04.08.08.46.00 (version=SSLv3 cipher=OTHER); Fri, 08 Apr 2011 08:46:03 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4D9F2DB8.8070506@gnutls.org> Date: Fri, 08 Apr 2011 17:46:00 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Yoav Nir References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.com> <006FEB08D9C6444AB014105C9AEB133F013ABE025E05@il-ex01.ad.checkpoint.com> <4D9D6DF2.4070801@gnutls.org> <48F16295-4EC7-4C7F-938A-D56D97EB2412@checkpoint.com> In-Reply-To: <48F16295-4EC7-4C7F-938A-D56D97EB2412@checkpoint.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:44:22 -0000 On 04/07/2011 08:08 PM, Yoav Nir wrote: > > On Apr 7, 2011, at 10:55 AM, Nikos Mavrogiannopoulos wrote: > >> On 04/06/2011 03:53 PM, Yoav Nir wrote: >> >>> I agree that if I were implementing EAP-in-TLS now, it would be more >>> about EAP-MSChapv2 than any of the good methods. >> >> Then it looks more that EAP-in-TLS is to be used as a by-pass method to >> include weak authentication algorithms, that would have never be >> approved by this WG. > > I don't see why. EAP-MSChapv2 is in wide use, and is not considered broken when used inside an encrypted transport like TLS or IKE. > Also, creating EAP-EKE/PWD/SRP plug-ins for AAA servers is well documented, and does not require work by any IETF working group. Considering it broken or not depends on your attack scenario and the deployment scenario. By the definition of EAP-TLS, you know neither. If for example I use anonymous DH and perform mutual authentication of peers using EAP and mschapv2, then it is broken. I suppose there several scenarios where one can combine that and have a useful protocol. That is the reason the original TLS did not allow many extensions. To contain the security decisions to protocol designers, not individual administrators. regards, Nikos From nico@cryptonector.com Fri Apr 8 11:52:40 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9240B3A69B4 for ; Fri, 8 Apr 2011 11:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGJ1F1X3sNAn for ; Fri, 8 Apr 2011 11:52:39 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id 6FD553A6962 for ; Fri, 8 Apr 2011 11:52:36 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id D56ED1F0086 for ; Fri, 8 Apr 2011 11:54:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=dWP9gR1bP/ZAOpg5J5AkT TfZSurSTqXzIAmMHP0KSxwD6YIJqHQqm5GhD/v1MDneBYeUHfz7dA+fpq64IE23W FJxn10Mm4EO6uhD4VhbNLpo0yCONL9q9MpL+fEfvcHa/OYVY6JpRNBBmeMHiTxSK 5RHkFRiaTjP8gnYmwyUBeU= 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; s=cryptonector.com; bh=rIcs1ArIq9+SOIHjD2/D n3gBacQ=; b=qesTauVlP15s7d1TPQ1PrlxToKWyWzflLWpp1Zzop/sMyNt03MAu mcuMg2aYyzFU/kAgeOa8ruZCqBRDxlKSv+4S18vz8YTEFJUMxJyZ/wsI1XueuVRV Iq/YvGXyt9RgV2jyTHFeyQF6me6yf3nU48/awcdUPPaifUrZVaYv4gg= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 9EB271F0085 for ; Fri, 8 Apr 2011 11:54:21 -0700 (PDT) Received: by vxg33 with SMTP id 33so3565266vxg.31 for ; Fri, 08 Apr 2011 11:54:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.130 with SMTP id l2mr3855519vdv.14.1302288861035; Fri, 08 Apr 2011 11:54:21 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Fri, 8 Apr 2011 11:54:20 -0700 (PDT) In-Reply-To: <4D9F2DB8.8070506@gnutls.org> References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.com> <006FEB08D9C6444AB014105C9AEB133F013ABE025E05@il-ex01.ad.checkpoint.com> <4D9D6DF2.4070801@gnutls.org> <48F16295-4EC7-4C7F-938A-D56D97EB2412@checkpoint.com> <4D9F2DB8.8070506@gnutls.org> Date: Fri, 8 Apr 2011 13:54:20 -0500 Message-ID: From: Nico Williams To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 18:52:40 -0000 On Fri, Apr 8, 2011 at 10:46 AM, Nikos Mavrogiannopoulos wrote: > On 04/07/2011 08:08 PM, Yoav Nir wrote: >> I don't see why. EAP-MSChapv2 is in wide use, and is not considered broken when used inside an encrypted transport like TLS or IKE. >> Also, creating EAP-EKE/PWD/SRP plug-ins for AAA servers is well documented, and does not require work by any IETF working group. > > Considering it broken or not depends on your attack scenario and the > deployment scenario. By the definition of EAP-TLS, you know neither. > > If for example I use anonymous DH and perform mutual authentication of > peers using EAP and mschapv2, then it is broken. I suppose there > several scenarios where one can combine that and have a useful > protocol. That is the reason the original TLS did not allow > many extensions. To contain the security decisions to protocol > designers, not individual administrators. IMO: a) EAP methods that support cryptographic binding should/must be used, b) EAP cryptographic binding should/must be used to do RFC5056 channel binding to the TLS connection's tls-unique channel bindings. The question is whether (a) and (b) are a SHOULD or a MUST, and if it is not a MUST then what mitigation might or might not be feasible or acceptable. Note though that if RFC5056 channel binding is done from the EAP method to the TLS connection, then your objection is fully dealt with. And see the Subject: line in the header :) :) Simon brought up channel binding for a reason, namely, that he had the same concerns as you do. I have exactly the same concerns as well. However, Simon and I believe there's a solution: RFC5056 channel binding. If you believe that channel binding is not a solution, please say so and let's figure out why that might or might not be the case. Nico -- From jsalowey@cisco.com Sun Apr 10 14:24:00 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B53483A69C0 for ; Sun, 10 Apr 2011 14:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8p3MErxBOwR4 for ; Sun, 10 Apr 2011 14:23:59 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id EBBEE3A69B4 for ; Sun, 10 Apr 2011 14:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=999; q=dns/txt; s=iport; t=1302470640; x=1303680240; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=qBVQKSwg1kku3W4rp5DpMZCVewksiw/gqzB8wOWRoS0=; b=C+5jY0zc93KY/DpLrEv4ipUmBfxcpAvRnHOd0nPvZbeXPFxTERE1rXip zOwtuMchiEgutJ84eL6nm9PgKOPcdodcafQUaw8pYr5MvrkL/ntPh1DyQ /4YcIHfNpwB+Q2T/r18tC9tJOl/UFll0TkBaW37Up7tydUz3ojARmWJlX o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsIACofok2rRDoI/2dsb2JhbACYf40Zd6V1mwGFbgSFW4d9g2o X-IronPort-AV: E=Sophos;i="4.63,335,1299456000"; d="scan'208";a="293264450" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 10 Apr 2011 21:23:59 +0000 Received: from [10.33.251.67] ([10.33.251.67]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3ALNxXK003548 for ; Sun, 10 Apr 2011 21:23:59 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Apr 2011 14:25:44 -0700 Message-Id: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 21:24:00 -0000 Sean has asked that we update the working group charter. An overview of = the update was given at IETF 80. Below is a proposed text along the = lines of what was discussed. Please send comments on this text to the = list. =20 Thanks, Joe The TLS Working Group was established in 1996 to standardize a 'transport layer' security protocol. The working group began with SSL version 3.0. The TLS Working Group has completed a series of specifications that describe the Transport Layer Security protocol versions 1.0, 1.1, and 1.2, extensions to the protocol, and new ciphersuites to be used with TLS. The primary goals of the WG are to maintain: - The TLS protocol, RFC 5346; - The TLS extension definitions, RFC 6066; - The DTLS protocol, RFC 4347bis. The WG will attempt to avoid gratuitous changes to these protocols. The secondary goals of the WG are to publish: - Recommendations for use of TLS; - Extensions to TLS and DTLS; and, - Cipher suites.= From robert.cragie@gmail.com Sun Apr 10 15:03:38 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3C9B3A69CC for ; Sun, 10 Apr 2011 15:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=1.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iV-W-7JpqycF for ; Sun, 10 Apr 2011 15:03:37 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A573F3A69C6 for ; Sun, 10 Apr 2011 15:03:37 -0700 (PDT) Received: by iwn39 with SMTP id 39so6284112iwn.31 for ; Sun, 10 Apr 2011 15:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=m4JCkxUVHw3VSnfsJhrXJSruT4o7MobYZ1CaFQmmDO0=; b=GGt1zxyVzDpKnWTq+UjapfWInkL3HJLDxRDMJljiqf8qY5jccndDJalRsWDx8pyFDT PBk8b5uuPb7kJFERy3idSR0FHH+yzo24tRUoLysq3estQ4NDBquIIbyZW/NMiGRV1pD5 rnWKYGkZw3yXyCuQ9mI2a4bvo8norlcMEU9tM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ccAaWhBe412/9tYLqX85eEOYtqOrxsik6E22V0JtS1rTsae0xrxYxiWRzTZVOnH+EN YA1TjDAZBHpMfqw2Ag2FPHJ2az51e8Eu+2892OeKAaY05xan4dqFw7Sh0tmcqehfF/QN Wq/8rE0el5GebCgjJWktxXVResx1eRNaz6EKo= MIME-Version: 1.0 Received: by 10.231.142.38 with SMTP id o38mr4717281ibu.63.1302473017344; Sun, 10 Apr 2011 15:03:37 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.231.11.8 with HTTP; Sun, 10 Apr 2011 15:03:37 -0700 (PDT) Received: by 10.231.11.8 with HTTP; Sun, 10 Apr 2011 15:03:37 -0700 (PDT) In-Reply-To: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> References: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> Date: Sun, 10 Apr 2011 23:03:37 +0100 X-Google-Sender-Auth: idwMjE2B0y-_XP_rJBLq2JWX9hU Message-ID: From: Robert Cragie To: Joe Salowey Content-Type: multipart/alternative; boundary=0016e64603a08743cf04a097a170 Cc: tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 22:03:38 -0000 --0016e64603a08743cf04a097a170 Content-Type: text/plain; charset=ISO-8859-1 That should be RFC 5246. Robert On 10 Apr 2011 22:25, "Joe Salowey" wrote: Sean has asked that we update the working group charter. An overview of the update was given at IETF 80. Below is a proposed text along the lines of what was discussed. Please send comments on this text to the list. Thanks, Joe The TLS Working Group was established in 1996 to standardize a 'transport layer' security protocol. The working group began with SSL version 3.0. The TLS Working Group has completed a series of specifications that describe the Transport Layer Security protocol versions 1.0, 1.1, and 1.2, extensions to the protocol, and new ciphersuites to be used with TLS. The primary goals of the WG are to maintain: - The TLS protocol, RFC 5346; - The TLS extension definitions, RFC 6066; - The DTLS protocol, RFC 4347bis. The WG will attempt to avoid gratuitous changes to these protocols. The secondary goals of the WG are to publish: - Recommendations for use of TLS; - Extensions to TLS and DTLS; and, - Cipher suites. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --0016e64603a08743cf04a097a170 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

That should be RFC 5246.

Robert

On 10 Apr 2011 22:25, "Joe Salowey" = <jsalowey@cisco.com> wrote:=

Sean has asked that we update the working group charter. =A0An over= view of the update was given at IETF 80. =A0Below is a proposed text along = the lines of what was discussed. =A0 Please send comments on this text to t= he list.

Thanks,

Joe


The TLS Working Group was established in 1996 to standardize a
'transport layer' security protocol. The working group began with S= SL
version 3.0. The TLS Working Group has completed a series of
specifications that describe the Transport Layer Security protocol
versions 1.0, 1.1, and 1.2, extensions to the protocol, and new
ciphersuites to be used with TLS.

The primary goals of the WG are to maintain:
=A0- The TLS protocol, RFC 5346;
=A0- The TLS extension definitions, RFC 6066;
=A0- The DTLS protocol, RFC 4347bis.
The WG will attempt to avoid gratuitous changes to these protocols.

The secondary goals of the WG are to publish:
=A0- Recommendations for use of TLS;
=A0- Extensions to TLS and DTLS; and,
=A0- Cipher suites.
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--0016e64603a08743cf04a097a170-- From paul.hoffman@vpnc.org Sun Apr 10 16:10:16 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D2913A6A15 for ; Sun, 10 Apr 2011 16:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.136 X-Spam-Level: X-Spam-Status: No, score=-102.136 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGii0bnMrqE2 for ; Sun, 10 Apr 2011 16:10:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 42AEF3A6A0F for ; Sun, 10 Apr 2011 16:10:15 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3ANABAG025304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 10 Apr 2011 16:10:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> Date: Sun, 10 Apr 2011 16:10:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> To: Joe Salowey X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 23:10:16 -0000 On Apr 10, 2011, at 2:25 PM, Joe Salowey wrote: > The primary goals of the WG are to maintain: > - The TLS protocol, RFC 5346; That *could* be read to mean that the WG is not supposed to work on TLS = 1.3. If that is the intention, then the charter should say so = explicitly. If it is not the intention, than the charter should say "The = TLS 1.2 protocol and its successors". > - The TLS extension definitions, RFC 6066; That document does not define all extensions. Also, that document = probably does not need maintenance outside what is covered in the second = bullet in the secondary goals. Please consider removinv this bullet. > - The DTLS protocol, RFC 4347bis. That specific document will hopefully be an RFC within a few months. = Similar to the above, maybe say "The DTLS 1.2 protocol and its = successors". > The WG will attempt to avoid gratuitous changes to these protocols. >=20 > The secondary goals of the WG are to publish: > - Recommendations for use of TLS; > - Extensions to TLS and DTLS; and, > - Cipher suites. --Paul Hoffman From ekr@rtfm.com Sun Apr 10 21:48:38 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7083A68A2 for ; Sun, 10 Apr 2011 21:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.913 X-Spam-Level: X-Spam-Status: No, score=-102.913 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyXsVzCVj1OQ for ; Sun, 10 Apr 2011 21:48:37 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8C96C3A69CD for ; Sun, 10 Apr 2011 21:48:37 -0700 (PDT) Received: by iwn39 with SMTP id 39so6525085iwn.31 for ; Sun, 10 Apr 2011 21:48:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.140.193 with SMTP id l1mr7227798icu.119.1302497317390; Sun, 10 Apr 2011 21:48:37 -0700 (PDT) Received: by 10.42.241.5 with HTTP; Sun, 10 Apr 2011 21:48:37 -0700 (PDT) In-Reply-To: References: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> Date: Sun, 10 Apr 2011 21:48:37 -0700 Message-ID: From: Eric Rescorla To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 04:48:38 -0000 On Sun, Apr 10, 2011 at 4:10 PM, Paul Hoffman wrote= : > On Apr 10, 2011, at 2:25 PM, Joe Salowey wrote: > >> The primary goals of the WG are to maintain: >> =A0- The TLS protocol, RFC 5346; > > That *could* be read to mean that the WG is not supposed to work on TLS 1= .3. If that is the intention, then the charter should say so explicitly. I hope that's how it should be read. I don't see any pressing need for the TLS WG to do a TLS 1.3. >> =A0- The TLS extension definitions, RFC 6066; > > That document does not define all extensions. Also, that document probabl= y does not need maintenance outside what is covered in the second bullet in= the secondary goals. Please consider removinv this bullet. I'm fine with that. >> =A0- The DTLS protocol, RFC 4347bis. > > That specific document will hopefully be an RFC within a few months. Simi= lar to the above, maybe say "The DTLS 1.2 protocol and its successors". Yes, I agree that we should do to address that point. -Ekr From n.mavrogiannopoulos@gmail.com Sun Apr 10 23:38:33 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45973A6A8C for ; Sun, 10 Apr 2011 23:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tneIOs9tvvyQ for ; Sun, 10 Apr 2011 23:38:32 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6ECDB3A6A8B for ; Sun, 10 Apr 2011 23:38:32 -0700 (PDT) Received: by wyb29 with SMTP id 29so4973104wyb.31 for ; Sun, 10 Apr 2011 23:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=WqN0g4uKaOaQcxgjGXir65t8ZZN6m5JcLPXJoyEIP24=; b=LkVf6+/EOn/0jyBPiikGwGIDonWc2tZkGcfegzQn4YUhesbPa/Iz6RwvLLFPOL8l9G A7kHRW5aaeL0QzihAGtvFpM6H0bmrHblouLd3Xvn2/GQrSDDK1Nkp9utwc9pQDmKgZm8 gjw2uGv+mYVRPiXmfpbjQ8yht/cRKFTsFdzSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=MZJF19nuyRK9nhvvkMyX+xQGY5KI7LoO1rKeqK8UduW4lLmuilvXC4nkb8p0XmlaS/ 23t4bJ8JvZGfxiQGwFObbBO0faBNg9WB7UVVLMzbIYDGNRchd2Fgx7hOT+Ompu4lDKpR TZeQkk5CzV1Gn7aHC6/kHW0miLg7WlRa9OdMA= Received: by 10.216.134.230 with SMTP id s80mr4364701wei.74.1302503911746; Sun, 10 Apr 2011 23:38:31 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id j49sm2467963wer.38.2011.04.10.23.38.29 (version=SSLv3 cipher=OTHER); Sun, 10 Apr 2011 23:38:30 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4DA2A1E4.5020005@gnutls.org> Date: Mon, 11 Apr 2011 08:38:28 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Eric Rescorla References: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 06:38:33 -0000 On 04/11/2011 06:48 AM, Eric Rescorla wrote: > On Sun, Apr 10, 2011 at 4:10 PM, Paul Hoffman wrote: >> On Apr 10, 2011, at 2:25 PM, Joe Salowey wrote: >> >>> The primary goals of the WG are to maintain: >>> - The TLS protocol, RFC 5346; >> That *could* be read to mean that the WG is not supposed to work on TLS 1.3. If that is the intention, then the charter should say so explicitly. > I hope that's how it should be read. I don't see any pressing need for > the TLS WG to do a TLS 1.3. Over the years, I've kept a list of issues of TLS (apply to TLS 1.2). (I skip all the issues already reported by Peter Gutmann at: http://www.ietf.org/mail-archive/web/tls/current/msg07608.html ) * Renegotiation semantics are unclear. When one is supposed to do renegotiation? How to distinguish data before a renegotiation and after? (especially since application data are allowed to be processed during a renegotiation). See also http://www.ietf.org/mail-archive/web/tls/current/msg05607.html * RFC6066 Max fragment size cannot be used to increase the TLS fragment, thus punishing hardware accelerated implementations, that have to stick to the maximum 16k header. * The RFC6066 truncated HMAC extension is very limited as it only truncates to 80-bits. It could be very useful especially in DTLS where the fragment size is very limiting, but not in its current form. 80-bits should be enough for everybody is not very convincing. Common security levels should be allowed at least (64/80/96/128/192/256). This extension might belong to the core TLS protocol if it is ever made aware of security levels. * Short finished message signature fixed to 12 bytes. The provisioning of TLS 1.2 for ciphersuites to increase it was never used by ciphersuites that aimed high security levels (AES-256, HMAC-384), thus it is pretty much already obsolete. It seems the finished message size should be defined by the TLS protocol itself to be usable. (this is another argument of TLS being made aware of security levels). * TLS version negotiation. If 1.1 and 1.3 is implemented, then negotiation will always fail if talking to a 1.2 server. This requires a client to implement all possible TLS protocols instead of the latest and a fallback (e.g. TLS 1.0). * AEAD interface was defined only for stream ciphers. If a block cipher emerges for AEAD it will not be usable with TLS. * It is not known when is record version acceptable. Is a record version of 3.55 acceptable? Is 4.0 acceptable? What about 65.35? There should be at least a ranges of acceptable record version numbers (for the initial hello message). Thus for me there should be work to solve those issues. regards, Nikos From pgut001@login01.cs.auckland.ac.nz Mon Apr 11 01:33:47 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D59C3A6AA7 for ; Mon, 11 Apr 2011 01:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJe62KgV70+4 for ; Mon, 11 Apr 2011 01:33:46 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id D390A3A6AA6 for ; Mon, 11 Apr 2011 01:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1302510826; x=1334046826; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20ekr@rtfm.com,=20nmav@gnutls.org|Subject:=20Re:=20[ TLS]=20Proposed=20working=20group=20charter=20update|Cc: =20paul.hoffman@vpnc.org,=20tls@ietf.org|In-Reply-To:=20< 4DA2A1E4.5020005@gnutls.org>|Message-Id:=20|Date:=20Mon,=2011=20Apr =202011=2020:33:33=20+1200; bh=bwAZo9SUKutY6PO+DvGBcZqKslln70m8erRwTpwhZmg=; b=UjgOvb/5GB/M/oejkAABF3kBXkXvQYwjI475AMfNYVU1kVLs4zOMQHQ/ QV3xeypfPEGUw2LNBmvoBO//lWyoKJyPXnnVxmP6j8dTvrbc6CN3Eanat zxCViEHcht57hbbWMTEGjWc40XXojuOuRUicRHsx9yAgvnzcJOtP+Va9m U=; X-IronPort-AV: E=Sophos;i="4.63,338,1299409200"; d="scan'208";a="56238202" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Apr 2011 20:33:33 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q9CYv-0005kH-GZ; Mon, 11 Apr 2011 20:33:33 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q9CYv-0002hw-28; Mon, 11 Apr 2011 20:33:33 +1200 From: Peter Gutmann To: ekr@rtfm.com, nmav@gnutls.org In-Reply-To: <4DA2A1E4.5020005@gnutls.org> Message-Id: Date: Mon, 11 Apr 2011 20:33:33 +1200 Cc: paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 08:33:48 -0000 Nikos Mavrogiannopoulos writes: >* RFC6066 Max fragment size cannot be used to increase the TLS fragment, thus >punishing hardware accelerated implementations, that have to stick to the >maximum 16k header. Is there any server around that implements this? I know that some implementations advertise support for it, but I've never found anything where I could actually test my code (which has been commented out pretty much forever due to lack of anything else that does it). >* The RFC6066 truncated HMAC extension is very limited as it only truncates >to 80-bits. Since, according to the Wikipedia TLS implementation survey, there are precisely zero implementations of this, I don't think it matters much what it truncates to. >* Short finished message signature fixed to 12 bytes. The provisioning of TLS >1.2 for ciphersuites to increase it was never used by ciphersuites that aimed >high security levels (AES-256, HMAC-384), We kinda went through this one recently, but I agree that it should be the output size of the MAC used and not the IPsec cargo-cult 96 bits. >* AEAD interface was defined only for stream ciphers. If a block cipher >emerges for AEAD it will not be usable with TLS. Again, support for any kind of AEAD is practically nonexistent. We can solve this one if it ever becomes an issue. Peter. From n.mavrogiannopoulos@gmail.com Mon Apr 11 01:43:34 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5703A69E3 for ; Mon, 11 Apr 2011 01:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.066 X-Spam-Level: * X-Spam-Status: No, score=1.066 tagged_above=-999 required=5 tests=[AWL=-4.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_GUARANTEE1=4.533, FUZZY_GUARANTEE=1.252, MANGLED_GRNTEE=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6WZpVCvPCiY for ; Mon, 11 Apr 2011 01:43:34 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by core3.amsl.com (Postfix) with ESMTP id 183F23A69D2 for ; Mon, 11 Apr 2011 01:43:34 -0700 (PDT) Received: by pxi20 with SMTP id 20so3011545pxi.27 for ; Mon, 11 Apr 2011 01:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0vElELb2iwxzO7d7PBviSwSRVEmvAIpZXpQQ2SUANm0=; b=rVdF7eI83OxFhlphaFsk+6XahuCUYPaFo4Z6K5yGF0VVgCUztXUJpkiFL9U2nQ/sdg kLkCbneyvBKN96XqWDGdLF8MxWhmuHGZeQYlnsvOWJp2pKgbsyumP+Ia1TtXpfHwRfc5 zDk2r39eVA4I0eRLrh8oVTOOxhMgklWvkeysU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=inJ5JELtdVVMY+hnEUAoz3tUMA1qa0shIM5ECm6elBNlfEzrYdfIm7Uepr/j66Vb+X te7mxT7ZmN1qvPc4FNLyFTbLodSbNZy4oE4OD4XP+IEmGnmYwLzv21IDjIHPDjdhR3w0 25RPORmdWsCOdigM6ZCTuZQcPbZQIMmoiG1t4= MIME-Version: 1.0 Received: by 10.142.248.4 with SMTP id v4mr5250287wfh.145.1302511414211; Mon, 11 Apr 2011 01:43:34 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.68.48.105 with HTTP; Mon, 11 Apr 2011 01:43:34 -0700 (PDT) In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.com> <006FEB08D9C6444AB014105C9AEB133F013ABE025E05@il-ex01.ad.checkpoint.com> <4D9D6DF2.4070801@gnutls.org> <48F16295-4EC7-4C7F-938A-D56D97EB2412@checkpoint.com> <4D9F2DB8.8070506@gnutls.org> Date: Mon, 11 Apr 2011 10:43:34 +0200 X-Google-Sender-Auth: KToyT3K65Ko2sIalQoJtRg4wV-A Message-ID: From: Nikos Mavrogiannopoulos To: Nico Williams Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 08:43:34 -0000 On Fri, Apr 8, 2011 at 8:54 PM, Nico Williams wrote= : >> If for example I use anonymous DH and perform mutual authentication of >> peers using EAP and mschapv2, then it is broken. I suppose there >> several scenarios where one can combine that and have a useful >> protocol. That is the reason the original TLS did not allow >> many extensions. To contain the security decisions to protocol >> designers, not individual administrators. > IMO: a) EAP methods that support cryptographic binding should/must be > used, b) EAP cryptographic binding should/must be used to do RFC5056 > channel binding to the TLS connection's tls-unique channel bindings. > The question is whether (a) and (b) are a SHOULD or a MUST, and if it > is not a MUST then what mitigation might or might not be feasible or > acceptable. > Note though that if RFC5056 channel binding is done from the EAP > method to the TLS connection, then your objection is fully dealt with. > =C2=A0And see the Subject: line in the header :) :) =C2=A0Simon brought u= p > channel binding for a reason, namely, that he had the same concerns as > you do. =C2=A0I have exactly the same concerns as well. =C2=A0However, Si= mon and > I believe there's a solution: RFC5056 channel binding. =C2=A0If you belie= ve > that channel binding is not a solution, please say so and let's figure > out why that might or might not be the case. My concern was not related to channel bindings, but to the protocol combination described in the initial message and the fact that any security guarrantee on the original protocol is turned void by such combined protocols (one has to reevaluate the security goals and threats for the new protocol). Channel bindings indeed provide a better way to stack security protocols and authentication in a layered approach. regards. Nikos From n.mavrogiannopoulos@gmail.com Mon Apr 11 01:51:42 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F12C3A69E3 for ; Mon, 11 Apr 2011 01:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.822 X-Spam-Level: X-Spam-Status: No, score=-2.822 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfuZo+-QhVlh for ; Mon, 11 Apr 2011 01:51:41 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 238943A69F0 for ; Mon, 11 Apr 2011 01:51:41 -0700 (PDT) Received: by pwi5 with SMTP id 5so2439597pwi.31 for ; Mon, 11 Apr 2011 01:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Vl5fMYdPjrvvkzpF48FQmMZbvT5Z45kM2P1fAFlh7Ik=; b=RRFa90OFGr+jJVcKLXIXGkSmKhVA2U0FaRG2zCCml3j1/Ar05Hx9OX5cQkchXxdiU3 EOO8NF6D2V8FP/GkUaMbgbwplAGjeoEgFy28XEpqQYFLR9EC5d/etfGxYhQeXrP0Qbig lE7AfX9sn/Svf8Ulau/RKkObdYCxPaOATgQbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=R5kD6ASjuFcjdJEEIMHVtYdfL14Suc8npXMI9JKd4MnrfMtVxRvA/tHnE+yxZrFY+u eCexh7oAe/ktkuqHJIiuGTRXyN8Uv6P/PBWm4wP8n02dUAiIHl6/kLQHADzO0rOTnrFZ CtPuhKwLx9Xr9vmkQc7iCwYwH6csLTzgJpT74= MIME-Version: 1.0 Received: by 10.142.248.4 with SMTP id v4mr5256451wfh.145.1302511901247; Mon, 11 Apr 2011 01:51:41 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.68.48.105 with HTTP; Mon, 11 Apr 2011 01:51:41 -0700 (PDT) In-Reply-To: References: <4DA2A1E4.5020005@gnutls.org> Date: Mon, 11 Apr 2011 10:51:41 +0200 X-Google-Sender-Auth: 8P5HSnZqHkTutcjeD5sTIY4ECHE Message-ID: From: Nikos Mavrogiannopoulos To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 08:51:42 -0000 On Mon, Apr 11, 2011 at 10:33 AM, Peter Gutmann wrote: >>* RFC6066 Max fragment size cannot be used to increase the TLS fragment, = thus >>punishing hardware accelerated implementations, that have to stick to the >>maximum 16k header. > Is there any server around that implements this? =C2=A0I know that some > implementations advertise support for it, but I've never found anything w= here > I could actually test my code (which has been commented out pretty much > forever due to lack of anything else that does it). GnuTLS supports it. We have a test server at http://www.gnu.org/software/gnutls/server.html. >>* The RFC6066 truncated HMAC extension is very limited as it only truncat= es >>to 80-bits. > Since, according to the Wikipedia TLS implementation survey, there are > precisely zero implementations of this, I don't think it matters much wha= t it > truncates to. If you do DTLS using the fancy-pancy SHA256 would take 32-bytes of your dat= agram (which might be limited to 1400 bytes or so due to MTU), and having a trunc= ation mechanism that is really extensible in a sense that you could cut the MAC o= n the security level negotiated would save precious bytes without reducing th= e level. (given that the highest TLS security level is 96-bits due to the finished message MAC, having a 256-bit MAC at the record messages is pointless). >>* AEAD interface was defined only for stream ciphers. If a block cipher >>emerges for AEAD it will not be usable with TLS. > Again, support for any kind of AEAD is practically nonexistent. =C2=A0We = can solve > this one if it ever becomes an issue. Given that there is hardware support in modern CPUs for GCM I think AEAD support would increase. regards, Nikos From ynir@checkpoint.com Mon Apr 11 03:13:51 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE3D28C0E7 for ; Mon, 11 Apr 2011 03:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=-4.005, BAYES_00=-2.599, FRT_GUARANTEE1=4.533, FUZZY_GUARANTEE=1.252, MANGLED_GRNTEE=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Qs4wdg81qtY for ; Mon, 11 Apr 2011 03:13:50 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 574B23A6AF5 for ; Mon, 11 Apr 2011 03:13:50 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p3BADTnh006936; Mon, 11 Apr 2011 13:13:30 +0300 X-CheckPoint: {4DA2E202-17-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 11 Apr 2011 13:13:29 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 11 Apr 2011 12:13:29 +0200 From: Yoav Nir To: Nikos Mavrogiannopoulos Date: Mon, 11 Apr 2011 12:13:27 +0200 Thread-Topic: [TLS] EAP-in-TLS and channel bindings Thread-Index: Acv4MRoRWGlbsRybT56tF0rWSXxwLw== Message-ID: <601D84F0-847A-47CC-BA7B-D33D1A183503@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.com> <006FEB08D9C6444AB014105C9AEB133F013ABE025E05@il-ex01.ad.checkpoint.com> <4D9D6DF2.4070801@gnutls.org> <48F16295-4EC7-4C7F-938A-D56D97EB2412@checkpoint.com> <4D9F2DB8.8070506@gnutls.org> 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 Cc: "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 10:13:51 -0000 On Apr 11, 2011, at 11:43 AM, Nikos Mavrogiannopoulos wrote: > On Fri, Apr 8, 2011 at 8:54 PM, Nico Williams wro= te: >=20 >>> If for example I use anonymous DH and perform mutual authentication of >>> peers using EAP and mschapv2, then it is broken. I suppose there >>> several scenarios where one can combine that and have a useful >>> protocol. That is the reason the original TLS did not allow >>> many extensions. To contain the security decisions to protocol >>> designers, not individual administrators. >> IMO: a) EAP methods that support cryptographic binding should/must be >> used, b) EAP cryptographic binding should/must be used to do RFC5056 >> channel binding to the TLS connection's tls-unique channel bindings. >> The question is whether (a) and (b) are a SHOULD or a MUST, and if it >> is not a MUST then what mitigation might or might not be feasible or >> acceptable. >> Note though that if RFC5056 channel binding is done from the EAP >> method to the TLS connection, then your objection is fully dealt with. >> And see the Subject: line in the header :) :) Simon brought up >> channel binding for a reason, namely, that he had the same concerns as >> you do. I have exactly the same concerns as well. However, Simon and >> I believe there's a solution: RFC5056 channel binding. If you believe >> that channel binding is not a solution, please say so and let's figure >> out why that might or might not be the case. >=20 > My concern was not related to channel bindings, but to the protocol > combination described in the initial message and the fact that > any security guarrantee on the original protocol is turned void by such > combined protocols (one has to reevaluate the security goals and > threats for the new protocol). > Channel bindings indeed provide a better way to stack security protocols > and authentication in a layered approach. There are two attributes that we consider for EAP methods. They can be key-= generating (produce an MSK), in which case that MSK can be used for channel= binding, and they can be mutually-authenticating, in which case you are sa= fe to use anonymous D-H. If the method is not mutually-authenticating, the = client needs to verify the server certificate. While these two attributes are orthogonal, in practice the modern methods h= ave both. Yoav= From nico@cryptonector.com Mon Apr 11 09:50:46 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A10AD28C135 for ; Mon, 11 Apr 2011 09:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.095 X-Spam-Level: ** X-Spam-Status: No, score=2.095 tagged_above=-999 required=5 tests=[AWL=-4.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_GUARANTEE1=4.533, FUZZY_GUARANTEE=1.252, MANGLED_GRNTEE=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lyT0LqSLrgm for ; Mon, 11 Apr 2011 09:50:45 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id D32813A68DC for ; Mon, 11 Apr 2011 09:50:45 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 5D49F42807D for ; Mon, 11 Apr 2011 09:50:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=hnsHFI36SelgHIwawmKEw7G3XRHuaeh0E6JJaQlBUvwt GFuTYF/glOchl+TjAo4vmuUFfhAq466gJG1HIuwWY0DvZLQ4pVu7F4jz/HKB1Ah2 htV84gC3QDN3g03bPSWPPgzxVj/fZuB06KsBZxgZddTSpb8OsxwLSygCwdga8NY= 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=JK0V0mvGYQLzfwklshIiumCp+qY=; b=iR2TvZpLkVE 2nK1zQcNr9nm9HRZlOA3o46RAQTwwSCFjfgtgtKPKf2Ci7v5rAgo/keh0nja+Yvc n9KZiUd1akfHC9gDJL2lTyV0Eka+EgBh5y0PtGNVSHnwfG9rfcHyq+XtU05m0pa5 GS1udYyBD0Rt2UR74K0H48Q+Pqs8pOLs= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id EE15942807B for ; Mon, 11 Apr 2011 09:50:39 -0700 (PDT) Received: by vxg33 with SMTP id 33so5315550vxg.31 for ; Mon, 11 Apr 2011 09:50:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.101.168 with SMTP id fh8mr2115003vdb.134.1302540638817; Mon, 11 Apr 2011 09:50:38 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Mon, 11 Apr 2011 09:50:38 -0700 (PDT) In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.com> <006FEB08D9C6444AB014105C9AEB133F013ABE025E05@il-ex01.ad.checkpoint.com> <4D9D6DF2.4070801@gnutls.org> <48F16295-4EC7-4C7F-938A-D56D97EB2412@checkpoint.com> <4D9F2DB8.8070506@gnutls.org> Date: Mon, 11 Apr 2011 11:50:38 -0500 Message-ID: From: Nico Williams To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 16:50:46 -0000 On Mon, Apr 11, 2011 at 3:43 AM, Nikos Mavrogiannopoulos wrote: > My concern was not related to channel bindings, but to the protocol > combination described in the initial message and the fact that > any security guarrantee on the original protocol is turned void by such > combined protocols (one has to reevaluate the security goals and > threats for the new protocol). But your concern is addressed by channel binding. Indeed, I like to think that the only real concern with respect to adding EAP to TLS _is_ channel binding. Any time we layer security technologies we need to think of composition, and the best, and perhaps only _formal_ tool that we have for that is channel binding. > Channel bindings indeed provide a better way =C2=A0to stack security prot= ocols > and authentication in a layered approach. Thanks for the vote of confidence. Are there any other approaches? Nico -- From nico@cryptonector.com Mon Apr 11 09:56:38 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4288A28C147 for ; Mon, 11 Apr 2011 09:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.128 X-Spam-Level: ** X-Spam-Status: No, score=2.128 tagged_above=-999 required=5 tests=[AWL=-3.980, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_GUARANTEE1=4.533, FUZZY_GUARANTEE=1.252, MANGLED_GRNTEE=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXXqYmqfND6M for ; Mon, 11 Apr 2011 09:56:36 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 6C30728C135 for ; Mon, 11 Apr 2011 09:56:36 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 34F3767808E for ; Mon, 11 Apr 2011 09:56:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=E2Vn9Kdxxl6yapfWpUOxKcBEgIMp9zyIy1vArjBMMOzM uCpyHsh6DbxX4Jh+aMicsnczegybrl8wqnS5AZCb+T/7lF254Y2dYkoYKDBK/R7Q GNo+gXvKhgrCmnmUMV6PTe79jcmXKUSLgZcedrpLXfF3AJLVhMOpLmpN5L9p4wo= 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=l1tUtYyswvAcvR573LlQq9zGBTw=; b=BI8O9VMw00k 5zbDvO5fBOMta9M01clAQh506oeT35IReC+sfWl+8DEtEBNyaX8BseN164h+Gnee RVeKQRgVsWJVs1h2Ee4VOWmr4daNRs3H7vhoPrnHgYjF3JpNkvm1M6wJpFP3ip5X ruba/tGle0iXZ3MYp8G6GwF88wMeYO08= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 94DEC678063 for ; Mon, 11 Apr 2011 09:56:25 -0700 (PDT) Received: by vxg33 with SMTP id 33so5321385vxg.31 for ; Mon, 11 Apr 2011 09:56:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.111.41 with SMTP id if9mr2192260vdb.54.1302540984767; Mon, 11 Apr 2011 09:56:24 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Mon, 11 Apr 2011 09:56:24 -0700 (PDT) In-Reply-To: <601D84F0-847A-47CC-BA7B-D33D1A183503@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.com> <006FEB08D9C6444AB014105C9AEB133F013ABE025E05@il-ex01.ad.checkpoint.com> <4D9D6DF2.4070801@gnutls.org> <48F16295-4EC7-4C7F-938A-D56D97EB2412@checkpoint.com> <4D9F2DB8.8070506@gnutls.org> <601D84F0-847A-47CC-BA7B-D33D1A183503@checkpoint.com> Date: Mon, 11 Apr 2011 11:56:24 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 16:56:38 -0000 On Mon, Apr 11, 2011 at 5:13 AM, Yoav Nir wrote: > On Apr 11, 2011, at 11:43 AM, Nikos Mavrogiannopoulos wrote: >> My concern was not related to channel bindings, but to the protocol >> combination described in the initial message and the fact that >> any security guarrantee on the original protocol is turned void by such >> combined protocols (one has to reevaluate the security goals and >> threats for the new protocol). >> Channel bindings indeed provide a better way =C2=A0to stack security pro= tocols >> and authentication in a layered approach. > > There are two attributes that we consider for EAP methods. They can be ke= y-generating (produce an MSK), in which case that MSK can be used for chann= el binding, and they can be mutually-authenticating, in which case you are = safe to use anonymous D-H. If the method is not mutually-authenticating, th= e client needs to verify the server certificate. Key generation can definitely be used for RFC5056 CB. EAP Cryptographic Binding can also be used to implement RFC5056 CB. I don't understand the comment about mutual authentication though. Can you expand on that? Did you mean that the EAP method can authenticate the TLS server's certficate? (If so that's one form of RFC5056 CB, using the tls-server-end-point CB type.) Or did you mean something else? There has got to be some binding between EAP and TLS, otherwise you get into trouble. But you might be able to use tunneled EAP methods to deal with otherwise weak EAP methods. Nico -- From paul.hoffman@vpnc.org Mon Apr 11 10:10:37 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C8E3A6B23 for ; Mon, 11 Apr 2011 10:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.146 X-Spam-Level: X-Spam-Status: No, score=-102.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2seYcsRX7Al for ; Mon, 11 Apr 2011 10:10:37 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 8E1BD3A6938 for ; Mon, 11 Apr 2011 10:10:36 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3BH3L2C064557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Apr 2011 10:03:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 11 Apr 2011 10:03:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5F5999BE-4959-406F-88C2-1647B91FBE6F@vpnc.org> References: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 17:10:37 -0000 On Apr 10, 2011, at 9:48 PM, Eric Rescorla wrote: > On Sun, Apr 10, 2011 at 4:10 PM, Paul Hoffman = wrote: >> On Apr 10, 2011, at 2:25 PM, Joe Salowey wrote: >>=20 >>> The primary goals of the WG are to maintain: >>> - The TLS protocol, RFC 5346; >>=20 >> That *could* be read to mean that the WG is not supposed to work on = TLS 1.3. If that is the intention, then the charter should say so = explicitly. >=20 > I hope that's how it should be read. I don't see any pressing need for > the TLS WG to do a TLS 1.3. I hear that you don't, but at least a few other people on the list have = said that they do. The charter needs to be clear one way or the other. --Paul Hoffman From nico@cryptonector.com Mon Apr 11 10:16:07 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01B133A6946 for ; Mon, 11 Apr 2011 10:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDNYRqKoxEkK for ; Mon, 11 Apr 2011 10:16:06 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 11BFE3A68DC for ; Mon, 11 Apr 2011 10:16:06 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 7160C77806E for ; Mon, 11 Apr 2011 10:16:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=p977IyhbG8tbyEGoVVbbO mAmpKy3FP5BHkUTzfXsLUn5NpMtnWyfIzievB/ujGrHTC0d3SWiA++5FNCCFmFii SOTl8JfYTbp9QRrxhES65DL4GUejSFjWeBlBPEruaoYn/HN647H+UiBIb9UPStD/ peTpFl1JVHMJ4husa9omeM= 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; s=cryptonector.com; bh=MXM75ujXksbx/PrmTJNm 1nLy4Bg=; b=iwTmhw6eUa0LPB2XX7J6ZduLnBQ0YooTjr08+leZIDY6n0dLk2BI gsgmTGPKhmsFsFHtq5rqCnrqJcI7jSW/tbamtnelHnq6j4qJhTA7oP7jnPkVa224 8SGdGKcZvFyfEgCrzf8pRExgW6pFlEVcRhcPpMMW63fZI1lEVgUdc30= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 4332B77805F for ; Mon, 11 Apr 2011 10:16:06 -0700 (PDT) Received: by vws12 with SMTP id 12so5374544vws.31 for ; Mon, 11 Apr 2011 10:16:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.111.41 with SMTP id if9mr2223463vdb.54.1302542165501; Mon, 11 Apr 2011 10:16:05 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Mon, 11 Apr 2011 10:16:05 -0700 (PDT) In-Reply-To: <4DA2A1E4.5020005@gnutls.org> References: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> <4DA2A1E4.5020005@gnutls.org> Date: Mon, 11 Apr 2011 12:16:05 -0500 Message-ID: From: Nico Williams To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 17:16:07 -0000 On Mon, Apr 11, 2011 at 1:38 AM, Nikos Mavrogiannopoulos wrote: > Over the years, I've kept a list of issues of TLS (apply to TLS 1.2). > > (I skip all the issues already reported by Peter Gutmann at: > http://www.ietf.org/mail-archive/web/tls/current/msg07608.html ) > > * Renegotiation semantics are unclear. When one is supposed to > do renegotiation? How to distinguish data before a renegotiation > and after? (especially since application data are allowed > to be processed during a renegotiation). See also > http://www.ietf.org/mail-archive/web/tls/current/msg05607.html I thought it was clear enough: when the client wants to do it (even though the server can ask the client to do it, the client needn't do it until it's ready). But of course, the devil's in the detail... And ultimately this ties into what the actual APIs look like, because the application really needs to be in charge of renegotiation boundaries (i.e., when the server wants it, and when the client starts it). > [...] > * TLS version negotiation. If 1.1 and 1.3 is implemented, then > negotiation will always fail if talking to a 1.2 server. This > requires a client to implement all possible TLS protocols > instead of the latest and a fallback (e.g. TLS 1.0). Hopefully there will not be a TLS 1.3. Instead we should use all the extensibility in 1.2 to avoid the need for 1.3. Nico -- From ynir@checkpoint.com Mon Apr 11 11:01:16 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3683A6A1E for ; Mon, 11 Apr 2011 11:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=-3.945, BAYES_00=-2.599, FRT_GUARANTEE1=4.533, FUZZY_GUARANTEE=1.252, MANGLED_GRNTEE=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qudch+lx1lN5 for ; Mon, 11 Apr 2011 11:01:15 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 2A57B3A6A09 for ; Mon, 11 Apr 2011 11:01:14 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p3BI0fW6003529; Mon, 11 Apr 2011 21:00:42 +0300 X-CheckPoint: {4DA34F81-2-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 11 Apr 2011 21:00:41 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 11 Apr 2011 20:00:41 +0200 From: Yoav Nir To: Nico Williams Date: Mon, 11 Apr 2011 20:00:40 +0200 Thread-Topic: [TLS] EAP-in-TLS and channel bindings Thread-Index: Acv4cl5DubOqYq+uQSqtcnvVb6r3OA== Message-ID: <7D27F068-C1F3-4FB1-A321-4D813A2DD9BD@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.com> <006FEB08D9C6444AB014105C9AEB133F013ABE025E05@il-ex01.ad.checkpoint.com> <4D9D6DF2.4070801@gnutls.org> <48F16295-4EC7-4C7F-938A-D56D97EB2412@checkpoint.com> <4D9F2DB8.8070506@gnutls.org> <601D84F0-847A-47CC-BA7B-D33D1A183503@checkpoint.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 Cc: "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 18:01:16 -0000 On Apr 11, 2011, at 7:56 PM, Nico Williams wrote: > On Mon, Apr 11, 2011 at 5:13 AM, Yoav Nir wrote: >> On Apr 11, 2011, at 11:43 AM, Nikos Mavrogiannopoulos wrote: >>> My concern was not related to channel bindings, but to the protocol >>> combination described in the initial message and the fact that >>> any security guarrantee on the original protocol is turned void by such >>> combined protocols (one has to reevaluate the security goals and >>> threats for the new protocol). >>> Channel bindings indeed provide a better way to stack security protoco= ls >>> and authentication in a layered approach. >>=20 >> There are two attributes that we consider for EAP methods. They can be k= ey-generating (produce an MSK), in which case that MSK can be used for chan= nel binding, and they can be mutually-authenticating, in which case you are= safe to use anonymous D-H. If the method is not mutually-authenticating, t= he client needs to verify the server certificate. >=20 > Key generation can definitely be used for RFC5056 CB. EAP > Cryptographic Binding can also be used to implement RFC5056 CB. >=20 > I don't understand the comment about mutual authentication though. > Can you expand on that? It was in response to Nikos' earlier line: "If for example I use anonymous = DH and perform mutual authentication of peers using EAP and mschapv2, then it is broken." This is because MS-Chapv2 is vulnerable to dictionary attacks, so it can't = be considered mutually-authenticated. If you don't use an ADH ciphersuite, = and the client does verify the server certificate, then you don't have this= problem. >=20 > Did you mean that the EAP method can authenticate the TLS server's > certficate? (If so that's one form of RFC5056 CB, using the > tls-server-end-point CB type.) Or did you mean something else? >=20 > There has got to be some binding between EAP and TLS, otherwise you > get into trouble. But you might be able to use tunneled EAP methods > to deal with otherwise weak EAP methods. I intend to use the MSK or a mix of MSK and master secret or extractor to c= ompute a signature similar to the "Finished" message. I'm not sure whether this is enough for binding, or whether you also need t= o mix the key into the session resumption state cache, or actually into the= secret used for computing extractors. I think it's not necessary, but what do you think? From stpeter@stpeter.im Mon Apr 11 11:06:36 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877823A6A34 for ; Mon, 11 Apr 2011 11:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqOLXm-dxXaJ for ; Mon, 11 Apr 2011 11:06:35 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 73FF93A69A0 for ; Mon, 11 Apr 2011 11:06:35 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7FCB340022; Mon, 11 Apr 2011 12:09:26 -0600 (MDT) Message-ID: <4DA34328.8060808@stpeter.im> Date: Mon, 11 Apr 2011 12:06:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Paul Hoffman References: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> <5F5999BE-4959-406F-88C2-1647B91FBE6F@vpnc.org> In-Reply-To: <5F5999BE-4959-406F-88C2-1647B91FBE6F@vpnc.org> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020902050705000506020406" Cc: tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 18:06:36 -0000 This is a cryptographically signed message in MIME format. --------------ms020902050705000506020406 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/11/11 11:03 AM, Paul Hoffman wrote: > On Apr 10, 2011, at 9:48 PM, Eric Rescorla wrote: >=20 >> On Sun, Apr 10, 2011 at 4:10 PM, Paul Hoffman >> wrote: >>> On Apr 10, 2011, at 2:25 PM, Joe Salowey wrote: >>>=20 >>>> The primary goals of the WG are to maintain: - The TLS >>>> protocol, RFC 5346; >>>=20 >>> That *could* be read to mean that the WG is not supposed to work >>> on TLS 1.3. If that is the intention, then the charter should say >>> so explicitly. >>=20 >> I hope that's how it should be read. I don't see any pressing need >> for the TLS WG to do a TLS 1.3. >=20 > I hear that you don't, but at least a few other people on the list > have said that they do. The charter needs to be clear one way or the > other. Well, rechartering isn't that expensive, so the WG could always recharter again when folks think it needs to work on TLS 1.3. But I'd agree that this needs to be clear in this version of the charter. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020902050705000506020406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQx MTE4MDYzMlowIwYJKoZIhvcNAQkEMRYEFDJYJMy/PvWgRn1hUD8t3nh6/7lGMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQB++XGLELjibg2aj/+PJ7R1QI1IwZoBM7J9o4d/D2vGQ3kPfjcGa2P4r4CJ NU1PugeGEF8fIkq1aAj1gwfAk5p52gJY0Hag9l3+vtnRRWOOAnblEDG5c6Z2AaGgHXNJeQst Uo1VO62jDIITt3dCq05feAzPJM7rA4h0Q3I2ISUmCp6NjLAdq8da5N338YrzKOl0zrXpu1AW YCGPQKEYHk/hJ+HFapM+tKwU4RRRbNmKWb8u7NI5N+KI1vNQmr4/h6z3WWsOE0XpE9stZPDy m4nXNzqIZQ1mSN/NqI2XkqgX8nCok5Ucgw43SId/795/CR+y/3xXpQJ+AUH95P6NR/eFAAAA AAAA --------------ms020902050705000506020406-- From nico@cryptonector.com Mon Apr 11 11:20:22 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A79243A6A09 for ; Mon, 11 Apr 2011 11:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtYYemgZ7dNO for ; Mon, 11 Apr 2011 11:20:21 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id C16AC3A6946 for ; Mon, 11 Apr 2011 11:20:21 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 3D5DBB8074 for ; Mon, 11 Apr 2011 11:20:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=jpRyH5YPuylB+mNhHJfzjePN9UmIMYlqA+BYX6NxsQay I0wMFICxsFtWMnExml856qaIqtm/bw7FJHQ8BB+a1z7Qq5Obpv6xZ8f8kvLcuB+G y3v3d+B8EznvyfLGmA28R82nP4cKJ/EfP6p2ty4uwJ4ZOmNE5ppmsmfRUeE5/8g= 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=c12sfiyZ4St1PdDO/s9lc6TLuCM=; b=FX17/27NozI SU3APP5R1QRXmuNMdpMKrCqhhW8JQQoQk43H/3rO3rHHGR6Gg/YXy21BZ6hFm4KA 7Zin/0pGIE6VnK0dHEK8iNvAH5lU+mR7+mm9a4mLI0SVKv7luv8haXecI97mazMq NUsBWMpcHw9FM+p9ZGv2pATXnMexxIxQ= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 0880AB805C for ; Mon, 11 Apr 2011 11:20:21 -0700 (PDT) Received: by vxg33 with SMTP id 33so5402543vxg.31 for ; Mon, 11 Apr 2011 11:20:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.111.41 with SMTP id if9mr2325184vdb.54.1302546021364; Mon, 11 Apr 2011 11:20:21 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Mon, 11 Apr 2011 11:20:21 -0700 (PDT) In-Reply-To: <7D27F068-C1F3-4FB1-A321-4D813A2DD9BD@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F013ABE025DFD@il-ex01.ad.checkpoint.com> <006FEB08D9C6444AB014105C9AEB133F013ABE025E05@il-ex01.ad.checkpoint.com> <4D9D6DF2.4070801@gnutls.org> <48F16295-4EC7-4C7F-938A-D56D97EB2412@checkpoint.com> <4D9F2DB8.8070506@gnutls.org> <601D84F0-847A-47CC-BA7B-D33D1A183503@checkpoint.com> <7D27F068-C1F3-4FB1-A321-4D813A2DD9BD@checkpoint.com> Date: Mon, 11 Apr 2011 13:20:21 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] EAP-in-TLS and channel bindings X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 18:20:22 -0000 On Mon, Apr 11, 2011 at 1:00 PM, Yoav Nir wrote: > On Apr 11, 2011, at 7:56 PM, Nico Williams wrote: >>> There are two attributes that we consider for EAP methods. They can be = key-generating (produce an MSK), in which case that MSK can be used for cha= nnel binding, and they can be mutually-authenticating, in which case you ar= e safe to use anonymous D-H. If the method is not mutually-authenticating, = the client needs to verify the server certificate. >> >> Key generation can definitely be used for RFC5056 CB. =C2=A0EAP >> Cryptographic Binding can also be used to implement RFC5056 CB. >> >> I don't understand the comment about mutual authentication though. >> Can you expand on that? > > It was in response to Nikos' earlier line: "If for example I use anonymou= s DH and perform mutual authentication of > peers using EAP and mschapv2, then it is broken." > > This is because MS-Chapv2 is vulnerable to dictionary attacks, so it can'= t be considered mutually-authenticated. If you don't use an ADH ciphersuite= , and the client does verify the server certificate, then you don't have th= is problem. But this is not enough. You want to protect the method against the TLS server as well. After all you might be federating authentication (OK, that's probably out of scope for your protocol, but then that's quite limiting, particularly in comparison to the ABFAB work, so I'd have to wonder why bother with EAP-in-TLS! see below), and even if you're not, you'd still want defense in depth, wouldn't you? So, for weak methods I think you'd want to use tunneling, with the tunnel end-point located in some server other than the peer of the TLS client. > I intend to use the MSK or a mix of MSK and master secret or extractor to= compute a signature similar to the "Finished" message. What you should sign (MAC) is the tls-unique channel bindings data of the TLS connection. > I'm not sure whether this is enough for binding, or whether you also need= to mix the key into the session resumption state cache, or actually into t= he secret used for computing extractors. It's enough binding, provided both peers send a MAC and check the one received. But you'll want to associate the authenticated user name with the TLS session ID. What is the story regarding federation? If there isn't one, then I really have to ask: why bother with this work? I'd much rather you pursue draft-williams-tls-sasl-opt + the ABFAB WG GSS-EAP mechanism. That way you'd get: a) EAP (which is what you want), b) in/over TLS (also what you want), c) with CB (which you should want), d) plus federation (which others are bound to want, even if you don't), e) much more of the crypto worked out for you already (in ABFAB), f) a fair bit of source code (since much of the Project Moonshot stuff is open source). That's a lot of benefits, meriting at least serious consideration. (Note also that there's a further one round-trip optimization to make for draft-williams-tls-sasl-opt by making an optimistic SASL/GS2 mechanism selection and using MIC tokens, one of them PROT_READY, to do the CB. If some of those terms mean nothing to you, don't worry -- they are GSS-API specific, and we can go into them later if you choose to investigate this approach in depth.) Nico --=20 Nico -- From marsh@extendedsubset.com Mon Apr 11 11:58:40 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69A563A6B33 for ; Mon, 11 Apr 2011 11:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD7Z6lLpcim7 for ; Mon, 11 Apr 2011 11:58:39 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id BAE913A6B32 for ; Mon, 11 Apr 2011 11:58:39 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Q9MJs-000H2V-42; Mon, 11 Apr 2011 18:58:40 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 84D2D6066; Mon, 11 Apr 2011 18:58:38 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/NBsXB3Ttjs9YZSCTGR2pLdUtxAe6AbPw= Message-ID: <4DA34F5F.30501@extendedsubset.com> Date: Mon, 11 Apr 2011 13:58:39 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Peter Saint-Andre References: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> <5F5999BE-4959-406F-88C2-1647B91FBE6F@vpnc.org> <4DA34328.8060808@stpeter.im> In-Reply-To: <4DA34328.8060808@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 18:58:40 -0000 On 04/11/2011 01:06 PM, Peter Saint-Andre wrote: > On 4/11/11 11:03 AM, Paul Hoffman wrote: >> On Apr 10, 2011, at 9:48 PM, Eric Rescorla wrote: >>> >>> I hope that's how it should be read. I don't see any pressing need >>> for the TLS WG to do a TLS 1.3. >> >> I hear that you don't, but at least a few other people on the list >> have said that they do. The charter needs to be clear one way or the >> other. > > Well, rechartering isn't that expensive, so the WG could always > recharter again when folks think it needs to work on TLS 1.3. But I'd > agree that this needs to be clear in this version of the charter. The idea that the charter would actively prohibit the group from considering what might go in TLS 1.3 seems strange to me. If someone wanted to develop a version increment on the standard does this mean they would have to do it outside the WG? Would the WG then refuse to look at it? Of course, this may be something of a moot point given the acceptance level of TLS 1.1 and 1.2. But some recent extensions have the potential to give a significant performance improvement at the cost of added complexity. There have also been questions about the strength of Finished.verify_data, which is really not negotiable via an extension. If a significant protocol improvement, the natural expression of which needed a version bump, were to be proposed is the group charter a good basis for rejecting it out-of-hand? Recent extension proposals have been coming from vendors and other interested parties. Why does the WG feel the need to tie its own hands with respect to base protocol versioning? - Marsh From ynir@checkpoint.com Mon Apr 11 12:23:40 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39A9028C150 for ; Mon, 11 Apr 2011 12:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.444 X-Spam-Level: X-Spam-Status: No, score=-10.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDMxmKmL9fQ8 for ; Mon, 11 Apr 2011 12:23:38 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 59BFF28C13A for ; Mon, 11 Apr 2011 12:23:38 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p3BJNY92014865; Mon, 11 Apr 2011 22:23:34 +0300 X-CheckPoint: {4DA362ED-3-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 11 Apr 2011 22:23:34 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 11 Apr 2011 21:23:34 +0200 From: Yoav Nir To: Marsh Ray Date: Mon, 11 Apr 2011 21:23:32 +0200 Thread-Topic: [TLS] Proposed working group charter update Thread-Index: Acv4ffKLDZQ4TFBEQaKkVE3GB/mb5g== Message-ID: <4AF21539-E3FE-4FC4-8A48-E5C21D0BF5DB@checkpoint.com> References: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> <5F5999BE-4959-406F-88C2-1647B91FBE6F@vpnc.org> <4DA34328.8060808@stpeter.im> <4DA34F5F.30501@extendedsubset.com> In-Reply-To: <4DA34F5F.30501@extendedsubset.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 Cc: Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 19:23:40 -0000 On Apr 11, 2011, at 9:58 PM, Marsh Ray wrote: > On 04/11/2011 01:06 PM, Peter Saint-Andre wrote: >> On 4/11/11 11:03 AM, Paul Hoffman wrote: >>> On Apr 10, 2011, at 9:48 PM, Eric Rescorla wrote: >>>>=20 >>>> I hope that's how it should be read. I don't see any pressing need >>>> for the TLS WG to do a TLS 1.3. >>>=20 >>> I hear that you don't, but at least a few other people on the list >>> have said that they do. The charter needs to be clear one way or the >>> other. >>=20 >> Well, rechartering isn't that expensive, so the WG could always >> recharter again when folks think it needs to work on TLS 1.3. But I'd >> agree that this needs to be clear in this version of the charter. >=20 > The idea that the charter would actively prohibit the group from=20 > considering what might go in TLS 1.3 seems strange to me. The charter cannot limit what the group considers. You can start a discussi= on on the mailing list for almost anything, and the best WG chairs or ADs c= an do is ask you to pretty please get back to discussing charter items. > If someone wanted to develop a version increment on the standard does=20 > this mean they would have to do it outside the WG? Would the WG then=20 > refuse to look at it? Of course, this may be something of a moot point=20 > given the acceptance level of TLS 1.1 and 1.2. You can always submit draft-ray-tls-1-3-00.txt, and tell everyone on the li= st about it. If the group wants to accept it as a working group item, then = it will have to recharter. Also, all the big browsers now support TLS 1.1 and 1.2. Microsoft and GNU-T= LS based servers also support them. OpenSSL still doesn't, but that's bound= to change sometime. > But some recent extensions have the potential to give a significant=20 > performance improvement at the cost of added complexity. There have also= =20 > been questions about the strength of Finished.verify_data, which is=20 > really not negotiable via an extension. I don't see why it's not negotiable via an extension, but if it's not, go a= head and write that draft. > If a significant protocol improvement, the natural expression of which=20 > needed a version bump, were to be proposed is the group charter a good=20 > basis for rejecting it out-of-hand? No. It's a good basis for saying, "Hold on. We have to go to the ADs and re= charter for this" > Recent extension proposals have been coming from vendors and other=20 > interested parties. Why does the WG feel the need to tie its own hands=20 > with respect to base protocol versioning? If you compare the proposed charter to the ipsecme charter ( http://tools.i= etf.org/wg/ipsecme/charters ) you can see that this one is far broader and = more open-ended. While this one says that the WG goal is to publish extensi= ons, the ipsecme charter enumerates the specific extensions. To add any new= item to the agenda, the ipsecme group has to recharter. I don't know what level of open-endedness is best, but as Peter said, recha= rtering is not all that difficult. From n.mavrogiannopoulos@gmail.com Mon Apr 11 12:26:39 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C873A6B37 for ; Mon, 11 Apr 2011 12:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id El2k0r687QtF for ; Mon, 11 Apr 2011 12:26:38 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id BE4AE3A6B2F for ; Mon, 11 Apr 2011 12:26:37 -0700 (PDT) Received: by wwk4 with SMTP id 4so3014098wwk.1 for ; Mon, 11 Apr 2011 12:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=wyIxrh2Hk2NP/5Z6yUcqsprq9TMDtycngba6L/4pmoY=; b=I8+luHqIh0JfQLBt4K3z5RwkTue+vibes99aODCnyU1tMe0f+5LvHJqo0BeThByfbp LZxeB68yPukQTaWm//o1AX2w/u049jJlgHAvsn4KXUHFtET/TeJlSskclDYhEdQH1AQe qiUMv/Z/Vehyk7TZdb3+5Je12LKR75JtIo0io= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=dXnby7t0C9nDqgLVUwdLBwB0DjLBtT22v3JNbh38fSI8kAF6dqjqupWH5Kv2fRKdN4 kCQFG6kS1mIiH7rF13z/lmoU5I6o1VMCnRpraZYPJQyEYfFcssg7FHRj6/8d7MsX1D+g Rkt4TA0ipcXV07/9YfDrLuozWsnvh3iLpv4Sg= Received: by 10.216.67.136 with SMTP id j8mr5612701wed.102.1302549996023; Mon, 11 Apr 2011 12:26:36 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id d59sm2831440wed.45.2011.04.11.12.26.33 (version=SSLv3 cipher=OTHER); Mon, 11 Apr 2011 12:26:34 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4DA355E9.2030606@gnutls.org> Date: Mon, 11 Apr 2011 21:26:33 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Nico Williams References: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> <4DA2A1E4.5020005@gnutls.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 19:26:39 -0000 On 04/11/2011 07:16 PM, Nico Williams wrote: >> * Renegotiation semantics are unclear. When one is supposed to do >> renegotiation? How to distinguish data before a renegotiation and >> after? (especially since application data are allowed to be >> processed during a renegotiation). See also >> http://www.ietf.org/mail-archive/web/tls/current/msg05607.html > I thought it was clear enough: when the client wants to do it (even > though the server can ask the client to do it, the client needn't do > it until it's ready). But of course, the devil's in the detail... > And ultimately this ties into what the actual APIs look like, > because the application really needs to be in charge of > renegotiation boundaries (i.e., when the server wants it, and when > the client starts it). I wasn't clear enough. RFC5246 mentions: "HelloRequest is a simple notification that the client should begin the negotiation process anew. In response, the client should send a ClientHello message when convenient. " So when is convenient? For how long should a server wait for renegotiation? Would it be wait for 10 application data packets? 10 seconds? Forever? If I want to require renegotiation as a server what should I do? It is not possible to implement the described semantics. >> [...] * TLS version negotiation. If 1.1 and 1.3 is implemented, >> then negotiation will always fail if talking to a 1.2 server. This >> requires a client to implement all possible TLS protocols instead >> of the latest and a fallback (e.g. TLS 1.0). > Hopefully there will not be a TLS 1.3. Instead we should use all > the extensibility in 1.2 to avoid the need for 1.3. The same problem exists for TLS 1.2 and TLS 1.0. I cannot skip the implementation of TLS 1.1, if I would like to. This is not a problem for my implementation in particular, but newcomers would probably want to implement the latest version and a fallback such as TLS 1.0 or SSL 3.0. This is not possible today. One has to implement the whole list of published protocols. regards, Nikos From mrex@sap.com Mon Apr 11 15:29:04 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C9946E066A for ; Mon, 11 Apr 2011 15:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.101 X-Spam-Level: X-Spam-Status: No, score=-10.101 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+TBKfpcI7en for ; Mon, 11 Apr 2011 15:29:03 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfc.amsl.com (Postfix) with ESMTP id 0A287E06A9 for ; Mon, 11 Apr 2011 15:28:58 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p3BMSOGZ005086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2011 00:28:24 +0200 (MEST) From: Martin Rex Message-Id: <201104112228.p3BMSNFE015273@fs4113.wdf.sap.corp> To: nmav@gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 12 Apr 2011 00:28:23 +0200 (MEST) In-Reply-To: <4DA355E9.2030606@gnutls.org> from "Nikos Mavrogiannopoulos" at Apr 11, 11 09:26:33 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2011 22:29:04 -0000 Nikos Mavrogiannopoulos wrote: > > On 04/11/2011 07:16 PM, Nico Williams wrote: > > > > > > Nikos Mavrogiannopoulos wrote: > > > * Renegotiation semantics are unclear. The issue is two fold: - the TLS spec says so little about renegotiation that this protocol feature went completely unreviewed for 15 years. And the security ramifications of the little that is says are not described, either. - there is just about any conceivable behaviour present in the installed base. It would seem unreasonable to limit any future guidance to what might have been conceived by the original authors of the renegotiation at Netscape. > > > > > When one is supposed to do renegotiation? 1.) DON'T 2.) If you can't be good, at least be good at it: rfc5746 3.) pray that your peer doesn't abort on renegotiation requests > > > How to distinguish data before a renegotiation and after? > > > (especially since application data are allowed to be processed > > > during a renegotiation). See also > > > http://www.ietf.org/mail-archive/web/tls/current/msg05607.html If you take into account HTTP Request pipelining, then there could be a lot of app-data records sitting in the network OS receive buffer of a server that decides to request renegotiation from a client. > > I wasn't clear enough. RFC5246 mentions: > "HelloRequest is a simple notification that the client should begin > the negotiation process anew. In response, the client should send > a ClientHello message when convenient. " > So when is convenient? For how long should a server wait for > renegotiation? Would it be wait for 10 application data packets? 10 > seconds? Forever? If I want to require renegotiation as a server > what should I do? It is not possible to implement the described semantics. An even more difficult question is about "when is the client authenticated during renegotiation"? If a TLS server uses an event-based API, and that event-based API is called when the server processes the Client Certificate handshake message, then you already have a security problem, since the authentication of the client requires at least the successful validation of the CertificateVerify handshake message of an rfc5746- protected renegotiation to be secure. The following requirement in the spec looks dangerous for assumptions of calling applications: TLSv1.2, Section 6.2.1 Fragmentation (last paragraph) http://tools.ietf.org/html/rfc5246#section-6.2.1 Note: Data of different TLS record layer content types MAY be interleaved. Application data is generally of lower precedence for transmission than other content types. However, records MUST be delivered to the network in the same order as they are protected by the record layer. Recipients MUST receive and process interleaved application layer traffic during handshakes subsequent to the first one on a connection. > > >> [...] * TLS version negotiation. If 1.1 and 1.3 is implemented, > >> then negotiation will always fail if talking to a 1.2 server. This > >> requires a client to implement all possible TLS protocols instead > >> of the latest and a fallback (e.g. TLS 1.0). > > Hopefully there will not be a TLS 1.3. Instead we should use all > > the extensibility in 1.2 to avoid the need for 1.3. > > The same problem exists for TLS 1.2 and TLS 1.0. I cannot skip > the implementation of TLS 1.1, if I would like to. This is not > a problem for my implementation in particular, but newcomers > would probably want to implement the latest version and a > fallback such as TLS 1.0 or SSL 3.0. This is not possible today. > One has to implement the whole list of published protocols. I believe the problem is worse: Due to version intolerance interop problems, it seems currently not advisable to send a client version higher than TLSv1.0 unless there already is an application-level reconnect fallback in place. Or in other words: the existing TLS protocol version negotiation does not work in the installed base as designed and ought to be replaced. While SSLv3 -> TLSv1.0 -> TLSv1.1 could mostly be seen as generally useful security improvements, I doubt that this characterization applies to rfc5246. So yes, I also see a need to sidestep TLS protocol versions by now. -Martin From paul.hoffman@vpnc.org Mon Apr 11 15:33:34 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6CAE5E06DF for ; Mon, 11 Apr 2011 15:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.513 X-Spam-Level: X-Spam-Status: No, score=-101.513 tagged_above=-999 required=5 tests=[AWL=1.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3ln7gwsyx7A for ; Mon, 11 Apr 2011 15:33:33 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfc.amsl.com (Postfix) with ESMTP id DD0C3E06D6 for ; Mon, 11 Apr 2011 15:33:20 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3BJuQF5073679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Apr 2011 12:56:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4AF21539-E3FE-4FC4-8A48-E5C21D0BF5DB@checkpoint.com> Date: Mon, 11 Apr 2011 12:56:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> <5F5999BE-4959-406F-88C2-1647B91FBE6F@vpnc.org> <4DA34328.8060808@stpeter.im> <4DA34F5F.30501@extendedsubset.com> <4AF21539-E3FE-4FC4-8A48-E5C21D0BF5DB@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1084) Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 22:33:34 -0000 On Apr 11, 2011, at 12:23 PM, Yoav Nir wrote: >> The idea that the charter would actively prohibit the group from=20 >> considering what might go in TLS 1.3 seems strange to me. >=20 > The charter cannot limit what the group considers. Er, yes it can, if the WG chairs want to use it as a tool to do so. It = sounds like Ekr, in fact, wants this tool. > You can start a discussion on the mailing list for almost anything, = and the best WG chairs or ADs can do is ask you to pretty please get = back to discussing charter items. And then you have an uphill battle. >> If someone wanted to develop a version increment on the standard does=20= >> this mean they would have to do it outside the WG? Would the WG then=20= >> refuse to look at it? Of course, this may be something of a moot = point=20 >> given the acceptance level of TLS 1.1 and 1.2. >=20 > You can always submit draft-ray-tls-1-3-00.txt, and tell everyone on = the list about it. If the group wants to accept it as a working group = item, then it will have to recharter. In such a situation, the WG does not *have* to recharter. The chairs can = set up roadblocks. (I say this as a chair who has, in the past, set up = such roadblocks.) > I don't know what level of open-endedness is best, but as Peter said, = rechartering is not all that difficult. He said that it was not expensive, not that it wasn't difficult. = Rechartering is difficult when one or both chairs doesn't want it. --Paul Hoffman From mrex@sap.com Mon Apr 11 15:42:54 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 75E2EE0692 for ; Mon, 11 Apr 2011 15:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.105 X-Spam-Level: X-Spam-Status: No, score=-10.105 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkMNQV71vo45 for ; Mon, 11 Apr 2011 15:42:52 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfc.amsl.com (Postfix) with ESMTP id 25DD8E066A for ; Mon, 11 Apr 2011 15:42:51 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p3BMgk2S018302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2011 00:42:46 +0200 (MEST) From: Martin Rex Message-Id: <201104112242.p3BMgkwm016076@fs4113.wdf.sap.corp> To: jsalowey@cisco.com (Joe Salowey) Date: Tue, 12 Apr 2011 00:42:46 +0200 (MEST) In-Reply-To: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> from "Joe Salowey" at Apr 10, 11 02:25:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2011 22:42:54 -0000 Joe Salowey wrote: > > The primary goals of the WG are to maintain: > - The TLS protocol, RFC 5246; > The WG will attempt to avoid gratuitous changes to these protocols. I'm irritated by this particular combination of statements. It creates the impression that you want to preclude the TLS WG from working on fixes for the problems of TLSv1.2 that have already been identified. Personally, I'm seeing so many problems with the original TLS protocol version negotiation, that I think that needs to be changed as well in order to improve the interop with the installed base and improved migration to future protocol updates. During its lifetime IPv4 was faced with challenges to its original design. Anyhow, the IETF adopted CIDR at some point, and in spite of initial fierce resistance against it, the IETF at some point accepted the existence and use of NAT to address problems of the real world. I believe that we are seeing a divergence with the TLS specs from the necessities and (interop) problems of the real world, and the TLS WG ought to be pragmatic and propose remedies for the real world, rather than start religious wars about what a perfect world should look like. -Martin From nico@cryptonector.com Mon Apr 11 16:07:37 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7D257E0613 for ; Mon, 11 Apr 2011 16:07:37 -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=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72N2DzeWKDzd for ; Mon, 11 Apr 2011 16:07:35 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfc.amsl.com (Postfix) with ESMTP id 41243E0674 for ; Mon, 11 Apr 2011 16:07:35 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id E371F76806A for ; Mon, 11 Apr 2011 16:07:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=ke4MwA3fpR2EIPHbmAUGHLWLiO1QybkkOjMdK1OLS4z3 LAZ/O6kVfYI+iaICkosA2tCWETh5xzwHWI86SIU3eijxfnBy+hPe6tPuj6VABBkb Yqgf5ZyuGasXBlPFKyQTbz31yr3qJiQRKKdYm1+QLTUA8PNgmV3y78jOYg8XolQ= 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=P0crCojZIAof3YiFKfVZcpxyGAc=; b=mIBiAvpTktb vdq8jKtP6qM2A6FHpseuLpeOHBWCZmM+KHesbU9Xy236uwAn3u2RRNOmCNUNBOmI OffaMJsWjhqQDhtMmBpcXBSanB9K4x28puybvT4y6xtmKsMNIG742PMQA8lZRL6Q T5bevsS1MP6LwtggdywEfRoJgULo7S2w= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id B8860768064 for ; Mon, 11 Apr 2011 16:07:30 -0700 (PDT) Received: by vws12 with SMTP id 12so5718763vws.31 for ; Mon, 11 Apr 2011 16:07:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.66.19 with SMTP id b19mr126005vdt.94.1302563250023; Mon, 11 Apr 2011 16:07:30 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Mon, 11 Apr 2011 16:07:29 -0700 (PDT) In-Reply-To: <201104112242.p3BMgkwm016076@fs4113.wdf.sap.corp> References: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> <201104112242.p3BMgkwm016076@fs4113.wdf.sap.corp> Date: Mon, 11 Apr 2011 18:07:29 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 23:07:37 -0000 On Mon, Apr 11, 2011 at 5:42 PM, Martin Rex wrote: > Joe Salowey wrote: >> >> The primary goals of the WG are to maintain: >> =C2=A0 - The TLS protocol, RFC 5246; >> The WG will attempt to avoid gratuitous changes to these protocols. > > I'm irritated by this particular combination of statements. > > It creates the impression that you want to preclude the TLS WG > from working on fixes for the problems of TLSv1.2 that have already > been identified. I suppose it depends on what is meant by "maintain the protocol". I assumed "fix bugs", "clarify", that sort of activity -- what else could be meant by that? Specific proposals to fix protocol or specification bugs may or may not be "gratuitous". Taken together, and unless I'm misreading the meaning of "maintain", I think the above means that simple fixes to protocol and/or specification bugs will generally be adopted, while fixes that would amount to, say, a new minor version of the protocol would not be. If the proposed charter text confuses you regarding this, then it should be clarified. Nico -- From ynir@checkpoint.com Mon Apr 11 16:11:42 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 88C40E06B3 for ; Mon, 11 Apr 2011 16:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=4.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UkO00UxCs0T for ; Mon, 11 Apr 2011 16:11:41 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfc.amsl.com (Postfix) with ESMTP id BF044E0680 for ; Mon, 11 Apr 2011 16:11:39 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p3BKNOUA022820; Mon, 11 Apr 2011 23:23:24 +0300 X-CheckPoint: {4DA370F3-0-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 11 Apr 2011 23:23:24 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 11 Apr 2011 22:23:24 +0200 From: Yoav Nir To: Paul Hoffman Date: Mon, 11 Apr 2011 22:23:23 +0200 Thread-Topic: [TLS] Proposed working group charter update Thread-Index: Acv4hk7F3VhdGLahR5ufmZo2j5TZrw== Message-ID: <07A4223C-E6F0-48C1-A8A1-DFFA823ADFDB@checkpoint.com> References: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> <5F5999BE-4959-406F-88C2-1647B91FBE6F@vpnc.org> <4DA34328.8060808@stpeter.im> <4DA34F5F.30501@extendedsubset.com> <4AF21539-E3FE-4FC4-8A48-E5C21D0BF5DB@checkpoint.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 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 23:11:42 -0000 On Apr 11, 2011, at 10:56 PM, Paul Hoffman wrote: > On Apr 11, 2011, at 12:23 PM, Yoav Nir wrote: >>> The idea that the charter would actively prohibit the group from=20 >>> considering what might go in TLS 1.3 seems strange to me. >>=20 >> The charter cannot limit what the group considers. >=20 > Er, yes it can, if the WG chairs want to use it as a tool to do so. It so= unds like Ekr, in fact, wants this tool. >=20 >> You can start a discussion on the mailing list for almost anything, and = the best WG chairs or ADs can do is ask you to pretty please get back to di= scussing charter items. >=20 > And then you have an uphill battle. A lot of pushing documents forward feels like an uphill battle. If you can = get enough people to support the idea, these battles can be won. >>> If someone wanted to develop a version increment on the standard does=20 >>> this mean they would have to do it outside the WG? Would the WG then=20 >>> refuse to look at it? Of course, this may be something of a moot point= =20 >>> given the acceptance level of TLS 1.1 and 1.2. >>=20 >> You can always submit draft-ray-tls-1-3-00.txt, and tell everyone on the= list about it. If the group wants to accept it as a working group item, th= en it will have to recharter. >=20 > In such a situation, the WG does not *have* to recharter. The chairs can = set up roadblocks. (I say this as a chair who has, in the past, set up such= roadblocks.) Did you set up roadblocks against WG consensus? If so, then the ADs should= have intervened. This was not the case in ipsecme where the chairs and AD= s limited the amount of items on the group's agenda. Sure, some people didn= 't like it that their pet drafts were excluded, but I think there was conse= nsus for not taking on a dozen items at the same time. >=20 >> I don't know what level of open-endedness is best, but as Peter said, re= chartering is not all that difficult. >=20 > He said that it was not expensive, not that it wasn't difficult. Recharte= ring is difficult when one or both chairs doesn't want it. I think the chairs could make it just as difficult, even if the charter sai= d "maintain TLS 1.2 and write future versions if needed".= From mrex@sap.com Mon Apr 11 16:25:54 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4D112E0661 for ; Mon, 11 Apr 2011 16:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.11 X-Spam-Level: X-Spam-Status: No, score=-10.11 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbEMJ3j6DpXd for ; Mon, 11 Apr 2011 16:25:53 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfc.amsl.com (Postfix) with ESMTP id 0D419E0613 for ; Mon, 11 Apr 2011 16:25:51 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p3BNPSh9011200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2011 01:25:28 +0200 (MEST) From: Martin Rex Message-Id: <201104112325.p3BNPRv7018604@fs4113.wdf.sap.corp> To: nmav@gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 12 Apr 2011 01:25:27 +0200 (MEST) In-Reply-To: <4DA2A1E4.5020005@gnutls.org> from "Nikos Mavrogiannopoulos" at Apr 11, 11 08:38:28 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2011 23:25:54 -0000 Nikos Mavrogiannopoulos wrote: > > * RFC6066 Max fragment size cannot be used to increase the TLS fragment, > thus punishing hardware accelerated implementations, that have > to stick to the maximum 16k header. It it really weird to deny communication peers to consensually negotiate fragments larger than 16 KByte. > > * The RFC6066 truncated HMAC extension is very limited as it > only truncates to 80-bits. It could be very useful especially > in DTLS where the fragment size is very limiting, but not > in its current form. 80-bits should be enough for everybody > is not very convincing. Common security levels should > be allowed at least (64/80/96/128/192/256). This extension > might belong to the core TLS protocol if it is ever made aware > of security levels. I hadn't noticed that limitation of this TLS extension. Considering the guidance in rfc2104 and the work in the IPSEC area, it seems strange that truncation for the data HMACS to half the underlying hash output size is not part of the TLS base spec already. > > * Short finished message signature fixed to 12 bytes. The provisioning > of TLS 1.2 for ciphersuites to increase it was never used > by ciphersuites that aimed high security levels (AES-256, HMAC-384), > thus it is pretty much already obsolete. It seems the finished > message size should be defined by the TLS protocol itself > to be usable. (this is another argument of TLS being made > aware of security levels). Yup, that should be fixed along the way. > > * TLS version negotiation. If 1.1 and 1.3 is implemented, then > negotiation will always fail if talking to a 1.2 server. This > requires a client to implement all possible TLS protocols > instead of the latest and a fallback (e.g. TLS 1.0). The most significant problem that I have with the existing TLS specs is that every implementor has to work out the differences all by himself. And the less experience one has with any of the protocols (SSLv3,TLSv1.0,TLSv1.1,TLSv1.2) the more difficult it is to start a new implementation with the necessary generality that it will support all protocol versions with no changes to the architecture of the implementation. As you can see from the discussion in the TLS WG archives, for the original design of SSLv3, you did not need to memorize handshake messages to compute the handshake message hash that was used by the ClientVerify handshake message and by the PRF(), and that design was explicitly carried over to TLSv1.0 (and TLSv1.1). The design of the TLSv1.2 signature algorithm extension as well as the CertificateRequest handshake message break with this design in a very bad way -- and neither does TLSv1.2 indicate that it breaks that design, not does it give any rationale why breaking this would be necessary. > > * It is not known when is record version acceptable. Is a record > version of 3.55 acceptable? Is 4.0 acceptable? What about 65.35? > There should be at least a ranges of acceptable record version > numbers (for the initial hello message). That particular question should be easy to answer by common sense. The protocol version on the record layer gives you the protocol version of the PDU(!). Sending { 0x03,0x00 } ist the most sensible default for ClientHello on the initial handshake of a new connection. If a client does not care about getting back a TLS alert from old servers, the client may use the lowest protocol version in the record layer, that it would be willing to negotiate (because the server will have to be able to parse protocol PDUs of that protocol version). -Martin From nico@cryptonector.com Mon Apr 11 16:40:29 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0B2B5E06A3 for ; Mon, 11 Apr 2011 16:40: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=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnISG8RHtAQt for ; Mon, 11 Apr 2011 16:40:28 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfc.amsl.com (Postfix) with ESMTP id E8CF3E06B0 for ; Mon, 11 Apr 2011 16:40:27 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by hapkido.dreamhost.com (Postfix) with ESMTP id 1BCEB17B202 for ; Mon, 11 Apr 2011 12:52:06 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id D879B6B007B for ; Mon, 11 Apr 2011 12:52:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=AfQQef2AUydDrxKc9JcYt3s0d+fuCnMCP3Xt0s4DJfs+ sRjjKleb/GGNhLhPFliVGzWdFn/kcosmhmPmZUMJmGnGCCEL3kChWtCdSJkqjmbz CTLGXIETfgDnK4pHeKgnY6OpIF+UpEIss3BX+VMF5kKEW+yUjvS6EMd7Oi2/bN4= 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=6rRYb7iE2/ehyRmOeNSi7D/OfvM=; b=U/hmkU4DTTL Tp51rDcB2ej2b9fwUg1RUyO6dbXQ6MO2ac3vwK7JIt1Hp7+6hOSYC5HenO30AmsM w6ZBlPm+68A52A2a23ZIBmnoP33tagxUBgVxMlReUN4sdwGCNf2KGX53KJ+sR61M xwPeDpX0mFxR6erxB5pXe1YVvRdyaXWg= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 9F5326B0078 for ; Mon, 11 Apr 2011 12:52:05 -0700 (PDT) Received: by vws12 with SMTP id 12so5537190vws.31 for ; Mon, 11 Apr 2011 12:52:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.188.230 with SMTP id gd6mr2766399vdc.294.1302551524979; Mon, 11 Apr 2011 12:52:04 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Mon, 11 Apr 2011 12:52:04 -0700 (PDT) In-Reply-To: <4DA355E9.2030606@gnutls.org> References: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> <4DA2A1E4.5020005@gnutls.org> <4DA355E9.2030606@gnutls.org> Date: Mon, 11 Apr 2011 14:52:04 -0500 Message-ID: From: Nico Williams To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 23:40:29 -0000 On Mon, Apr 11, 2011 at 2:26 PM, Nikos Mavrogiannopoulos wrote: > On 04/11/2011 07:16 PM, Nico Williams wrote: >>> * Renegotiation semantics are unclear. When one is supposed to do >>> renegotiation? How to distinguish data before a renegotiation and >>> after? (especially since application data are allowed to be >>> processed during a renegotiation). See also >>> http://www.ietf.org/mail-archive/web/tls/current/msg05607.html >> I thought it was clear enough: when the client wants to do it (even >> though the server can ask the client to do it, the client needn't do >> it until it's ready). =C2=A0But of course, the devil's in the detail... >> And ultimately this ties into what the actual APIs look like, >> because the application really needs to be in charge of >> renegotiation boundaries (i.e., when the server wants it, and when >> the client starts it). > > I wasn't clear enough. RFC5246 mentions: > =C2=A0 =C2=A0"HelloRequest is a simple notification that the client shoul= d begin > =C2=A0 =C2=A0 the negotiation process anew. =C2=A0In response, the client= should send > =C2=A0 =C2=A0 a ClientHello message when convenient. " > So when is convenient? For how long should a server wait for > renegotiation? Would it be wait for 10 application data packets? 10 > seconds? Forever? If I want to require renegotiation as a server > what should I do? It is not possible to implement the described semantics= . If you distinguish between "TLS" and "application" server then the answer should be obvious: the TLS implementation on the server side doesn't "wait" -it just sends the request on behalf of the application- while the application on the server side does whatever is appropriate for it. For example, an LDAP server might request renegotiation and treat the connection as unauthenticated until the client either renegotiates or, perhaps, does some acceptable LDAP SASL Bind operation. Similarly for IMAP, and other protocols for that matter. It seems silly to discuss renegotiation as a way to authenticate the client user without distinguishing between TLS and the application. This is why I keep harping on the need for abstract APIs: it helps draw such distinctions and delineate responsibility for different actions (e.g., TLS vs. application), and it helps implementors design actual APIs that provide the necessary functionality. Without abstract APIs we end up writing text like what you quote. Fortunately it is often/usually possible to analyze a situation such as this one from an API point of view and make the inference I drew above, and which I called "obvious" -- it's obvious to me, though only because I applied that p.o.v. Of course, you and/or others might disagree with this point of view, or you might point to examples where what got implemented conflicts with my interpretation of that text (though this latter wouldn't invalidate that interpretation). >>> [...] * TLS version negotiation. If 1.1 and 1.3 is implemented, >>> then negotiation will always fail if talking to a 1.2 server. This >>> requires a client to implement all possible TLS protocols instead >>> of the latest and a fallback (e.g. TLS 1.0). >> Hopefully there will not be a TLS 1.3. =C2=A0Instead we should use all >> the extensibility in 1.2 to avoid the need for 1.3. > > The same problem exists for TLS 1.2 and TLS 1.0. I cannot skip > the implementation of TLS 1.1, if I would like to. This is not > a problem for my implementation in particular, but newcomers > would probably want to implement the latest version and a > fallback such as TLS 1.0 or SSL 3.0. This is not possible today. > One has to implement the whole list of published protocols. That is very sad. How much work is it to implement 1.1 though, if you already have 1.0 and 1.2? I suspect it's not that much. Implementing 1.2 if you have 1.1 and 1.3 might be a huge PITA, however, depending on what ever goes into 1.3. Nico -- From pgut001@login01.cs.auckland.ac.nz Tue Apr 12 06:54:07 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CF2DAE0699 for ; Tue, 12 Apr 2011 06:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.453 X-Spam-Level: X-Spam-Status: No, score=-3.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCJoqr-oOy0T for ; Tue, 12 Apr 2011 06:54:07 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id C6CD2E0697 for ; Tue, 12 Apr 2011 06:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1302616447; x=1334152447; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20nmav@gnutls.org,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[TLS]=20Proposed=20working=20group=20ch arter=20update|Cc:=20ekr@rtfm.com,=20paul.hoffman@vpnc.or g,=20tls@ietf.org|In-Reply-To:=20|Message-Id:=20|Date:=20Wed,=2013=20 Apr=202011=2001:54:01=20+1200; bh=EZhJm9VSl8Nv0Q55XjaAs2dqJexSNt6MZrXDxKMrwlw=; b=V9F/6m51WQFBN2MZD/eUA/MvRu41ARMiIsE9Fo0QDvyY37V/Ziihdmbv 6x6A916pSkgRNE3lgkfmFsN3JZI9a3IKy+j/FaRa0nrg6Y2GGJ5G33bFQ rU3DGAjaO+PSDHCyxxg7cKg4UtuYEr9N9HL/e6364cFoSlSmnaOlqAquZ 8=; X-IronPort-AV: E=Sophos;i="4.64,195,1301832000"; d="scan'208";a="56451773" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Apr 2011 01:54:02 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q9e2b-0005Fp-IO; Wed, 13 Apr 2011 01:54:01 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q9e2b-0000qw-LB; Wed, 13 Apr 2011 01:54:01 +1200 From: Peter Gutmann To: nmav@gnutls.org, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Wed, 13 Apr 2011 01:54:01 +1200 Cc: paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 12 Apr 2011 13:54:08 -0000 Nikos Mavrogiannopoulos writes: >If you do DTLS using the fancy-pancy SHA256 would take 32-bytes of your >datagram (which might be limited to 1400 bytes or so due to MTU), and having >a truncation mechanism that is really extensible in a sense that you could >cut the MAC on the security level negotiated would save precious bytes >without reducing the level. (given that the highest TLS security level is 96- >bits due to the finished message MAC, having a 256-bit MAC at the record >messages is pointless). Ah, good point. In fact you could truncate every MAC to about 64 bits without losing any security. >Given that there is hardware support in modern CPUs for GCM I think AEAD >support would increase. AES-GCM is a stream cipher, so there isn't a problem with this anyway. What you'd need is some as-yet-unspecified AEAD block cipher, if we haven't even got GCM support deployed then I don't think unspecified-block-cipher support is anything to worry about. Peter. From jsalowey@cisco.com Tue Apr 12 11:34:35 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 38608E0857 for ; Tue, 12 Apr 2011 11:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64W4C8a41LsY for ; Tue, 12 Apr 2011 11:34:34 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 351A0E067F for ; Tue, 12 Apr 2011 11:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=2065; q=dns/txt; s=iport; t=1302633274; x=1303842874; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=CnPOLrohkDymxZOyzRoV3I8WFDWxudsi6P3JEwtEwYw=; b=lpd7onP+9QlWpXFPuaIsn91dTxjsgSdOuskSp1RDl9SnhDDGUV6Ru9nf u4FshzjaT/pAUKBpWd2NBh7h27zFzpwVxIvWP7Z2hDIeqrmvZtwGYIs0W OzkPTeDwyblv5XuEGpFombXiITewEVqNMXOwn2z5XJlsbbCMbozd94EUZ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQHANSZpE2rRDoI/2dsb2JhbACYV40pd4h6nSSdBIVuBIVbiAeDbg X-IronPort-AV: E=Sophos;i="4.64,198,1301875200"; d="scan'208";a="335655884" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 12 Apr 2011 18:34:16 +0000 Received: from [10.33.251.67] ([10.33.251.67]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3CIYF6q010346; Tue, 12 Apr 2011 18:34:15 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <201104112242.p3BMgkwm016076@fs4113.wdf.sap.corp> Date: Tue, 12 Apr 2011 11:36:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1C784221-CED2-4740-9D96-E29CBDB7476C@cisco.com> References: <201104112242.p3BMgkwm016076@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 12 Apr 2011 18:34:35 -0000 On Apr 11, 2011, at 3:42 PM, Martin Rex wrote: > Joe Salowey wrote: >>=20 >> The primary goals of the WG are to maintain: >> - The TLS protocol, RFC 5246; >> The WG will attempt to avoid gratuitous changes to these protocols. >=20 > I'm irritated by this particular combination of statements. >=20 > It creates the impression that you want to preclude the TLS WG > from working on fixes for the problems of TLSv1.2 that have already > been identified. >=20 [Joe] This is not the intention. Fixes problems or clarifying the = protocol would be part of maintenance as long as the changes are not too = great. If the changes are significant then the work would require = adding to the charter. Depending upon the consensus around the issue = this can be difficult or not. Given the problems discussed on this = thread, if there were consensus to address them, it does not seem to me = they would require a modification to the charter. There could be some = approaches to solving these problems (such as changing the TLS version = number) that would require changing the charter. I'll try to come up = with some better wording. =20 >=20 > Personally, I'm seeing so many problems with the original TLS protocol > version negotiation, that I think that needs to be changed as well > in order to improve the interop with the installed base and improved > migration to future protocol updates. >=20 >=20 > During its lifetime IPv4 was faced with challenges to its original > design. Anyhow, the IETF adopted CIDR at some point, and in spite > of initial fierce resistance against it, the IETF at some point = accepted > the existence and use of NAT to address problems of the real world. >=20 >=20 > I believe that we are seeing a divergence with the TLS specs from > the necessities and (interop) problems of the real world, and the TLS = WG > ought to be pragmatic and propose remedies for the real world, rather > than start religious wars about what a perfect world should look like. >=20 >=20 > -Martin From marsh@extendedsubset.com Tue Apr 12 12:18:32 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 22B3AE08A2 for ; Tue, 12 Apr 2011 12:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0MqTK8jTHSs for ; Tue, 12 Apr 2011 12:18:31 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfc.amsl.com (Postfix) with ESMTP id 8288CE0844 for ; Tue, 12 Apr 2011 12:18:31 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Q9j6a-000OIJ-16; Tue, 12 Apr 2011 19:18:28 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id DF68F6067; Tue, 12 Apr 2011 19:18:22 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+XHxELNHne0DdQ6P/9kJUbDz9L4O6YJ2k= Message-ID: <4DA4A57E.4060909@extendedsubset.com> Date: Tue, 12 Apr 2011 14:18:22 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 12 Apr 2011 19:18:32 -0000 On 04/12/2011 08:54 AM, Peter Gutmann wrote: > Nikos Mavrogiannopoulos writes: > >> If you do DTLS using the fancy-pancy SHA256 would take 32-bytes of your >> datagram (which might be limited to 1400 bytes or so due to MTU), and having >> a truncation mechanism that is really extensible in a sense that you could >> cut the MAC on the security level negotiated would save precious bytes >> without reducing the level. (given that the highest TLS security level is 96- >> bits due to the finished message MAC, having a 256-bit MAC at the record >> messages is pointless). > > Ah, good point. In fact you could truncate every MAC to about 64 bits without > losing any security. Does that really follow in practice? In order for the bad guy to arrange a situation where Finished messages could be collided he may need 2^49 or so active server and/or client sessions or handshake attempts in play at the same time. But a collision on a DTLS record MAC may simply need that quantity of data records in order to be useful. Most protocols will hopefully have far more data packets than handshake messages. So a Finished message collision seems categorically harder than a data record collision. Many of us feel that the 96-bit Finished.verify_data length is too short, but thankfully there are some mitigating factors that seem to make an attack impractical. We should not then interpret it as an absolute 48-bit ceiling on the security factor which justifies adjusting the strength of other parts of the system downwards. - Marsh From n.mavrogiannopoulos@gmail.com Tue Apr 12 13:28:25 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0AB17E0926 for ; Tue, 12 Apr 2011 13:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSdArJ8yqMxi for ; Tue, 12 Apr 2011 13:28:24 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 2735AE0916 for ; Tue, 12 Apr 2011 13:28:24 -0700 (PDT) Received: by wyb29 with SMTP id 29so6659628wyb.31 for ; Tue, 12 Apr 2011 13:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=sj//c82LduLuAyqTyg64NYQwZnyXEI/6tIpI8MQbYpI=; b=gG+/ZF9KZw2xYQ6th75YIV4ffTM+d0Kr4ZkraqRJmz4ThsFVYIhh4TwjsKtgm7eYA8 BJNpBAxbRgPcZYLCpe7cPwGlNCvGqHc95A5DNe+fik/bnyS/uKLUZavGsqeiQZBW6v93 eCDp2q+zgugQz0fzOvfMTOnX2MyoWbJizX774= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=irIgLiLOhDporkJFmSQeeYntaJ5bB81y5g5Up6rllyIIZwY4Ve9Ftlquqa7N6uxv0Q 3tJLKJeVxQTy4yVjisHMaCq64veUsR0NQMy204IOGSKGfiKwc0IWgFmfwmxyt/oHK0cc hITUao9sXeTcLizCUR76aIKmy8lVFDcwjDkAc= Received: by 10.227.1.102 with SMTP id 38mr2511442wbe.109.1302640103472; Tue, 12 Apr 2011 13:28:23 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id w12sm781533wby.24.2011.04.12.13.28.19 (version=SSLv3 cipher=OTHER); Tue, 12 Apr 2011 13:28:21 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4DA4B5E2.9060400@gnutls.org> Date: Tue, 12 Apr 2011 22:28:18 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Marsh Ray References: <4DA4A57E.4060909@extendedsubset.com> In-Reply-To: <4DA4A57E.4060909@extendedsubset.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, paul.hoffman@vpnc.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 12 Apr 2011 20:28:25 -0000 On 04/12/2011 09:18 PM, Marsh Ray wrote: >> Ah, good point. In fact you could truncate every MAC to about 64 bits >> without >> losing any security. > Does that really follow in practice? > In order for the bad guy to arrange a situation where Finished messages > could be collided he may need 2^49 or so active server and/or client > sessions or handshake attempts in play at the same time. But a collision > on a DTLS record MAC may simply need that quantity of data records in > order to be useful. Most protocols will hopefully have far more data > packets than handshake messages. So a Finished message collision seems > categorically harder than a data record collision. Why is that? Both are fatal if verification fails, thus any attack would have the same effect being on finished message or record message. > Many of us feel that the 96-bit Finished.verify_data length is too > short, but thankfully there are some mitigating factors that seem to > make an attack impractical. The same factors make the attack impractical for application data records that have much larger MAC attached to them. I don't see why there needs to be a different handling of those two MACs. regards, Nikos From n.mavrogiannopoulos@gmail.com Tue Apr 12 13:30:05 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D8634E0916 for ; Tue, 12 Apr 2011 13:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeQkIWcRV40v for ; Tue, 12 Apr 2011 13:30:05 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id F1D85E090C for ; Tue, 12 Apr 2011 13:30:04 -0700 (PDT) Received: by wyb29 with SMTP id 29so6660799wyb.31 for ; Tue, 12 Apr 2011 13:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=ewHNYYIlvvTpHKrinnqZEoBgtVL6HRCfBhKh3TL5cSI=; b=sbh7aaCi5RrTW6MFHUITLH4rPhKM/bFaNc03rv/caf7EdbMy1gE0ehY+wViimDyCFC xPzVHNwihyiUQOfiJxc7VMfHnubnONaPEaLCCKaQBF3cteeU+u+GR14A19VYzRlnVu7o WFUw8JLoxpMbi8j9eBLlK0amFJTa9VDYWQggo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=Iao5tMoxniNfvy3mkpxma4phKBlyNugHS5rnQnDdyFYOwq4TKTLSbxzhUXYQlRhOLr OPlE3PgHhD+w4MEMJwTPAzR9lyQqIWvqDZL5jvlxoeB7EDhqWAAMJsP8OK0JnL0g++gz lM9ddglj4KKNju/aSOdZAD7DXy7gt3v/5bXEw= Received: by 10.216.62.129 with SMTP id y1mr2352186wec.61.1302640204293; Tue, 12 Apr 2011 13:30:04 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id c54sm3374731wer.6.2011.04.12.13.30.02 (version=SSLv3 cipher=OTHER); Tue, 12 Apr 2011 13:30:03 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4DA4B649.4060509@gnutls.org> Date: Tue, 12 Apr 2011 22:30:01 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 12 Apr 2011 20:30:06 -0000 On 04/12/2011 03:54 PM, Peter Gutmann wrote: > Nikos Mavrogiannopoulos writes: > >> If you do DTLS using the fancy-pancy SHA256 would take 32-bytes of your >> datagram (which might be limited to 1400 bytes or so due to MTU), and having >> a truncation mechanism that is really extensible in a sense that you could >> cut the MAC on the security level negotiated would save precious bytes >> without reducing the level. (given that the highest TLS security level is 96- >> bits due to the finished message MAC, having a 256-bit MAC at the record >> messages is pointless). > > Ah, good point. In fact you could truncate every MAC to about 64 bits without > losing any security. Do you mean to 96-bits? With 64-bits you lower your security level to 64-bits from 96. regards, Nikos From marsh@extendedsubset.com Tue Apr 12 14:27:31 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7ADD5E0987 for ; Tue, 12 Apr 2011 14:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1++g+IQwljHB for ; Tue, 12 Apr 2011 14:27:30 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfc.amsl.com (Postfix) with ESMTP id EFA3CE0976 for ; Tue, 12 Apr 2011 14:27:29 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Q9koa-0008pk-23; Tue, 12 Apr 2011 21:08:00 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D94AE606B; Tue, 12 Apr 2011 21:27:20 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1++Z+yl5kMaKdWVy3qMA0byaYngQSX+H60= Message-ID: <4DA4C3B8.3030804@extendedsubset.com> Date: Tue, 12 Apr 2011 16:27:20 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <4DA4A57E.4060909@extendedsubset.com> <4DA4B5E2.9060400@gnutls.org> In-Reply-To: <4DA4B5E2.9060400@gnutls.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, paul.hoffman@vpnc.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 12 Apr 2011 21:27:31 -0000 On 04/12/2011 03:28 PM, Nikos Mavrogiannopoulos wrote: > > On 04/12/2011 09:18 PM, Marsh Ray wrote: >> So a Finished message collision seems categorically harder than a >> data record collision. > > Why is that? Both are fatal if verification fails, thus any attack > would have the same effect being on finished message or record > message. The DTLS RFC sums up one way they are different: http://tools.ietf.org/html/rfc4347#section-4.1.2 > > Note that one important difference between DTLS and TLS MAC handling > is that in TLS MAC errors must result in connection termination. In > DTLS, the receiving implementation MAY simply discard the offending > record and continue with the connection. This change is possible > because DTLS records are not dependent on each other in the way that > TLS records are. > > In general, DTLS implementations SHOULD silently discard data with > bad MACs. This is comparing DTLS and TLS record MACs, but Finished messages are analogous to TLS record MACs in that they are consipcuously fatal. I admit it's not a rigorous argument, but it just seems a bit more plausible that a DTLS endpoint would silently discard 2^(security factor) datagrams than that a client or server experiencing a similar number of handshake failures would go unnoticed. - Marsh From ekr@rtfm.com Tue Apr 12 14:39:39 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9E0A5E0980 for ; Tue, 12 Apr 2011 14:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=0.668, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbZGe3ku8cig for ; Tue, 12 Apr 2011 14:39:39 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id E9AB4E0809 for ; Tue, 12 Apr 2011 14:39:38 -0700 (PDT) Received: by iye19 with SMTP id 19so8739340iye.31 for ; Tue, 12 Apr 2011 14:39:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.227.194 with SMTP id jb2mr5518266icb.454.1302644378534; Tue, 12 Apr 2011 14:39:38 -0700 (PDT) Received: by 10.42.241.5 with HTTP; Tue, 12 Apr 2011 14:39:38 -0700 (PDT) In-Reply-To: <4DA4C3B8.3030804@extendedsubset.com> References: <4DA4A57E.4060909@extendedsubset.com> <4DA4B5E2.9060400@gnutls.org> <4DA4C3B8.3030804@extendedsubset.com> Date: Tue, 12 Apr 2011 14:39:38 -0700 Message-ID: From: Eric Rescorla To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, paul.hoffman@vpnc.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 12 Apr 2011 21:39:39 -0000 On Tue, Apr 12, 2011 at 2:27 PM, Marsh Ray wrote= : > On 04/12/2011 03:28 PM, Nikos Mavrogiannopoulos wrote: >> >> On 04/12/2011 09:18 PM, Marsh Ray wrote: >>> >>> So a Finished message collision seems categorically harder than a >>> data record collision. >> >> Why is that? Both are fatal if verification fails, thus any attack >> would have the same effect being on finished message or record >> message. > > The DTLS RFC sums up one way they are different: > > http://tools.ietf.org/html/rfc4347#section-4.1.2 >> >> Note that one important difference between DTLS and TLS MAC handling >> is that in TLS MAC errors must result in connection termination. =A0In >> DTLS, the receiving implementation MAY simply discard the offending >> record and continue with the connection. =A0This change is possible >> because DTLS records are not dependent on each other in the way that >> TLS records are. >> >> In general, DTLS implementations SHOULD silently discard data with >> bad MACs. > > This is comparing DTLS and TLS record MACs, but Finished messages are > analogous to TLS record MACs in that they are consipcuously fatal. > > I admit it's not a rigorous argument, but it just seems a bit more plausi= ble > that a DTLS endpoint would silently discard 2^(security factor) datagrams > than that a client or server experiencing a similar number of handshake > failures would go unnoticed. I agree that DTLS is significantly more vulnerable to packet forgery at a g= iven MAC length than TLS. For a given MAC length, the chance that an arbitrary packet/MAC pair will verify is 2^{-k} where k is the number of bits in the MAC. With TLS, a= s the consequence of a failed MAC is that the connection is terminated, an attacker only gets one try per connection. With DTLS, because the packet is just dropped, you get an arbitrary number of trials per connection. Howe= ver, even for a 64-bit MAC, that means you would need to send 2^{64} packets in order to get a single accepted forgery, so that seems like a pretty high level of security. -Ekr From mrex@sap.com Tue Apr 12 17:20:17 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 72F2FE06D9 for ; Tue, 12 Apr 2011 17:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.964 X-Spam-Level: X-Spam-Status: No, score=-9.964 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoRRlCHuiEjz for ; Tue, 12 Apr 2011 17:20:16 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfc.amsl.com (Postfix) with ESMTP id 47F85E06B8 for ; Tue, 12 Apr 2011 17:20:16 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p3D0K34M001686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Apr 2011 02:20:03 +0200 (MEST) From: Martin Rex Message-Id: <201104130020.p3D0K20X013444@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Wed, 13 Apr 2011 02:20:02 +0200 (MEST) In-Reply-To: <878vvmy4cr.fsf@latte.josefsson.org> from "Simon Josefsson" at Apr 7, 11 08:15:16 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2011 00:20:17 -0000 Simon Josefsson wrote: > > Peter Gutmann writes: > > > > Hovav Shacham writes: > > > > > >How about we remove DSA support from TLS, then? The decision in 1997 to mandate DHE_DSS was more of a political than a technical decision, because the DH patent had just expired and the RSA patent would not expire until 2000 (albeit the RSA patent existed only in that part of the world where patent filing was allowed up to a year after publication). > > > Possibly a bit extreme, but we could at least mark it "historical" or > > "deprecated" or something. In fact we could do that for an awful lot of > > existing cipher suites. Note that this isn't changing the standard > > in any way, it's just documenting what's already the norm among > > implementations. If a cipher suite's been in there for ten years > > and there are, approximately, zero cases of it being used, then > > saying "Don't bother with this one" in order to help guide > > implementers seems sensible. > > Unfortunately I think DSA is still mandatory-to-implement in some > protocols. That makes it a bit more complicated, but still doable. DHE_DSS was mandatory to implement _only_ for TLSv1.0 (but not SSLv3!): TLSv1.0 http://tools.ietf.org/html/rfc2246#section-9 9. Mandatory Cipher Suites In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. TLSv1.1 http://tools.ietf.org/html/rfc4346#section-9 In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA. TLSv1.2 http://tools.ietf.org/html/rfc5246#section-9 In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition). The wording in that section 9 looks garbled to me. I assume this requirement was supposed to apply to "TLS compliant implementations", and not application callers of TLS (applications would not implement, but rather request cipher suites). In practice, a TLS implementation without these two cipher suites CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; will likely encounter interop problems with a number of TLS peers, whereas TLS implementations with _only_ RSA (no DH, no DHE, no DSS) hardly ever missed those cipher suites, except maybe in a few exotic PKIs. SSLv3 does not appear to have any mandatory cipher suites. Section D.1 of the SSL version 3 draft (draft302.txt) says this: D.4 CipherSuites SSL supports a range of key sizes and security levels, including some which provide no or minimal security. A proper implementation will probably not support many cipher suites. -Martin From geoffk@geoffk.org Tue Apr 12 17:43:49 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AAE9DE06AF for ; Tue, 12 Apr 2011 17:43:49 -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=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41S6u+KxR6g3 for ; Tue, 12 Apr 2011 17:43:49 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfc.amsl.com (Postfix) with ESMTP id E77ADE067D for ; Tue, 12 Apr 2011 17:43:48 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id E953233D162; Wed, 13 Apr 2011 00:43:45 +0000 (UTC) Sender: geoffk@localhost.localdomain To: mrex@sap.com References: <878vvmy4cr.fsf@latte.josefsson.org> <201104130020.p3D0K20X013444@fs4113.wdf.sap.corp> From: Geoffrey Keating Date: 12 Apr 2011 17:43:45 -0700 In-Reply-To: <201104130020.p3D0K20X013444@fs4113.wdf.sap.corp> Message-ID: Lines: 27 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 00:43:49 -0000 Martin Rex writes: > In practice, a TLS implementation without these two cipher suites > > CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; > CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; > > will likely encounter interop problems with a number of TLS peers, > whereas TLS implementations with _only_ RSA (no DH, no DHE, no DSS) > hardly ever missed those cipher suites, except maybe in a few > exotic PKIs. Actually, the first one is almost certainly not necessary for a client. A small fraction (less than 0.5%) of servers still require TLS_RSA_WITH_RC4_128_MD5, but generally if you have TLS_RSA_WITH_3DES_EDE_CBC_SHA you'll be OK, and you can reasonably add TLS_DHE_RSA_WITH_AES_256_CBC_SHA to obtain forward security on those servers that support it. Many servers do prefer RC4 (probably for performance reasons, if their alternative was 3DES!) but if it's not available they'll choose something else. There are some Internet hosts with a DSA key signed by a popular root CA, but we're talking 0.03% or so, and many of those are expired. For future work, I would ignore DSS. It has some useful characteristics in some circumstances, but ECDSA has the same characteristics and more. From pgut001@login01.cs.auckland.ac.nz Tue Apr 12 20:26:54 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D1B98E06C3 for ; Tue, 12 Apr 2011 20:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+p6d1+AjwJU for ; Tue, 12 Apr 2011 20:26:53 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id 4DB2AE066A for ; Tue, 12 Apr 2011 20:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1302665214; x=1334201214; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20geoffk@geoffk.org,=20mrex@sap.com|Subject:=20Re: =20[TLS]=20DSS=20with=20other=20than=20SHA-1=20algorithms |Cc:=20simon@josefsson.org,=20tls@ietf.org|In-Reply-To: =20|Message-Id:=20< E1Q9qjC-0005fy-Tk@login01.fos.auckland.ac.nz>|Date:=20Wed ,=2013=20Apr=202011=2015:26:50=20+1200; bh=ZorZ8Pv0aHR2Sbb6RvRzDOlff/NwN3mulavuubHIz/c=; b=npgyE9IjjBA4k2l5+qRiOpJG32Bc4aMgfjapAlSHDiVM5EqC6ue3Xuto vOm4d8Sq9zBYRcZMlzcV+aHGTwBC1InbYtdupkZxJpmt9/EO6+iE4r438 CQjpldGwLAtb7szB0PQEk0kX2qwosFjzspNvpREWKI9v1qwt5/GJbDePP I=; X-IronPort-AV: E=Sophos;i="4.64,202,1301832000"; d="scan'208";a="56569876" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Apr 2011 15:26:51 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q9qjC-0008Vl-JL; Wed, 13 Apr 2011 15:26:51 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q9qjC-0005fy-Tk; Wed, 13 Apr 2011 15:26:50 +1200 From: Peter Gutmann To: geoffk@geoffk.org, mrex@sap.com In-Reply-To: Message-Id: Date: Wed, 13 Apr 2011 15:26:50 +1200 Cc: simon@josefsson.org, tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 03:26:55 -0000 Geoffrey Keating writes: >For future work, I would ignore DSS. I missed a chance to comment on this earlier, but when someone asked "why would you need a TLS 1.3 when TLS 1.2 is infinitely extensible", my response would have been "we might need a TLS 1.3 precisely *because* TLS 1.2 is infinitely extensible and therefore potentially infinitely complex". TLS 1.3 would have the one or two standard cipher suites that everyone uses anway, the one or two standard hash algorithms that ..., and a fixed way of doing things that would satisfy (literally, from the figures we've seen posted here) about 99.995% of all users while vastly reducing the complexity (and thereby attack surface) of implementations. Speaking of fixing TLS 1.2 problems, what's the next move for the action list of TLS 1.2 issues I posted a week or so back? Can I get the edit token for TLS 1.2bis, or should I do a distinct draft that'll then be folded into a future TLS 1.2bis? Peter. From ekr@rtfm.com Tue Apr 12 22:33:38 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4FA77E0675 for ; Tue, 12 Apr 2011 22:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9MLwsZgRW0n for ; Tue, 12 Apr 2011 22:33:37 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id AC13BE065A for ; Tue, 12 Apr 2011 22:33:37 -0700 (PDT) Received: by iwn39 with SMTP id 39so335720iwn.31 for ; Tue, 12 Apr 2011 22:33:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.47.201 with SMTP id ut9mr5785100icb.186.1302672817231; Tue, 12 Apr 2011 22:33:37 -0700 (PDT) Received: by 10.42.241.5 with HTTP; Tue, 12 Apr 2011 22:33:37 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Apr 2011 22:33:37 -0700 Message-ID: From: Eric Rescorla To: Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: simon@josefsson.org, geoffk@geoffk.org, tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 05:33:38 -0000 On Tue, Apr 12, 2011 at 8:26 PM, Peter Gutmann = wrote > Speaking of fixing TLS 1.2 problems, what's the next move for the action = list > of TLS 1.2 issues I posted a week or so back? =A0Can I get the edit token= for TLS > 1.2bis, or should I do a distinct draft that'll then be folded into a fut= ure > TLS 1.2bis? With regard to the specific list of issues you raised: 1. I'm not convinced that the requirement that relying parties check the signature_algorithm should in fact be relaxed. In general, I believe that semantics that are requested in the protocol should indeed be enforced. However, even if we were to make this change, the simplest thing would be a standalone document that relaxed the requirement. 2. I don't have a problem with changing the name of SignatureAndHashAlgorithm in some future draft, but since this is basically an editorial change, I also don't think it merits a -bis. 3. The ECC issues you raise are not issues in 5246 at all, since ECC is specified in a different document (4492). So, with this list in mind, I don't believe a revision of 5246 is either necessary or appropriate at this time. -Ekr From ekr@rtfm.com Tue Apr 12 22:35:20 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6833FE067B for ; Tue, 12 Apr 2011 22:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUu2Ido1jL9M for ; Tue, 12 Apr 2011 22:35:19 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id D68CAE065A for ; Tue, 12 Apr 2011 22:35:19 -0700 (PDT) Received: by iwn39 with SMTP id 39so336904iwn.31 for ; Tue, 12 Apr 2011 22:35:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.60.205 with SMTP id wt13mr11495093icb.253.1302672919488; Tue, 12 Apr 2011 22:35:19 -0700 (PDT) Received: by 10.42.241.5 with HTTP; Tue, 12 Apr 2011 22:35:19 -0700 (PDT) In-Reply-To: <201104130020.p3D0K20X013444@fs4113.wdf.sap.corp> References: <878vvmy4cr.fsf@latte.josefsson.org> <201104130020.p3D0K20X013444@fs4113.wdf.sap.corp> Date: Tue, 12 Apr 2011 22:35:19 -0700 Message-ID: From: Eric Rescorla To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 05:35:20 -0000 On Tue, Apr 12, 2011 at 5:20 PM, Martin Rex wrote: > Simon Josefsson wrote: >> >> Peter Gutmann writes: >> > >> > Hovav Shacham writes: >> > > >> > >How about we remove DSA support from TLS, then? > > The decision in 1997 to mandate DHE_DSS was more of a political > than a technical decision, because the DH patent had just expired > and the RSA patent would not expire until 2000 (albeit the RSA > patent existed only in that part of the world where patent filing > was allowed up to a year after publication). Yes, I agree with that assessment of the situation. Not the IESG's finest hour, really. -Ekr From pgut001@login01.cs.auckland.ac.nz Tue Apr 12 23:20:09 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A1373E0687 for ; Tue, 12 Apr 2011 23:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvOGeGsQ9dgS for ; Tue, 12 Apr 2011 23:20:08 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id 8E8FFE065A for ; Tue, 12 Apr 2011 23:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1302675609; x=1334211609; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20ekr@rtfm.com,=20pgut001@cs.auckland.ac.nz|Subject: =20Re:=20[TLS]=20DSS=20with=20other=20than=20SHA-1=20algo rithms|Cc:=20geoffk@geoffk.org,=20mrex@sap.com,=20simon@j osefsson.org,=20tls@ietf.org|In-Reply-To:=20|Message-Id:=20|Date:=20Wed, =2013=20Apr=202011=2018:20:04=20+1200; bh=jUGEbeE1o5quApXx4KHDoCaT7Sb1HlKjApyzUYrHsP0=; b=LnrBZ9gq2gCcPXFieffau/CAWcrGGj/iEFMLLtgfGZy8G3dvIrIFNYJU IFbv0pI6+SRzaP5OLn+uXw911bBQQj73kBYjJNdoHeB57woA6VCvnw1NM VTTV4sQ0BjD1hVR73grDxh/RJd2URVZPPAQTahMGiABBq1oUX9/vlZ8zg c=; X-IronPort-AV: E=Sophos;i="4.64,202,1301832000"; d="scan'208";a="56604828" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Apr 2011 18:20:05 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q9tQr-0006gx-GC; Wed, 13 Apr 2011 18:20:05 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q9tQq-0006Q4-VU; Wed, 13 Apr 2011 18:20:04 +1200 From: Peter Gutmann To: ekr@rtfm.com, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Wed, 13 Apr 2011 18:20:04 +1200 Cc: simon@josefsson.org, geoffk@geoffk.org, tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 06:20:09 -0000 Eric Rescorla writes: >1. I'm not convinced that the requirement that relying parties check the >signature_algorithm should in fact be relaxed. This despite the fact that every single person who responded considered it a really bad idea (and some were far more vigorous in their comments than just "bad idea"), and that no implementation actually checks it? This sort of approach sounds more like PKIX than TLS. >3. The ECC issues you raise are not issues in 5246 at all, since ECC is >specified in a different document (4492). 5246 claims to be an update to 4492 (line 4 of the doc), and a far more drastic one than just adding a few new cipher suites since it's not backwards-compatible with 4492. This would be just another update of 4492, and one that's fully backwards-compatible. Peter. From pgut001@login01.cs.auckland.ac.nz Wed Apr 13 00:00:47 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F0CF1E070D for ; Wed, 13 Apr 2011 00:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4axSrwCtfBg for ; Wed, 13 Apr 2011 00:00:46 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id EABA8E0674 for ; Wed, 13 Apr 2011 00:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1302678046; x=1334214046; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20nmav@gnutls.org,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[TLS]=20Proposed=20working=20group=20ch arter=20update|Cc:=20ekr@rtfm.com,=20paul.hoffman@vpnc.or g,=20tls@ietf.org|In-Reply-To:=20<4DA4B649.4060509@gnutls .org>|Message-Id:=20|Date:=20Wed,=2013=20Apr=202011=2019:00:44=20+12 00; bh=5MU5m6LJbH9NApqkQPB6XvyFkgnshhyks+/FVSHGkCg=; b=Bdf5ZvmiqvPDggd7PEkVKbli3VzkJh9Ek6zKVYHKVm0LaN0g573a7GeK DLF+VHY8btOmdmA4IEwKUrLw34xSg+1F3zv/lo17E8v2z9BYsnZxki8kk Qt4/L5YJpzPEOxIiTtsp+9qrMjtgYZTgk+eI5sIddaynNCoIHLnok5hBZ o=; X-IronPort-AV: E=Sophos;i="4.64,203,1301832000"; d="scan'208";a="56606994" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Apr 2011 19:00:45 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q9u4C-0007zk-J2; Wed, 13 Apr 2011 19:00:44 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q9u4C-0008QA-Qe; Wed, 13 Apr 2011 19:00:44 +1200 From: Peter Gutmann To: nmav@gnutls.org, pgut001@cs.auckland.ac.nz In-Reply-To: <4DA4B649.4060509@gnutls.org> Message-Id: Date: Wed, 13 Apr 2011 19:00:44 +1200 Cc: paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] Proposed working group charter update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 07:00:47 -0000 Nikos Mavrogiannopoulos writes: >Do you mean to 96-bits? With 64-bits you lower your security level to 64-bits >from 96. No, I meant 64. Having a 1 in 2^64 chance to guess a MAC isn't going to make things any easier for an attacker than a 1 in 2^96 chance (for pure TLS, where you get one guess and then get disconnected). For DTLS it's a little bit easier, but still astronomically remote. Peter. From juhovh@iki.fi Wed Apr 13 01:12:55 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 84C32E06A5 for ; Wed, 13 Apr 2011 01:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2T9d8M-S-AY for ; Wed, 13 Apr 2011 01:12:54 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfc.amsl.com (Postfix) with ESMTP id 5E861E0789 for ; Wed, 13 Apr 2011 01:12:54 -0700 (PDT) Received: from [192.168.1.100] (88.192.44.252) by kirsi2.inet.fi (8.5.133) id 4D959687001826C6; Wed, 13 Apr 2011 11:12:19 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= In-Reply-To: Date: Wed, 13 Apr 2011 11:11:18 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8431E43B-DCE8-4233-AF17-2BFDF8C7F736@iki.fi> References: To: Peter Gutmann X-Mailer: Apple Mail (2.1084) Cc: simon@josefsson.org, geoffk@geoffk.org, tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 08:12:55 -0000 On Apr 13, 2011, at 9:20 AM, Peter Gutmann wrote: > Eric Rescorla writes: >=20 >> 1. I'm not convinced that the requirement that relying parties check = the=20 >> signature_algorithm should in fact be relaxed. >=20 > This despite the fact that every single person who responded = considered it a=20 > really bad idea (and some were far more vigorous in their comments = than just=20 > "bad idea"), and that no implementation actually checks it? This sort = of > approach sounds more like PKIX than TLS. Personally I was pretty shocked by this comment, should someone gather = the related discussion from the mailing list into a single statement, in = case the consensus wasn't clear enough already? I think there was only = one argument for the strict checking, which was constrained devices that = don't want to implement multiple hash functions and signing methods. But = the bad sides presented clearly outweighed the good sides, having = multiple certificates for each hash function just to fill this = requirement in TLS 1.2 is simply not going to happen... It's far more = likely that either the strict checking is ignored or TLS 1.2 is not = implemented at all. Juho From ekr@rtfm.com Wed Apr 13 06:47:19 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C3361E06C6 for ; Wed, 13 Apr 2011 06:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHAkgAH7LINu for ; Wed, 13 Apr 2011 06:47:19 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfc.amsl.com (Postfix) with ESMTP id 29B0BE06BD for ; Wed, 13 Apr 2011 06:47:19 -0700 (PDT) Received: by ywi6 with SMTP id 6so312471ywi.31 for ; Wed, 13 Apr 2011 06:47:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.47.201 with SMTP id ut9mr6441179icb.186.1302702438678; Wed, 13 Apr 2011 06:47:18 -0700 (PDT) Received: by 10.42.241.5 with HTTP; Wed, 13 Apr 2011 06:47:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Apr 2011 06:47:18 -0700 Message-ID: From: Eric Rescorla To: Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: simon@josefsson.org, geoffk@geoffk.org, tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 13:47:19 -0000 On Tue, Apr 12, 2011 at 11:20 PM, Peter Gutmann wrote: >>3. The ECC issues you raise are not issues in 5246 at all, since ECC is >>specified in a different document (4492). > > 5246 claims to be an update to 4492 (line 4 of the doc), and a far more > drastic one than just adding a few new cipher suites since it's not > backwards-compatible with 4492. =A0This would be just another update of 4= 492, > and one that's fully backwards-compatible. Yes, the "Updates:" language in IETF documents isn't very expressive. Sorry about that. Regardless, if you want to do a document which only affects ECC algorithms, the appropriate place to do it is in a separate document, not as a revision to 5246. -Ekr From mrex@sap.com Wed Apr 13 08:06:21 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8243BE078F for ; Wed, 13 Apr 2011 08:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.971 X-Spam-Level: X-Spam-Status: No, score=-9.971 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcSsvg1UcuJ7 for ; Wed, 13 Apr 2011 08:06:20 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfc.amsl.com (Postfix) with ESMTP id 931B7E0778 for ; Wed, 13 Apr 2011 08:06:19 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p3DF6Hvr011995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Apr 2011 17:06:17 +0200 (MEST) From: Martin Rex Message-Id: <201104131506.p3DF6H3X003459@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Wed, 13 Apr 2011 17:06:17 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Apr 13, 11 06:47:18 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2011 15:06:21 -0000 Eric Rescorla wrote: > > Peter Gutmann wrote: > > >>3. The ECC issues you raise are not issues in 5246 at all, since ECC is > >>specified in a different document (4492). > > > > 5246 claims to be an update to 4492 (line 4 of the doc), and a far more > > drastic one than just adding a few new cipher suites since it's not > > backwards-compatible with 4492.  This would be just another update of 4492, > > and one that's fully backwards-compatible. rfc5246 is explicit about the little it updates: http://tools.ietf.org/html/rfc5246#appendix-A.7 > > Yes, the "Updates:" language in IETF documents isn't very expressive. > Sorry about that. Regardless, if you want to do a document which only > affects ECC algorithms, the appropriate place to do it is in a > separate document, not as a revision to 5246. I think we need both. An update to rfc-5246 to standardize the use of DSA & ECDSA with hash function beyond SHA-1, and then an update of rfc4492 to make use of this and to profile a reasonable subset of algorithm parameters. See last paragraph of Section 7.4.8 Certificate Verify, rfc5246 http://tools.ietf.org/html/rfc5246#section-7.4.8 Because DSA signatures do not contain any secure indication of hash algorithm, there is a risk of hash substitution if multiple hashes may be used with any key. Currently, DSA [DSS] may only be used with SHA-1. Future revisions of DSS [DSS-3] are expected to allow the use of other digest algorithms with DSA, as well as guidance as to which digest algorithms should be used with each key size. In addition, future revisions of [PKIX] may specify mechanisms for certificates to indicate which digest algorithms are to be used with DSA. Since truncation of SHA-256 for DSA keypairs with public prime q shorter than the hash output size is actually well-defined in FIPS 186-3, a pragmatic approach for TLSv1.2 would have been to use SHA-256 rather than SHA-1 throughout by default, i.e. including for the handshake message hash that goes into the ClientVerify handshake message, the signature in the ServerKeyExchange handshake message and the input to the PRF. We cannot fix that for TLSv1.2 (rfc5246), as it would be backwards- incompatible, so our fixing options are either to define a TLS extension (which could be used in TLSv1.0 and TLSv1.1 with ease), or to define a TLSv1.3. Considering the undesirable impact of the rfc5246 SignatureAndHashAlgorithm on the original TLS design (not knowing which hash algorithm is going to be used for the handshake message hash of the CertifcateVerify handshake message in TLSv1.2), so I do not think it would be sensible to define TLSv1.3 without fixing that part of TLSv1.2. -Martin From juhovh@gmail.com Wed Apr 13 09:33:54 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 26563E07C7 for ; Wed, 13 Apr 2011 09:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QHXqmb6XRzr for ; Wed, 13 Apr 2011 09:33:53 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfc.amsl.com (Postfix) with ESMTP id 22DBEE07CF for ; Wed, 13 Apr 2011 09:33:53 -0700 (PDT) Received: by ewy19 with SMTP id 19so276445ewy.31 for ; Wed, 13 Apr 2011 09:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=CcYHvpG4uAmddENgVuO5q4rM/R9QglUV6Qbf9p3wSlg=; b=AgwTbR/dYT5teo+iWlsDHf4hzpNohk3mT6q2UCpM/qTy3NC1XOjKsZHR+mn/pmyg4n +ebFSGQbOZ7pQIbjQ6DDDiaipRbpz3CzqV1wwMksYRIuI15k379eGoLJMH4j7bzKlXnB um//CBpJhzDs1+7KERRus79vB5ERQ9x9mW2kI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=TWwQ/Xk4s5c+sfhdASfyof7tNMMbkFMUpy99gAJl1p3wAAmYp0/qS8Tj+wYEewmVyB GLZTTit1M2zz7EFCBF7l+/Beq/599gsA4OD20eRRShU11zU0OfOt/+PwSY40KTaGK/TP 8HU6Y8b7tOZ4dF2NM60b0/lHIxHNi5gtTjRw0= Received: by 10.213.20.78 with SMTP id e14mr295901ebb.74.1302712432161; Wed, 13 Apr 2011 09:33:52 -0700 (PDT) Received: from [192.168.1.100] (dsl-hkibrasgw3-ff2cc000-252.dhcp.inet.fi [88.192.44.252]) by mx.google.com with ESMTPS id x54sm513503eeh.5.2011.04.13.09.33.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2011 09:33:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "=?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?=" In-Reply-To: Date: Wed, 13 Apr 2011 19:33:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4da5d06e.ce7c0e0a.71c9.1ce4@mx.google.com> References: To: Peter Gutmann X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 13 Apr 2011 09:47:52 -0700 Cc: simon@josefsson.org, geoffk@geoffk.org, tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:33:54 -0000 On Apr 13, 2011, at 9:20 AM, Peter Gutmann wrote: >> 3. The ECC issues you raise are not issues in 5246 at all, since ECC = is=20 >> specified in a different document (4492). >=20 > 5246 claims to be an update to 4492 (line 4 of the doc), and a far = more=20 > drastic one than just adding a few new cipher suites since it's not=20 > backwards-compatible with 4492. This would be just another update of = 4492, > and one that's fully backwards-compatible. I had to go to dig out the original email describing the ECC issues, = because I didn't read it well enough the first time. I was wondering if you = could clarify the following statement a bit: Sub-issue: The overall suite chosen can be retroactively modified by ECC parameters sent later in the handshake, so when choosing a suite you = have to remember not only the main suite but also one (or possibly more) backup = suites to fall back on if a later ECC parameter means you can't use your first choice. I don't see how this works, because in case of ECC the server is always selecting the cipher suite and sending the ServerKeyExchange, and these = both happen between ServerHello and ServerHelloDone. What did I miss? Otherwise I think we can agree that the ECC extension in TLS is very = complex, but then again I'm happy that it doesn't mandate for example supporting = P256 curve, because I'm working with devices that wouldn't have the resources = for handling it. Juho From pgut001@login01.cs.auckland.ac.nz Wed Apr 13 18:38:21 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 185BAE0781 for ; Wed, 13 Apr 2011 18:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3w1fB-wB4VkI for ; Wed, 13 Apr 2011 18:38:20 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id EE5ABE05F5 for ; Wed, 13 Apr 2011 18:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1302745100; x=1334281100; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20ekr@rtfm.com,=20pgut001@cs.auckland.ac.nz|Subject: =20Re:=20[TLS]=20DSS=20with=20other=20than=20SHA-1=20algo rithms|Cc:=20geoffk@geoffk.org,=20mrex@sap.com,=20simon@j osefsson.org,=20tls@ietf.org|In-Reply-To:=20|Message-Id: =20|Date: =20Thu,=2014=20Apr=202011=2013:38:13=20+1200; bh=oS8pm3KehNK/ai6MzKmNbiRWQE+pYN2q1ewVTFllFho=; b=V9B7efQQR+f5+9Myljqs05nJU9dhg1wqjMnjy6+SYNLJsmyXdeKsqHGV ZOxdwQ6WcT/bYvYsuVChLAsJNBk5316YxzFryPSE8UEWEMn2800MUA61m mqmwhtabmoiFytWEhf3AFD4fnepghizxW9+LIITHZBp+ifMTEmbClLeVL s=; X-IronPort-AV: E=Sophos;i="4.64,208,1301832000"; d="scan'208";a="56738278" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Apr 2011 13:38:14 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QABVd-0002rV-Is; Thu, 14 Apr 2011 13:38:13 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QABVd-000387-P9; Thu, 14 Apr 2011 13:38:13 +1200 From: Peter Gutmann To: ekr@rtfm.com, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Thu, 14 Apr 2011 13:38:13 +1200 Cc: simon@josefsson.org, geoffk@geoffk.org, tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 01:38:21 -0000 Eric Rescorla writes: >the appropriate place to do it is in a separate document, not as a revision >to 5246. OK, I'll get to work on that. It would be good to be able to connect to an ECC-suporting server and not have to iteratively guess what parameters you need to send it to get it to connect. Peter. From iesg-secretary@ietf.org Thu Apr 14 14:13:28 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 70EE2E08AC; Thu, 14 Apr 2011 14:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5ECSGiw1NHJ; Thu, 14 Apr 2011 14:13:27 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1DF3FE083A; Thu, 14 Apr 2011 14:13:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce , tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.51 Message-ID: <20110414211327.23921.25373.idtracker@ietfc.amsl.com> Date: Thu, 14 Apr 2011 14:13:27 -0700 Subject: [TLS] Second Last Call: (Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)) to Informational RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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: Thu, 14 Apr 2011 21:13:28 -0000 The IESG has received a request from an individual submitter to consider the following document: - 'Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)' as an Informational RFC This SECOND last call has been made because an IPR disclosure was received after the first IETF LC was initiated. 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 2011-05-12. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-kanno-tls-camellia/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-kanno-tls-camellia/ IPR disclosures for this document exist: https://datatracker.ietf.org/ipr/1502/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1502/ From pgut001@login01.cs.auckland.ac.nz Sat Apr 16 01:10:35 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DD1E8E067D for ; Sat, 16 Apr 2011 01:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bYs+FIxXoGJ for ; Sat, 16 Apr 2011 01:10:33 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id 74304E0675 for ; Sat, 16 Apr 2011 01:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1302941434; x=1334477434; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20juhovh@gmail.com,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[TLS]=20DSS=20with=20other=20than=20SHA -1=20algorithms|Cc:=20ekr@rtfm.com,=20geoffk@geoffk.org, =20simon@josefsson.org,=20tls@ietf.org|In-Reply-To:=20<4d a5d06e.ce7c0e0a.71c9.1ce4@mx.google.com>|Message-Id:=20|Date:=20Sat, =2016=20Apr=202011=2020:10:24=20+1200; bh=jGsOww1e6vVnOOpujpAnEseJBlrWVBuHEv+V+TDqqNI=; b=iQnSWdeRO048okCDLALJXHh/1LOIhGOSEvOh9chk/uDJL7+rdTcOMZSs 9f73sh454JqEnCN7ErHwuFW7Gvp6DqxOjZPCVHD1Ns2RTGqd6CxfoLFvP tsiEoa1EEazzcpipDO+G7+1LhAR/pNa8uk5jsXV2LHr4KskEqGR/XVarr k=; X-IronPort-AV: E=Sophos;i="4.64,223,1301832000"; d="scan'208";a="57016298" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 16 Apr 2011 20:10:25 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QB0aG-0005UF-Ic; Sat, 16 Apr 2011 20:10:24 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QB0aG-0005xJ-NJ; Sat, 16 Apr 2011 20:10:24 +1200 From: Peter Gutmann To: juhovh@gmail.com, pgut001@cs.auckland.ac.nz In-Reply-To: <4da5d06e.ce7c0e0a.71c9.1ce4@mx.google.com> Message-Id: Date: Sat, 16 Apr 2011 20:10:24 +1200 Cc: simon@josefsson.org, geoffk@geoffk.org, tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 08:10:36 -0000 "=?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?=" writes: >I don't see how this works, because in case of ECC the server is always >selecting the cipher suite and sending the ServerKeyExchange, and these both >happen between ServerHello and ServerHelloDone. What did I miss? Say you (i.e. the server) see, and select, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, as the best suite. Then later in the exchange the client says, via an extension, that it wants to do P256, which isn't really suited for use with SHA384 (unless you go through odd truncation calisthenics, but then why use a hash with a key size that's too short for it?), so you have to go back and reprocess the hello to see if there's something with SHA256 present to match that. Then you go back and reprocess the extensions to see whether that's OK. In the end you may end up falling back to a non-ECC suite, depending on your heuristics. Of course no implementation actually does this, they just fail the handshake unless they see the exact parameters they want. In practice it's even worse than that, you can use completely different curves for the key exchange, to sign the key exchange, and for client auth, and for hashes it's nearly as bad. What are you supposed to do if an implementation uses (say) P192 for the keyex signature but P521 for the keyex itself? What security level do you treat this as being? You can use the unnncessary flexibility to make a complete mess of things, and from the little testing I've done almost anything you do that's slightly unusual results in a handshake failure or dropped connection, and I don't even want to try and see what happens when you start using the really odd capabilities, non-named curves and point compression and other oddities. So at the moment we already have a kind of de facto profile, mostly it seems to be P256+SHA256 everywhere, with optional P384+SHA384 everywhere, and I think I got away with P521 once or twice. The single profile we have for ECC use with TLS, the Suite B one, already does this, it's 256-throughout (ECC keys and hashes) or 384-throughout (ECC keys and hashes). Peter. From juhovh@iki.fi Sat Apr 16 12:18:47 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 35734E073E for ; Sat, 16 Apr 2011 12:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvxPB84YCoem for ; Sat, 16 Apr 2011 12:18:45 -0700 (PDT) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by ietfc.amsl.com (Postfix) with ESMTP id A41E0E065F for ; Sat, 16 Apr 2011 12:18:45 -0700 (PDT) Received: from [172.20.10.2] (GYYYDCCXXVII.gprs.sl-laajakaista.fi [85.77.27.227]) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id DD8462165EB; Sat, 16 Apr 2011 22:18:22 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= In-Reply-To: Date: Sat, 16 Apr 2011 22:18:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Peter Gutmann X-Mailer: Apple Mail (2.1084) Cc: simon@josefsson.org, geoffk@geoffk.org, tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 19:18:47 -0000 On Apr 16, 2011, at 11:10 AM, Peter Gutmann wrote: > Say you (i.e. the server) see, and select, > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, as the best suite. Then = later in the > exchange the client says, via an extension, that it wants to do P256, = which I'm sorry I probably wasn't clear enough in my message. I was trying to = ask, when exactly will the client say that it wants to do P256? Are we = talking about an exchange where the client doesn't send the = elliptic_curves extension in its hello message? Because how I see the = ECC handshake is pretty much like: 1. Client sends a ClientHello with elliptic_curves extension specifying = its supported extensions 2. Server selects an ECC cipher suite and a curve that can be found in = its supported curves list and client's supported curves list 3. Server sends its Certificate message which includes the curve OID of = ECDSA public key (server might want to check that this can be found from = elliptic_curves extension, but I'm still not quite sure that TLS should = care about PKIX too much) 4. Server sends its ServerKeyExchange message which includes the curve = it selected 5. Client uses the information from ServerKeyExchange and uses the same = curve to send ClientKeyExchange I tried to think of how this could be broken and could only think of the = case where client doesn't send elliptic_curves extension. In that case = it becomes really complicated, but doesn't seem so serious because it = can be solved by simply sending the extension. And the specification = could be MUCH more clear about all this, it took me quite a long time to = find out how the ECC handshake should actually be done. > In practice it's even worse than that, you can use completely = different curves > for the key exchange, to sign the key exchange, and for client auth, = and for > hashes it's nearly as bad. What are you supposed to do if an = implementation > uses (say) P192 for the keyex signature but P521 for the keyex itself? = What > security level do you treat this as being? You can use the = unnncessary How is this different from using 1024-bit RSA keys for keyex signature = but 2048-bit Diffie-Hellman keys for the keyex itself? It's a valid = concern, but I don't see how it is ECC specific. And I like to keep PKIX = and TLS separate, but some guidelines defining the security levels would = be very useful. > flexibility to make a complete mess of things, and from the little = testing > I've done almost anything you do that's slightly unusual results in a > handshake failure or dropped connection, and I don't even want to try = and see > what happens when you start using the really odd capabilities, = non-named > curves and point compression and other oddities. The non-named curves is a very strange feature, but I don't see it = causing any harm. If someone needs to use it somewhere, it's nice that = there's a defined and standard way to do it. I could imagine a need for = something like that in proprietary implementations where the TLS = implementations are only going to communicate with themselves and not = any 3rd party software. The specification should be just made much more = clear about what is actually used and what is there just because it = might be useful some day. Now it doesn't make a clear difference, and as = I already found out earlier a large part of the non-named curves is = impossible to implement. (see RFC 4492 errata) > So at the moment we already have a kind of de facto profile, mostly it = seems > to be P256+SHA256 everywhere, with optional P384+SHA384 everywhere, = and I > think I got away with P521 once or twice. The single profile we have = for ECC > use with TLS, the Suite B one, already does this, it's 256-throughout = (ECC > keys and hashes) or 384-throughout (ECC keys and hashes). I think I have seen 256+384+521 quite a lot, mostly because of the Suite = B requiring 256 and 384. But I'm using TLS on some devices that simply = don't have the processing capacity to do P-256 handshakes well. I tried = to implement P-256 modular reduction, but first of all the key length is = bigger and second the pseudo-Mersenne prime used in P-256 is 2^256 - = 2^224 + 2^192 + 2^96 - 1. This means modular reduction needs = 256/(256-224)=3D8 rounds and each rounds requires 4 addition operations. = Compared with for example P-224 that uses prime 2^224 - 2^96 + 1 and = requires just 2 rounds and 2 addition operations, the computational = difference between the curves is much larger than the bit length would = let one assume. Sorry if I'm going too much into details here, but I'm simply trying to = say that requiring support for P-256 might leave out a large number of = devices with lower capabilities. But I think it would be fair to define = that all implementations SHOULD implement at least P-256 and P-384, = maybe also P-521 if it is considered useful. Now the specification is = just giving a huge list of named curves with no idea about what curves = are actually used, even though pretty much all of the implementations = are just using two or three of them. That's not right. Juho From jsalowey@cisco.com Wed Apr 20 09:52:19 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 43592E0695 for ; Wed, 20 Apr 2011 09:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE3RViw7txTQ for ; Wed, 20 Apr 2011 09:52:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 609B8E0677 for ; Wed, 20 Apr 2011 09:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1026; q=dns/txt; s=iport; t=1303318338; x=1304527938; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=as5z1JJ101876JKa2Ux0jeJAfDYEmB655WxbLjTinAw=; b=WPILsP/zmuYcdEb5Wc7K97qmdrU0bKaSu4a7tdJZpBUedoEDgb9xKe18 gbZADcAutwCn/mn9DqwuyLn/eB6qPOIaSdQSFi+AHmjZQV3IkkrGQR2Ip yeQyW8KmcH4fvSaa+plarajgAIqHEhTXu7X3pc+iGo3SGqeMe2ujIS/BJ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYHABoOr02rRDoJ/2dsb2JhbACXcI1Ld6p3nH+FcQSFdIgug38 X-IronPort-AV: E=Sophos;i="4.64,247,1301875200"; d="scan'208";a="433678249" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 20 Apr 2011 16:52:16 +0000 Received: from [10.33.251.67] ([10.33.251.67]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3KGqGGj027471 for ; Wed, 20 Apr 2011 16:52:16 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Apr 2011 09:53:29 -0700 Message-Id: To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [TLS] Revised TLS Charter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 16:52:19 -0000 Below is updated charter text reflecting feedback on the list. Please = indicate if you support this text or if you have issues with the text. =20= Thanks, Joe The TLS Working Group was established in 1996 to standardize a 'transport layer' security protocol. The working group began with SSL version 3.0. The TLS Working Group has completed a series of specifications that describe the Transport Layer Security protocol versions 1.0, 1.1, and 1.2, extensions to the protocol, and new ciphersuites to be used with TLS. The primary goals of the WG are to maintain: - The TLS protocol, RFC 5246; - The DTLS protocol, RFC 4347bis. Significant changes to the protocol, such as a new version 1.3, are not=20= within scope of the working group unless they are explicitly added to=20 the charter.=20 The secondary goals of the WG are to publish: - Recommendations for use of TLS; - Extensions to TLS and DTLS; and, - Cipher suites. Milestones Dec 2011 - Heartbeat Extension Sent to IESG= From paul.hoffman@vpnc.org Wed Apr 20 10:16:16 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0661EE06B2 for ; Wed, 20 Apr 2011 10:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.023 X-Spam-Level: X-Spam-Status: No, score=-102.023 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aI5mJwktkIpw for ; Wed, 20 Apr 2011 10:16:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfc.amsl.com (Postfix) with ESMTP id 63318E0677 for ; Wed, 20 Apr 2011 10:16:15 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3KHGB7X042703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Apr 2011 10:16:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Wed, 20 Apr 2011 10:16:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <74388AEE-08C0-458B-869A-5BED8743B692@vpnc.org> References: To: Joe Salowey X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] Revised TLS Charter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 17:16:16 -0000 On Apr 20, 2011, at 9:53 AM, Joe Salowey wrote: > - The DTLS protocol, RFC 4347bis. s/RFC 4347bis/draft-ietf-tls-rfc4347-bis/. That is, there is a specific = WG draft we are talking about (particularly when the authors clear the = three-month-old DISCUSS). --Paul Hoffman From pgut001@login01.cs.auckland.ac.nz Sat Apr 23 22:24:26 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F11BBE06F9 for ; Sat, 23 Apr 2011 22:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EsVxboVG3Rr for ; Sat, 23 Apr 2011 22:24:24 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id 299E5E06A0 for ; Sat, 23 Apr 2011 22:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1303622665; x=1335158665; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20juhovh@iki.fi,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[TLS]=20DSS=20with=20other=20than=20SHA -1=20algorithms|Cc:=20ekr@rtfm.com,=20geoffk@geoffk.org, =20simon@josefsson.org,=20tls@ietf.org|In-Reply-To:=20|Message-Id:=20 |Date:=20Su n,=2024=20Apr=202011=2017:24:20=20+1200; bh=kQRGyuzX+NtrbONe0qFaDfmCeeNemXlfuMzBUp016Os=; b=MeYgdTal64wnzMtLG/iOjEkqQ+B8EKU2oY3Uj/o5YzJtHmxB86eRc8l0 GblV+0w3oR78p7X5lstdqQU2265Hz47rHivYCwb+ERWx2vwQOXO1hZJXh v9f9uR5Yp1LbCh2AXf7XlKoh/9zilAW8t9BkdMz36yBZa8bhUAVIo1oN+ c=; X-IronPort-AV: E=Sophos;i="4.64,261,1301832000"; d="scan'208";a="57943185" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 Apr 2011 17:24:21 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QDrnw-0002Sj-HI; Sun, 24 Apr 2011 17:24:20 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QDrnw-0003gv-A4; Sun, 24 Apr 2011 17:24:20 +1200 From: Peter Gutmann To: juhovh@iki.fi, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Sun, 24 Apr 2011 17:24:20 +1200 Cc: simon@josefsson.org, geoffk@geoffk.org, tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2011 05:24:26 -0000 =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= writes: >I'm sorry I probably wasn't clear enough in my message. I was trying to ask, >when exactly will the client say that it wants to do P256? Are we talking >about an exchange where the client doesn't send the elliptic_curves extension >in its hello message? Yes. It transforms the current ECC "suites", which aren't really suites at all but more an indication of intent to navigate a Chinese menu with details to be decided later, into true cipher suites. >1. Client sends a ClientHello with elliptic_curves extension specifying its >supported extensions But the elliptic_curves extension isn't part of the ClientHello. This is the problem, the ClientHello contains a notification-of-intent and then later bits and pieces contain the actual suite details. If any of the later bits and pieces don't as expected you have to go back to the ClientHello and try another Chinese-menu option, then go back to the later extensions and see if... and so on, although in practice everything I've seen so far just aborts the handshake if they don't see exactly what they expect. >But I'm using TLS on some devices that simply don't have the processing >capacity to do P-256 handshakes well. That's no problem, nothing in the ECC-suites proposal says you can't still use ECC-Chinese-menu to negotiate whatever you want. All ECC-suites does is provide a few standardised true suites that everyone can agree on. >Sorry if I'm going too much into details here, but I'm simply trying to say >that requiring support for P-256 might leave out a large number of devices >with lower capabilities. Oh no, this doesn't mandate anything, it just provides a single, standard, unambiguous way of indicating a few common ECC choices, leaving the full Chinese-menu capability in place for people whose needs aren't met by the fixed suites. Peter. From pgut001@login01.cs.auckland.ac.nz Sun Apr 24 05:31:22 2011 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BD6B5E0697 for ; Sun, 24 Apr 2011 05:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4EwKUwStY5K for ; Sun, 24 Apr 2011 05:31:22 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id CC25AE0660 for ; Sun, 24 Apr 2011 05:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1303648282; x=1335184282; h=from:to:subject:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20tls@ietf.org|Subject:=20Re:=20[TLS]=20DSS=20with =20other=20than=20SHA-1=20algorithms|Message-Id:=20|Date:=20Mon,=202 5=20Apr=202011=2000:31:17=20+1200; bh=ZKBoPjK3BJtaclDiEzfkb4c2OtX904nT14z2aevILrI=; b=Wf8xOpDxmb83xCyVGwcGwsSagRU6DP6z8KvkFEeV2rmBsS0KJKJAjB4e CM3sKXPccBKxlLpAE0e3vf37iL8OaRybN3jLaVwZhHgJjZmSQeu77z22Z ODJ66zaaS1yOvfOVLirZ4jDMJ0KUdRhPPqYrwK7Vf4RoBD0Uj0KMtbMk9 4=; X-IronPort-AV: E=Sophos;i="4.64,263,1301832000"; d="scan'208";a="57956683" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Apr 2011 00:31:17 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QDyT7-0005Xi-It for tls@ietf.org; Mon, 25 Apr 2011 00:31:17 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QDyT7-0006mk-PF for tls@ietf.org; Mon, 25 Apr 2011 00:31:17 +1200 From: Peter Gutmann To: tls@ietf.org Message-Id: Date: Mon, 25 Apr 2011 00:31:17 +1200 Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 24 Apr 2011 12:31:22 -0000 I've now posted a first draft for comment: http://www.ietf.org/id/draft-gutmann-tls-eccsuites-00.txt Peter. From n.mavrogiannopoulos@gmail.com Tue Apr 26 10:12:58 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91987E07E7 for ; Tue, 26 Apr 2011 10:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1wu+xH7bJwm for ; Tue, 26 Apr 2011 10:12:57 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 91C9FE07A0 for ; Tue, 26 Apr 2011 10:12:57 -0700 (PDT) Received: by ewy19 with SMTP id 19so322725ewy.31 for ; Tue, 26 Apr 2011 10:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:references:in-reply-to:x-enigmail-version :openpgp:content-type:content-transfer-encoding; bh=LKx/EWaMI6SrgtGc0kKE3aAnkhI/NF7Uexn1cY3g098=; b=IiaP7Byt5AaF+UlgZZKRBRLViZDVcfP+TIxs7touuG3Ape7g0tE0KSwn2e3vE/jtG9 +dPj4LTnvTb5CPEaeF4LU8pfF3Qy8xpBqWfKQKwKzS2CJFRyYJG8pX+SMeCXHDDWwl9T cB85z3MROGSDsnUVzJFCy2pC/++Bt6iyrgtZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=kG2rfWZyUad7Iej6BmHwVxZlvbWKtbNNV2Sw0bx3C80r3Gu68Chbhla/+hu5H48i88 7kLG0Et+KqRBwpMtS7R8lB9qUHrLzHoNbVwLiFNw3tw9z86500ZoatzYHnVRA7akvgZi tg84/eAPFebHK7udJ1nqHnv818Z+Tx4qHdZIo= Received: by 10.14.126.73 with SMTP id a49mr459160eei.178.1303837975668; Tue, 26 Apr 2011 10:12:55 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id y7sm4948718eeh.7.2011.04.26.10.12.53 (version=SSLv3 cipher=OTHER); Tue, 26 Apr 2011 10:12:54 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4DB6FD14.20203@gnutls.org> Date: Tue, 26 Apr 2011 19:12:52 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 26 Apr 2011 17:12:58 -0000 On 04/24/2011 02:31 PM, Peter Gutmann wrote: > I've now posted a first draft for comment: > http://www.ietf.org/id/draft-gutmann-tls-eccsuites-00.txt I have not implemented ECC ciphersuites, but the things that striked me while reading it are: * There is no mention of ECDHE_RSA or anon ciphersuites. For me they are the most important as they optimize normal DH using existing RSA certificates (in the _RSA case). * A single ciphersuite negotiates the ECDHE parameters AND the parameters of the ECDSA certificate. Could there be cases where one can verify any ECDSA certificate, and only his capabilities to ECDHE are restricted? In that case it might be better to allow for any ECDSA certificate rather than handling each different parameter as different algorithm. (but I repeat I don't have an overview of ECC in practice). * It doesn't really need to be that aggressive with the previous attempt. If this one is better/simpler it will be used in practice and replace the old one. Maybe some examples of failures of the current TLS-ECC-RFC might be more convincing. regards, Nikos From pgut001@login01.cs.auckland.ac.nz Wed Apr 27 02:22:54 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F35CE0794 for ; Wed, 27 Apr 2011 02:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdImBgH6O3qA for ; Wed, 27 Apr 2011 02:22:50 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4473CE071F for ; Wed, 27 Apr 2011 02:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1303896171; x=1335432171; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20nmav@gnutls.org,=20tls@ietf.org|Subject:=20Re:=20[ TLS]=20DSS=20with=20other=20than=20SHA-1=20algorithms |In-Reply-To:=20<4DB6FD14.20203@gnutls.org>|Message-Id: =20|Date: =20Wed,=2027=20Apr=202011=2021:22:42=20+1200; bh=z6K6qpoUQR6d65BLdy5/K+5DNZqqXLb2eV+0D9zqJXY=; b=o04iDq2BNCSo5am9pEMI3NMj204k/CS0fuZ4VQZiyEa/gjeTJisx10rw +TGMKGjofZw+GJgYmRXFy1BM6zxLbiVsNXKFdJCtkQBJeLTQvf6US2lM4 FLh06VHwQGlp0fCGdOfFwDAPHj9RQsVUYh7HCNbf3iSaFA3zaCxc3OyOj Y=; X-IronPort-AV: E=Sophos;i="4.64,273,1301832000"; d="scan'208";a="58370050" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Apr 2011 21:22:42 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QF0xG-0005r9-HB; Wed, 27 Apr 2011 21:22:42 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QF0xG-00064o-8q; Wed, 27 Apr 2011 21:22:42 +1200 From: Peter Gutmann To: nmav@gnutls.org, tls@ietf.org In-Reply-To: <4DB6FD14.20203@gnutls.org> Message-Id: Date: Wed, 27 Apr 2011 21:22:42 +1200 Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 09:22:54 -0000 Nikos Mavrogiannopoulos writes: >* There is no mention of ECDHE_RSA or anon ciphersuites. For me they are the >most important as they optimize normal DH using existing RSA certificates (in >the _RSA case). Nothing (AFAIK) implements these. The point of the RFC (draft) is to standardise what are already de facto cipher suite configurations. If nothing uses them then they're not really de facto standard configs :-). >* It doesn't really need to be that aggressive with the previous attempt. If >this one is better/simpler it will be used in practice and replace the old >one. This doesn't replace the existing one, it complements it. This profiles a set of de facto standard cipher suites (rather than RFC 4492's Chinese menus) that are already in common (well, as common as TLS-ECC gets anyway, which is to say "not very") use. The point is to have them standardised before TLS-ECC does get common and the existing interop problems get worse. Peter. From juhovh@iki.fi Wed Apr 27 03:15:01 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A47E068F for ; Wed, 27 Apr 2011 03:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12svTOH0cT9m for ; Wed, 27 Apr 2011 03:15:00 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 86C6CE067C for ; Wed, 27 Apr 2011 03:15:00 -0700 (PDT) Received: from mail.visino.fi (84.251.121.70) by jenni2.inet.fi (8.5.133) id 4D9AC72600F64E80; Wed, 27 Apr 2011 13:14:52 +0300 Received: from [130.233.194.202] (tko-add-202.cs.hut.fi [130.233.194.202]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id 2F8C320395; Wed, 27 Apr 2011 13:13:44 +0300 (EEST) Message-ID: <4DB7EBE7.8020705@iki.fi> Date: Wed, 27 Apr 2011 13:11:51 +0300 From: =?ISO-8859-1?Q?Juho_V=E4h=E4-Herttua?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: simon@josefsson.org, geoffk@geoffk.org, tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 10:15:01 -0000 24.4.2011 8:24, Peter Gutmann kirjoitti: >> 1. Client sends a ClientHello with elliptic_curves extension specifying its >> supported extensions > But the elliptic_curves extension isn't part of the ClientHello. This is the > problem, the ClientHello contains a notification-of-intent and then later bits > and pieces contain the actual suite details. If any of the later bits and > pieces don't as expected you have to go back to the ClientHello and try > another Chinese-menu option, then go back to the later extensions and see > if... and so on, although in practice everything I've seen so far just aborts > the handshake if they don't see exactly what they expect. I don't quite understand this part, I know it is not indicated as MUST in the current RFC, but the text quite clearly says: The extensions SHOULD be sent along with any ClientHello message that proposes ECC cipher suites. ... A client that proposes ECC cipher suites in its ClientHello message appends these extensions (along with any others), enumerating the curves it supports and the point formats it can parse. Clients SHOULD send both the Supported Elliptic Curves Extension and the Supported Point Formats Extension. So every client sending a ClientHello SHOULD append the Supported Elliptic Curves extension in ClientHello itself and therefore the selected curve should be clear immediately after receiving the complete ServerHello including ServerKeyExchange. I'm not saying the suggested draft is not a good idea, I think it looks pretty good, I'm just saying the situation doesn't seem quite as bad as suggested. I think the reference to Microsoft's SChannel cipher suites was a very good one. I wasn't aware they have already chosen to take this approach and it's one more argument for defining it officially. However, I'm also wondering why ECDHE_RSA is dropped from the draft? Even Microsoft has included ECDHE_RSA cipher suites in their list and since almost all certificates in use are RSA certificates, it is quite likely that ECDHE_RSA cipher suites are the only cipher suites existing TLS servers can start to use immediately without applying for a new certificate. (one can argue that they could just use RSA key exchange, but that doesn't have forward secrecy like ECDHE does) Also mandating the same curve in ECDSA signature as in ECDH keys could be debated, but I think it's quite well justified here. It's also worth to note that this draft doesn't require the whole certificate chain is signed with ECDSA and certain curve, so for example a certificate containing P-256 keys signed with something else would still be valid. I think this is good for flexibility, in case the server administrator is unable to obtain a ECDSA certificate signed with ECDSA. It's up to the client to find out if it's able to determine its validity then. Juho From juhovh@iki.fi Wed Apr 27 03:23:23 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFC1E069A for ; Wed, 27 Apr 2011 03:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSMdu5G4xGfA for ; Wed, 27 Apr 2011 03:23:23 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id CBC2FE068F for ; Wed, 27 Apr 2011 03:23:22 -0700 (PDT) Received: from mail.visino.fi (84.251.121.70) by jenni2.inet.fi (8.5.133) id 4D9AC72600F66F13 for tls@ietf.org; Wed, 27 Apr 2011 13:23:22 +0300 Received: from [130.233.194.202] (tko-add-202.cs.hut.fi [130.233.194.202]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id D929D20395 for ; Wed, 27 Apr 2011 13:23:21 +0300 (EEST) Message-ID: <4DB7EE85.2090700@iki.fi> Date: Wed, 27 Apr 2011 13:23:01 +0300 From: =?ISO-8859-1?Q?Juho_V=E4h=E4-Herttua?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: tls@ietf.org References: <4DB6FD14.20203@gnutls.org> In-Reply-To: <4DB6FD14.20203@gnutls.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 10:23:23 -0000 26.4.2011 20:12, Nikos Mavrogiannopoulos kirjoitti: > * A single ciphersuite negotiates the ECDHE parameters > AND the parameters of the ECDSA certificate. Could there > be cases where one can verify any ECDSA certificate, and > only his capabilities to ECDHE are restricted? In that > case it might be better to allow for any ECDSA certificate > rather than handling each different parameter > as different algorithm. (but I repeat I don't have an > overview of ECC in practice). I could comment here, that both ECDSA signing and verification consist of ECC point multiplication and modulo operations. The ECDH operation on the other hand is a simple ECC point multiplication with no additional parameters. Therefore, if there is a case where one can verify an ECDSA certificate but his capabilities to ECDHE are restricted, the restrictions are completely artificial. Only thing coming to my mind would be some kind of proprietary or hardware based PKIX library supporting ECC but not offering an API to the low level ECC point multiplication. If someone knows about this kind of setup could us know now, but in my opinion it wouldn't make much sense... Juho From bsmith@mozilla.com Wed Apr 27 18:59:31 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D220E08E3 for ; Wed, 27 Apr 2011 18:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTCvLNTRG7fH for ; Wed, 27 Apr 2011 18:59:31 -0700 (PDT) Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0A26EE07A5 for ; Wed, 27 Apr 2011 18:59:31 -0700 (PDT) Received: from mail.mozilla.com (mail.mozilla.com [10.2.72.15]) by mail.mozilla.com (Postfix) with ESMTP id 57C7A17FC92E for ; Wed, 27 Apr 2011 18:59:30 -0700 (PDT) Date: Wed, 27 Apr 2011 18:59:30 -0700 (PDT) From: Brian Smith To: tls@ietf.org Message-ID: <1103696595.157623.1303955970290.JavaMail.root@cm-mail03.mozilla.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [63.245.220.240] X-Mailer: Zimbra 6.0.8_GA_2678 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661) Subject: Re: [TLS] Revised TLS Charter X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 01:59:31 -0000 Joe Salowey wrote: > Below is updated charter text reflecting feedback on the list. Please > indicate if you support this text or if you have issues with the text. Are extensions that add/remove/reorder handshake records acceptable for TLS 1.2? If so, then I think the the proposed charter looks fine. Thanks, Brian From n.mavrogiannopoulos@gmail.com Thu Apr 28 01:59:37 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11355E06D6 for ; Thu, 28 Apr 2011 01:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeKJ5JTH9TPd for ; Thu, 28 Apr 2011 01:59:36 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5DFDE06D4 for ; Thu, 28 Apr 2011 01:59:36 -0700 (PDT) Received: by pwi5 with SMTP id 5so1477531pwi.31 for ; Thu, 28 Apr 2011 01:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y5JkcoC0HqaQEBWg9fSWhI5aK9brmyCiNiQSBm8OytU=; b=Kgk4EkHNUWU7DmbhxEygsO3sqJVsS00oucMiws5g8Cbw3cHuE7OA1WhohkaBPW/3Je TMoAVZeVNxjw7KNL8swBobIqXG1E0mZGYDeDiXXEwgqHimWlNRFhWPgveA1VH1C6A6q4 cQiBOYd8dzxHMi5V3BaTniXT+xf+6W4KKo1w8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Fzu6NvQBlMA6aCkrmACkuDSty0974RPemQ05PUg0XJfVVJ+HrI0E95vXFJiofZy7YH mNP22EyxTw91I9DLZ41Rv/qNOY6HAnefHYD3qNF1cKv6kDOFOuvnM1gssT5wromD6Bwq ryqmHjLjJ5kPZWspEUD6Ne5rpA18WnAc63iE0= MIME-Version: 1.0 Received: by 10.68.33.8 with SMTP id n8mr3277991pbi.51.1303981176221; Thu, 28 Apr 2011 01:59:36 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.68.40.130 with HTTP; Thu, 28 Apr 2011 01:59:36 -0700 (PDT) In-Reply-To: References: <4DB6FD14.20203@gnutls.org> Date: Thu, 28 Apr 2011 10:59:36 +0200 X-Google-Sender-Auth: JDCkqC-rewH0NzbuIvulRnQwy7s Message-ID: From: Nikos Mavrogiannopoulos To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 08:59:37 -0000 On Wed, Apr 27, 2011 at 11:22 AM, Peter Gutmann wrote: >>* It doesn't really need to be that aggressive with the previous attempt.= If >>this one is better/simpler it will be used in practice and replace the ol= d >>one. > This doesn't replace the existing one, it complements it. =C2=A0This prof= iles a set > of de facto standard cipher suites (rather than RFC 4492's Chinese menus)= that > are already in common (well, as common as TLS-ECC gets anyway, which is t= o say > "not very") use. =C2=A0The point is to have them standardised before TLS-= ECC does > get common and the existing interop problems get worse. Thinking about it, it would be very IPSec to have two ways to do the same thing. If this method is intended to replace the current ECC draft, it should specify how the extensions are used once this draft is supported. I'd suggest to make i= t mutual exclusive. If this draft is supported then the extensions are used t= o negotiate unnamed curves only or so. regards, Nikos From juhovh@iki.fi Thu Apr 28 04:02:32 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F001E0663 for ; Thu, 28 Apr 2011 04:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RhvI+p-tIMP for ; Thu, 28 Apr 2011 04:02:31 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB8CE06B1 for ; Thu, 28 Apr 2011 04:02:30 -0700 (PDT) Received: from mail.visino.fi (84.251.121.70) by jenni1.inet.fi (8.5.133) id 4D9AD3B801078B24 for tls@ietf.org; Thu, 28 Apr 2011 14:02:29 +0300 Received: from [130.233.194.202] (tko-add-202.cs.hut.fi [130.233.194.202]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id 89A50201C5 for ; Thu, 28 Apr 2011 14:02:14 +0300 (EEST) Message-ID: <4DB94922.7080806@iki.fi> Date: Thu, 28 Apr 2011 14:01:54 +0300 From: =?UTF-8?B?SnVobyBWw6Row6QtSGVydHR1YQ==?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: tls@ietf.org References: <4DB6FD14.20203@gnutls.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 11:02:32 -0000 28.4.2011 11:59, Nikos Mavrogiannopoulos kirjoitti: > Thinking about it, it would be very IPSec to have two ways to do the > same thing. > If this method is intended to replace the current ECC draft, it should > specify how > the extensions are used once this draft is supported. I'd suggest to make it > mutual exclusive. If this draft is supported then the extensions are used to > negotiate unnamed curves only or so. Before suggesting making the extensions only to be used for unnamed curves, it should be mentioned that RFC 4492 defines total of 25 named curves, of which this draft redefines only the 2 most commonly used. Also there are a lot of existing implementations out there that already implement ECC and many browsers have ECC turned on by default, most of them implement the suites listed in the draft. Making the draft mutually exclusive with existing ECC methods would make the transition almost impossible, causing more compatibility problems than it is trying to solve. Juho From pgut001@login01.cs.auckland.ac.nz Fri Apr 29 05:10:46 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172E3E071D for ; Fri, 29 Apr 2011 05:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VqQghSsK8AX for ; Fri, 29 Apr 2011 05:10:42 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id C5628E06C0 for ; Fri, 29 Apr 2011 05:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1304079042; x=1335615042; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20juhovh@iki.fi,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[TLS]=20DSS=20with=20other=20than=20SHA -1=20algorithms|Cc:=20tls@ietf.org|In-Reply-To:=20<4DB7EB E7.8020705@iki.fi>|Message-Id:=20|Date:=20Sat,=2030=20Apr=202011=200 0:10:34=20+1200; bh=pX+Ck8WcLddKh1yEe//PE8LK61+4ncE8iFAqtxz2pEM=; b=Yr8MNwOmKI1t7LMliEBi/qXmwWzJWMcQgNiCKgKPoORMnRFdLVVCGs+b ALMl3EElwC+MzCk8mPPQ4UPi5DhgJmi6dFWzBVi0I4qhmWn1zjV6HYWyA jumZip0ptDEh9i1vR/CPcBRySHRIl4jUGxoVN9+0ohG+t0DP1hEpSaN3y k=; X-IronPort-AV: E=Sophos;i="4.64,287,1301832000"; d="scan'208";a="59079326" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Apr 2011 00:10:34 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QFmWo-00072H-H0; Sat, 30 Apr 2011 00:10:34 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QFmWo-0000Js-7O; Sat, 30 Apr 2011 00:10:34 +1200 From: Peter Gutmann To: juhovh@iki.fi, pgut001@cs.auckland.ac.nz In-Reply-To: <4DB7EBE7.8020705@iki.fi> Message-Id: Date: Sat, 30 Apr 2011 00:10:34 +1200 Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 12:10:46 -0000 =?ISO-8859-1?Q?Juho_V=E4h=E4-Herttua?= writes: >So every client sending a ClientHello SHOULD append the Supported Elliptic >Curves extension in ClientHello itself and therefore the selected curve >should be clear immediately after receiving the complete ServerHello >including ServerKeyExchange. Hmm, I'll try and explain this again... consider how the parts of the Client Hello are processed. For standard suites the server iterates through a list of suites and selects the most cromulent one. In my case I just have a list of suite IDs and parameters sorted in order of preference and select the lowest-ranked suite I find, I assume most implementations do something more or less similar. For the Chinese-menu suites, the server finds a Chinese menu selector and then has to skip the remaining suites and other parts of the hello and process the extensions to see whether what's in there matches up with that the Chinese- menu selector requested. For example if the Chinese menu said TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 but the supported-curves says P256 then you have to either hope the other side does the special-case X9.62 handling for hash truncation and gets it right (and I've never been able to find anything that does this to test mine against so who knows whether anything does do it, and does get it right), or not take the gamble and go back to the cipher suites and look for another Chinese-menu option, and then skip the rest of the hello and process the extension again to see if things work out now, and if that doesn't work either then go back ... In practice, with the servers I tried, it was hard enough just trying to figure out which basic combinations they supported (the usual response was a dropped connection or aborted handshake, so I had to use trial-and-error probing, and with some servers I never did figure out how to do more than one or two basic combinations), and I never got to the point of being able to interop test any of the more exotic combinations like e.g. hash truncation. So the sole purpose of this RFC is to try and indentify the common combinations of parameters that everyone seems to implement anyway and list them as conventional cipher suites, with no further parameterisation required. The intent is to try and document what everyone's doing already anyway. Peter. From pgut001@login01.cs.auckland.ac.nz Fri Apr 29 05:33:59 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A8AE0659 for ; Fri, 29 Apr 2011 05:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwIsJDplyJiW for ; Fri, 29 Apr 2011 05:33:54 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 68779E064B for ; Fri, 29 Apr 2011 05:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1304080434; x=1335616434; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20nmav@gnutls.org,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[TLS]=20DSS=20with=20other=20than=20SHA -1=20algorithms|Cc:=20tls@ietf.org|In-Reply-To:=20 |Message-Id:=20|Date:=20Sat,=2030=20Apr=202011=2000:33:51=20+1200; bh=U1syv+qn+qMiraA8VvjX03oOHGqPWni0mfDlBcqk7D0=; b=RlpamEyhkcPTdrZne6YNLMJYLnADFclZ5MNXDtAmkSrfo36XSx+xxdoO 4sR1cdyYS73bq1tI0s+CxNUEw3vGBRuEPM+YtAUQhkjc1VZm6vQcQZeP1 1RAqmHn8fNg2uZLRGErOoL0/aCh0RF6qwqkA6dCgopKUiJfIfRnepttHC k=; X-IronPort-AV: E=Sophos;i="4.64,287,1301832000"; d="scan'208";a="59081072" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Apr 2011 00:33:51 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QFmtL-0007hs-Hq; Sat, 30 Apr 2011 00:33:51 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QFmtL-0001Hu-Fr; Sat, 30 Apr 2011 00:33:51 +1200 From: Peter Gutmann To: nmav@gnutls.org, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Sat, 30 Apr 2011 00:33:51 +1200 Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 12:33:59 -0000 Nikos Mavrogiannopoulos writes: >Thinking about it, it would be very IPSec to have two ways to do the same >thing. If this method is intended to replace the current ECC draft, it should >specify how the extensions are used once this draft is supported. I'd suggest >to make it mutual exclusive. If this draft is supported then the extensions >are used to negotiate unnamed curves only or so. Uhh, that's exactly what the current draft does, see the two paragraphs beginning "If no additional Chinese-menu ECC suites...". Peter. From juhovh@iki.fi Fri Apr 29 07:25:50 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969E6E0708 for ; Fri, 29 Apr 2011 07:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNseWbKvoPIQ for ; Fri, 29 Apr 2011 07:25:50 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 14ED4E06BF for ; Fri, 29 Apr 2011 07:25:48 -0700 (PDT) Received: from mail.visino.fi (84.251.121.70) by jenni2.inet.fi (8.5.133) id 4D9AC72601173D54; Fri, 29 Apr 2011 17:25:41 +0300 Received: from [130.233.194.202] (tko-add-202.cs.hut.fi [130.233.194.202]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id 0E475201C5; Fri, 29 Apr 2011 17:25:17 +0300 (EEST) Message-ID: <4DBACA38.2020100@iki.fi> Date: Fri, 29 Apr 2011 17:24:56 +0300 From: =?ISO-8859-1?Q?Juho_V=E4h=E4-Herttua?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 14:25:50 -0000 29.4.2011 15:10, Peter Gutmann kirjoitti: > Hmm, I'll try and explain this again... consider how the parts of the Client > Hello are processed. For standard suites the server iterates through a list > of suites and selects the most cromulent one. In my case I just have a list > of suite IDs and parameters sorted in order of preference and select the > lowest-ranked suite I find, I assume most implementations do something more or > less similar. Thank you for taking the time to explain it a bit more thoroughly. And sorry for asking so many questions, but I want to understand the motivation behind this well and on the mailing list it will at least be documented for future references. > For the Chinese-menu suites, the server finds a Chinese menu selector and then > has to skip the remaining suites and other parts of the hello and process the > extensions to see whether what's in there matches up with that the Chinese- > menu selector requested. For example if the Chinese menu said Everything clear so far. > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 but the supported-curves says P256 > then you have to either hope the other side does the special-case X9.62 > handling for hash truncation and gets it right (and I've never been able to > find anything that does this to test mine against so who knows whether > anything does do it, and does get it right), or not take the gamble and go Actually, I tried to look through RFC 4492 (ECC), RFC 5246 (TLS 1.2) and RFC 5289, but I didn't find a requirement of using SHA-384 for signatures for that cipher suite. So in this case the server could choose SHA-256 (in case it can be found from signature_algorithms extension) and use that for signature hashing, but use SHA-384 for the PRF and therefore perform no hash truncation. It would be silly to use two different hashes, but that is how I would probably solve it to maintain compatibility. I think it's a general problem with both TLS 1.2 and ECC specifications, that they're both trying to be flexible and extensible up to the point that finding out the actual details becomes tedious work and it's more likely for many implementations to "get it wrong". I suppose that's exactly the thing you're trying to fix with the draft... > back to the cipher suites and look for another Chinese-menu option, and then > skip the rest of the hello and process the extension again to see if things > work out now, and if that doesn't work either then go back ... I think this what makes this worse is that existing TLS 1.0/1.1 implementations haven't necessarily prepared well for such complicated cipher suite selection ECC and TLS 1.2 introduce and that makes the transition a bit difficult. > In practice, with the servers I tried, it was hard enough just trying to > figure out which basic combinations they supported (the usual response was a > dropped connection or aborted handshake, so I had to use trial-and-error > probing, and with some servers I never did figure out how to do more than one > or two basic combinations), and I never got to the point of being able to > interop test any of the more exotic combinations like e.g. hash truncation. Dropping the connection or aborting the handshake is clearly wrong, but again as just noted, selecting a cipher suite used to be a simple thing and now it's suddenly quite hard. Abortion in that case is an understandable solution. > So the sole purpose of this RFC is to try and indentify the common > combinations of parameters that everyone seems to implement anyway and list > them as conventional cipher suites, with no further parameterisation required. > The intent is to try and document what everyone's doing already anyway. Should it be added to the draft that for example implementations using mentioned SHA-256 cipher suites must also send signature_algorithms extension with corresponding hash and ECDSA pair? Right now it only points out the used hash functions, but TLS 1.2 specification quite clearly says that one should default to the {sha1,ecdsa} combination if no extension is sent. I think this draft doesn't make it clear enough if it overrides that requirement or not. Also, the term "Chinese-menu" is a word I haven't seen in any existing TLS related RFC, even though it is very widely used in your draft and related discussion. I think it would make sense to at least define the meaning of the word a bit more clearly if it is going to be used, but it might be worth changing it to something completely different. I for one have lived in China for some years and have always managed to agree on the menu and the details, so I believe at least the Chinese people might find it puzzling. Not to mention someone might even consider it offending... Juho From dkg@fifthhorseman.net Fri Apr 29 10:15:22 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C14E06A1 for ; Fri, 29 Apr 2011 10:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2kbwiracdud for ; Fri, 29 Apr 2011 10:15:21 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C9FD6E069F for ; Fri, 29 Apr 2011 10:15:21 -0700 (PDT) Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id ED441F970; Fri, 29 Apr 2011 13:15:14 -0400 (EDT) Message-ID: <4DBAF21E.2080908@fifthhorseman.net> Date: Fri, 29 Apr 2011 13:15:10 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110402 Icedove/3.1.9 MIME-Version: 1.0 To: =?UTF-8?B?SnVobyBWw6Row6QtSGVydHR1YQ==?= References: <4DBACA38.2020100@iki.fi> In-Reply-To: <4DBACA38.2020100@iki.fi> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE5F99E750CC8084BA168C931" Cc: tls@ietf.org Subject: Re: [TLS] DSS with other than SHA-1 algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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, 29 Apr 2011 17:15:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE5F99E750CC8084BA168C931 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/29/2011 10:24 AM, Juho V=C3=A4h=C3=A4-Herttua wrote: > Also, the term "Chinese-menu" is a word I haven't seen in any existing > TLS related RFC, even though it is very widely used in your draft and > related discussion. I think it would make sense to at least define the > meaning of the word a bit more clearly if it is going to be used, but i= t > might be worth changing it to something completely different. I for one= > have lived in China for some years and have always managed to agree on > the menu and the details, so I believe at least the Chinese people migh= t > find it puzzling. Not to mention someone might even consider it > offending... I agree that this should be clarified, and the term possibly replaced with something more suitable. I think the sense that Gutmann is going for here is something like "a la carte" (if we want to stay in the culinary metaphor) or "combinatorial explosion of possible parameters" (if we want to be dry and technical about it). --dkg --------------enigE5F99E750CC8084BA168C931 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.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJNuvIeXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpDigP/2BPk0BBsJYzq2gZqyzeMws9 24QlBq0qa5+qFHBKDlJeFY+9QUWc7vEQw+pFwMGIIuaSAP72Ry5tBTG18s6wuetK eQRTgcmzhfdPpR+/LBzZ/H1MTYB+9wOSrli3GvJvVwX0Z2Jz79zVKgYnvnSIJCBk jIB78L/fIdC7rmUW4einsH6Dp2K9ngS0YMtt/8LUJO53zlAw788155zmhR51KJWf qZTixuq6MV/O/21p8HrwE2oiMZef2/iTrCHUsClYlrN8l1d0007eBbMIr2AOtZne 473L0IqmtdyTLz2Fa3+MhUdzYeeAGGDQOWaVLPRiByB/J9ToPEhwLWXqKtacdObh hvU2LIXHKK4rYNQPDXo6QzJXOVNDaT+otSLdpaMpjlsqMxe7l4To9hV6+ZV22HEN 4+VZzC74PgDK8x4UxtQUMxqhOqb8SFC+5sYRMVNgM+PVO4o2cSmZP72HeAkV8Gwk SzvmxAAcUeSZybEUy0GCf81zX8m/5LGZGuzO6ayk3NZdQCTBQj1nCVDEKIdJk8nI IgJaOAhGlXtULi7C4wxdU6yiItOOY9wuIyfRt2MZKyvT0p+iMBMdKJhGnhTJz3f7 GI0FHwP7ZkTUhzCFIYJu65a9l+Lz7UEQgszyGpHydj9TOPoXAHMV6gD1wPY2BH8N kxveHVwdgqGvrf9/GApP =5Dnb -----END PGP SIGNATURE----- --------------enigE5F99E750CC8084BA168C931--