Re: [TLS] Confirming consensus about one
Martin Rex <mrex@sap.com> Wed, 27 January 2010 15:37 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 906663A6AB6; Wed, 27 Jan 2010 07:37:00 -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 MrpTEeqzbahL; Wed, 27 Jan 2010 07:36:59 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 5FA0D28C0D6; Wed, 27 Jan 2010 07:36:57 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o0RFb4tH004363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 16:37:04 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001271537.o0RFb31s016880@fs4113.wdf.sap.corp>
To: ynir@checkpoint.com
Date: Wed, 27 Jan 2010 16:37:03 +0100
In-Reply-To: <04D03489-0B2F-4301-A957-E0D4030716E6@checkpoint.com> from "Yoav Nir" at Jan 27, 10 09:56:34 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: DPKemp@missi.ncsc.mil, tls@ietf.org, ietf@ietf.org
Subject: Re: [TLS] Confirming consensus about one
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 15:37:00 -0000
Yoav Nir wrote: > > On Jan 27, 2010, at 12:50 AM, Kemp, David P. wrote: > > > Yes. I agree that SCSV could be defined to convey only 1 bit of > > information while RI conveys 2 bits, and agree that -01 (which went > > through last call) does not define it that way. > > > > What I don't understand is why the issue of changing the semantics of > > -01 and -03 to reflect a "1 bit SCSV" is so #$%& important. > > 1. It is trivially easy to code to either version. > > Actually it's easier to hard-code the ciphersuite list on the client, > because it never changes with most applications. Adding logic to > differentiate between initial handshakes and repeated handshakes > complicates the code (though not by much) 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. And it is a different question whether providers of an implementation offer this configuration option (which a number of them likely has to), or wether we recommend that this configuration setting is actually used. These are two different guidances, and the -03 document does not distinguish them, which is a bad idea. > > > 2. There is no security impact of using either version. > > 3. It is easier to articulate and to understand an "identical" soundbite > > than to explain how SCSV and empty RI are semantically different, and > > "SCSV means the client supports RI". There. That was easy to articulate. > An empty extension is less easy IMO. The concept that I had in mind when I created the label TLS_RENEGO_PROTECTION_REQUEST was a signal that indicates "Please protect me from an old-style TLS handshake" And an old-style TLS handshake is one where you have no possibility to detect whether there is an MitM attacking you. > > > 4. The "identical" version is ready to go, in the form of -03 that can > > be published as an RFC right now. Process-wise, Pasi could have made a consensus call on exact SCSV semantics on Dec 17th providing several options, the result of a free and open discussion on SCSV semantics could have been part of -03, Pasi could have re-issued an IETF Last Call on Jan 7th, we would have received further editorial comments and today an -04 document could be in much better shape, ready for IESG approval and in perfect alignment with the IETF processes. > > > And although I hesitate to bring up the following since they are > > non-essential, > > 5. SCSV is a hack meant to appease ancient and/or non-conforming > > servers. That is one ugly baby, and I wish it would just disappear. > > There is absolutely no reason for it ever to be sent in a ClientHello > > containing a non-empty RI (it is a no-op that just wastes N bits of > > bandwidth to convey 0 bits of additional information, and no legacy > > implementation would ever send or interpret it), so I see absolutely no > > downside to prohibiting it during renegotiation. > > To me RI looks like a hack just as much as SCSV. Hopefully in the > future, the way to indicate support for secure renegotiation would > be in the client version of the ClientHello. Unfortunately, that "go away" is impossible for any implementation of TLS that offers interop with protocol versions 0x03,0x00 -> 0x03,0x03 (aka SSLv3 and TLS protocol version v1.0->v1.2). And although clients could stop sending SCSV when they stop using extension-less ClientHellos, the server-side support for SCSV is going to stick forever. Likewise, the TLS extension RI band-aid is going to be with us for at least 20 years. It's not possible to make this design an integral part of a future TLS version that obviates sending this data over the wire. Except maybe defining an alternative and negotiating that as well. The latter could obviate transfering the data, but would require implementations to implement essentialls two solutions for the same problem, which, unless someone finds a problem with TLS extension RI (which I doubt), would be a complete waste of resources. I remember that Stephen Farrell suggested to standardize both (TLS extension RI without SCSV plus a well-discussed successor of draft-mrex-tls-secure-renegotiation), but *I* don't like two solution where one is sufficient. -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)