Re: [TLS] SCSV vs RI when both specified. Was: Updated draft
"Kemp, David P." <DPKemp@missi.ncsc.mil> Tue, 12 January 2010 15:43 UTC
Return-Path: <DPKemp@missi.ncsc.mil>
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 9A6D53A6A0D for <tls@core3.amsl.com>; Tue, 12 Jan 2010 07:43:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 XSGEbMld-D+S for <tls@core3.amsl.com>; Tue, 12 Jan 2010 07:43:36 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 8D5323A67D6 for <tls@ietf.org>; Tue, 12 Jan 2010 07:43:36 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Jan 2010 10:43:33 -0500
Message-ID: <201001121543.o0CFhYuI011143@stingray.missi.ncsc.mil>
In-Reply-To: <201001121440.o0CEe7k1026688@fs4113.wdf.sap.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft
Thread-Index: AcqTlUE7l7NkR4APTM+Z+mGuQ8t4MQAAF6wA
References: <200912301753.nBUHrRw2021772@stingray.missi.ncsc.mil> from "Kemp, David P." at Dec 30, 9 12:52:35 pm <201001121440.o0CEe7k1026688@fs4113.wdf.sap.corp>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: tls@ietf.org
X-OriginalArrivalTime: 12 Jan 2010 15:44:05.0171 (UTC) FILETIME=[12206830:01CA939E]
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 15:43:37 -0000
Perhaps I misunderstand the issue, but if there is absolutely no known security problem in the absence of C->S signaling (ClientHello contains neither SCSV nor empty RI), then it would seem that C->S signaling is superfluous and should have been omitted from the renego spec. I inferred from its existence that it served some useful purpose. If a renegotiation attack exists (which I also infer from the urgent discussions over the past several months), then either a client or a server may wish to guarantee that it is not subject to that attack. The only way to provide that guarantee is for the new protocol spec to require that both client and server support the new protocol or abort the connection. If the attack could be prevented by modifying only clients, then the spec would not have required modifications to the installed base of servers, and vice versa. That is not a policy decision embedded in protocol, it is a truth in advertising requirement. If a client's or server's policy is that communication is more important than resistance to renegotiation attack, than that policy is expressed by accepting connections using the SSLv3, TLSv1.0, TLSv1.1, and TLSv1.2 protocols. Dave -----Original Message----- From: Martin Rex [mailto:mrex@sap.com] Sent: Tuesday, January 12, 2010 9:40 AM To: Kemp, David P. Cc: tls@ietf.org Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft Kemp, David P. wrote: > > Amazon and Google are free to accept SSLv2 as well as TLSv1.x-unpatched > (minor MSbit unset) if they perceive the benefit of communicating to be > greater than the risk of being attacked. That has no bearing on > whether the protocol spec for TLSv1.x-patched requires aborting > connections with bozo endpoints, which of course it should. Service > providers/consumers can make their own choice of which protocol versions > and ciphersuites to accept, with the knowledge that more restrictive > choices will lock out some endpoints. It has always been thus. I don't understand what you mean. If by "accept TLSv1.x-unpatched" you mean initial handshakes with the installed base of SSLv3, TLSv1.0, TLSv1.1 or TLSv1.2 without the renegotiation protection then your assertion is flawed. There is absolutely _NO_ known security problem and no vulnerability for a server to accept an initial handshake with the existing SSLv3, TLSv1.0, TLSv1.1 or TLSv1.2 protocol, even when the ClientHello handshake message does neither contain SCSV nor an empty extension RI. The possibility for an "attack" where an old client's renegotiation handshake is proxied into the initial handshake of a server is of no concern to the server. That's purely a client issue and has the prerequisite that the client completely botches the server authentication on the initial handshake and is equivalent in effectiveness to XSRF, XSS and server impersonation -- something that protected TLS renegotiation can not protect from. -Martin
- 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