Subject: [keyassure] End entity certificate matching, trust anchors, and protocol-06

From: Paul Hoffman <[email-masked]>
Date: Sat, 12 Mar 2011 15:01:21 -0800

Greetings again. Draft -06 has two major changes, mandatory-to-implement 
algorithms and revised semantics for End entity certificate matching and 
trust anchors. The first is fairly straight-forward and hopefully 
exactly what was prescribed for the resolution to now-closed issue #21.

The second is more problematic, which is reflected in the fact that 
there is now much more text. Please read the new text carefully, 
including the quoted text from RFC 5280. You may be surprised both by 
the restrictions that PKIX puts on us (namely that self-signed 
certificates are always CA certificates) and by the measures suggested 
in -06 (format validation on end entity certificates is relaxed to allow 
self-signed certificates for end entities).

Comments are, of course, welcome. Proposals for new wording if needed 
are even more welcome. If we have made mistakes in reading RFC 5280, 
quoting from that document in your messages will be helpful to the 
entire WG.

We will be presenting on this in Prague, but would love to see 
discussion happen in the weeks before then.

--Paul Hoffman

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 13 Mar 2011 15:42:44 +1300

Paul Hoffman <[email-masked]> writes:

>Comments are, of course, welcome.

Using http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-protocol-06.txt
(which presnets -06 as diffs against -05) may be helpful here.

Peter.

---

From: Peter Palfrader <[email-masked]>
Date: Mon, 21 Mar 2011 10:25:14 +0100

> Comments are, of course, welcome.

Verison 06 of the draft, in section 2.3, introduces this new paragraph:

|  The end entity certificate from TLS, regardless of whether it was
|  matched with a TLSA type 1 certificate or chained to a TLSA type 2 CA
|  certificate, must have at least one identifier in the subject or
|  subjectAltName field of the matched certificates matches the expected
|  identifier for the TLS server.
[..]

This requirement has been discussed in passing earlier already (e.g in
the thread around [1]), but I think never exhaustively.  If it has and I
just missed it please accept my apologies (and I'd appreciate a pointer
to the right thread).

Do we assume that every client that will ever support TLSA will also
support SNI?  If not, then this would require that every time a virtual
host is added to, or removed from a webserver the certificate be
re-generated to update the list of SANs and the corresponding TLSA
information be updated.

Updating the certificate and its corresponding binding in DNS is not
dissimilar to updating DNSKEY and DS records: care must be taken to get
the timing right, so that's a potential source of error.

Another drawback is that a having all the domains listed as
subjectAltNames in a certificate leaks that list of domains hosted on a
given server.

But even if we do require SNI for TLSA to be useful with virtual
hosting, that still means a virtual hosting provider has to create a
certificate for each of the domains they want to serve[2].

This requirement seems to place some additional burden on the entity
implementing TLSA, but it does not provide any benefit that is obvious
to me.  So I wonder what the rationale for needing a matching CN or SAN
in the certificate is.

Thanks,
Peter

1. http://www.ietf.org/mail-archive/web/keyassure/current/msg01582.html
2. I am not familiar with hardware accelerators for RSA, but I assume
   there are certain limits on the number of keys such a thing can hold
   and some overhead for switching keys, so in the end a hoster might be
   tempted to create all the certificates from the same key material,
   maybe.
-- 
                           |  .''`.       ** Debian **
      Peter Palfrader      | : :' :      The  universal
 http://www.palfrader.org/ | `. `'      Operating System
                           |   `-    http://www.debian.org/

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 21 Mar 2011 10:59:39 +0100

> the timing right, so that's a potential source of error.

Update TLSA resource records is very different from update DNSKEY et al. - as long as you take the TTL into consideration, you can update as you wish.

> certificate for each of the domains they want to serve[2].

Yes, why would that be a problem?

	jakob

---

From: Peter Palfrader <[email-masked]>
Date: Mon, 21 Mar 2011 14:04:30 +0100

On Mon, 21 Mar 2011, Jakob Schlyter wrote:

> Update TLSA resource records is very different from update DNSKEY et
> al. - as long as you take the TTL into consideration, you can update
> as you wish.

Create a new cert, create its hash, send to the DNS guys for inclusion.
Wait TTL.
Deploy new cert.
Mail the DNS people that they can now remove the old hash.

That's not really something you want to have to do all that often.

> Yes, why would that be a problem?

Why is it needed in the first place?

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Mar 2011 08:59:48 -0700

> Why is it needed in the first place?

That's a very good question. I don't feel that it is a "need", but it "makes some sense". That is, if I want to go to www.example.com, and I get an A record for www.example.com, and I get a TLSA record for _http._tcp.www.example.com, and I get a certificate that says "this key is associated with www.somethingelse.com", what does it mean?

I can see both ways: "it doesn't matter what the cert says, we are trusting the binding from the DNS" vs. "the cert needs to mean something"? Jakob and I have that text in because a number of people on the list were in the latter category, but it seems like a reasonable question to ask separately.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2011 15:46:28 -0400 (EDT)

> I can see both ways: "it doesn't matter what the cert says, we are trusting the binding from the DNS" vs. "the cert needs to mean something"? Jakob and I have that text in because a number of peopl…

This is exactly why bare public keys are good for those who do not wish to deal with
a CA or making up arbitrary CN= entries in certificates only used to contain a public
key verified by DNS.

In fact, if forced to use a cert container, I would use a self signed *.xelerance.com,
but I definitely not add a *.xelerance.com wildcard in DNS.

