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