Re: [TLS] Deployment ... Re: This working group has failed

[Andy Lutomirski <[e-mail]>]

On Tue, Nov 26, 2013 at 3:28 PM, Peter Gutmann <[e-mail]> wrote:
> Andy Lutomirski <[e-mail]> writes:
>
>>- When in client mode, implementations MUST refuse to connect to a server
>>unless an explicitly chosen set of trust roots (or other mechanism such as
>>DANE) authenticates that server (hello, everything).
>
> Translated: "TLS implementations MUST refuse to connect to any computer or
> device that isn't a public web server with a commercial CA-issued
> certificate".  You may as well mandate that "TLS implementations MUST NOT
> allow the tide to come in".

Not at all.  I didn't say "bundled set of trust roots;" I said
"explicitly chosen".  This would ban, for example:

 - stunnel in client mode with verify = 0 or verify = 1
 - OpenSSL's SSL_VERIFY_NONE mode
 - The default behavior of Python's urllib2 module

etc.  If an implementation wanted to offer a scary opt-in way to say
"make me completely insecure", I have no problem with that.  It's
unacceptable, though, that the default behavior of a lot of libraries
is to skip verification.

I personally use TLS with private trust roots -- lots of people do
this.  The problem is when people use TLS with no trust roots at all.

>
> (There's a reason why some of the things are the way they are, and you're
> unlikely to be able to change them unless you control both sides of the
> infrastructure.  Sometimes you can't even do that, witness Google's ongoing
> problems with trying to get Chrome into a secure-by-default mode with Google's
> own servers).

Do you really think that "completely insecure against active attack"
is a good option?

--Andy