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

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Sat, 19 Dec 2009 23:31:00 -0500

The only purpose of any protocol is to allow entities to communicate (under a given set of constraints). Thus every effort SHOULD be invested to provide this capability whenever possible. 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".

Personal curiosity - what kind of work do you do? (Feel free to answer in a private email or to ignore altogether.)

I'm shocked that nobody else seems to pick on this. Is it that mid-weekend thing, or am I the only one who cares whether the peer would establish or refuse connection?!

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Sat Dec 19 18:20:25 2009
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

On Dec 19, 2009, at 5:24 AM, Blumenthal, Uri - 0662 - MITLL wrote:

> You're saying it's not important whether the protocol spec demands aborting the connection or not?!  

As long as the spec is clear about what to do in that case (either abort or not), it doesn't really matter what the decision is. The code is about the same. The amount of testing is identical as far as I can tell.

> As long as the processing amount to arrive at the decision is about the same?

I don't know what this means.

-- 
Steve Checkoway

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Steve Checkoway <[email-masked]>
Date: Sun, 20 Dec 2009 07:12:28 -0800

On Dec 19, 2009, at 8:31 PM, Blumenthal, Uri - 0662 - MITLL wrote:

> The only purpose of any protocol is to allow entities to communicate  
> (under a given set of constraints). Thus every effort SHOULD be  
> invested to provide this capability whenever possible. 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".

My point was merely that publication and subsequent implementation of  
the fix is more important than worrying about the specifics of what  
happens when two signals are used (as long as it is clearly specified,  
of course). Others may feel differently.

> I'm shocked that nobody else seems to pick on this. Is it that mid- 
> weekend thing, or am I the only one who cares whether the peer would  
> establish or refuse connection?!

There seem to be roughly 20 emails in this thread and its predecessor  
"Updated draft" talking about this starting with <http://www.imc.org/ietf-tls/mail-archive/msg11433.html 
 >.

-- 
Steve Checkoway

     "Anyone who says that the solution is to educate the users
     hasn't ever met an actual user." -- Bruce Schneier

---

From: Martin Rex <[email-masked]>
Date: Sun, 20 Dec 2009 23:39:47 +0100 (MET)

> of course). Others may feel differently.

http://digbib.ubka.uni-karlsruhe.de/volltexte/documents/1827

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Mon, 21 Dec 2009 10:28:29 -0600

Blumenthal, Uri - 0662 - MITLL wrote:
> invested to provide this capability whenever possible.

TLS is a cryptographic data security protocol.

"Allowing entities to communicate" takes a back seat to the primary goal
of preventing unauthorized communication.

> 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"?

> Personal curiosity - what kind of work do you do? (Feel free to
> answer in a private email or to ignore altogether.)

I do software development (and security research) work on PhoneFactor, a
product/service for doing two-factor authentication with ordinary phones.

> I'm shocked that nobody else seems to pick on this. Is it that
> mid-weekend thing, or am I the only one who cares whether the peer
> would establish or refuse connection?!

Yes, I care greatly that the peer refuses any connection that looks the
least bit funny.

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Tue, 22 Dec 2009 10:21:49 +0200

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

---

From: Marsh Ray <[email-masked]>
Date: Tue, 22 Dec 2009 10:51:15 -0600

Yoav Nir 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".

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

---

From: Ben Laurie <[email-masked]>
Date: Mon, 28 Dec 2009 13:36:36 +0000

On Tue, Dec 22, 2009 at 8:21 AM, Yoav Nir <[email-masked]> wrote:

> 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
CONNECTED(00000003)
write:errno=54

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 30 Dec 2009 12:52:35 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Laurie
Sent: Monday, December 28, 2009 8:37 AM
To: Yoav Nir
Cc: [email-masked]
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

Oh yes we are :-) 

CONNECTED(00000003)

write:errno=54