Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

Marsh Ray <marsh@extendedsubset.com> Tue, 22 December 2009 16:51 UTC

Return-Path: <marsh@extendedsubset.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 7596D3A68E6 for <tls@core3.amsl.com>; Tue, 22 Dec 2009 08:51:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.592
X-Spam-Level:
X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 qWwxATulJmUP for <tls@core3.amsl.com>; Tue, 22 Dec 2009 08:51:29 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 9F7B93A6889 for <tls@ietf.org>; Tue, 22 Dec 2009 08:51:29 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NN7x2-000EW7-RS; Tue, 22 Dec 2009 16:51:12 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F353D603A; Tue, 22 Dec 2009 16:51:10 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX194045+WZPCAPl/ldnTtk06T3LzTbbmpE8=
Message-ID: <4B30F903.8000305@extendedsubset.com>
Date: Tue, 22 Dec 2009 10:51:15 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854013@LLE2K7-BE01.mitll.ad.local> <4B2FA22D.2090800@extendedsubset.com> <BA53741D-8774-41AD-91FF-0882DEAD3BD3@checkpoint.com>
In-Reply-To: <BA53741D-8774-41AD-91FF-0882DEAD3BD3@checkpoint.com>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft
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: Tue, 22 Dec 2009 16:51:30 -0000

Yoav Nir wrote:
> On Dec 21, 2009, at 6:28 PM, Marsh Ray wrote:
> 
>> Blumenthal, Uri - 0662 - MITLL wrote:
>> 
>>> If the protocol spec demands aborting connection, it better have
>>> a damn good reason to do so - and more substantive than "some
>>> Steve decided it doesn't really matter to him if the peers
>>> connect or not".
>> How about "remote endpoint doesn't pass the bozo test"?
> 
> We do not discriminate against bozos.

If just one or two of the major implementations did from the beginning,
then they wouldn't exist in the ecosystem.

> Seriously, servers are there to communicate. Amazon or Google are not
> going to turn away customers because their browsers are a little off.
> That's why they agree to work in SSLv2.

That's their decision, but you cannot let it drive the evolution of the
protocol. Some users take security very very seriously.

It's common to have a trade-off between security and compatibility.

If the protocol spec mandates behavior on the side of security, it
remains secure for everyone who needs security. If A&G preferred
compatibility they can opt to configure their systems that way.

But if the spec sacrifices security for the sake of compatibility, then
no one can put the missing security back in later.

- Marsh