Subject: [dane] Impossible situation in the last example of section A.2.1.1. (draft 14)

From: Pieter Lexis <[email-masked]>
Date: Wed, 25 Jan 2012 21:56:36 +0100

Hi,

I just noticed that the last example in section A.2.1.1. describes an
impossible situation, I'll show the example and explain after that:

   sub5.example.com.           IN CNAME sub6.example.com.
   _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab...
   sub6.example.com.           IN A 10.0.0.0
   _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49...

Both TLSA record contain the SHA-256 hash of public key (Selector 1) of
the end-entity certificate and they are different. This is impossible,
as they describe the _exact_ same thing in the same way.

If you connect to port 443 on both sub5 and sub6 you will get the same
certificate from the webserver (because sub5 CNAME sub6) and therefore
one of those connections will be terminated by the TLS stack because the
TLSA doesn't match. A proper example could be:

   sub5.example.com.           IN CNAME sub6.example.com.
   _443._tcp.sub5.example.com. IN TLSA 0 1 1 308202c5308201ab...
   sub6.example.com.           IN A 10.0.0.0
   _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49...

Changing the usage (or the selector, or the matching type) field will
fix this fault.

- -- 
Pieter Lexis

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 25 Jan 2012 22:01:33 +0100

On 25 jan 2012, at 21:56, Pieter Lexis wrote:

> TLSA doesn't match.

SNI (Server Name Identification, RFC 4366) allows you to present different certificates based on the virtual host.

	jakob

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Jan 2012 22:06:12 +0100 (MET)

> as they describe the _exact_ same thing in the same way.

To me that example looks OK (but either needs TLS extension SNI
or a TLS cert with two hostnames or a wildcard cert).

A Web-Browser that gets the URL  https://sub5.example.com
will perform a server endpoint identification for "sub5.example.com",
independent of whether sub5.example.com resolves into an A record directly,
or resolves into an A record through CNAME indirection.

Likewise a Web-Browser that gets the URL https://sub6.example.com
will perform a server endpoint identification for "sub6.example.com"
independent of whether sub6.example.com resolves into an A record directly,
or resolves into an A record through CNAME indirection.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Jan 2012 22:09:21 +0100 (MET)

> or a TLS cert with two hostnames or a wildcard cert).

but based on the differing TLSA contents of that example,
it appears that TLS extension SNI is assumed,
not the multiple dNSName-SubjectAltNames and neither the Wildcard cert.

-Martin

---

From: bert hubert <[email-masked]>
Date: Wed, 25 Jan 2012 22:12:36 +0100

> not the multiple dNSName-SubjectAltNames and neither the Wildcard cert.

It might be 'explainable' why this example could be legit, but it might be better to follow Pieters suggestion and make it something that doesn't need explaining.  It is a minor tweak, shouldn't hurt, and would make things internally more consistent.

	Bert

---

From: Pieter Lexis <[email-masked]>
Date: Thu, 26 Jan 2012 00:37:12 +0100

> not the multiple dNSName-SubjectAltNames and neither the Wildcard cert.

In my experience SNI is hardly deployed 'out there' (but I can't quickly
find an article to prove or disprove it), hence I didn't thought about it.

In order to avoid this confusion (I'd doubt I'm the only one) either a
small remark (+ reference to RFC 4366?) should be added to this example
that the use of SNI is assumed or the example should be changed by
changing one of the first 3 fields in the Rdata. I'd prefer the second
option.

- --
Pieter

---

From: Martin Rex <[email-masked]>
Date: Thu, 26 Jan 2012 00:55:48 +0100 (MET)

> changing one of the first 3 fields in the Rdata. I'd prefer the second

I agree, that examples should not rely on silent assumptions
and let the reader wonder whether the example is incorrect.

If an example relies on optional protocol features, such as
a TLS extension SNI prerequisite for it to work, then this
needs to be clearly spelled out in the description of the
example.

Newer Web Browsers (Firefox,Chrome,Opera) usually support TLS
extension SNI and have it enabled.  Where TLS is not part of the
browser, but part of the OS, the version of the Browser might be
irrelevant, such as on Microsoft Windows XP/2003, where SChannel
does not support TLS extensions, so none of MSIE 6/7/8 has SNI
on XP/2003.  And neither does Apple Safari on Windows XP/2003.

Many programmatic clients do not have TLS extension SNI enabled
(or do not have it at all), because it will require explicit
application-level reconnect fallback code to cope with
extensions-intolerant servers.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 26 Jan 2012 01:20:16 +0100 (MET)

> changing one of the first 3 fields in the Rdata. I'd prefer the second

I forgot

YES, rfc4366 is the correct reference for TLS extension SNI.

Although there is rfc6066 which is _updating_ rfc4366
(rather than obsoleting it, as the incorrect meta-data suggests).

