Subject: Re: [keyassure] The draft and subj alt names

From: Paul Wouters <[email-masked]>
Date: Fri, 1 Apr 2011 03:22:39 -0400 (EDT)

On Fri, 1 Apr 2011, Jay Daley wrote:

>> As I've said in other threads, this WG should be silent on requirements for certificate names, since different applications use TLS certificate names in different ways.  See for example the difference between RFC 2818 and RFC 6125.  The text you reference in the draft is technically harmless ("must" not "MUST"), but should probably be deleted anyway.
>
> There are two separate issues here:
> a) whether we think name matching is still needed with DANE
> b) what the draft should say about that
>
> On a) I would make the case that name matching is should not be done because
> - DNSSEC provides sufficient trust
> - name matching forces certain operational decisions onto end user (e.g. multiple certs, cert reuse) that are unreasonable

Also, image you have to keep updating your cert in DANE every time you add/remove a
vhost and you have to update the subjectAltname. One of the advantages of putting it
in DNS is that you know the name of the entity without having to look inside the cert.

The cert is just a legacy container for the public key. We should not be adding policy
in DANE that entangles DANE with PKIX (or any other trust scheme)

Paul

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 1 Apr 2011 15:10:56 +0200

Let me phrase it differently.  If you give DANE specific name matching requirements, then you not only have to update the appropriate application RFCs, you have to change all the corresponding code.  If you look at HTTPS libraries, for example: 
-- Most of them will only check the cert against the domain name in the HTTPS URI (with no user-configurability)
-- Some can be configured to accept a list of names
-- None that I'm aware of have a "don't check the name" option.  
(Some of them don't ever check names, but they're non-compliant anyway.)

This is not to mention that if you put a cert with the wrong domain name in TLS, you're going to break non-DANE clients.  

I don't think that all this trouble is worth the small optimization, and (not to be a process weenie) I don't think that working at the application layer is within the scope of this working group.

--Richard

On Apr 1, 2011, at 5:15 AM, Jay Daley wrote:

> On 1/04/2011, at 3:06 PM, Richard L. Barnes wrote:
> 
>> The only choice that avoids updating several RFCs is 5.
> 
> Is that your only reason for not wanting to tackle this?  Do you have any view on the nature of trust that DNSSEC provides to applications or not?
> 
>> Just leave it alone!
> 
> No.
> 
> warmest regards
> Jay
> 
>> --Richard
>> 
>> 
>> On Mar 31, 2011, at 10:41 PM, Jay Daley wrote:
>> 
>>> On 1/04/2011, at 12:12 AM, Richard L. Barnes wrote:
>>> 
>>> On b) There are six options for the draft:
>>> 
>>> 1.  State that name matching must be done
>>> 2.  State that name matching must not be done
>>> 3.  Leave it to applications with a recommendation to match
>>> 4.  Leave it to applications with a recommendation not to match
>>> 5.  Leave it to applications with no recommendation
>>> 6.  Add a flag into TLSA that specifies whether name matching is to be done or not
>>> 
>>> My choice, in order of preference would be 2, 6, 4.  
>>> 
>>> Jay
>>> 
>>>> 
>>>> --Richard
>>>> 
>>>> 
>>>> 
>>>> On Mar 31, 2011, at 12:05 PM, Olle E. Johansson wrote:
>>>> 
>>>>> I have read the draft and reacted to one thing. Sorry if this already have been discussed on the list.
>>>>> 
>>>>> The draft -06 says
>>>>> "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. "
>>>>> 
>>>>> The new RFC 6125 tells us that we should:
>>>>> "Move toward including and checking even more specific
>>>>>  subjectAlternativeName extensions where appropriate for using the
>>>>>  protocol (e.g., uniformResourceIdentifier and the otherName form
>>>>>  SRVName)."
>>>>> 
>>>>> I feel we need to be more specific in the draft.  What type of subjectAltName should we match with?
>>>>> dnsName?
>>>>> 
>>>>> And if we're using SIP, and have URI's in the certificate - should that be part of this draft
>>>>> or should we open for protocol-specific specifications for other types of subject Alt Names?
>>>>> 
>>>>> /O
>>>>> _______________________________________________
>>>>> keyassure mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>> 
>>>> _______________________________________________
>>>> keyassure mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>> 
>>> 
>>> -- 
>>> Jay Daley
>>> Chief Executive
>>> .nz Registry Services (New Zealand Domain Name Registry Limited)
>>> desk: +64 4 931 6977
>>> mobile: +64 21 678840
>>> 
>> 
> 
> 
> -- 
> Jay Daley
> Chief Executive
> .nz Registry Services (New Zealand Domain Name Registry Limited)
> desk: +64 4 931 6977
> mobile: +64 21 678840
>

---

From: Martin Rex <[email-masked]>
Date: Fri, 1 Apr 2011 15:56:27 +0200 (MEST)

Jay Daley wrote:
> 
> 6.  Add a flag into TLSA that specifies
>     whether name matching is to be done or not

I think that (6.) would be the most sensible solution.

Especially for self-signed X.509 certificates, it doesn't make sense
to look at name attributes of the certificate at all, because these
are all self-asserted attributes, not certified attributes.  The
only thing that really matters is the public key.

Today's browsers show a very intimidating warning page when they
receive a server cert that doesn't match their expectations.
But once you have convinced your browser that you want to connect,
and to make this decision persistent (cert pinning), then there
are no more warnings on further connects about mismatches on
name attributes of the certificate.

TLSv1.2  1. Introduction, last sentence

  http://tools.ietf.org/html/rfc5246#page-5

                                  the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS.

HTTP over TLS, 3.1 Server Endpoint Indentification, 2nd paragraph

  http://tools.ietf.org/html/rfc2818#section-3.1

   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted. (For instance, a
   client may be connecting to a machine whose address and hostname are
   dynamic but the client knows the certificate that the server will
   present.)

or the new RFC-6125

  http://tools.ietf.org/html/rfc6125#page-8

   o  Keys or certificates employed outside the context of PKIX-based
      systems.

      Some deployed application technologies use a web of trust model
      based on or similar to OpenPGP [OPENPGP], or use self-signed
      certificates, or are deployed on networks that are not directly
      connected to the public Internet and therefore cannot depend on
      Certificate Revocation Lists (CRLs) or the Online Certificate
      Status Protocol [OCSP] to check CA-issued certificates.  However,
      the method for binding a public key to an identifier in OpenPGP
      differs essentially from the method in X.509, the data in self-
      signed certificates has not been certified by a third party in any
      way, [...]

-Martin

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 01 Apr 2011 16:38:27 +0200

> I think that (6.) would be the most sensible solution.

This starts to look like overengineering.  Let's not put too many 
ingreedients into one pot please.

> only thing that really matters is the public key.

On the other hand it's not that hard to issue a self-signed CA issued 
cert which matches the domain name, isn't it?

The other option would be use the bare keys (see Paul W. proposal in TLS 
WG).  E.g. if you use X.509 do match, if you use bare key, don't match.

>        signed certificates has not been certified by a third party in any

I think that those paragraphs are exactly the reason why the option 
"Leave it alone - it's up to the application" is most appropriate for 
the DANE WG.  And there will be interest I think that it could be solved 
elsewhere or here as BCP RFC.

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: Jeff Schmidt <[email-masked]>
Date: Fri, 1 Apr 2011 21:35:46 +0000

>in DANE that entangles DANE with PKIX (or any other trust scheme)

+1.  Or have an easy way to unwind any such entanglements (i.e. make them
optional).

Jeff