Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02

From: Christopher Morrow <[email-masked]>
Date: Wed, 4 May 2011 01:55:50 -0400

On Sat, Apr 30, 2011 at 9:24 PM, Warren Kumari <[email-masked]> wrote:
>
> On Apr 29, 2011, at 12:03 PM, Warren Kumari wrote:
>
>> Hi all,
>>
>> I think that Richard has integrated most of the comments received on-list into this most recent version of the doc and so, as I mentioned, we are going to kick off WGLC...
>>
>> Please get y'er comments in --  WGLC will be closing on 2011-05-13 at 16:00UTC (noonish EDT).

failing another place to ask/point-this-out, in reading the doc I noticed this:

"3.3.  Domain-Issued Certificates

   Alice would like to be able to use generate and use certificates for
   her website on alice.example.com without involving an external CA at
   all. "

The first sentence is a tad odd...  'to use generate and use
certificates for" ... probably some other sentence fragment belongs
there.

-chris
(more when more rested)

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 4 May 2011 09:06:39 +0200

> certificates for" ... probably some other sentence fragment belongs

Thanks, I've fixed this in my working copy.
Looking forward to the rest,
--Richard

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 May 2011 07:32:58 -0700

This draft seems to hit all the use cases and requirements that I remember seeing on the list, although it is hard to be sure given that people didn't change the Subject: line when they, you know, changed the subject.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Wed, 4 May 2011 16:13:52 -0400 (EDT)

I believe this document still needs some work before publication. 
Comments below.

the first use case is about pinning the CA using DANE. It states:

   Because these constraints do not increase the scope of PKIX-based
   assertions about domains, there is not a strict requirement for
   DNSSEC.

This seems untrue if choices for CAs are going to be made based on
a DANE record. Specifically,

   When Bob connects to alice.example.com, he uses this mechanism to
   verify that that the certificate presented by the server was issued
   under the proper CA

I have no idea what "verify" means in the absense of DNSSEC, but it is
not a process I feel comfortable endorsing. It also conflicts more or
less with the introduction that states:

    and with the advent of DNSSEC [RFC1034][RFC4033], it is possible
    for this information to be provided securely, 

Providing insecure information used to pin the CA seems wrong. Saying that
this new feature could be spoofed but in that case we can still rely on the
underlying PKIX security raises the question what this new dane process
would add securety wise. Without DNSSEC, only a false sense of security.

Addiitonally, it ALSO conflicts with section 4's statement of:

     Downgrade:  An attacker who can tamper with DNS responses must not
     be able to make a DANE-compliant client treat a site that has
     deployed DANE and DNSSEC like a site that has deployed neither.

I still feel very strongly that dane should just make a clear cut "DNSSEC
required" statement. 

   Injected or modified false records are not useful unless the
   attacker can also obtain a certificate for the target domain.

This is also not true, with users having warning pop-up fatigue. An attacker
will have a certain percentage of users clicking through. 

The entire use case becomes much clearer if we don't try to explain (badly)
why DNSSEC is optional in this use case.

    This is not a significant incremental risk, however, relative to the
   current PKIX-based system.  

This sentence can be parsed in different ways, and I am not sure I even
understand it. It seems to try and say that this gives more power to the
DNS operator since there is no CA involved. However, it is wrong. In the
use case of 3.2, the DNS operator can also remove the CA based dane record
for a domain based dane record and then they can generate their own valid
certificate as well.

Paul

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 5 May 2011 08:49:06 +0200

> This draft seems to hit all the use cases and requirements that I remember seeing on the list, although it is hard to be sure given that people didn't change the Subject: line when they, you know,…

I concur and support moving the draft forward.

	jakob

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 5 May 2011 12:39:25 -0700

I am going to support the removal of this comment for a slightly different
reason.

