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

From: [email-masked]
Date: Wed, 04 Jan 2012 00:15:57 -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)       : Paul Hoffman
                          Jakob Schlyter
	Filename        : draft-ietf-dane-protocol-14.txt
	Pages           : 24
	Date            : 2012-01-04

   TLS and DTLS use PKIX 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.  TLSA provides bindings of keys to domains that 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 intended domain name.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-14.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-protocol-14.txt

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 4 Jan 2012 09:22:04 +0100

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

-14 (aka "the happy new year release") includes the following changes:

- clarification on DNSSEC validation requirements
- first cut at integrating new text on "Creating TLSA Records" from Ondřej Mikle
- revised pseudo code (please check this carefully!)

	jakob & paul

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 4 Jan 2012 11:54:34 +0200

> -14 (aka "the happy new year release") includes the following changes:
<...> 
> - revised pseudo code (please check this carefully!)

The "if (R.certUsage == 0) {" block in pseudocode seems to open 5
blocks but close only 4 (the innermost block is seems to be missing
'}').

-Ilari

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 4 Jan 2012 14:18:08 +0100

> blocks but close only 4 (the innermost block is seems to be missing

Thanks, fixed in next rev.

	jakob

---

From: Pieter Lexis <[email-masked]>
Date: Tue, 10 Jan 2012 14:09:41 +0100

Hi *,

> ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-protocol-14.txt

There is a typo in Appendix A.1.1. on page 17, In the first
(non-listing) paragraph:

<snip>
Thes reissued certificates are .....
</snip>

Should be:
<snip>
These reissued certificates are .....
</snip>

-- Pieter Lexis

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Wed, 11 Jan 2012 12:04:09 -0500

> - revised pseudo code (please check this carefully!)

Section 1, 3rd para starting  "[DANEUSECASES] also lists many requirements, most of which ... " 

- Why "most of", and not "all of"? 

Section 4.4, 2nd para starting "The TLS session that is to be set up....".

- We should give specific guidance to application developers that states that TLSA records MUST NOT be cached by *applications* beyond the TTL (RRSIG expiration?) of the TLSA resource record set.

Section 4.4, 6th para starting "If an application receives ...."

- Although we say in a preceeding bullet item  that "if the DNSSEC validation state on the response to the request for the TLSA RRset is bogus, this MUST cause TLS not to be started..", I think we should also say what an application must do if it could not validate the non-existence of TLSA records. That is, suppose we receive zero usable certificate associations, but no proof to assert non-existence we should fail-close.

Section 4.4, 7th para starting "Clients that validate the DNSSEC signatures ..."

- I'm a bit uneasy over the suggestion that it is okay for an intermediary resolver to be able to introduce new certificates to the client as long as the client communicates with it over a secure channel. I'm probably okay with usage types 0 and 1 being used at the client side when validation is not performed locally, but I'd really want a way (at the client side) to be able to disable usage  type 2 in certain environments. If nothing else, I think we need to say something about this in the security considerations section.

Section 5, 2nd para:

- I agree with the the observation that "some of these might be excessively glib". Should we make this a little more clear? For folks coming fresh to this section perhaps saying how the requirements are met would help. For instance:

Multiple Ports: The TLSA records for different application services running on a single host can be distinguished  through the service name and port number prefixed to the host name (see section 3).

No Downgrade: Section 4.4 specifies the conditions under which a client can process and act upon TLSA records. Specifically, if the DNSSEC status for the TLSA resource record set is determined to be bogus, TLS is not attempted at all. 

Encapsulation: ??

Predicatability: The (non-normative) appendix sections provide operational considerations and implementation guidance in order to enable application developers to form a consistent interpretation of the recommended DANE client behavior. 

Opportunistic Security: If a client conformant to this specification can reliably determine the presence of a TLSA record, it will attempt to use this information. Conversely, if a client can reliably determine the absence of any TLSA record, it will fallback to processing TLS in the normal fashion. This is discussed in section 4.4.

Combination: Multiple TLSA records can be published for a given host name, thus enabling the client to construct multiple TLSA certificate associations that reflect different DANE assertions. [No support is provided to combine two TLSA certificate associations in a single operation]. 

Roll-over: Section 4.4 states  {SK: subject to my note above}  that applications must not cache TLSA records beyond their TTL expiration. This ensures that clients will not latch on to assertions made by older TLSA records, and will be able to transition between using one DANE mechanism to another.

Simple Key Management: The SubjectPublicKeyInfo selector in the TLSA record provides a mode that enables a domain holder to only have to maintain a single long-lived public/private key, without the need to manage certificates. Section A.1.2.2 outlines the usefulness and the potential downsides to using this mode.

Minimal Dependencies: This TLSA specification relies on DNSSEC to protect the origin authenticity and integrity of the TLSA resource record set. Additionally if DNSSEC validation is not performed on the system that wishes to use TLSA certificate bindings, this specification requires that the "last mile" be over some secure transport. There are no other deployment dependencies for this approach.

Minimal Options: The operating modes map precisely to the DANE use cases and requirements. DNSSEC use is mandatory in that this specification encourages applications to use TLSA records that are only shown to be validated. {SK: In section 8 we say that "client treatment of any information included in the trust anchor is a matter of local policy". What configuration knobs do we foresee?}

Wildcards: [covered in a limited manner in the TLSA request syntax; see Appendix A.]

Redirection: [covered in the TLSA request syntax; see Appendix A.]

Section 8.

- See my point above on using cert usage type 2 when validation is not done locally.

- I think we do need to say something related to cert usage 2 and its removal of dependencies on the PKI infrastructure. That is, in cases where the CA was following good (ideal?) practices but the DNS administrator was not, an attacker who is able to compromise the DNS name server will not only be able to take you to a different machine that claims to be the webserver, but will also give you a TLS connection that you (or your application) will believe.   

B.2 Pseudo code

- For consistency, we should probably use {R.matchingType, R.selectorType, R.cert}
- All calls to Match() should probably specify R.cert as the last parameter

Suresh

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 11 Jan 2012 19:00:49 +0100

The introduction does not seem to be worded nicely to me.
I think the authors should make an effort to avoid the
necessecity of external information, hidden assumptions
which may not be the same for everybody, and use a
more precise and non-ambiguous  wording, well, I may
simply live on another planet.

   The first response from the server in TLS may contain a certificate.

- what does mean "first" and "response"?
- I am not sure that one should start with this sentence at all.

   "In TLS, a server may present its identity by means of a certificate."

   "In order for the TLS client to authenticate that it is talking to the
    expected server, the client must
   - determine whether the identity present in the certificate
     is associated to the intended domain name, and

Note: extracting a domain name and comparing it is not exactly
the same as comparing a domain name with the identities in the cert.
example wild-card names in the cert.

   - validate the authenticity using a certificate chain starting/rooted 
with
     a client's trust anchor.

This description (or the existing text) does not talk about
certification authorities; This the first sentence of the second
paragraph

    Some people want a different way to authenticate the association of
    the server's certificate with the intended domain name without
    trusting an external certificate authority (CA).

can only be understood under certain assumptions. A client may
already only trust its own CA, and not anyone else for example.

     The easiest way to do this is to use the DNS.

'to do this' is related to the 'making an authoritive binding'.

   "It makes sense to publish such an authoritive binding through the DNS."

The word "authoritive" may easily be confused with "can be 
authenticated" IMO.

1.1

   A certificate association is formed from a piece of information
    identifying a certificate with the domain name where the data is
    found.

Which "data are found.?" and what means "where"?
Well,  data="piece of information"

one does not find things in th DNS, it is a cloud type
service that responds to queries. One can find things
in the responses.

    the entire certificate in the normal format is used.

There is no such thing as a "normal format".

1.2:

    Because the
    certificate association was retrieved based on a DNS query, the
    domain name in the query is by definition associated with the
    certificate.

That doesn't seem a correct sentence: It is only  some
information which will be used to form an association
with the DNS name in the query?
Doesn't that sentence belong to 1.1?

regards
Peter Sylvester

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Jan 2012 12:43:56 -0800

> - Why "most of", and not "all of"? 

Because we don't think it actually meets all the use cases listed.

> - We should give specific guidance to application developers that states that TLSA records MUST NOT be cached by *applications* beyond the TTL (RRSIG expiration?) of the TLSA resource record set.

We already say "The matching or chaining MUST be done within the life of the TTL on the TLSA record." Is that not sufficient? Do we really want to start partially describing to an application how to be a good caching resolver?

> - Although we say in a preceeding bullet item  that "if the DNSSEC validation state on the response to the request for the TLSA RRset is bogus, this MUST cause TLS not to be started..", I think we…

Under which circumstances is an inability to validate the non-existence of TLSA records *not* either bogus or insecure?

> - I'm a bit uneasy over the suggestion that it is okay for an intermediary resolver to be able to introduce new certificates to the client as long as the client communicates with it over a secure c…

How is this any different than the trusted-but-lying intermediary resolver lying about any other DNS record?

> Redirection: [covered in the TLSA request syntax; see Appendix A.]

These are great, thanks!

> - See my point above on using cert usage type 2 when validation is not done locally.

Define "locally". Seriously. What if the app asks the operating system to do the validation and fetching: is that local or not? The OS can be a trusted-but-lying intermediary just as easily as a server is.

> - I think we do need to say something related to cert usage 2 and its removal of dependencies on the PKI infrastructure. That is, in cases where the CA was following good (ideal?) practices but the…

What useful can we say here? The above doesn't give an implementer or a user any useful warning.

> - For consistency, we should probably use {R.matchingType, R.selectorType, R.cert}

Good suggestion.

> - All calls to Match() should probably specify R.cert as the last parameter

Indeed.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 Jan 2012 22:06:00 +0100 (MET)

Paul Hoffman wrote:
> 
>Suresh Krishnaswamy wrote:
>> 
>> - We should give specific guidance to application developers that
>> states that TLSA records MUST NOT be cached by *applications* beyond
>> the TTL (RRSIG expiration?) of the TLSA resource record set.
> 
> We already say "The matching or chaining MUST be done within the life
> of the TTL on the TLSA record." Is that not sufficient? Do we really
> want to start partially describing to an application how to be a good
> caching resolver?

I think that "MUST be done within the life to the TTL" is inappropriate
and potentially misleading (about the resulting security properties).

The TTL mechanism is a loose control for the caching of DNS records,
but it is *NOT* a security feature.  The TTL is neither covered
nor verified by DNSSEC.

Within the remaining validity of the RRSIG, an attacker can replay
previous DNS replies with arbitrary TTL values.

-Martin

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Wed, 11 Jan 2012 17:07:10 -0500

> Because we don't think it actually meets all the use cases listed.

Use-cases are different from requirements, I think. If we mean use-cases, we should say so and perhaps point to the specific use cases that we don't meet.

> We already say "The matching or chaining MUST be done within the life of the TTL on the TLSA record." Is that not sufficient? Do we really want to start partially describing to an application how t…

If we feel that it's important to mention TTL at all I think it's also useful to clearly state any implementation advice relating to it.

> Under which circumstances is an inability to validate the non-existence of TLSA records *not* either bogus or insecure?

The set of bullet points in section 4.4 relate to the positive answer scenario, i.e. when TLSA records are available. The following para begins with "If an application receives zero usable certificate associations, it processes TLS in the normal fashion...". Providing clarity on negative answer processing will help, I think.

> How is this any different than the trusted-but-lying intermediary resolver lying about any other DNS record?

The difference is that I may be forced to talk to an untrusted-and-lying intermediary resolver that only wants to talk over a secure channel. Simply having a secure channel to a lying recursive name server does not mean I place more trust on it.

> Define "locally". Seriously. What if the app asks the operating system to do the validation and fetching: is that local or not? The OS can be a trusted-but-lying intermediary just as easily as a se…

I think the user has a basic level of trust on the OS and the hardware on which it runs. You'd probably be willing to trust an answer that you received from your local validating resolver than one from a validating recursive nameserver provided by your favorite coffee shop. "Local" is saying where our trust boundary lies.

> What useful can we say here? The above doesn't give an implementer or a user any useful warning.

We're mentioning the trade-off, that's all.

Also, I forgot to mention the other operational/availability trade-off: this approach relies on our ability to validate DNSSEC responses, so if DNSSEC validation this is impeded in anyway (middle boxes, broken environments etc) we will lose our ability to do any TLS since we will fail-close.

Suresh

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 16 Jan 2012 10:23:11 +0100

On Wed, Jan 11, 2012 at 12:43:56PM -0800,
 Paul Hoffman <[email-masked]> wrote 
 a message of 83 lines which said:

> I think we should also say what an application must do if it could
> not validate the non-existence of TLSA records. That is, suppose we
> receive zero usable certificate associations, but no proof to assert
> non-existence we should fail-close.
> 
> Under which circumstances is an inability to validate the
> non-existence of TLSA records *not* either bogus or insecure?

Don't know if it is the problem but, currently, an application cannot
easily distinguish "insecure because the domain is not signed / has no
DS above" and "insecure because the resolver I use does not
validate". IMHO, it changes nothing for DANE (in both cases, the TLSA
records MUST be ignored) but it can be a problem for some persons
(when you publish proper and valid TLSA records, you can never be sure
they will be used).

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Jan 2012 08:12:35 -0800

