Subject: [Fwd: I-D Action:draft-saintandre-tls-server-id-check-00.txt]

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Jun 2009 16:34:18 -0600

FYI. All I did was update the references, change the title slightly, and
update the authors. Feedback is welcome before we publish a version with
more significant modifications.

Peter

- -------- Original Message --------
Subject: I-D Action:draft-saintandre-tls-server-id-check-00.txt
Date: Wed,  3 Jun 2009 15:30:02 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Best Practices for Checking of Server Identities in
the Context of Transport Layer Security (TLS)
	Author(s)       : P. Saint-Andre, et al.
	Filename        : draft-saintandre-tls-server-id-check-00.txt
	Pages           : 7
	Date            : 2009-06-03

This document specifies the how an entity establishing a TLS
connection, or other PKI-based interaction, with a server should
verify the server identity.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 04 Jun 2009 10:29:17 +0200

> more significant modifications.

Generally, I agree a document like this is needed.  Some suggestions:

1) Define all terminology in section 2.  The term "reference identity"
is defined in section 3 but used in other sections too.

2) Re 3.1, should the reference identity be considered a stored string
wrt IDNA?  As I understand what reference identity refers to, it seems
like a query string to me.

Thanks,
/Simon

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Jun 2009 07:24:21 -0700

Greetings again. I would like to argue that, from a security perspective, we should not allow looking up DNS names in the subjecName in PKIX certificates in this document. Section 3.1 says:
   The server's identity may also be verified by comparing the reference
   identity to the Common Name (CN) [LDAP-SCHEMA] value in the leaf
   Relative Distinguished Name (RDN) of the subjectName field of the
   server's certificate.  This comparison is performed using the rules
   for comparison of DNS names in Section 3.1.3.1, below, with the
   exception that no wildcard matching is allowed.  Although the use of
   the Common Name value is existing practice, it is deprecated, and
   Certification Authorities are encouraged to provide subjectAltName
   values instead.  Note that the TLS implementation may represent DNs
   in certificates according to X.500 or other conventions.  For
   example, some X.500 implementations order the RDNs in a DN using a
   left-to-right (most significant to least significant) convention
   instead of LDAP's right-to-left convention.

That ambiguity leads to a fairly trivial identity attack. There is no good reason for a CA to issue certificates with domain names in the subjectName, and lots of reasons for it not to. This document should prohibit checking domain names in the subjectName, and should say why.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 05 Jun 2009 23:42:20 +0100

Hi Paul,

Paul Hoffman wrote:

>Greetings again. I would like to argue that, from a security perspective, we should not allow looking up DNS names in the subjectName in PKIX certificates in this document. Section 3.1 says:
>That ambiguity leads to a fairly trivial identity attack.
>
Can you elaborate on this? (A pointer to discussion elsewhere would be 
fine as well.)

>There is no good reason for a CA to issue certificates with domain names in the subjectName, and lots of reasons for it not to.
>
I think the current reality is that many of CAs still do that without 
supporting DNS name in the subjectAltName.

>This document should prohibit checking domain names in the subjectName, and should say why.
>

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 6 Jun 2009 07:51:12 -0700

At 11:42 PM +0100 6/5/09, Alexey Melnikov wrote:
>Can you elaborate on this? (A pointer to discussion elsewhere would be fine as well.)

If there is a TLD that has the same name as the SLD that you want to attack, you can get a certificate that uses the CNs. For example, if you want to attack ar.com, you could register com.ar, get a certificate for it, and use it to fool systems that follow the rule in the last sentence above. This attack will get easier as more TLDs with names that exist as current SLDs are created in the coming years.

>I think the current reality is that many of CAs still do that without supporting DNS name in the subjectAltName.

Probably. Are you saying that the fact that they are doing this knowingly insecurely should stop us from prohibiting it in this profile? This profile is supposed to be a way to codify secure authentication practice. Saying "but there are CAs who do it wrong and you should validate their certificates anyway" seems counterproductive.

---

From: John C Klensin <[email-masked]>
Date: Sun, 07 Jun 2009 14:27:18 -0400

Alexey,

