Re: [TLS] Chatter on consensus
Martin Rex <mrex@sap.com> Wed, 27 January 2010 21:02 UTC
Return-Path: <mrex@sap.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 1264A3A69F6 for <tls@core3.amsl.com>; Wed, 27 Jan 2010 13:02:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 x+DdoE6svvhC for <tls@core3.amsl.com>; Wed, 27 Jan 2010 13:02:07 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 7921B3A6828 for <tls@ietf.org>; Wed, 27 Jan 2010 13:02:06 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o0RL2JUL007673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 22:02:19 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001272102.o0RL2I9x007631@fs4113.wdf.sap.corp>
To: DPKemp@missi.ncsc.mil
Date: Wed, 27 Jan 2010 22:02:18 +0100
In-Reply-To: <201001271913.o0RJD2B7008022@stingray.missi.ncsc.mil> from "Kemp, David P." at Jan 27, 10 02:13:00 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Chatter on consensus
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." <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: Wed, 27 Jan 2010 21:02:09 -0000
Kemp, David P. wrote: > > > From: Martin Rex [mailto:mrex@sap.com] > > > > These two MUST NOTs and the two unexplained NOT RECOMMENDEDs > > to which I'm opposed are clear violations of rfc-2119 section 6: > > This is admittedly a strong argument. However, in my opinion, alignment > with 2119 must be evaluated in light of: > > > [Nikos]: I believe allowing the sending of both SCSV > > and extension might harm interoperability instead. This is a clear misunderstanding on the issue. Secure renegotiation requires verification of the contents of the verify_data contained in the renegotiation_info. So if the presence of an empty RI or SCSV in a ClientHello during a handshake that is a renegotiation to the server confuses a server about having to match the verify_data, then you have much more serious issues to worry about. > > > [Pettersen]: The SCSV is a temporary fallback, one that > > will not be needed when clients enter strict mode, since > > when that happens servers have to support the RI extension. This is also a misunderstanding. The requirement for the server to recognize SCSV is PERMANENT, even in -03. Clients may stop sending SCSV when they stop sending extension-less ClientHellos or SSLv2 CLIENT-HELLO, but the requirement for the server to recognize SCSV is going to stick for just as long as the support for TLS protocol_versions {0x03,0x00} to {0x03,0x03} Personally, I believe it is not possible to create an argument (that is not lame) to justify that violation of rfc-2119 section 6. As previously mentioned, I have provided an explanation along the lines of a semi-formal correctness proof that these signals do not interfere with each other -- it only a bad choice of description in the document. The only reason why this awkward exception was added to the document is to make it less obvious that not making SCSV mandatory and getting rid of empty RI on initial handshakes in ClientHello is a poor engineering decision. Just as it is often possible to simplify logic circuits to obtain the results of complex boolean functions, the use of abstract architecture and methodologies from functional correctness proofing can help you simplify the results if you, for whatever reason, want to combine two different implementations of the same feature of an abstract architecture. > > > From: Martin Rex [mailto:mrex@sap.com] > > > > It more complicated than that, because SCSV is additionally > > necessary for sensible behaviour even with -03 when doing > > old renegotiation on a connection where the initial > > ClientHello did not use any TLS extensions. > > Say whaaaaat? When doing old renegotiation, neither SCSV nor RI are > necessary because by assumption the client, the server, or both do not > support secure renegotiation. For me, that's a deja-vu. I've found myself pretty unsuccessful convincing people at the abstract architecture level. I always have to resort to scaring people with depictions of attack scenarios to get their attention. In case that you are a TLS implementor, then we DEFINITELY need that brand-new section 4.2 in the -03 document fixed before publication. It's been discussed during IETF Last Call of the -01 document: Martin Rex http://www.ietf.org/mail-archive/web/tls/current/msg05151.html Marsh Ray http://www.ietf.org/mail-archive/web/tls/current/msg05155.html Pasi Eronen http://www.ietf.org/mail-archive/web/tls/current/msg05186.html We in the IETF are supposed to provide the highest possible interoperability, configuration options for policy and resonable default settings. Quoting section 4 from the -03 ("current") version of the WG document: 4. Backward Compatibility Existing implementations which do not support this extension are widely deployed and in general must interoperate with newer implementations which do support it. This section describes considerations for backward compatible interoperation. What exact settings the consumer of the technology uses is up to the consumer. If you are worried about "original" TLS, then your browser ought to have regular HTTP and FTP securely disabled? (my browser does not even provide such a setting...) > > If an old server requests a new client to renegotiate, and: > 1) the client ignores the RECOMMENDED refusal to renegotiate, and > 2) the old server INCORRECTLY fails to ignore extensions, and > 3) the client sends an RI extension as RECOMMENDED, > ... then there may be a handshake failure, which sounds to me like the > desired outcome in such a broken circumstance. If that was really the desired outcome, then our browsers would already have old renegotiation securely removed for months. Browsers probably are the most regularly patched pieces of software we have. No. A client MUST send either RI or SCSV to an _old_ server on a permitted old renegotiation so that this handshake can not be proxied by an MitM into an initial handshake of a _patched_ server. If the connection is not attack, that signal ends up being totally ignored. Which is exactly what the convoluted section 4.2 says. > > If the client instead sends SCSV in order to dodge a handshake failure, > which is NOT RECOMMENDED, the server is prevented from immediately > detecting an attack. Sending SCSV in this circumstance, far from being > necessary or sensible, sounds to me like reckless behavior - pushing the > envelope of legacy interoperability. That NOT RECOMMENDED makes no sense here and violates rfc-2119 section 6. The general interop recommendation in TLS is that you get the highest chance of interoperability if a client supplies the same parameters in a renegotiation ClientHello that it applied in the initial ClientHello on a connection. Same for session resume on a new connection. If the client didn't send TLS extensinons in the initial ClientHello, it is a pretty bad advice to start sending TLS extensions in the renegotiation ClientHello, and it is in conflict with the general recommendation for what TLS client should do for maximum interop (send the same parameters in ClientHello). And if the client does not want to renegotiate, then there is no ClientHello to be sent but instead either a warning-level no_renegotiation alert if the clients wants to try continue talking or a fatal handshake_failure if the client wants to abort the connection. > > As above, it might enhance interoperability long-term if new clients > operating in secure renegotiation mode simply failed to renegotiate with > broken servers. If I were for changes to -03 (which I am NOT!), it > would be to change NOT RECOMMENDED to MUST NOT send SCSV in insecure > renegotiation. That would not only violate rfc-2119, that would be completely unreasonable. I do _not_ mind if you do not care for backwards interop scenarios, but I would recommend that you get out of the way of those who care because they must provide it to their customers in a non-disruptive fashion. -Martin
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Chatter on consensus Martin Rex
- [TLS] Confirming consensus about one draft-ietf-t… Pasi.Eronen
- Re: [TLS] Confirming consensus about one draft-ie… Robert Dugal
- Re: [TLS] Confirming consensus about one draft-ie… Dr Stephen Henson
- Re: [TLS] Confirming consensus about one draft-ie… Kemp, David P.
- Re: [TLS] Confirming consensus about one draft-ie… Paul Hoffman
- Re: [TLS] Confirming consensus about one draft-ie… Michael D'Errico
- Re: [TLS] Confirming consensus about one draft-ie… Rex, Martin
- Re: [TLS] Confirming consensus about one draft-ie… Joseph Salowey (jsalowey)
- Re: [TLS] Confirming consensus about one draft-ie… Martin Rex
- [TLS] Metadiscussion on changes in draft-ietf-tls… Paul Hoffman
- Re: [TLS] Confirming consensus about one draft-ie… Marsh Ray
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Confirming consensus about one draft-ie… Hovav Shacham
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Confirming consensus about one Kemp, David P.
- Re: [TLS] Confirming consensus about one draft-ie… Nikos Mavrogiannopoulos
- Re: [TLS] Confirming consensus about one Yoav Nir
- Re: [TLS] Confirming consensus about one draft-ie… Yngve Nysaeter Pettersen
- [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Chatter on consensus Martin Rex
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Confirming consensus about one Nelson B Bolyard
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Metadiscussion on changes in draft-ietf… Bob Braden
- Re: [TLS] Confirming consensus about one Michael D'Errico
- Re: [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Confirming consensus about one Marsh Ray
- Re: [TLS] Confirming consensus about one draft-ie… Robert Relyea
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Metadiscussion on changes in draft-ietf… Paul Hoffman
- [TLS] interoperability and security guarantees [w… Daniel Kahn Gillmor
- Re: [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Chatter on consensus Michael D'Errico
- Re: [TLS] Chatter on consensus Martin Rex
- Re: [TLS] Confirming consensus about one Yoav Nir
- Re: [TLS] Metadiscussion on changes in draft-ietf… Pasi.Eronen
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Chatter on consensus Nikos Mavrogiannopoulos
- Re: [TLS] Metadiscussion on changes in draft-ietf… Pasi.Eronen
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Confirming consensus about one draft-ie… Paul Hoffman
- Re: [TLS] Confirming consensus about one draft-ie… Martin Rex
- Re: [TLS] Chatter on consensus Martin Rex
- Re: [TLS] Confirming consensus about one draft-ie… Bill Frantz
- Re: [TLS] Confirming consensus about one draft-ie… tom.petch
- Re: [TLS] Confirming consensus about one draft-ie… Joseph Salowey (jsalowey)