Demanding information that will be filled in with bogus or unvalidatable information
makes no sense from a security point of view.

Paul

---

From: Peter Palfrader <[email-masked]>
Date: Wed, 30 Mar 2011 11:14:16 +0200

On Mon, 21 Mar 2011, Paul Hoffman wrote:

> That's a very good question. I don't feel that it is a "need", but it
> "makes some sense". That is, if I want to go to www.example.com, and I
> get an A record for www.example.com, and I get a TLSA record for
> _http._tcp.www.example.com, and I get a certificate that says "this
> key is associated with www.somethingelse.com", what does it mean?
> 
> I can see both ways: "it doesn't matter what the cert says, we are
> trusting the binding from the DNS" vs. "the cert needs to mean
> something"? Jakob and I have that text in because a number of people
> on the list were in the latter category, but it seems like a
> reasonable question to ask separately.

I wonder if one approach here would be to require a match if, and only
if, any naming attributes (CN, SubjectAltName) are in the certificate.

If there are no CN and no SAN attributes in the certificate then that
would be acceptable too.

Cheers,
Peter

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Mar 2011 07:19:39 -0400

>If there are no CN and no SAN attributes in the certificate then that

A CN is a type of attribute in the Subject DN.  A SAN admits a 
variety of name types, some of which can have attributes. Do you mean 
to focus on DNS names as SANs or did you have a broader range of SANs 
in mind?

Steve

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 13:55:48 +0200

This is outside of DANE's scope.  Checking of names in certificates is up to the application that uses TLS.
--Richard

On Mar 30, 2011, at 1:19 PM, Stephen Kent wrote:

> A CN is a type of attribute in the Subject DN.  A SAN admits a variety of name types, some of which can have attributes. Do you mean to focus on DNS names as SANs or did you have a broader range of SANs in mind?
> 
> Steve
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Jay Daley <[email-masked]>
Date: Thu, 31 Mar 2011 08:45:36 +1300

I would argue the complete opposite - that it is in scope for DANE to state that names in certificates should not be checked because the trust chain has been provided by DNSSEC.  Doing that allows individuals and organisations to reuse certificates as they need to for operational reasons and not as dictated to by suppliers or paranoid protocol developers.

Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 22:03:27 +0200

Nope, it's up to applications.  If you want SN/CAN *not* to be checked for HTTPS, then you need to go revise RFC 2818; for SMTP, RFC 3207; for IMAP/POP3, RFC 2595.

--Richard

---

From: Jay Daley <[email-masked]>
Date: Thu, 31 Mar 2011 09:14:24 +1300

> Nope, it's up to applications.  If you want SN/CAN *not* to be checked for HTTPS, then you need to go revise RFC 2818; for SMTP, RFC 3207; for IMAP/POP3, RFC 2595.

Indeed.

I assumed we were updating RFC 2818.

As for RFC 3207 that says this gem, which is as much use as a chocolate teapot and so will need updating:

-  A SMTP client would probably only want to authenticate an SMTP
   server whose server certificate has a domain name that is the
   domain name that the client thought it was connecting to."

And RFC 2595 is going to need updating because the name check is specific:

   - The client MUST use the server hostname it used to open the
     connection as the value to compare against the server name as
     expressed in the server certificate.  The client MUST NOT use any
     form of the server hostname derived from an insecure remote source
     (e.g., insecure DNS lookup).  CNAME canonicalization is not done.

Jay

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Mar 2011 22:20:21 +0200

> I assumed we were updating RFC 2818.

In that case, this document will need to be dual last called in the
TLS WG, since 2818 was a TLS product.

-Ekr

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 22:36:38 +0200

The milestone reads:
"
April 2011 - First WG draft of standards-track protocol for using DNS to associate hosts with keys for TLS and DTLS
"
So no, not updating 2818, 3207, etc.

The upshot of this naming discussion is that nothing that touches names is going to be general to TLS and DTLS.  So if you want to update 2818 to use DANE for name matching, you'll have to do it in a separate document, either as a new DANE milestone or (more likely) in TLS.  

--Richard

---

From: Martin Rex <[email-masked]>
Date: Thu, 31 Mar 2011 03:05:20 +0200 (MEST)

Eric Rescorla wrote:
> 
> Jay Daley <[email-masked]> wrote:
> >
> > Richard L. Barnes wrote:
> > >
> > > Nope, it's up to applications.  If you want SN/CAN *not* to be
> > > checked for HTTPS, then you need to go revise RFC 2818; for SMTP,
> > > RFC 3207; for IMAP/POP3, RFC 2595.
> >
> > Indeed.
> >

While it doesn't call itself an update to rfc2818 by its document header,
I always assumed it wanted to be this update.

  http://tools.ietf.org/html/rfc6125

The question is more about "if the creator of the certificate placed
attributes in that certificates that are traditionally considered
"constraints" or "usage restrictions", should these be still be honoured,
even if there is no PKIX cert path validation performed on the certificate.

This is why personally, I have a preference to use X.509v1 certs as
self-signed TLS server certs -- there are significantly less attributes
to get wrong by accident.

But the real issue is more about determining intent.
Maybe the DANE TLSA record should also carry a hint whether or not
the cert attributes (anything besides the public key) should
be ignored (= not checked, not seen as usage limitations).

There may be clients in the installed base that have certain
checks or assumptions about presence of specific attributes in
a certificate hardcoded, and the TLS server admin may want to
provide the attributes only/specifically for those old clients
in the installed base -- not for DANE-aware new clients.

-Martin