Subject: [Uta] Hostname validation and other missing details

From: Watson Ladd <[email-masked]>
Date: Tue, 5 Aug 2014 20:53:47 -0700

Dear all,

We seem to be woefully short on advice dealing with hostname
validation. This is probably the real world problem that most often
trips people up, in part because OpenSSL versions prior to 0.9.8 don't
do it, and many TLS libraries have poor interfaces for it. We're also
ignoring a discussion of how to avoid being victimized by Triple
Handshake.

We're also missing ephemeral key reuse and I think the section of
draft-ietf-uta-tls-bcp-01 discussing PFS should include (because it
isn't clear) that the suites with ECDHE or DHE in the name are the
correct ones, not the ECDH or DH ones.

Sincerely,
Watson Ladd

---

From: Richard Moore <[email-masked]>
Date: Wed, 6 Aug 2014 13:18:51 +0100

> ignoring a discussion of how to avoid being victimized by Triple
The hostname validation functions weren't added to openssl until 1.1.0.

Rich.

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 16 Aug 2014 12:51:42 +0300

Hi Watson,

On 08/06/2014 06:53 AM, Watson Ladd wrote:
> do it, and many TLS libraries have poor interfaces for it.

I would appreciate proposed text about hostname validation. I suspect 
this simply amounts to "please implement the RFC correctly", but if 
there's something better we can say, let's do it.

> We're also

Added in our working copy.

>
> We're also missing ephemeral key reuse

The TLS WG keeps ignoring the need to standardize this issue (cf. RFC 
6989). I you can offer some text that would NOT add normative TLS 
behavior but would still be useful, please do so.

> and I think the section of

Sure, done.

Thanks,
	Yaron

---

From: Ralph Holz <[email-masked]>
Date: Sun, 17 Aug 2014 18:21:29 +0200

Hi,

> there's something better we can say, let's do it.

IIRC the current Baseline Requirements by the CA/B Forum have such a
definition. It amounts to putting the domain/host name in the Subject
Alternative Name, with wildcarding defined.

I can put together some text, if you want?

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Ralph Holz <[email-masked]>
Date: Sun, 17 Aug 2014 18:22:40 +0200

EDIT: And of course, RFC 5280 describes the process of correct hostname
validation, too.

Hi,

Ralph

---

From: Watson Ladd <[email-masked]>
Date: Sun, 17 Aug 2014 10:12:38 -0700

> EDIT: And of course, RFC 5280 describes the process of correct hostname

The issue isn't implementing validation: it's knowing that this is a
separate step that TLS implementations (yaSSL, OpenSSL, MatrixSSL,...)
don't do automatically (or in some cases at all). Maybe the text.

"Application authors should take note that TLS implementations
frequently do not validate hostnames, and must therefore determine if
the TLS implementation they are using does, and if not write their own
validation code or consider changing the TLS implementation" would
work.

As for ephemeral keys, I feel that text akin to "TLS users should be
aware that reuse of ephemeral keys negates many of the advantages, and
SHOULD NOT be used" is fine. It might be seen as adding a normative
bit, but that's okay: we're taking optional behavior and saying "yes,
this is good, but alternatives aren't".

Sincerely,
Watson Ladd

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

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

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 17 Aug 2014 20:25:36 +0300

I'm fine with the text re: validation. Thank you. 

But IMHO your text on reuse is, in fact, normative. 

Thanks, Yaron 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 17 Aug 2014 10:38:38 -0700

> But IMHO your text on reuse is, in fact, normative.

And? Banning SSL3 is also normative. Reuse of ephemeral exponents makes
them useless: why can't we say that?
>>> ________________________________
>>>
>>>  Uta mailing list
>>>  [email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 17 Aug 2014 23:22:40 +0300

Banning SSLv3 is something that seems to have the community's consensus 
(we should still ascertain that).

Banning exponent reuse is not, and we know that implementations are 
actually reusing exponents. So we would need a more nuanced wording and 
I think this exercise is outside the scope of this WG.

Thanks,
	Yaron

On 08/17/2014 08:38 PM, Watson Ladd wrote:
>
> On Aug 17, 2014 10:32 AM, "Yaron Sheffer" <[email-masked]
> <mailto:[email-masked]>> wrote:
>  >
>  > On 17 August, 2014 8:12:38 PM GMT+02:00, Watson Ladd
> <[email-masked] <mailto:[email-masked]>> wrote:
>  >>
>  >> On Sun, Aug 17, 2014 at 9:22 AM, Ralph Holz <[email-masked]
> <mailto:[email-masked]>> wrote:
>  >>>
>  >>> [email-masked] <mailto:[email-masked]>

---

From: Watson Ladd <[email-masked]>
Date: Sun, 17 Aug 2014 14:19:54 -0700

On Sun, Aug 17, 2014 at 1:22 PM, Yaron Sheffer <[email-masked]> wrote:
> Banning SSLv3 is something that seems to have the community's consensus (we
> should still ascertain that).
>
> Banning exponent reuse is not, and we know that implementations are actually
> reusing exponents. So we would need a more nuanced wording and I think this
> exercise is outside the scope of this WG.

So we're going to ignore the issue? To be clear, reusing exponents
means an attacker who rolls up, grabs the server and snarfs RAM along
with the disks has every bit of data that ever went through that
server. This is only marginally an improvement from no ephemeral key
exchange, and it's something that people designing systems based on
TLS need to be aware of.

Sincerely,
Watson Ladd

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 17 Aug 2014 14:50:28 -0700

On Aug 17, 2014, at 2:19 PM, Watson Ladd <[email-masked]> wrote:

> To be clear, reusing exponents
> server.

...since the exponent was last changed. It sounds like you are assuming that servers that reuses exponents does so forever, rather than for, say a minute. And yet the argument for some exponent reuse is that regenerating the exponent every time is overkill if they don't care about a minute or so's worth of exposure to the a break-in or to a catastrophic cryptographic attack.

> This is only marginally an improvement from no ephemeral key

So, make them aware of it. Discuss the tradeoffs in that document. This document is about best current practices, and some of those practices are based on assumptions different than yours.

--Paul Hoffman

---

From: Watson Ladd <[email-masked]>
Date: Sun, 17 Aug 2014 15:28:51 -0700

On Aug 17, 2014 2:50 PM, "Paul Hoffman" <[email-masked]> wrote:
> ...since the exponent was last changed. It sounds like you are assuming
that servers that reuses exponents does so forever, rather than for, say a
minute. And yet the argument for some exponent reuse is that regenerating
the exponent every time is overkill if they don't care about a minute or
so's worth of exposure to the a break-in or to a catastrophic cryptographic
attack.

Read the code. Or read AGLs blog post about what servers actually do.
Specifically, many servers generate keys on startup and never again. Given
that restarts are rare, this can be a lot of data.

> So, make them aware of it. Discuss the tradeoffs in that document. This
document is about best current practices, and some of those practices are
based on assumptions different than yours.

The issue is out of scope for this WG, specifically writing the nuanced
wording that is required. Let's assume people mean what they say, and
require them to say what they mean.

---

From: Will Sargent <[email-masked]>
Date: Sun, 17 Aug 2014 17:38:35 -0700

On Sat, Aug 16, 2014 at 2:51 AM, Yaron Sheffer <[email-masked]>
wrote:

> I would appreciate proposed text about hostname validation. I suspect this
> simply amounts to "please implement the RFC correctly", but if there's
> something better we can say, let's do it.

Rather than "please implement the RFC correctly", I'd say "please test that
your implementation correctly implements hostname verification, using
dnschef or another spoofer. I have an example here:
http://tersesystems.com/2014/03/31/testing-hostname-verification/

Will.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Aug 2014 08:11:47 -0700

On Aug 17, 2014, at 5:38 PM, Will Sargent <[email-masked]> wrote:

> Rather than "please implement the RFC correctly", I'd say "please test that your implementation correctly implements hostname verification, using dnschef or another spoofer. I have an example here: http://tersesystems.com/2014/03/31/testing-hostname-verification/ 

So, we can't really say that using that particular implementation verifier is a Best Practice, but we *can* say that verifying that an implementation implements each of the listed best practice is itself a best practice. Separately, someone (probably not me) should create a public list of TLS implementation verification tools, and that should include dnschef (which I had not heard of before).

--Paul Hoffman

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 18 Aug 2014 17:13:41 +0200

> So, we can't really say that using that particular implementation verifier is a Best Practice, but we *can* say that verifying that an implementation implements each of the listed best practice is…

We also need to consider protocols where the hostname is not part of the verification process. SIP currently have the SIP domain, not the server hostname, in the certificate.
There are other protocols than HTTP out there. :-)

