Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 27 Aug 2009 17:35:22 -0600

Sorry about the very delayed reply. I'm finally revising the I-D so I
might be posting additional messages in some old threads...

On 6/6/09 8:51 AM, Paul Hoffman wrote:
> At 11:42 PM +0100 6/5/09, Alexey Melnikov 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.
>>> 
>>> That ambiguity leads to a fairly trivial identity attack.
>>> 
>> 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.
> 
>>> 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.
> 
> 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.

Paul, I agree that this document needs to codify secure authentication
practices. However, that raises a more general issue: shall this
document specify rules only for certificate validation or also for
certificate generation? My understanding of the scope that Kurt and I
inherited from JeffH and RL Bob is that the document specifies rules
only for validation, and even there only for a particular subset of
validation, namely matching of the server's presented identities against
the client's expected "reference identity" (e.g., not necessarily
mentioning anything about the fact that the certificate needs to be
certified by a chain of certificates terminating in a trust anchor).
Personally I think that it would be helpful to specify rules about both
generation and validation (and about how the client should proceed if
validation in the broadest sense fails), but before expanding the scope
of the document I'd like to make sure that people here are comfortable
with doing so.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Aug 2009 17:34:45 -0700

At 5:35 PM -0600 8/27/09, Peter Saint-Andre wrote:
>certificate generation?

Validation only.

>My understanding of the scope that Kurt and I

Correct. You might toss in a paragraph saying "of course, you need to do full PKIX checking as well, details are in 5280", but I don't think you even need that.

>of the document I'd like to make sure that people here are comfortable

It would be useful to say what to do when validation fails; you simply don't have to list all the PKIXy ways it can fail.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 28 Aug 2009 09:48:32 -0600

Again, sorry about the delayed reply.

On 6/4/09 2:29 AM, Simon Josefsson wrote:
> Peter Saint-Andre <[email-masked]> writes:
> 
>> 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.
> 
> 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.

Done in my working copy.

> 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.

Could you perhaps elaborate your reasons for thinking so?

JeffH and RL Bob wrote that text, so they can explain their reasoning
better than I can. However, I note the following text from RFC 3454
regarding the distinction between stored strings and queries:

   In general, "stored strings"
   are strings that are used in protocol identifiers and named entities,
   such as names in digital certificates and DNS domain name parts.
   "Queries" are strings that are used to match against strings that are
   stored identifiers, such as user-entered names for digital
   certificate authorities and DNS lookups.

   ....

   The goal of the requirements in this section is to prevent
   comparisons between two strings that were both permitted to contain
   unassigned code points.  When two strings X and Y are compared and
   string Y was prepared in a way that permits unassigned code points, a
   negative result to the comparison is not definitive; it's possible
   that the strings don't match even though they would match if a more
   recent version of the profile were used for Y.  However, if both X
   and Y were prepared in a way that permits unassigned code points,
   something worse can happen: even a positive result for the comparison
   is not definitive.  It is possible that the strings do match even
   though they would not match if a more recent version of the profile
   were used (one that prohibits a code point appearing in both X and
   Y).

   Due to the way that versioning is handled in this section, stored
   strings that are embedded in structures that cannot be changed (such
   as the signed parts of digital certificates) MUST NOT contain any
   unassigned code points.

Given that (1) what I am now calling presented identities (i.e., the
identities presented by the server in its X.509 certificate) are
"embedded in structures that cannot be changed" and (2) RFC 3454 seems
to be saying that a comparison must be made either between two stored
strings or between two queries (not between a stored string and a
query), I think the current text makes sense because we want to compare
the reference identity to each presented identity and the latter will be
stored strings, not queries.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 28 Aug 2009 10:28:37 -0600

On 6/8/09 11:59 AM, Paul Hoffman wrote:
> 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".

Right, in this document we are not legislating what can go in a CN.
However, my understanding is that we are saying that a client would not
compare its reference identity against the string "www.example.com" as
found in the CN. Correct?

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Aug 2009 09:39:38 -0700

At 10:28 AM -0600 8/28/09, Peter Saint-Andre wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>

Correct. The document is about how to find the identifier in an interoperable fashion, not what CAs need to do.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 28 Aug 2009 14:40:51 -0600

On 6/7/09 1:31 PM, Alexey Melnikov wrote:
>>>> 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.
>>>>
>>>> That ambiguity leads to a fairly trivial identity attack
>>>>
>> 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.
>>
> 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.

After puzzling over the text for a while, I agree that this is what it
is trying to say (perhaps not very well). But as far as I can see, in
the second example the client would not check the CN because it is not
the leaf RDN. Or is the text saying that sometimes the leaf RDN might
actually be right-most instead of left-most?

> So there is no reordering of domains inside the CN value.

Agreed.

> [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
> ]

Yes, let's make it clear that DCs will not be checked.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 28 Aug 2009 21:55:57 +0100

>>document specify rules only for certificate validation or also for
I tend to agree. But generation has to match validation, so I don't see 
much practical difference. Unless I am missing some subtle point...

>Correct. You might toss in a paragraph saying "of course, you need to do full PKIX checking as well, details are in 5280",
>
Agreed.

>but I don't think you even need that.
>  
>
I think the reference to RFC 5280 needs to be normative for this document.

Agreed.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 28 Aug 2009 15:01:02 -0600

> much practical difference. Unless I am missing some subtle point...

This specification is not legislating how CAs MUST or MUST NOT generate
certificates, only how clients MUST or MUST NOT check the identities
that they find. The difference between encoding and decoding, I suppose.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Aug 2009 14:10:55 -0700

At 9:55 PM +0100 8/28/09, Alexey Melnikov wrote:
>I tend to agree. But generation has to match validation, so I don't see much practical difference. Unless I am missing some subtle point...

Not subtle at all. Telling CAs what they should and should not put in certificates has been a complete failure in the past. Telling CAs what conformant implementations will do with their certificates should be / could be more effective. It also puts the onus on relying parties to actually read the certs in order to comply with the RFC, not to assume that the CA did anything special.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 28 Aug 2009 15:18:54 -0600

On 8/28/09 3:10 PM, Paul Hoffman wrote:
>>>> Paul, I agree that this document needs to codify secure
>>>> authentication practices. However, that raises a more general
>>>> issue: shall this document specify rules only for certificate
>>>> validation or also for certificate generation?
>>>> 
>>> Validation only.
>>> 
>>> 
>> I tend to agree. But generation has to match validation, so I don't
>> see much practical difference. Unless I am missing some subtle
>> point...
> 
> Not subtle at all. Telling CAs what they should and should not put in
> certificates has been a complete failure in the past. Telling CAs
> what conformant implementations will do with their certificates
> should be / could be more effective. It also puts the onus on relying
> parties to actually read the certs in order to comply with the RFC,
> not to assume that the CA did anything special.

Yes, exactly.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 28 Aug 2009 22:28:33 +0100

>On 6/7/09 1:31 PM, Alexey Melnikov wrote:
 [...]

>actually be right-most instead of left-most?
I think it is.

>Yes, let's make it clear that DCs will not be checked.
Good.