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

From: Peter Gutmann <[email-masked]>
Date: Tue, 26 Nov 2013 23:28:18 +0000

Andy Lutomirski <[email-masked]> 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".

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

Peter.

---

From: Andy Lutomirski <[email-masked]>
Date: Tue, 26 Nov 2013 15:51:56 -0800

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

> problems with trying to get Chrome into a secure-by-default mode with Google's

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

--Andy

---

From: Nico Williams <[email-masked]>
Date: Tue, 26 Nov 2013 19:00:22 -0600

> Do you really think that "completely insecure against active attack"

For some things, yes.  Specifically: SMTP.

Nico
--

---

From: Andy Lutomirski <[email-masked]>
Date: Tue, 26 Nov 2013 17:05:13 -0800

> For some things, yes.  Specifically: SMTP.

Why?

My .msmtprc contains (excerpted):

tls on
tls_starttls on
tls_certcheck on
tls_min_dh_prime_bits 2048
tls_trust_file /etc/ssl/certs/ca-bundle.crt

host smtp.gmail.com

If msmtp were easier to configure, I'd pin Google's CA.  Sadly it's
not, but nonetheless this was *easy* to set up in such a way that my
SMTP is about as secure as HTTPS.

Why on earth is it considered acceptable that the defaults are
insecure?  If it's really okay to connect, *not verify the server
certificate*, and send a password without using a real PAKE algorithm,
then at least the software that does it should not pretend to offer
any form of security.

--Andy

---

From: Nico Williams <[email-masked]>
Date: Tue, 26 Nov 2013 19:46:02 -0600

>> For some things, yes.  Specifically: SMTP.

I'm  talking about SMTP between MTAs, not SUBMIT (SMTP between MUAs
and MSAs).  With that clarification:

Because it's more important that e-mail flow and be delivered than
that it be hop-by-hop secure.

> My .msmtprc contains (excerpted):

You're talking about mail submission.  This part needs to use TLS
securely, of course, though mostly only because your MSA wants to
authenticate you using a plain username and password authentication
method.

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Tue, 26 Nov 2013 17:50:31 -0800

> authenticate you using a plain username and password authentication
Please explain how any authentication method is any help at all when
working over
an insecure channel. Authentication only makes sense when you can link
the authorized
person to the data over the channel.
>
> Nico
> --
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Andy Lutomirski <[email-masked]>
Date: Tue, 26 Nov 2013 17:51:14 -0800

> that it be hop-by-hop secure.

Then let those programs use some kind of hack to turn off
authentication if they really know what they're doing.  (SMTP isn't
hop-by-hop secure, regardless of TLS.)

> authenticate you using a plain username and password authentication

Nearly the entire web works by sending plain usernames and passwords
over TLS, for better or for worse.

--Andy

---

From: Nico Williams <[email-masked]>
Date: Tue, 26 Nov 2013 19:57:17 -0600

On Tue, Nov 26, 2013 at 05:50:31PM -0800, Watson Ladd wrote:
> working over an insecure channel. Authentication only makes sense when
> you can link the authorized person to the data over the channel.

Please re-read.

MTAs generally fallback on not using TLS when using TLS fails when
talking to other MTAs.  Clearly it is an improvement over plain TCP to
use TLS in a way that is vulnerable to active attacks, particularly
considering that e-mail by itself has never been secure.

For *submission* (from your mail client to your outgoing mail server)
it's clear that you want TLS with protection against active attackers.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 26 Nov 2013 20:01:18 -0600

> hop-by-hop secure, regardless of TLS.)

Exactly.  It has to be possible to turn off what you said must not be
possible to turn off.

> over TLS, for better or for worse.

I'm aware, as aware as anybody else.  But here we were talking about
your outgoing mail server... that happens to use the same credentials
for mail submission as for all related web services, which is why it's
so critical that for *submission* TLS be used properly.  But for mail
*transfer* (between MTAs) it's generally more critical that mail get
through than that it do so securely.

Nico
--

---

From: Andy Lutomirski <[email-masked]>
Date: Tue, 26 Nov 2013 18:28:23 -0800

> Exactly.  It has to be possible to turn off what you said must not be

Then I'll propose a rephrased straw-man version:

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).
 As an exception, an implementation may support an explicit "insecure
mode" in which it is possible to disable peer authentication.

In any case, this is moot unless people think it's actually a good
idea to publish something like this.

--Andy

---

From: Yoav Nir <[email-masked]>
Date: Wed, 27 Nov 2013 08:56:55 +0200

> this.  The problem is when people use TLS with no trust roots at all.
If by "lots" you mean too many to get them all together for beer night 
-- yes. But the kind of technical know-how is in short supply, and 
caring about this even among those with technical know-how is also thin 
on the ground.

I'm sure there are thousands of people who use TLS with private trust 
roots, as well as thousands of companies. But that's a small portion of 
people and companies, and the rest of us also need stuff that works.

Yoav

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 27 Nov 2013 11:55:55 -0800

> people and companies, and the rest of us also need stuff that works.

Do you mean that the rest of us need to write mobile apps that appear to
work but are, in fact, insecure?  I really don't think that TLS is
supposed to serve the purpose of making people feel good about using it
-- it's supposed to provide some form of security.

I think that the rest of us actually need a TLS library that doesn't
suck and an easy and foolproof way to create and use a CA key, CA cert,
and server keypair.

--Andy

---

From: Yoav Nir <[email-masked]>
Date: Wed, 27 Nov 2013 21:22:32 +0000

On Nov 27, 2013, at 9:55 PM, Andy Lutomirski <[email-masked]>
 wrote:
> work but are, in fact, insecure?  

No. Those of us who write mobile apps need the know-how, and can and should get it. And they should be able to configure a common library to be secure according to their needs. That does not mean that this library should not have any other modes.
> suck and an easy and foolproof way to create and use a CA key, CA cert,

OpenSSL scripts are a Google search away. XCA is free and available for all platforms. The more irritating part is dealing with revocation.

Yoav

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 27 Nov 2013 14:08:35 -0800

> No. Those of us who write mobile apps need the know-how, and can and should get it. And they should be able to configure a common library to be secure according to their needs. That does not mean t…

Empirically they don't.

Note that I changed my straw-man language to allow an insecure mode.
But I still think that, in any sane TLS implementation, it must be
crystal clear that, by turning off verification, you are doing
something completely insecure.  Insecure-by-default is crap and should
end.

> OpenSSL scripts are a Google search away. XCA is free and available for all platforms. The more irritating part is dealing with revocation.

XCA looks decent.  The OpenSSL scripts that are a Google search away
AFAICT mostly suck or are at the very least written by people who
don't know what they're talking about.

--Andy