I'll let Paul supply the references and details (although I'd be
happy to collaborate with him if needed and if neither of you
are in a hurry), but, fwiw, I basically agree with his reasoning
as expressed in this and other notes.  We've created
flexibilities that can, with the help (intentional or otherwise)
of top-level and root registries, render the names ambiguous and
hence subject to attack.  With the apparent ICANN intention of
treating the root zone strictly as a market-driven activity and
to exercise little or no control over the behavior of TLD
registries, the opportunity to have (to take an entirely
fanciful example) com.berlin as well as berlin.com appears to be
just a matter of time and revenue stream to ICANN... with no
processes in place to require that they be under the same
control.  

An alternative to Paul's proposal to simply deprecate domain
names in this context would be to require that they all be
explicitly root-anchored, i.e., that "com.berlin" would be
invalid, but "com.berlin." would be permitted.  But my suspicion
is that convention would be neither honored nor effective,
especially since that convention has no obvious X.500 DN
equivalent.

    john

--On Friday, June 05, 2009 23:42 +0100 Alexey Melnikov
<[email-masked]> wrote:

> Hi Paul,
> 
> Paul Hoffman wrote:
> 
>> Greetings again. I would like to argue that, from a security
>> perspective, we should not allow looking up DNS names in the
>> subjectName in PKIX certificates in this document. Section
>> 3.1 says: The server's identity may also be verified by
>>   comparing the reference identity to the Common Name (CN)
>>   [LDAP-SCHEMA] value in the leaf Relative Distinguished Name
>>   (RDN) of the subjectName field of the server's certificate.
>>   This comparison is performed using the rules for comparison
>>   of DNS names in Section 3.1.3.1, below, with the exception
>>   that no wildcard matching is allowed.  Although the use of
>>   the Common Name value is existing practice, it is
>>   deprecated, and Certification Authorities are encouraged to
>>   provide subjectAltName values instead.  Note that the TLS
>>   implementation may represent DNs in certificates according
>>   to X.500 or other conventions.  For example, some X.500
>>   implementations order the RDNs in a DN using a
>>   left-to-right (most significant to least significant)
>>   convention instead of LDAP's right-to-left convention.
>> 
>> There is no good reason for a CA to issue certificates with
>> domain names in the subjectName, and lots of reasons for it
>> not to.
>> 
> I think the current reality is that many of CAs still do that
> without supporting DNS name in the subjectAltName.
> 
> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 07 Jun 2009 20:31:03 +0100

Paul Hoffman wrote:

>>>That ambiguity leads to a fairly trivial identity attack
>>>
Paul, I missed your point entirely. Yes, this is indeed a concern.

However I believe the text is talking about something else entirely. It 
is talking about order of Relative DNs (RDNs). For example, a 
subjectName for a domain might look like:

  cn=www.example.com, ou=Web Services, c=GB

Here c=GB is the most significant RDN. What the text is saying is that 
some X.500 implementations would represent it as

  c=GB, ou=Web Services, cn=www.example.com

or something like this. Kurt can probably explain this better than I can.

So there is no reordering of domains inside the CN value.
[As a side note, if the document were allowing use of DC (domain 
components) in subjectName, the problem you've identifier would have 
been relevant:
 dc=com, dc=ar, ou=Web Services, c=GB
versa
 dc=ar, dc=com, ou=Web Services, c=GB
]

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 07 Jun 2009 20:32:49 +0100

>processes in place to require that they be under the same
Right.

>especially since that convention has no obvious X.500 DN
Indeed.

But as per my reply to Paul, I don't think this is actually an issue.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 7 Jun 2009 13:35:07 -0700