On Jan 16, 2012, at 1:23 AM, Stephane Bortzmeyer wrote:

> [[ Suresh Krishnaswamy asked: ]]

I don't think it is a problem for us. The DANE WG should not be redefining "insecure" for DNSSEC into two sub-categories. We are given a definition for "insecure" and we need to use that.

--Paul Hoffman

---

From: Scott Schmit <[email-masked]>
Date: Sat, 21 Jan 2012 16:38:53 -0500

>    server's certificate with the intended domain name.

Proposed text for A.4 Handling Certificate Rollover:

Certificate rollover is handled in much the same was as for rolling
DNSSEC zone signing keys using the pre-publish key rollover method
[RFC4641]. Suppose example.com has a single TLSA record for a TLS
service on tcp port 990:

_990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...

To start the rollover process, obtain or generate the new certificate or
SubjectPublicKeyInfo to be used after the rollover and generate the new
TLSA record. Add that record alongside the old one:

_990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...
_990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...

After the new records have propagated to the authoritative nameservers
and the TTL of the old record has expired, switch to the new
certificate on the TLS server. Once this has occurred, the old TLSA
record can be removed:

_990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...

This completes the certificate rollover.

[[ Is it typical practice for a CA to revoke the old certificate at
renewal, or is there a grace period? If there is no grace period, then
the operator is going to need to either match the CA certificate instead
of the EE cert (or switch to it in the interim, provided they can find
out what it is in advance) or do SPKI matching (again, possibly
temporarily). ]]

