Re: [TLS] Confirming consensus about one

Yoav Nir <ynir@checkpoint.com> Thu, 28 January 2010 05:39 UTC

Return-Path: <ynir@checkpoint.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 D3F2B3A6881 for <tls@core3.amsl.com>; Wed, 27 Jan 2010 21:39:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level:
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 OBwzP9JMZJy2 for <tls@core3.amsl.com>; Wed, 27 Jan 2010 21:39:57 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 707233A682B for <tls@ietf.org>; Wed, 27 Jan 2010 21:39:57 -0800 (PST)
X-CheckPoint: {4B61207E-10010-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 49BE029C00A; Thu, 28 Jan 2010 07:40:13 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1052129C002; Thu, 28 Jan 2010 07:40:13 +0200 (IST)
X-CheckPoint: {4B61207E-10000-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o0S5eCT7007478; Thu, 28 Jan 2010 07:40:12 +0200 (IST)
X-CheckPoint: {4B612324-0-1B201DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 28 Jan 2010 07:40:33 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "mrex@sap.com" <mrex@sap.com>
Date: Thu, 28 Jan 2010 07:40:03 +0200
Thread-Topic: [TLS] Confirming consensus about one
Thread-Index: Acqf3GjD/D9OF6HJTC+ow7Ed/lt/vA==
Message-ID: <02F6A83D-6FE0-4095-8523-A91C95BE1481@checkpoint.com>
References: <201001271537.o0RFb31s016880@fs4113.wdf.sap.corp>
In-Reply-To: <201001271537.o0RFb31s016880@fs4113.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "David P. Kemp" <DPKemp@missi.ncsc.mil>, "tls@ietf.org Group" <tls@ietf.org>
Subject: Re: [TLS] Confirming consensus about one
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: Thu, 28 Jan 2010 05:39:59 -0000

On Jan 27, 2010, at 5:37 PM, Martin Rex wrote:

>> 
>>> 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.

There has been discussion about whether RI should actually hold the old verify_data, or whether that should be incorporated into the signature without explicitly sending it. We've settled on the former partly because it is easier to implement in existing code, and easier to explain to certify.

A new version of TLS (4.0?  It's time to stop explaining that three-point-one-means-one-point-zero) would have to be certified again anyway, so it might as well change the way Finished is calculated. Then you don't need either SCSV or RI.

Of course as long as you support older versions of TLS, you still need them, but fully 4.0 handshakes will need neither SCSV nor RI.