At 8:31 PM +0100 6/7/09, Alexey Melnikov wrote:
>[As a side note, if the document were allowing use of DC (domain components) in subjectName, the problem you've identifier would have been relevant:

I am assuming that the problem is reordering of DC values. None of the others affect the matching discussed in this document. It is *completely* believable that some implementations string together the DC values in different orders.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 08 Jun 2009 11:09:17 +0100

>I am assuming that the problem is reordering of DC values. None of the others affect the matching discussed in this document. It is *completely* believable that some implementations string together…
Right.
Use of DC attributes is already disallowed by not being explicitly allowed.

Of course the document needs to be clear on what it means about 
left-to-right RDN ordering versa right-to-left RDN ordering. So some 
text needs to be added to clarify, or the confusing sentence needs to be 
removed.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Jun 2009 07:02:39 -0700

>Use of DC attributes is already disallowed by not being explicitly allowed.

It would be better if it was explicit, given that many systems still use DC.

>Of course the document needs to be clear on what it means about left-to-right RDN ordering versa right-to-left RDN ordering. So some text needs to be added to clarify, or the confusing sentence needs to be removed.

Fully agree. Examples of where it is and is not OK to look would be helpful here.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 8 Jun 2009 16:22:12 +0200

> It would be better if it was explicit, given that many systems still  

While I tend to agree with you Paul (and specifically, I do not  
personally like DC naming), I am also nervous over words like "many",  
"few", "almost everyone" etc.

Do you have any knowledge of how bad the situation really is? Is there  
anything more to do to fix this? Do we talk about many standards, many  
vendors, many products, many deployed entities -- or all of the above?

    Patrik

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 08 Jun 2009 15:57:50 +0100

Philip Guenther wrote:

>On Mon, 8 Jun 2009, Paul Hoffman wrote:
>  
>
>My understanding is that all Alexey is saying that an implementation that 
>matches a cert whose subject is
>	dc=example,dc=com
>
>(expressed in LDAP-style, most-specific-leftmost) against the domain 
>"example.com" is not compliant because that is not a documented method.
>  
>
Yes.

>Is that what you're saying many systems do, Paul?
>  
>
I can't say I am an expert, but this never came up for Isode's deployments.
For example, openssl wouldn't generate certificates containing DC RDNs 
be default. So one has to go out of the way to do that.

However I know that Microsoft uses DC attributes for naming 
users/servers. So subjectNames with DC might be generated for such entities.

>(I don't think there's any suggestion here of deprecating the use of dc 
>components in DNs; they just can't be used for the SSL hostname check.)
>  
>
Exactly.

---

From: Philip Guenther <[email-masked]>
Date: Mon, 8 Jun 2009 08:44:59 -0600

Philip Guenther

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Jun 2009 09:04:26 -0700

At 3:57 PM +0100 6/8/09, Alexey Melnikov wrote:
>Philip Guenther wrote:
>>(I don't think there's any suggestion here of deprecating the use of dc components in DNs; they just can't be used for the SSL hostname check.)
>Exactly.

There was a desire to make this document useful for more than TLS if other groups want to re-use it. I would like to see this document not allow the use of DC in DNs for validating host names. That is definitely not a prohibition on CAs issuing certificates with DCs; a CA can decide whether or not they want to continue to do so in a world where parties follow this document.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Jun 2009 12:33:24 -0500

On Sat, Jun 06, 2009 at 07:51:12AM -0700, Paul Hoffman wrote:
> >>There is no good reason for a CA to issue certificates with domain
> >>names in the subjectName, and lots of reasons for it not to.
> >>
> Probably. Are you saying that the fact that they are doing this
> knowingly insecurely should stop us from prohibiting it in this
> profile? This profile is supposed to be a way to codify secure
> authentication practice. Saying "but there are CAs who do it wrong and
> you should validate their certificates anyway" seems
> counterproductive.

Non-interop would also be counter-productive.  And a knob wouldn't be
much help either.  A phase-out of certs with domain names in subjectName
seems in order.  Perhaps we should say that such certs issued after some
date are prohibited.

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Jun 2009 10:59:05 -0700

At 12:33 PM -0500 6/8/09, Nicolas Williams wrote:
>A phase-out of certs with domain names in subjectName
>seems in order. 

Not at all. It is fine to have a certificate with a subject with a CN of "www.example.com". That value follows the semantics for "common name".

>Perhaps we should say that such certs issued after some
>date are prohibited.

The chance of this have any success is near zero.

The document in question is about validating systems, not CAs. I think it is quite appropriate for us to keep that focus.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Jun 2009 12:58:47 -0500

On Mon, Jun 08, 2009 at 10:59:05AM -0700, Paul Hoffman wrote:
> Not at all. It is fine to have a certificate with a subject with a CN
> of "www.example.com". That value follows the semantics for "common
> name".

I hadn't caught up with the rest of the thread, which subsequently made
clear what the issue was.  I retract my comment.

Nico
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 12 Jun 2009 07:15:53 -0700

On Jun 8, 2009, at 7:02 AM, Paul Hoffman wrote:

>> left-to-right RDN ordering versa right-to-left RDN ordering. So  
>> some text needs to be added to clarify, or the confusing sentence  
>> needs to be removed.
>

The document should say that when CN=domain AVA is used, this AVA  
ought be the only AVA in the RDN (not a multi-valued RDN), and the RDN  
ought to be least significant RDN of the DN.   (Avoid the left-to- 
right/right-to-left descriptions, as these terms are based upon text  
representations of DNs, what matters is placement in the abstract  
value.)   We can argue whether "ought" above translates to MUST or  
SHOULD in the document.

However, IIRC, there are CAs which place the CN=domain AVA in a multi- 
valued RDN and/or place the RDN somewhere other than the least- 
significant RDN.  Both of which are problematic, but for different  
reasons.

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 12 Jun 2009 07:23:45 -0700

> Use of DC attributes is already disallowed by not being explicitly  

Well, as subsequently clarified, DC attributes are allowed in the  
subjectName DN, just not used to verify the subject.

> Of course the document needs to be clear on what it means about left- 
> to-right RDN ordering versa right-to-left RDN ordering. So some text  
> needs to be added to clarify, or the confusing sentence needs to be  
> removed.

In DC naming, the most significant domain component belongs in the  
most significant RDN... the second most significant component in the  
second most significant RDN, ..., and these RDNs ought to be singled  
valued.

But if the document doesn't discuss verification by DC naming, it  
doesn't need to say anything about DC naming.

-- Kurt

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 12 Jun 2009 08:20:34 -0700

At 7:15 AM -0700 6/12/09, Kurt Zeilenga wrote:
>The document should say that when CN=domain AVA is used,

AVA?

>this AVA ought be the only AVA in the RDN (not a multi-valued RDN), and the RDN ought to be least significant RDN of the DN.   (Avoid the left-to-right/right-to-left descriptions, as these terms are based upon text representations of DNs, what matters is placement in the abstract value.)   We can argue whether "ought" above translates to MUST or SHOULD in the document.

That's an important discussion. I am pretty sure I have seen certs with DNs with multiple CNs with different domain names in the past.

>However, IIRC, there are CAs which place the CN=domain AVA in a multi-valued RDN and/or place the RDN somewhere other than the least-significant RDN.  Both of which are problematic, but for different reasons.

...and therefore we need to describe the problems.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 12 Jun 2009 08:21:45 -0700

At 7:23 AM -0700 6/12/09, Kurt Zeilenga wrote:
>But if the document doesn't discuss verification by DC naming, it doesn't need to say anything about DC naming.

Given that some current systems do validate on DC names, I think we *do* need to say "DC matching is not allowed in this profile".

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 12 Jun 2009 09:23:23 -0700

>> The document should say that when CN=domain AVA is used,

Attribute Value Assertion.

>
>> this AVA ought be the only AVA in the RDN (not a multi-valued RDN),  
>> and the RDN ought to be least significant RDN of the DN.   (Avoid  
>> the left-to-right/right-to-left descriptions, as these terms are  
>> based upon text representations of DNs, what matters is placement  
>> in the abstract value.)   We can argue whether "ought" above  
>> translates to MUST or SHOULD in the document.
>
> That's an important discussion. I am pretty sure I have seen certs  
> with DNs with multiple CNs with different domain names in the past.
>
>> However, IIRC, there are CAs which place the CN=domain AVA in a  
>> multi-valued RDN and/or place the RDN somewhere other than the  
>> least-significant RDN.  Both of which are problematic, but for  
>> different reasons.
>