-- 
Scott Schmit

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 21 Jan 2012 14:00:59 -0800

> This completes the certificate rollover.

Thank you!

We still have some other sections to fill in; volunteers who want to follow in Scott's footsteps for "Provisioning with NS Records" and "Securing the Last Hop" are welcome to contact Jakob and I.

> out what it is in advance) or do SPKI matching (again, possibly

There are many "typical" practices, but "no grace period" is uncommon (but not unheard of).

--Paul Hoffman

---

From: Pieter Lexis <[email-masked]>
Date: Mon, 23 Jan 2012 22:06:32 +0100

Hi,

Another typo:

On page 8, in the RR examples:
The last 2 example miss the opening bracket before the certificate for
association.

   _443._tcp.www.example.com. IN TLSA
      1 1 2 92003ba34942dc74152e2f2c408d29ec
            a5a520e7f2e06bb944f4dca346baf63c
            1b177615d466f6c4b71c216a50292bd5
            8c9ebdd2f74e38fe51ffd48c43326cbc )

Must be:
   _443._tcp.www.example.com. IN TLSA (
      1 1 2 92003ba34942dc74152e2f2c408d29ec
            a5a520e7f2e06bb944f4dca346baf63c
            1b177615d466f6c4b71c216a50292bd5
            8c9ebdd2f74e38fe51ffd48c43326cbc )

And
   _443._tcp.www.example.com. IN TLSA
      2 0 0 30820307308201efa003020102020... )

must be
   _443._tcp.www.example.com. IN TLSA (
      2 0 0 30820307308201efa003020102020... )

Regards,

Pieter Lexis

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Jan 2012 14:56:26 -0800

> The last 2 example miss the opening bracket before the certificate for

Interestingly, the AppsArea reviewer's message from yesterday pointed this out. You have just negated my message to him that no one had noticed the error until now. :-)

Fixed in -15.

--Paul Hoffman