Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-04.txt

From: [email-masked]
Date: Thu, 10 Feb 2011 14:45:02 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

	Title           : Using Secure DNS to Associate Certificates with Domain Names For TLS
	Author(s)       : P. Hoffman, J. Schlyter
	Filename        : draft-ietf-dane-protocol-04.txt
	Pages           : 11
	Date            : 2011-02-10

TLS and DTLS use certificates for authenticating the server.  Users
want their applications to verify that the certificate provided by
the TLS server is in fact associated with the domain name they
expect.  Instead of trusting a certification authority to have made
this association correctly, the user might instead trust the
authoritative DNS server for the domain name to make that
association.  This document describes how to use secure DNS to
associate the TLS server's certificate with the the intended domain
name.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-04.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: Scott Schmit <[email-masked]>
Date: Sat, 19 Feb 2011 23:21:33 -0500

> 	Filename        : draft-ietf-dane-protocol-04.txt

Some of these are nits, some not:

Abstract:
---------

>  expect.  Instead of trusting a certification authority to have made
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  this association correctly, the user might instead trust the
   ^^^^^^^^^^^^^^^^^^^^^^^^^^
>  associate the TLS server's certificate with the the intended domain

I would argue that in DNSSEC, each zone operator is a CA, just not a
PKIX CA.

How does this sound instead?

   TLS and DTLS use certificates for authenticating the server.  Users
   want their applications to verify that the certificate provided by
   the TLS server is in fact associated with the domain name they
   expect. DNSSEC provides a mechanism for a zone operator to sign DNS
   information directly.  This way, bindings of keys to domains are
   asserted not by external entities, but by the entities that operate
   the DNS.  This document describes how to use secure DNS to associate
   the TLS server's certificate with the the intended domain name.

(I used the text from the charter, I figured that's the least
controversial option).

Section 2.2:
------------

I'm not the first to mention this, but I think the overlap between the
certificate type and hash type is a bad idea. It allows nonsensical
combinations to be expressed with all the problems that go with it.

It would make much more sense for the certificate type to only indicate
the kind of certificate that is referenced, and the second field
indicates how that reference is formatted in the RDATA. This would
change the text to something like:

   o  A one-octet value, called "certificate type", specifying the
      provided association that will be used to match the target
      certificate.  This will be an IANA registry in order to make it
      easier to add additional certificate types in the future.  The
      types defined in this document are:
 
         1 -- An end-entity certificate
 
         2 -- A certification authority's certificate
 
   o  A one-octet value, called "reference type", specifying how the
      certificate association is presented.  This value is defined in a
      new IANA registry.  The types defined in this document are:
 
         0 -- Full certificate in DER encoding
 
         1 -- SHA-1 hash of the certificate in DER encoding
 
         2 -- SHA-256 hash of the certificate in DER encoding
 
         3 -- SHA-384 hash of the certificate in DER encoding
 
      Using the same hash algorithm as is used in the signature in the
      certificate will make it more likely that the TLS client will
      understand this TLSA data.

Unless these are all MUSTs, the document needs to indicate which are
required and which are not.

Section 3:
----------

Should "If the application receives zero usable certificate
associations, it processes TLS in the normal fashion." be a MUST?

The last statement in section three should probably be:

"If no match between the usable certificate association(s) and the
server's end entity certificate in TLS is found, the TLS client MUST
abort the handshake with an "unknown_ca" error."

This adds "usable" to make clear the distinction between this and the
"continue as usual" case. Also, I changed access_denied to unknown_ca.
According to RFC 5246:

>  unknown_ca
>     A valid certificate chain or partial chain was received, but the
>     certificate was not accepted because the CA certificate could not
>     be located or couldn't be matched with a known, trusted CA.  This
>     message is always fatal.
>
>  access_denied
>     A valid certificate was received, but when access control was
>     applied, the sender decided not to proceed with negotiation.  This
>     message is always fatal.

To me, unknown_ca looks like the correct error -- DANE is about allowing
DNSSEC to redefine what the trusted CAs are.

Section 4.2/4.3:
----------------

Value 255 is unspecified. Is this a typo, or was that intended to be
reserved as experimental?

We need to specify which algorithms are required, optional, etc.

I don't think the registry policies are sufficiently restrictive to
prevent using up the available space. At minimum it should require
expert review if not IETF Review. Otherwise, the only limitation on
registration is an independent RFC.

Just to demonstrate how quickly the hash type (or whatever it turns
into) could be used up, NIST is currently holding a competition to
decide what algorithm will become SHA-3. They are now on their final
round of competition, and there are no further opportunities for tweaks
to the algorithms. So, all those algorithms are permanent and readily
available.

