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

"Blumenthal, Uri - 0662 - MITLL" <> Wed, 30 December 2009 18:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 041EC3A693E for <>; Wed, 30 Dec 2009 10:14:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tG0xDTtIJ7Cv for <>; Wed, 30 Dec 2009 10:14:27 -0800 (PST)
Received: from (LLMAIL1.LL.MIT.EDU []) by (Postfix) with ESMTP id DA7EA3A68A7 for <>; Wed, 30 Dec 2009 10:14:26 -0800 (PST)
Received: (from smtp@localhost) by (8.12.10/8.8.8) id nBUIE2TO018842; Wed, 30 Dec 2009 13:14:02 -0500 (EST)
Received: from ), claiming to be "" via SMTP by llpost, id smtpdAAAjhaGBr; Wed Dec 30 12:58:57 2009
Received: from ([ ]) by ([ ]) with mapi; Wed, 30 Dec 2009 12:58:57 -0500
From: "Blumenthal, Uri - 0662 - MITLL" <>
To: "''" <>, "''" <>
Date: Wed, 30 Dec 2009 12:58:56 -0500
Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft
Thread-Index: AcqHwvNWFWFsD5d6SOGoUYAcAHaNRwBs2tFwAADYvz8=
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90E934FC4BBC1946B3C27E673B4DB0E4A7EE854037LLE2K7BE01mit_"
MIME-Version: 1.0
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Dec 2009 18:14:28 -0000

I find it less than smart (and very counter-productive) trying to hard-code too much policy into the protocol spec.

Yes some policy unfortunately has to be there.


From: <>
To: <>
Sent: Wed Dec 30 12:52:35 2009
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

Amazon and Google are free to accept SSLv2 as well as TLSv1.x-unpatched (minor MSbit unset) if they perceive the benefit of communicating to be greater than the risk of being attacked.   That has no bearing on whether the protocol spec for TLSv1.x-patched requires aborting connections with bozo endpoints, which of course it should.   Service providers/consumers can make their own choice of which protocol versions and ciphersuites to accept, with the knowledge that more restrictive choices will lock out some endpoints.   It has always been thus.


From: [] On Behalf Of Ben Laurie
Sent: Monday, December 28, 2009 8:37 AM
To: Yoav Nir
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

On Tue, Dec 22, 2009 at 8:21 AM, 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.

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.

Oh yes we are :-)

$ openssl s_client -ssl2 -connect<>

TLS mailing list<>