Re: [TLS] Confirming consensus about one

Yoav Nir <ynir@checkpoint.com> Wed, 27 January 2010 07:56 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 013D73A68B0; Tue, 26 Jan 2010 23:56:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.382
X-Spam-Level:
X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 cpx2fzAn-zOV; Tue, 26 Jan 2010 23:56:30 -0800 (PST)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id ACB4B3A6820; Tue, 26 Jan 2010 23:56:29 -0800 (PST)
X-CheckPoint: {4B5FEF06-10005-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7FE0729C09A; Wed, 27 Jan 2010 09:56:42 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5174629C094; Wed, 27 Jan 2010 09:56:42 +0200 (IST)
X-CheckPoint: {4B5FEF06-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 o0R7ugT7011502; Wed, 27 Jan 2010 09:56:42 +0200 (IST)
X-CheckPoint: {4B5FF1AD-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; Wed, 27 Jan 2010 09:56:56 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "Kemp, David P." <DPKemp@missi.ncsc.mil>
Date: Wed, 27 Jan 2010 09:56:34 +0200
Thread-Topic: [TLS] Confirming consensus about one
Thread-Index: AcqfJkwVWu9svHkcRg2+kKSDKWkFTw==
Message-ID: <04D03489-0B2F-4301-A957-E0D4030716E6@checkpoint.com>
References: <201001261530.o0QFUxAT014069@stingray.missi.ncsc.mil> from "Kemp, David P." at Jan 26, 10 10:30:20 am <201001262143.o0QLhWA6009324@fs4113.wdf.sap.corp> <201001262251.o0QMpJMf020349@stingray.missi.ncsc.mil>
In-Reply-To: <201001262251.o0QMpJMf020349@stingray.missi.ncsc.mil>
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: "tls@ietf.org" <tls@ietf.org>, "ietf@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
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 07:56:31 -0000

I've stayed out of this discussion so far, because my opinion has already been noted, but since you've changed the subject...

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)

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

> 4. The "identical" version is ready to go, in the form of -03 that can
> be published as an RFC right now.

And this would be very important, if the world was holding its breath waiting for RI. I think it will take several years before RI is really deployed in a useful way, so I don't agree that spending a few more weeks getting it right is wrong because we have to publish this thing "now"

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

> 6. Reducing optional elements is always good security hygiene (hash
> collision space, covert channels, stack overflow alignment, etc.)  Take
> away a useless knob and nobody can twiddle that knob against you.
> 
> Dave