/O

---

From: Watson Ladd <[email-masked]>
Date: Mon, 18 Aug 2014 08:22:02 -0700

On Aug 18, 2014 8:12 AM, "Paul Hoffman" <[email-masked]> wrote:
> > Rather than "please implement the RFC correctly", I'd say "please test
that your implementation correctly implements hostname verification, using
dnschef or another spoofer. I have an example here:
http://tersesystems.com/2014/03/31/testing-hostname-verification/
>
> So, we can't really say that using that particular implementation
verifier is a Best Practice, but we *can* say that verifying that an
implementation implements each of the listed best practice is itself a best
practice. Separately, someone (probably not me) should create a public list
of TLS implementation verification tools, and that should include dnschef
(which I had not heard of before).

This is too meta. If your told "make sure X is done", then testing you do X
is implied. I wouldn't want to mandate a particular tool, but it seems
clear to me that "make sure your application checks it sees the right
certificate" addresses the problem directly and is protocol neutral.  We
probably need more wording explaining that overlying applications have
their one ways to do it.

---

From: Will Sargent <[email-masked]>
Date: Mon, 18 Aug 2014 13:36:31 -0700

On Mon, Aug 18, 2014 at 8:22 AM, Watson Ladd <[email-masked]> wrote:

> >  If your told "make sure X is done", then testing you do X is implied.