The issue is that Alice is worried that somebody else will generate a
certificate for her service.  There are two possibilities - a certificate
for the same key is created w/ different attributes or a certificate is
created for the purpose of setting up a different server.  The first case
can be ignored for now.  The second case is what Alice is worried about
happening.  If there is any path for this to be successful then Alice is not
going to feel reassured that it is not happening.  Thus if Mallory can get
the certificate and corrupt the DNS for Bob then the attack is successful
and Alice has been thwarted in what she wants to see happen.  Dane has not
really helped except by making the attack harder by Mallory needed to add or
remove one record from the DNS poisoning.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Wouters
> Sent: Wednesday, May 04, 2011 1:14 PM
> To: Warren Kumari
> Cc: [email-masked]
> Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02
> 
> 
> This seems untrue if choices for CAs are going to be made based on a DANE
> record. Specifically,
> 
> I have no idea what "verify" means in the absense of DNSSEC, but it is not
a
> process I feel comfortable endorsing. It also conflicts more or less with
the
> introduction that states:
> 
DNS
> operator since there is no CA involved. However, it is wrong. In the use
case
> of 3.2, the DNS operator can also remove the CA based dane record for a
> domain based dane record and then they can generate their own valid
> certificate as well.
> 
> Paul
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 May 2011 16:03:16 -0400

> Please get y'er comments in --  WGLC will be closing on 2011-05-13 at 16:00UTC (noonish EDT).

Dear colleagues,

I have read this document.  I have some comments.

I don't understand the reason for this reference to RFC 1034 in section 1:

   The DNS is built to provide information about domain names, and with
   the advent of DNSSEC [RFC1034][RFC4033],

I'm not entirely sure what the implications of section 3.6 are.  What
does that section imply for the work of this WG?

