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

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Mon, 21 Dec 2009 09:27:25 -0500

I see the reasoning, and while one could argue in favor of guessing - the logic presented is good enough (and thus there's no justification for re-opening this can and spending more time on it). 

I withdraw my objection.

Thanks!

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Blumenthal, Uri - 0662 - MITLL; [email-masked] <[email-masked]>
Sent: Mon Dec 21 03:57:19 2009
Subject: RE: [TLS] SCSV vs RI when both specified. Was: Updated draft

Uri Blumenthal wrote:

> OK. Karlsruhe server time-outs on me, so no chance to get enlightened
> by checking that thread. Please indulge me: the one short compelling
> reason why we don't want to say "when two signals are present use this
> one and ignore the other" instead of "when two signals are present -
> abort connection" - is...?

Well, if the spec says "the client MUST not send two signals", then if
two signals are present, it's probably safer to abort (since the
client is not following the spec anyway, it's hard to guess
what its intent was...)

Best regards,
Pasi
(not wearing any hats)

---

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Mon, 21 Dec 2009 23:45:10 -0500

Is this why soldiers in the field switch off their accredited certified secure comm gear (which won't talk when things look the least bit funny?) and turn to cell phones? As for them the need to communicate usually does NOT take a back seat.

We are talking hypothetically of course rather than about this particular TLS decision, which might well be the right choice.

----- Original Message -----
From: Marsh Ray <[email-masked]>
To: Blumenthal, Uri - 0662 - MITLL
Cc: [email-masked]' <[email-masked]>
Sent: Mon Dec 21 11:28:29 2009
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

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.

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: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Wed, 30 Dec 2009 12:58:56 -0500

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: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
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: [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

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

> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls