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

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.

Regards,
Uri

________________________________
From: tls-bounces@ietf.org <tls-bounces@ietf.org>
To: tls@ietf.org <tls@ietf.org>
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.

Dave

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

On Tue, Dec 22, 2009 at 8:21 AM, Yoav Nir <ynir@checkpoint.com<mailto:ynir@checkpoint.com>> 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 www.google.com:443<http://www.google.com:443>
CONNECTED(00000003)
write:errno=54

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls