Subject: Re: [dane] #13: Server name check for certificate type 1

From: "dane issue tracker" <[email-masked]>
Date: Tue, 08 Nov 2011 10:39:44 -0000

#13: Server name check for certificate type 1

Changes (by warren@…):

 * status:  new => closed
 * resolution:   => worksforme

Comment:

 See email: http://www.ietf.org/mail-archive/web/dane/current/msg03711.html

 This addressed in draft-ietf-dane-protocol-12 in Sections 2.1, 2.2, 2.3,
 most of section 4 and Appendix B.

-- 
--------------------------------+-------------------------
 Reporter:  mlepinsk@…          |       Owner:
     Type:  defect              |      Status:  closed
 Priority:  minor               |   Milestone:
Component:  protocol            |     Version:
 Severity:  Active WG Document  |  Resolution:  worksforme
 Keywords:                      |
--------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/13#comment:2>
dane <http://tools.ietf.org/dane/>

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 08 Nov 2011 08:10:26 -0800

>   most of section 4 and Appendix B.

I'm sorry I missed this when you sent out the call for comments.  I do 
not believe this issue has been adequately addressed in -12.  In 
particular, when the end-entity certificate matches a valid TLSA record 
but does NOT contain embedded name information matching the hostname 
under which the record was found, client behavior is unspecified.

(It's possible that you think "pass PKIX validation" covers this case, 
but that term is ill-defined to the point where I think it needs to be 
eradicated from the spec.)

(I was not able to resolve this issue in my rewrite because I don't know 
what the client *ought* to do in this circumstance, only that there 
needs to be a specified behavior.)

zw

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Nov 2011 09:07:25 -0800

On Nov 8, 2011, at 8:10 AM, Zack Weinberg wrote:

> I'm sorry I missed this when you sent out the call for comments.  I do not believe this issue has been adequately addressed in -12.  In particular, when the end-entity certificate matches a valid TLSA record but does NOT contain embedded name information matching the hostname under which the record was found, client behavior is unspecified.

We should specify it. What is your preference?

> (It's possible that you think "pass PKIX validation" covers this case, but that term is ill-defined to the point where I think it needs to be eradicated from the spec.)

It is defined in the PKIX specification. You may not like it, but that's the standard.

> (I was not able to resolve this issue in my rewrite because I don't know what the client *ought* to do in this circumstance, only that there needs to be a specified behavior.)

So, propose the one you like the best and see what the rest of the WG thinks.

--Paul Hoffman

---

From: Richard Barnes <[email-masked]>
Date: Tue, 8 Nov 2011 12:13:44 -0500

That is the correct behavior.  The name matching algorithm is not a TLS-layer issue, but an application-layer one.
"
   Some specifications for applications that run under TLS, such as
   [RFC2818] for HTTP, require the server's certificate to have a domain
   name that matches the host name expected by the client.  Some
   specifications such at [RFC6125] detail how to match the identify
   given in a PKIX certificate with those expected by the user.
"

On Nov 8, 2011, at 11:10 AM, Zack Weinberg wrote:

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 8 Nov 2011 17:11:44 -0500 (EST)

>   given in a PKIX certificate with those expected by the user.

That will require an update anyway for http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01

Perhap this update needs to be made explicit in that draft to reflect this change. However, it would be nice if
we did not have to force people to use raw pubkeys if they do not want to maintain a subjectAltname= list in their
certificates but still want to take advantage of PKIX validation.

Paul

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 08 Nov 2011 15:01:26 -0800

> We should specify it. What is your preference?

It would certainly be operationally convenient for a type-1 match to 
override domain name information in the certificate (eliminate the need 
for those horrible CDN certificates with dozens of hostnames in the 
subjectAltName) but for backward compatibility's sake people are going 
to have to keep doing that anyway, so I don't see a strong case either way.

I suppose we could split the difference and say that a DANE-compliant 
client MUST interpret a certificate with *no* embedded hostname 
information as if it had had embedded hostname information corresponding 
to the hostname where the TLSA record was, but SHOULD otherwise process 
embedded hostname information as it would have in the absence of TLSA 
records.

I'd like to hear from people who actually operate TLS servers at scale, 
though.

> It is defined in the PKIX specification. You may not like it, but that's the standard.

The definition of "validation" in the PKIX specification is so ambiguous 
that it is unusable.  Please see 
http://www.ietf.org/mail-archive/web/dane/current/msg03284.html and 
http://www.ietf.org/mail-archive/web/dane/current/msg03285.html -- I 
can't say it any better than Peter did.

zw

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Nov 2011 15:27:11 -0800

> That will require an update anyway for http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01

It would be unwise for this WG to get gated behind your draft. Instead, your draft can update both TLS and DANE.

> certificates but still want to take advantage of PKIX validation.

Correct. That is something that your draft should definitely deal with.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Nov 2011 15:31:10 -0800

On Nov 8, 2011, at 3:01 PM, Zack Weinberg wrote:

> It would certainly be operationally convenient for a type-1 match to override domain name information in the certificate (eliminate the need for those horrible CDN certificates with dozens of hostnames in the subjectAltName) but for backward compatibility's sake people are going to have to keep doing that anyway, so I don't see a strong case either way.

Should we take that as that the current wording is good enough?

> I suppose we could split the difference and say that a DANE-compliant client MUST interpret a certificate with *no* embedded hostname information as if it had had embedded hostname information corresponding to the hostname where the TLSA record was, but SHOULD otherwise process embedded hostname information as it would have in the absence of TLSA records.

That's not "splitting the difference", that is a technically separate proposal. 

Personally, I like the first part (if there is no host name, match wherever you got the TLSA record from), but the second part is too vague. What are the exceptions to the SHOULD? I would prefer a MUST or nothing.

> I'd like to hear from people who actually operate TLS servers at scale, though.

Yes, please.

> The definition of "validation" in the PKIX specification is so ambiguous that it is unusable.  

Then you believe that PKIX itself is unusable. The WG has chosen differently so far.

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 08 Nov 2011 15:44:04 -0800

> Should we take that as that the current wording is good enough?

Absolutely not.  I think we need to add wording that says either "TLSA 
hostname overrides in-certificate hostname" or "TLSA hostname must agree 
with in-certificate hostname" or "TLSA hostname overrides in-certificate 
hostname under circumstances X, Y, or Z, and must agree with 
in-certificate hostname otherwise."

But I do not feel qualified to pick one of these options, or to define 
circumstances X, Y, or Z, unilaterally.

> That's not "splitting the difference", that is a technically separate proposal.

I don't see why it matters whether it is a separate proposal or not.

> Personally, I like the first part (if there is no host name, match wherever
 > you got the TLSA record from), but the second part is too vague.
 > What are the exceptions to the SHOULD? I would prefer a MUST or nothing.

Well, Richard's language implies that there exist TLS-using application 
protocols that, as they are spoke, don't bother checking the 
in-certificate hostname(s) at all.  We wouldn't want to break them.  If 
there are no such protocols, then I would be happy to have a MUST.

> Then you believe that PKIX itself is unusable.

Only its definition of validation.

> The WG has chosen differently so far.

Please consider this message an objection to that decision, at whatever 
level of formality is appropriate to the present stage of the process.

zw

---

From: Martin Rex <[email-masked]>
Date: Wed, 9 Nov 2011 00:51:11 +0100 (MET)

Paul Hoffman wrote:
> 
> Zack Weinberg wrote:
> 
> > dane issue tracker wrote:
> > >
> > >  This addressed in draft-ietf-dane-protocol-12 in
> > >  Sections 2.1, 2.2, 2.3, most of section 4 and Appendix B.
> > 
> > I do not believe this issue has been adequately addressed in -12.
> > In particular, when the end-entity certificate matches a valid
> > TLSA record but does NOT contain embedded name information
> > matching the hostname under which the record was found,
> > client behavior is unspecified.
> 

I fully agree with Zack.  It is underspecified and needs to be explicit.

I believe that still performing the matching is preferable to provide
consistent behaviour accross the installed base of future DANE-aware
and existing, DANE-unware TLS clients.  Where both should work,
both should work (and fail) in the same way, unless the information
from PKIX and DANE is in contradiction to each other.

> > but that term is ill-defined to the point where I think it needs to
> > be eradicated from the spec.)
> 
> It is defined in the PKIX specification.
> You may not like it, but that's the standard.

As Richard mentions, this is statement factually wrong.  PKIX validation
has nothing to do with name matching for the purpose of
"TLS server endpoint identification" as defined in rfc2818 section 3.1
or in rfc6125.

rfc2818 was output of the TLS working group, rfc6125 was the output
of an IETF mailing list called "certid" (that was not an official WG).
rfc2818 is informational, documenting behaviour of the installed base,
not standards track.

-Martin

---

From: "dane issue tracker" <[email-masked]>
Date: Wed, 09 Nov 2011 05:06:13 -0000

#13: Hostnames in Certificates

Changes (by matt@…):

 * status:  closed => reopened
 * resolution:  worksforme =>

Comment:

 What is the answer to the question?  I don't see any reference to a server
 name check in the document (as Martin will remind us, "PKIX validation"
 does not include server name checking); does this mean the requirement is
 not imposed?  We certainly want it when the TLSA record contains a CA cert
 different from the server cert, to prevent MITM attackers from diverting
 TLS connections to unrelated servers with certs from the same CA.

-- 
--------------------------------+-----------------------
 Reporter:  mlepinsk@…          |       Owner:
     Type:  defect              |      Status:  reopened
 Priority:  minor               |   Milestone:
Component:  protocol            |     Version:
 Severity:  Active WG Document  |  Resolution:
 Keywords:                      |
--------------------------------+-----------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/13#comment:3>
dane <http://tools.ietf.org/dane/>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 9 Nov 2011 17:21:18 -0500

I still disagree with this.  Names are not considered at the DANE/PKIX/TLS layer -- only the application considers the name.  This document should not place any constraints on what names should or should not be in certificates.  

In any case, it's not clear where such a constraint would fit in.  Consider the three use cases / usage we have: The "cert lock" and "CA lock" usages place hard constraints on names -- the only name allowed in the matching cert is the one in the record.  In the "CA lock" case, the end server certificate can also be constrained by X.509 name constraints.  

In the "TA assertion" case, name constraint is actually the opposite of what you want in some cases.  If you want to use the same CA certificate as the basis for multiple hosts, you'll want to have the CA certificate have a different name than the individual host certificates.   

Now, all that said, there are some name-based risks.  Certain applications do rely on PKIX authorities as a stop-gap when DNSSEC isn't available, so if we make PKIX authority rest on DNSSEC, then we might create vulnerabilities for these applications.  For example, XMPP uses SRV to redirect between domains:
  _xmpp-server._tcp.example.com SRV xmpp1.provider.com 5222
When this record is not protected by DNSSEC, the server at xmpp1.provider.com has to authenticate as "example.com", so that the PKIX CA effectively attests to the delegation.  However, if the client uses a TLSA record under xmpp1.provider.com, the target server can assume any identity it wants to by asserting a usage-2 certificate with the proper name.

I think the proper resolution here is to clarify which domain is used to locate the TLSA records.  In the terminology of RFC 6125, the proper domain is the "source domain", the domain that the client expects the server to authenticate.  In the above example, "example.com".  Suggested change in Section 3:

OLD:
"
TLSA resource records are stored at a prefixed DNS domain name.
"
NEW:
"
The "source domain" for a TLS connection is the name that a client expects a server to present in the TLS handshake.  When a client wishes to connect to a given source domain, it searches for TLSA records under a special name formed by appending a prefix to the source domain.
"

--Richard

BTW, with regard to "those horrible CDN certificates with dozens of hostnames in the subjectAltName": DANE is not the droid you're looking for:
<http://en.wikipedia.org/wiki/Server_Name_Indication>
<http://tools.ietf.org/html/rfc6066#section-3>

On Nov 8, 2011, at 6:01 PM, Zack Weinberg wrote:

> The definition of "validation" in the PKIX specification is so ambiguous that it is unusable.  Please see http://www.ietf.org/mail-archive/web/dane/current/msg03284.html and http://www.ietf.org/mail-archive/web/dane/current/msg03285.html -- I can't say it any better than Peter did.
> 
> zw

---

From: Martin Rex <[email-masked]>
Date: Wed, 9 Nov 2011 23:43:05 +0100 (MET)

Richard Barnes wrote:
> 
> I still disagree with this.  Names are not considered at the
> DANE/PKIX/TLS layer -- only the application considers the name.
> This document should not place any constraints on what names should
> or should not be in certificates.  

I strongly disagree.

Matching of DNS names is an integral part of the security architecture
of DANE, because the name is necessary in order to obtain the relevant
DANE records.

While you could use TLS with PKIX and arbitrary certs and use
initial-leap-of-faith with cert-pinning (SSH-style) or out-of-band
confirmation for server endpoint identification, and thus work
without rfc2818 section 3.1 or rfc6125, this is impossible for DANE.

-Martin

---

From: Richard Barnes <[email-masked]>
Date: Wed, 9 Nov 2011 17:52:39 -0500

> of DANE, because the name is necessary in order to obtain the relevant

I certainly agree.  The choice of domain name is critical.  Hence the suggestion at the bottom of my previous message, pasted here for your convenience:

OLD:
"

That's the level at which we need to address domain names, not the content of the certificate.

--Richard

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Nov 2011 00:19:26 +0100 (MET)

Richard Barnes wrote:
> I certainly agree.  The choice of domain name is critical.
> Hence the suggestion at the bottom of my previous message,
> pasted here for your convenience:
>
>  [...]
> 

Thinking about it, I might need to clarify and adjust my position about
"PKIX validation" being unrelated to "server endpoint identification".

While technically independent, there are certainly assumptions made
on the part of the issuing CA and on the part of PKIX (at least those
who still believe that Name Constraints are not a complete failure).

If we allow skipping of the traditional server endpoint identification
for type 1 certificates, then we would be actively creating new
security problems and nullify the security value of commercial
SSL certificates and the RA process behind it for TLS clients that
implement DANE.

Picture this:
  - a TLS client with the intention to connect to
    https://www.higlytrustedbank.x-z-z
  - being MiTMed by an attacker, who is in posession of
    a real server cert for https://www.realbadguy.x-y-y
    from a commercial CA.

If we specify that traditional server endpoint matching is to
be skipped when a DANE TLSA record for a type 1 certificate
with a completely different server name exists, then we're
completely subverting the original TLS X.509 PKI trust model
for TLS clients that implement DANE.

Personally, I really do _not_ like that idea.  DANE adds value
when both checks are performed.  Doing the orginial (PKIX-based)
server endpoint identification only half-assed IMHO renders
the type 1 certificates useless.

-Martin

---

From: Richard Barnes <[email-masked]>
Date: Wed, 9 Nov 2011 22:46:51 -0500

> the type 1 certificates useless.

Good point.  I think we're in agreement here.  Using the source domain to locate TLSA records means you get both checks:
-- Client only takes records from www.highlytrustedbank.x-z-z (due to DANE)
-- Client only accepts certs with name www.highlytrustedbank.x-z-z (due to application)

Since the various TLS-based applications already specify the latter, we only need to address the former.

--Richard

---

From: Warren Kumari <[email-masked]>
Date: Sun, 13 Nov 2011 18:37:44 +0800

Ok, I am going to be re-closing this issue as I think this has been cleared up..

As a process point the chairs ask that folk do not reopen issues themselves  -- if you feel that consensus was not correctly judged, or that an issue was not fully addressed (or was misunderstood), please feel free to let us know and we'll re-evaluate / poll the WG, etc… 

W

---

From: "dane issue tracker" <[email-masked]>
Date: Sun, 13 Nov 2011 15:47:20 -0000

Changes (by warren@…):

 * status:  reopened => closed
 * resolution:   => worksforme

Comment:

 See: http://www.ietf.org/mail-archive/web/dane/current/msg03739.html

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/13#comment:4>
dane <http://tools.ietf.org/dane/>