So how many would that take up? I count 29 (4 BLAKE, 4 Groestl, 4
Keccak, 4 JH, 13 Skein). Throw in SHA-224, SHA-512 (from FIPS-180-3),
SHA-512/224, SHA-512/256 (from FIPS-180-4 once it's finalized), MD5, and
the existing entries from dane-04, and you have 37 entries--about 1/7th
of the available space.

Section 5:
----------

You have two references to just A records and three to A/AAAA records.
That's probably incomplete editing to change them all to the latter.

Also, I don't understand this paragraph:

>  A DNS administrator who goes rogue and changes both the A and TLSA
>  records for a domain name can cause the user to go to an unauthorized
>  server that will appear authorized, unless the client performs
>  certificate validation and rejects the certificate.  That
>  administrator could probably get a certificate issued anyway, so this
>  is not an additional threat.

What certificate validation is the client going to do that would detect
this attack?

The good news about this kind of attack is that it can be detected (by
machine, admittedly) since all the certificates/associations are
published in the DNS (unlike a rogue PKIX CA).

Maybe this is a lack of operational experience, but I'm not sure I
understand why adding or changing TLSA information would be less
protected than for A/AAAA records?

Hope this helps.

-- 
Scott Schmit

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 20 Feb 2011 12:10:29 -0800

> Some of these are nits, some not:

And all are appreciated.

>>   expect.  Instead of trusting a certification authority to have made

I would disagree. It is a trust anchor, not a certification authority. 
Yes, most users today don't understand the difference, but we should 
still be fairly precise in our language because some do. In specific, 
certification authorities do many things that are unimportant to most 
users but are definitely not done by zone operators. For example, zone 
operators probably do not do proof-of-possession checks for the the 
private key paired to the public key in the certificate, whereas most 
CAs do.

> (I used the text from the charter, I figured that's the least

That new text seems fine, and does not assert that DNS operators are CAs 
:-). Having the abstract actually use the words from the charter also 
seems like a good idea.

> Section 2.2:

Hrm. I like the addition of the 0 type for reference type; it definitely 
solves the silly-state problem. Given that this is an on-the-wire 
change, it needs to be discussed more. I have opened issue #20 for it.

> Section 3:

It could be, but it doesn't need to be, because that is already covered 
in the TLS spec.

> "continue as usual" case.

Good catch. Fixed.

> Also, I changed access_denied to unknown_ca.
> According to RFC 5246:
>
>>   unknown_ca

However, unknown_ca requires that a chain or partial chain be received, 
and one might not have been sent. For access_denied, you don't need a chain.

> Section 4.2/4.3:

The latter, and yet we forgot to add that to the draft. FWIW, I strongly 
prefer "private use" to "experimental". Fixed in the next version.

> We need to specify which algorithms are required, optional, etc.

Yes we do, but people wanted to push that off to later. I think it is 
still good to delay it until we are sure about the format and so on. I 
have opened this as issue #21 on the tracker.

> registration is an independent RFC.

There has been a not great track record with "expert review" for 
registries that have only occasional additions. (Ask Phill about his 
long-delayed request for a new RRtype...)

> to the algorithms. So, all those algorithms are permanent and readily

That is an overstatement. NIST has made it clear that it might make 
changes in whatever algorithm it decides.

> the existing entries from dane-04, and you have 37 entries--about 1/7th

And yet none of the SHA-3 candidates have been proposed as hash 
algorithms for this protocol (or any IETF protocol that I know of).

If the registry starts to fill up, the IETF can decide to tighten the 
registration rules at that time. There is no need to over-tighten now.

> Section 5:

Good catch; done.

> What certificate validation is the client going to do that would detect

There is none. The Security Considerations section is for all 
considerations, not just ones that can be easily caught.

> published in the DNS (unlike a rogue PKIX CA).

*Might* be caught: an attacker can give different answers to different 
DNS requests. This seems too far down the rathole to want to write 
about, I think, but others might want it.

> protected than for A/AAAA records?

It isn't: they are identical.

> Hope this helps.

It does indeed. As we move through the open issues, it will be 
interesting to see how the WG feels about the new ones.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Feb 2011 07:48:18 -0500

>>   expect.  Instead of trusting a certification authority to have made

If you issue an X.509 cert under which other certs will be validated,
you are a CA.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Feb 2011 07:57:18 -0500

At 12:10 PM -0800 2/20/11, Paul Hoffman wrote:
>I would disagree. It is a trust anchor, not a certification 
>authority. Yes, most users today don't understand the difference, 
>but we should still be fairly precise in our language because some 
>do. In specific, certification authorities do many things that are 
>unimportant to most users but are definitely not done by zone 
>operators. For example, zone operators probably do not do 
>proof-of-possession checks for the the private key paired to the 
>public key in the certificate, whereas most CAs do.

I agree that the info in the record could be a TA, and not a CA, but not if
the format of the data is an X.509 cert. Also, will not performing 
PoP be a good outcome?

Steve

---

From: Ben Laurie <[email-masked]>
Date: Mon, 21 Feb 2011 06:02:43 -0800

On 21 February 2011 04:57, Stephen Kent <[email-masked]> wrote:
>> Yes, most users today don't understand the difference, but we should still
>> be fairly precise in our language because some do. In specific,
>> certification authorities do many things that are unimportant to most users
>> but are definitely not done by zone operators. For example, zone operators
>> probably do not do proof-of-possession checks for the the private key paired
>> to the public key in the certificate, whereas most CAs do.
>
> the format of the data is an X.509 cert.

You said a minute ago: "if you issue an X.509 cert under which other
certs will be validated,
you are a CA."

This sounds correct to me. However, mostly what's being done here is
_not_ the issuing of X.509 certs under which other certs will be
validated (though it is an option), so most times the zone operator is
not a CA.

In any case it does seem worth making clear when we are talking about
a PKIX CA vs. any other kind.

> Also, will not performing PoP be a
> good outcome?

What would be the point of proving to myself that I own a key?

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Feb 2011 08:50:36 -0800

> the format of the data is an X.509 cert.

The data might not always be an X.509 cert. TLS might be extended to use 
bare keys in the server's certificate message, and/or using OpenPGP 
certificates might end up being a standard, and/or other certification 
methods might appear in the future. I don't think that limiting TLSA to 
PKIX now is good planning for the future.

> Also, will not performing PoP
> be a good outcome?

What would be the security reason for a DNS admin who has been told 
"please announce this certificate for this domain name" to need to learn 
about proof-of-possession?

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Feb 2011 20:01:55 -0500

>...

yep.

>validated (though it is an option), so most times the zone operator is

I though one option was to place a cert in the DNS and use it as the
basis for validating a cert chain that terminates at the EE cert for the
web site.  If so, then that cert is used to validate other certs and
it would generally be viewed as a CA cert.  I admit that some 
ambiguity arises when the cert is viewed as a TA. The ambiguity 
arises because In general,
if you issue a cert, you are a CA, but when a cert used to convey TA data,
an RP may elect to not check all of the data.

We do have TA format standards that make it clear what data is to be 
checked and it might be preferable to use them, vs. a self-signed 
cert (although the later option might minimize code reuse).

>a PKIX CA vs. any other kind.

It's really  not a "PKIX CA" per se; it's an X.509 CA.

>What would be the point of proving to myself that I own a key?

It would not be useful to you, but rather to someone who puts it in a
DNS record, if that someone does so on your behalf. Otherwise that entity
does not know if the public key really is yours.  But, I don't know that
this results in a vulnerability for the DANE context.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Fri, 25 Feb 2011 15:12:31 +0000

On 22 February 2011 01:01, Stephen Kent <[email-masked]> wrote:
>>  >
> it would generally be viewed as a CA cert.  I admit that some ambiguity
> arises when the cert is viewed as a TA. The ambiguity arises because In
> general,
> if you issue a cert, you are a CA

Eh? If I make a self-signed cert, am I a CA?

If I publish an EE cert issued by someone else, am I a CA?

Presumably at least one of these is a "no", so the zone operator is
not necessarily a CA. This was my point.

>, but when a cert used to convey TA data,
> We do have TA format standards that make it clear what data is to be checked
> and it might be preferable to use them, vs. a self-signed cert (although the
> later option might minimize code reuse).
>
>>  > Also, will not performing PoP be a
>>>
>>>  good outcome?
>>

Ah. If I am asking someone else to update DNS for me, then indeed a
PoP might be appropriate. But surely that's an issue for whatever
protocol I am using for speaking with my DNS provider?

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Feb 2011 10:12:01 -0500

>Eh? If I make a self-signed cert, am I a CA?

yes.

>If I publish an EE cert issued by someone else, am I a CA?

no. publishing is not the same as issuing. any 3rd party can publish any cert.

>not necessarily a CA. This was my point.

OK.

>protocol I am using for speaking with my DNS provider?

seems reasonable to me.

Steve