rfc6066 can not possibly obsolete rfc4366, because rfc6066 was
stripped from the definitions of ExtendedClientHello and
ExtendedServerHello PDUs and therefore it is impossible to
use rfc2246 + rfc6066 (without rfc4366) to add support for
TLS extension SNI to an existing implementation of TLSv1.0 (rfc2246).
Same for rfc4346+rfc6066 (without rfc4366) for an existing
implementation of TLSv1.1.

-Martin

---

From: Scott Schmit <[email-masked]>
Date: Wed, 25 Jan 2012 23:34:12 -0500

>    _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49...

Good catch on the original not being terribly sensible without SNI, but
I don't think sub5.example.com having a different type of TLSA record
from sub6.example.com really makes any more sense (you'd either be
saying that the same cert should be checked 2 different ways for no
obvious reason, or that they're different certs.)

IMHO, the best resolution would be this:
    sub5.example.com.           IN CNAME sub6.example.com.
    _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab...
    sub6.example.com.           IN A 10.0.0.0
    _443._tcp.sub6.example.com. IN TLSA 1 1 1 308202c5308201ab...

The selector type being 1 allows example.com to use matching SPKIs with
potentially-different certificates if SNI is used, or a wildcard
certificate, and both are consistent with the example and left to the
imagination of the reader.

While you're at it, the A record shouldn't be pointing at 10.0.0.0;
that's not a valid IPv4 address (based on the RFC 1918 reservation). For
that matter, we should be using an address from 192.0.2.0/24 and include
a AAAA from 2001:db8::/32 to promote IPv6 adoption. :-)

-- 
Scott Schmit

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 26 Jan 2012 07:33:31 +0100

> a AAAA from 2001:db8::/32 to promote IPv6 adoption. :-)

fixed in the next rev of the draft.

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 26 Jan 2012 07:41:05 +0100

> needs to be clearly spelled out in the description of the

I've added the follow text to the next rev of the draft:

+   One should note that deploying different certificates for multiple
+   services located at a shared TLS listener often requires the use of
+   TLS SNI (Server Name Indication) [RFC4366].

	jakob

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 26 Jan 2012 09:06:28 +0100

On 26. 1. 2012, at 0:37, Pieter Lexis wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

It will get deployed more and more as:

1) Windows XP gets replaced
2) IPv4 addresses run out

There's pretty good support for SNI in common webservers.  The Windows XP
and admin inertia are the only two obstacles left.

O.
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: James Cloos <[email-masked]>
Date: Thu, 26 Jan 2012 08:05:08 -0500

>>>>> "SS" == Scott Schmit <[email-masked]> writes:

SS> IMHO, the best resolution would be this:
SS>     sub5.example.com.           IN CNAME sub6.example.com.
SS>     _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab...
SS>     sub6.example.com.           IN A 10.0.0.0
SS>     _443._tcp.sub6.example.com. IN TLSA 1 1 1 308202c5308201ab...

Is it OK for children of a CNAME RR to exist?  Obviously NS and DS RRs
cannot have the same name as a CNAME RR, preventing zone cuts.  But can
they exist w/in a single zone?

I have a vague feeling that we might have dicussed this already, which
is why I didn't ask yesterday.  But just in case....

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Scott Schmit <[email-masked]>
Date: Thu, 26 Jan 2012 08:40:22 -0500

On Thu, Jan 26, 2012 at 08:05:08AM -0500, James Cloos wrote:
> >>>>> "SS" == Scott Schmit writes:
> 

This is legal. CNAMEs aren't allowed to coexist with any other record at
the node in question (with the exception of RRSIGs), but they don't
conflict with elements below them in the tree. That's what I remembered
from our previous discussions, and testing it out with some open & ISP
resolvers, it appears to work just fine.

-- 
Scott Schmit

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 26 Jan 2012 10:29:03 -0500

> resolvers, it appears to work just fine.

As we have recently discovered from, e.g., the way case is handled in
RRSIGs, testing with deployed software is not actually a reliable
measure of what the RFCs say.  But it's also true that there's nothing
in any RFC which makes CNAME a terminal RRTYPE.  Yes, it is permitted
to have records beneath a CNAME.  Interestingly, when this first came
up, it was surprising how many people who knew the DNS well thought
that CNAMEs _were_ a terminal type, so I expect this example will be
an opportunity for some people to learn something.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Martin Rex <[email-masked]>
Date: Thu, 26 Jan 2012 21:23:03 +0100 (MET)

> and admin inertia are the only two obstacles left.

SNI is usable for specific scenarios that are browser-only
and have limited participants/users.

SNI may become generally useful faster than IPv6, but not by
a significant margin.

We don't have support for SNI in the implementation I maintain,
neither in the TLS client, nor in the TLS server.

Support for SSLv3 with an initial SSL Version 2.0 CLIENT-HELLO
appears much more important to our customers (in some parts of
the world XP with MSIE 6 seems to be still common enough for
businesses to care).

-Martin