Re: [TLS] SCSV vs RI when both specified. Was: Updated draft
Marsh Ray <marsh@extendedsubset.com> Tue, 12 January 2010 19:55 UTC
Return-Path: <marsh@extendedsubset.com>
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 BBAAE3A683B for <tls@core3.amsl.com>; Tue, 12 Jan 2010 11:55:28 -0800 (PST)
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 xQhpy5DaY9BB for <tls@core3.amsl.com>; Tue, 12 Jan 2010 11:55:27 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id C8E5E3A6836 for <tls@ietf.org>; Tue, 12 Jan 2010 11:55:27 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NUmpo-0004Yy-WB; Tue, 12 Jan 2010 19:55:25 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2B7176076; Tue, 12 Jan 2010 19:55: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: U2FsdGVkX18X/G5etYygPApiIoHQe2fEHPVacXwZYCc=
Message-ID: <4B4CD3AB.1010102@extendedsubset.com>
Date: Tue, 12 Jan 2010 13:55:23 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: mrex@sap.com
References: <201001121939.o0CJdFsb018472@fs4113.wdf.sap.corp>
In-Reply-To: <201001121939.o0CJdFsb018472@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: DPKemp@missi.ncsc.mil, tls@ietf.org
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jan 2010 19:55:28 -0000
Martin Rex wrote: > > There is a document, approved by the IESG, where both of you are > listed as document co-authors, and it says this: > > http://tools.ietf.org/html/draft-ietf-tls-renegotiation-03#section-4.3 > > > 4.3. Server Considerations > > If the client does not offer the "renegotiation_info" extension or > the TLS_RENEGO_PROTECTION_REQUEST SCSV then this indicates that the > client does not support secure renegotiation. However, because the > above attack looks like two handshakes to the server, the server can > safely continue the connection as long as it does not allow the > client to renegotiate. > > I'm fine with that "the server can safely continue the connection as > long as it does not allow the client to renegotiate." I'm not, and I argued against the inclusion of that language repeatedly. The explanation I was given, IIRC, was that it was just referring to "the above attack" which was the one simplest case to explain. It was not supposed to be exhaustive of all attacks. I firmly believe that the language "the server can safely continue the connection as long as it does not allow the client to renegotiate" is in error. It was not worth continuing to argue about if it delays the implementation of the fix (which is the same in any case). > I don't want to continue discussing this issue. Agreed. I'll just have to make my point with working exploit code. - Marsh
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Michael D'Errico
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Michael D'Errico
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Steve Checkoway
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Steve Checkoway
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Steve Checkoway
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Pasi.Eronen
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Yoav Nir
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Michael D'Errico
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Dr Stephen Henson
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Michael D'Errico
- Re: [TLS] SCSV vs RI when both specified - consen… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified - consen… Nasko Oskov
- Re: [TLS] SCSV vs RI when both specified - consen… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified - consen… Michael D'Errico
- Re: [TLS] SCSV vs RI when both specified - consen… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Yoav Nir
- Re: [TLS] SCSV vs RI when both specified - consen… Yoav Nir
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Kemp, David P.
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Ben Laurie
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Kemp, David P.
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Steve Dispensa
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Kemp, David P.
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Kemp, David P.
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Kyle Hamilton