I think that the kind of people who post to this list think that it's
implied.  I don't believe that the audience would infer that they should
test their code with security tools.  They may not even know that security
tools exist, even as a concept.

I had this problem myself -- when I was writing Play WS, I literally had to
draw a diagram of what was happening in hostname verification to be sure I
understood it.  And I got it wrong! I ended up drawing something over
complicated!  I couldn't find a single good developer oriented description
of what I should look for in implementing hostname verification, and the
JSSE reference guide refers to it as "URL spoofing" so I wasn't sure if it
even meant the same thing.

http://tersesystems.com/2014/03/23/fixing-hostname-verification/

I think at the very least, mentioning a test with an appropriate security
tool and referencing positive and negative tests would be good.  I'm still
surprised that TLS doesn't come with a reference test suite that
implementations have to pass, but that's another discussion.

Will Sargent
Consultant, Professional Services
Typesafe <http://typesafe.com>, the company behind Play Framework
<http://www.playframework.com>, Akka <http://akka.io> and Scala
<http://www.scala-lang.org/>

---

From: Richard Moore <[email-masked]>
Date: Thu, 28 Aug 2014 22:47:01 +0100

> EDIT: And of course, RFC 5280 describes the process of correct hostname

Not in any useful way, from the RFC:

Finally, the semantics of subject alternative names that include
wildcard characters (e.g., as a placeholder for a set of names) are
not addressed by this specification.

ie. it fails to define the part of the hostname verification that is
actually hard. I've found (and reported or fixed) flaws in the hostname
verification of pretty much all the browsers and libraries and I don't
think the rules are clear. I'm happy to add the test cases I use for
testing this stuff myself to the rfc as examples if people think that would
be helpful.

Cheers

Rich.

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 28 Aug 2014 23:53:08 +0200 (CEST)

On Thu, 28 Aug 2014, Richard Moore wrote:

> I've found (and reported or fixed) flaws in the hostname verification of 
> pretty much all the browsers and libraries and I don't think the rules are 
> clear. I'm happy to add the test cases I use for testing this stuff myself 
> to the rfc as examples if people think that would be helpful.

As author of one of those libs Richard speaks of, I can only say that I would 
be happy to see such test cases.

Had we had such tests (and preferably a single RFC detailing all on how to 
verify a TLS server certificate) in the past, perhaps we could have avoided a 
few nasty security vulnerabilities.

--

  / daniel.haxx.se

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 29 Aug 2014 17:06:18 +0300

Hi Daniel, Richard,

In the latest version, we added the following text:

It is noted that the requirements regarding host name validation (and in 
general, binding between the TLS layer and the protocol that runs above 
it) vary between different protocols. For HTTPS, these requirements are 
defined by Sec. 3 of [RFC2818].

Readers are referred to [RFC6125] for further details regarding generic 
host name validation in the TLS context. In addition, the RFC contains a 
long list of example protocols, some of which implement a policy very 
different from HTTPS.

Can you please comment on this text? Please bear in mind that our 
context is wider than just HTTPS.

Thanks,
	Yaron

On 08/29/2014 12:53 AM, Daniel Stenberg wrote:
>> I've found (and reported or fixed) flaws in the hostname verification
>> of pretty much all the browsers and libraries and I don't think the
>> rules are clear. I'm happy to add the test cases I use for testing
>> this stuff myself to the rfc as examples if people think that would be
>> helpful.
>
> As author of one of those libs Richard speaks of, I can only say that I
> would be happy to see such test cases.
>
> Had we had such tests (and preferably a single RFC detailing all on how
> to verify a TLS server certificate) in the past, perhaps we could have
> avoided a few nasty security vulnerabilities.
>
> --
>
>   / daniel.haxx.se
>