I'm slightly uneasy with the requirement about wild cards and CNAME
(and why not DNAME?) at the end of section 4.  It's a little glib from
my point of view, and I'm not actually sure what is supposed to be
entailed.  For instance, once answer to "be compatible with" is "use
wildcards or use DANE, but not both."  Is that ok?  This is perhaps my
most serious issue.  I think I'd prefer to see text along the
following lines instead:

   Wild Cards and DNS redirection: The mechanism for distributing DANE
      information must not be susceptible to subversion in the face of
      DNS wild card labels (*) and redirection chains (such as those
      resulting from CNAME or DNAME records).  In the case of wild
      card labels, it is desirable that the mechanism work when the
      owner name is a wild card, so that it may cover any wild card
      expansion [note: is that what's intended?  ajs].  In the case of
      redirection chains, it is desirable that the mechanism work when
      the owner name is the result of following redirection chains.

I don't know if that's what was intended, and I'm sure that can be
made into more elegant prose.

Even with the above, I support moving ahead with this document.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 5 May 2011 14:15:28 -0700

In section 3.1 - para #1 - I think there is a small technical error that may
need to be addressed.  If Charlie and Trent are the same person (i.e.
Charlie's certificate is a self-signed certificate) would that certificate
actually appear in the certificate_list structure.  It is my understanding
that self-signed certificates are generally omitted from this list.  It
would be more accurate to say that the certificate will appear in the chain
tested by the PKIX path validation code.  (This also deals with cases where
a client takes the EE certificate from the structure and just uses the
balance of the certificates as possible certificates to chain through.  That
is the certificate chain built is not the same as that in the TLS
structure.)

In section 3.2 the next the last paragraph refers to text in section 3.1
that I cannot find.  It is also possible that there is text there that I
just don't associate with the referring text.  - It appears that section 3.1
should have text about Oscar - either that or the reference should be to
section 3.4

Is there a use case where Alice wants to do multiple of these operations at
the same time.  That is she wants to do both a CA constraint and a
Certificate constraint simultaneously?

In section 3.4 - for item 3 - I assume that the references to Diane should
be references to Oscar.

I think that the last sentence in this section should use the word enforce
rather than make.  One presumes that Alice might be able to make
requirements contractually.

I think that case 3.5 really should occur in section 4.   As the current
text is written it appears to be more a requirement on how DANE is defined
than on what Alice can do when implementing DANE.  

A better description of what I think you are really trying to say is:

Alice would like to publish a web site where Bob will use a secure link if
he is using a client which understands DANE, but will use an unsecure link
in the event that DANE is not understood by the client.

Note that as currently written, it is possible that the Encapsulation
criteria in section 4 is counter to  bullet point 3 in section 3.4

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 May 2011 19:03:00 -0400

> most serious issue.  I think I'd prefer to see text along the

Well this is a use cases and requirements document, so it would be OK if the
goal was aspirational in my view. I think its OK for a proposal to only meet
some of the requirements if it turns out that doing so has costs.

In the case of wildcard and CNAME/DNAME support I think that the question
comes down to whether this is a higher priority than efficiency or if both
are hard requirements whether it is OK to special case for HTTP Web browsing
interactions.

-- 
Website: http://hallambaker.com/

---

From: Scott Schmit <[email-masked]>
Date: Sun, 8 May 2011 14:18:19 -0400

> Please get y'er comments in --  WGLC will be closing on 2011-05-13 at 16:00UTC (noonish EDT).

In section 3.3, the 5th paragraph mentions that an attacker can cause
Bob to trust fake records if DNSSEC weren't required, but in the 4th
paragraph, you said that's not always true, since Bob could reject
Alice's TA. Suggested text:
   Providing trust anchor material in this way clearly requires DNSSEC,
   since corrupted or injected records could be used by an attacker to
   cause clients to trust an attacker's certificate (unless their 
                                                   ^^^^^^^^^^^^^^
   local policy rejects the records for other reasons).
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In section 3.4 (#3), there is a reference to Diane,  but Diane is not
one of the dramatis personae in section 3. Is Diane === Oscar?

In section 4, Encapsulation, "a DANE information" should just be "DANE
information".

-- 
Scott Schmit

---

From: Warren Kumari <[email-masked]>
Date: Wed, 11 May 2011 13:46:36 -0400

> Please get y'er comments in --  WGLC will be closing on 2011-05-13 at 16:00UTC (noonish EDT).

During the in-person meeting in Prague there were a large number of folk who expressed a desire for this document  -- well, now is the time to:
a: show support or
b: grump.
There is no "c"!

(AKA, I realize folk are busy, but please take a moment to provide feedback...)

W

> 
> W
> 
> On Apr 29, 2011, at 12:15 AM, [email-masked] wrote:
> 
>> 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           : Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)
>> 	Author(s)       : R. Barnes
>> 	Filename        : draft-ietf-dane-use-cases-02.txt
>> 	Pages           : 11
>> 	Date            : 2011-04-28
>> 
>> Many current applications use the certificate-based authentication
>> features in TLS to allow clients to verify that a connected server
>> properly represents a desired domain name.  Traditionally, this
>> authentication has been based on PKIX trust hierarchies, rooted in
>> well-known CAs, but additional information can be provided via the
>> DNS itself.  This document describes a set of use cases in which the
>> DNS and DNSSEC could be used to make assertions that support the TLS
>> authentication process.
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-02.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.
>> <Mail Attachment>_______________________________________________
>> dane mailing list
>> [email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Wed, 11 May 2011 13:47:25 -0400

> (AKA, I realize folk are busy, but please take a moment to provide feedback...)

and, thanks to those who already did...

W

---

From: Yoav Nir <[email-masked]>
Date: Wed, 11 May 2011 22:17:02 +0300

> During the in-person meeting in Prague there were a large number of folk who expressed a desire for this document  -- well, now is the time to:

Why do I have to choose? Can't I do both?

OK. I support this document even as is. But still, here are a few comments:

In section 3.1 we might add what PHB suggested in his CAA proposal - that CAs check the DNS before signing certificates, so if the DNS says that Alice's certificate must be signed by "ComSign Secured CA", Charlie won't sign it. The upside is that this begins to bring benefit as soon as the CAs update their software - even before the browser vendors do.

If the DNS record contained just the public key, you could even say the same for section 3.2.  Alice would generate a key pair, publish a DNS record with the public key, and then request a certificate. No matter how well at attacker could impersonate Alice to any CA, they would not be able to get the CA to sign any certificate with a different public key.

Section 3.3: s/the certificate presented by the server was issued by Alice/the certificate presented by the server has been issued by Alice/

Section 3.4 starts off with "In addition to guarding against CA mis-issue...". But nothing has previously been said about guarding against CA mis-issue. Unless you add text to cover my comments for sections 3.1 and 3.2.

Other than that, I support this document.

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 May 2011 15:53:21 -0400 (EDT)

> During the in-person meeting in Prague there were a large number of folk who expressed a desire for this document  -- well, now is the time to:

I gave feedback last week. Assuming that goes in, especially the use case
error on the level of trust of the DNS Operator with CA certs in DANE,
I have no objections.

Though seeing that out of this use cases document, no obvious changes
to the dane 06 draft came to light, one could argue that perhaps those
people in Prague were not as well informed, and that this document is
not really needed either.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 May 2011 13:01:46 -0700

> In section 3.1 we might add what PHB suggested in his CAA proposal - that CAs check the DNS before signing certificates, so if the DNS says that Alice's certificate must be signed by "ComSign Secur…

Stated as a use case, that would be "Alice wants CAs compliant with the protocol to not issue certificates for alice.example.com unless they have a trust anchor that she has listed using the DANE protocol". The related requirement is that the DANE protocol must be able to identify trust anchor certificates in a way that a CA can determine whether or not they are authorized under the protocol to issue new certificates.

> If the DNS record contained just the public key, you could even say the same for section 3.2.  Alice would generate a key pair, publish a DNS record with the public key, and then request a certific…

I *think* my proposed wording above covers that; please check.

> Section 3.4 starts off with "In addition to guarding against CA mis-issue...". But nothing has previously been said about guarding against CA mis-issue. Unless you add text to cover my comments for…

Good catch.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 May 2011 16:23:11 -0400

On Wed, May 11, 2011 at 3:53 PM, Paul Wouters <[email-masked]> wrote:

>> During the in-person meeting in Prague there were a large number of folk
>> who expressed a desire for this document  -- well, now is the time to:
>> a: show support or
>> b: grump.
>> There is no "c"!
>>
>

Or one could conclude that the various groups continue to fail to
communicate.

My problem with this process has been that people insisted on deriving the
requirements from the proposed spec. When I proposed a different set of
requirements that considered the problem from scratch I was told that this
was not what 'the group' wants to do.

So I am not at all surprised that you draw that conclusion, what other
conclusion could there have been?

---

From: Yoav Nir <[email-masked]>
Date: Wed, 11 May 2011 23:44:59 +0300

> I *think* my proposed wording above covers that; please check.

I don't think so. How about:
"Alice wants CAs compliant with the protocol to not issue certificates for alice.example.com unless the public key in those certificates matches what she has listed using the DANE protocol."

I realize that this may not work with the current DANE proposal, which hashes the entire cert in the record.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 May 2011 13:55:48 -0700

> "Alice wants CAs compliant with the protocol to not issue certificates for alice.example.com unless the public key in those certificates matches what she has listed using the DANE protocol."

That seems OK, but it is very much not what CAA is doing. CAA specifies the CA, not the trust anchor in my proposed text, and not the public key in your proposed text. I thought that my proposed text was closer to what users expect; given that Phill has been talking to other CAs for the past few months, CAA may be closer to what CAs expect.

My impression is that people here care more about restricting to a trust anchor than to a key, but I could easily be wrong about that. This discussion is a good way to hear those opinions.

> I realize that this may not work with the current DANE proposal, which hashes the entire cert in the record.

The purpose of this exercise is not to match what we already have in the protocol; it is to find what the WG wants to be there. Having said that, it would be easy to add an additional RRtype to DANE that covers what you have proposed, if people prefer that over what I proposed.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Wed, 11 May 2011 23:59:31 +0300

> That seems OK, but it is very much not what CAA is doing. CAA specifies the CA, not the trust anchor in my proposed text, and not the public key in your proposed text. I thought that my proposed te…

I meant your text for 3.1 and mine for 3.2.

> My impression is that people here care more about restricting to a trust anchor than to a key, but I could easily be wrong about that. This discussion is a good way to hear those opinions.

I think there's lots of people here with different things they care about. I care more about domain-issued certificates.

> Scanned by Check Point Total Security Gateway.

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 13 May 2011 11:57:24 -0400

On Fri, 2011-04-29 at 12:03 -0400, Warren Kumari wrote:
> I think that Richard has integrated most of the comments received
> on-list into this most recent version of the doc and so, as I
> mentioned, we are going to kick off WGLC...
> 

In general, I'm very happy with the document.  It provides an
even-handed discussion of a number of touchy issues.

Some suggestions:

- The security considerations in Section 3.1 could be clarified.  Here
is some alternative text as inspiration:

-----
Because these constraints do not increase the set of cases in which
server authentication succeeds, no security is lost by processing the
records even if they are retrieved without DNSSEC.  No matter what an
attacker does to the records, Bob will still require a valid PKIX
certificate that chains to a trust anchor, so he will achieve the same
level of security as without DANE.  However, security is only gained if
the records are DNSSEC signed and Bob is willing to fail unless he can
get a "secure" or verified "insecure" DNSSEC response.

An attacker with the ability to modify DNS responses as seen by Bob can
cause a denial of service by falsifying the DANE records, but in general
he can do so just as easily by falsifying the A or AAAA records, so this
is not a new risk.
-----

- This text does not belong in Section 3.3:

   Deleted records
   will only result in connection failure and denial of service,
   although this could result in clients re-connecting without TLS (a
   downgrade attack), depending on the application.  Therefore, in order
   for this use case to be safe, applications must forbid clients from
   falling back to unsecured channels when records appear to have been
   deleted (e.g., when a missing record has no NSEC or NSEC3 record).

Preventing a downgrade from TLS to non-TLS is, strictly speaking, an
orthogonal issue to TLS server authentication.  My understanding was
that the scope of DANE was only the latter, and the former would be
addressed with HASTLS or some such.  If the downgrade prevention is to
be mentioned here, it should be its own use case; it is not in any way
specific to the use of domain-issued certificates.

- Re the newfound power of DNSSEC zone operators under DANE (Section
3.3): I would not attempt to minimize this issue.  CAs will not hesitate
to remind us of the extra checks they perform for certain sites, so the
comparison to domain validation is not entirely correct.  Sites that
have special relationships with CAs but do not have proper oversight of
their DNSSEC zones will, indeed, have their security weakened when
clients adopt DANE.  If we are concerned about this, I think the natural
solution is to have a flag with each DNSSEC delegation that indicates
that the registrant fully trusts the child zone operator and hence
schemes such as DANE can be enabled.

- Section 3.4: I don't understand the motivation for constraining the
certificates used by an outsourcing provider.  If the provider is
operating the service, what security benefit can there be to forcing the
provider to use a particular certificate?  Is this something I missed in
the discussion?

-- 
Matt

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 13 May 2011 13:45:31 -0400

>>> Please get y'er comments in --  WGLC will be closing on 2011-05-13 at 16:00UTC (noonish EDT).

oops, I forgot to say: "I support the doc, it'd be nice to see a
re-spin if some of the more substantive comments need to be included."
-chris

---

From: Warren Kumari <[email-masked]>
Date: Fri, 13 May 2011 17:59:26 -0400

Thank you to everyone who provided comments, suggestions and (especially!) proposed text.

WGLC is now closed, and my cochair and I will discuss the comments, etc. (note to self: Don't end WGLC on a Friday :-P)

W

---

From: Warren Kumari <[email-masked]>
Date: Tue, 17 May 2011 10:39:31 -0400

Hello all,

Thank you all very much for your feedback, comments and (especially!) text.

Ondrej and I have discussed this and see good consensus for the document. There were some good comments (and text) provided, and Richard thinks that he will have some time in the next week or two to address / incorporate them.
We will then confirm that the revisions address the issues / concerns raised and then ship it...

W