Subject: [dane] #36: Only requiring DNSSEC where it is needed

From: "dane issue tracker" <[email-masked]>
Date: Tue, 27 Sep 2011 15:10:09 -0000

#36: Only requiring DNSSEC where it is needed

#choose ticket.new
  #when True
 Recent articles that talk about DANE have talked about the need for DNSSEC
 to
 be ubiquitous all the way to the client before DANE can be adopted.
 However,
 as we discussed during the use cases discussion, DNSSEC is only needed
 when
 normal PKIX validation is not being performed.

 Jakob and I propose that the WG consider changing the need for DNSSEC in
 the
 TLSA protocol by saying that it is (currently) only required for
 certificate
 usage 2. This change would entail:

 - more precise wording about DNSSEC in section 1
 - an explicit "MUST be protected by DNSSEC" for type 2 in 2.1.1
 - an explicit "MUST be protected by DNSSEC" for type 2 in 4.3
 - new wording in 4.4 about DNSSEC that points to the new text in the
   Security Considerations section
 - new text in the IANA Considerations in 7.2 that says that every new
   certificate type needs to say whether or not DNSSEC is required for
   that type
 - a new subsection in the Security Considerations in 8 that describes why
   DNSSEC is not needed for 0 and 1, and why it is needed for 2; this will
   be fairly detailed

 With such a change, we might see much earlier adoption of TLSA for
 certificate
 types 0 and 1 than we would have otherwise. This earlier adoption might
 lead
 to much faster adoption of type 2 when DNSSEC to the client is in place.
 On
 the other hand, earlier adoption of types 0 and 1 might delay the
 perceived
 need for type 2; however, we expect the fervor for type 2 to be strong
 regardless of deployment of type 0 and 1.
  #end
  #otherwise
    #if changes_body
Changes (by ):

    #end
    #if changes_descr
      #if not changes_body and not change.comment and change.author
Description changed by :
      #end

--
    #end
    #if change.comment

Comment(by undefined):

    #end
  #end
#end

-- 
----------------------------+----------------------------------------
 Reporter:  paul.hoffman@…  |      Owner:  draft-ietf-dane-protocol@…
     Type:  defect          |     Status:  new
 Priority:  major           |  Milestone:
Component:  protocol        |    Version:
 Severity:  -               |   Keywords:
----------------------------+----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/36>
dane <http://tools.ietf.org/dane/>

---

From: Martin Rex <[email-masked]>
Date: Wed, 28 Sep 2011 00:23:25 +0200 (MEST)

dane issue tracker wrote:
>  Recent articles that talk about DANE have talked about the
>  need for DNSSEC to be ubiquitous all the way to the client
>  before DANE can be adopted.  However, as we discussed during
>  the use cases discussion, DNSSEC is only needed when

That looks like a serious security problem to me.

The real benefit from confirmation of a PKIX-originating TLS Server
certificate through DANE comes from enabling the DNS admin to
to securely repudiate a server certificate for his domain.

If DNSSEC protection is obviated, then an attacker could not only
block the DANE repudiation, but even insert a false confirmation
for a fraudulently issued cert and create a false sense of security.

Neither coerced CAs (e.g. government agencies) nor CAs that have lost
track about certs they issued (DigiNotar for the *.google.com cert)
are going to quickly revoke such certs on their own -- and only clients
that are attacked would see them, there is no means for the domain
admin to find out about those certs.  And even then, PKIX-based
revocation is not a reliable mechanism.

I feel very uncomfortable with the proposal to make DANE optional for
PKIX-validated certs. 

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 28 Sep 2011 00:53:25 +0200 (MEST)

Sorry, typo (fixed below)

> revocation is not a reliable mechanism.
- I feel very uncomfortable with the proposal to make DANE optional for
- PKIX-validated certs. 
+ I feel very uncomfortable with the proposal to make DNSSEC optional
+ in DANE for PKIX-validated certs. 

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 27 Sep 2011 17:17:43 -0700

> That looks like a serious security problem to me.

Where, specifically? If we missed something in our proposal, we are happy to nuke it.

> to securely repudiate a server certificate for his domain.

Certificate type 2 is *one* "real benefit", but many of us think it is not the only one. Or are you proposing that we get rid of types 0 and 1 because they have no real benefit? (If so, you should open a different issue in the tracker...)

> for a fraudulently issued cert and create a false sense of security.

No, he can't. The attack you describe only applies to type 2 certs, which still need to be covered by DNSSEC in our proposal.

> revocation is not a reliable mechanism.

Fully agree. If that is your concern, using type 0 and type 1 certs will gain you nothing (but not expose you to anything new).

> I feel very uncomfortable with the proposal to make DANE optional for

Understood. Going back to your "false sense of security": would your concern be dealt with if we added wording saying "if a type 0 or 1 cert is received without DNSSEC, the application MUST NOT make any UI or log assertion that the certificate is more trusted than it would normally have been from TLS"?

--Paul Hoffman

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 27 Sep 2011 22:00:21 -0400

> No, he can't. The attack you describe only applies to type 2 certs, which still need to be covered by DNSSEC in our proposal.

Paul beat me to it.  With type 0/1 certs, the attacker can only block the DANE repudiation.  That's why there's not strictly a need for DNSSEC in that case.

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 27 Sep 2011 22:29:54 -0400

In other words, I support the authors' proposal.  That's what I get for not reading to the start of the thread.
--Richard

On Sep 27, 2011, at 10:00 PM, Richard L. Barnes wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 27 Sep 2011 22:40:22 -0400

Just leave off all the MUSTs.

Instead tell implementers and deployers what the consequence is of not
signing (record cannot be relied on for some purposes).

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 27 Sep 2011 23:35:05 -0400

I don't agree with that.  It's actively harmful to use type 2 certificates (TA assertions) without DNSSEC, so DNSSEC needs to be MUST USE for that class of TLSA record.

--Richard

---

From: "dane issue tracker" <[email-masked]>
Date: Wed, 28 Sep 2011 03:45:11 -0000

Comment (by matt@…):

 Let's be very clear what this means.  A client MUST NOT process additive
 assertions (i.e., type 2) that are not DNSSEC "secure"; that would be an
 obvious hole.  A client MAY process purely restrictive assertions (i.e.,
 types 0 and 1) regardless of DNSSEC usage or state.  However,
 users/implementers should realize that processing a restrictive assertion
 that is not DNSSEC "secure" is pointless security-wise except in unusual
 scenarios.

 A related issue is whether clients MUST (1) attempt a DNSSEC query, (2)
 fail the handshake unless the query completes with "secure" or "verified
 insecure" state, and (3) if a "secure" nonempty TLSA RRset is returned,
 process it as described in the spec.  This requirement goes hand in hand
 with the current statement that clients MUST fail the handshake if the
 server cert does not match any TLSA RR; one is not meaningful without the
 other.  So I think we should make both or neither of these behaviors
 conformance requirements (c.f. ticket:26).

-- 
----------------------------+-----------------------------------------
 Reporter:  paul.hoffman@…  |       Owner:  draft-ietf-dane-protocol@…
     Type:  defect          |      Status:  new
 Priority:  major           |   Milestone:
Component:  protocol        |     Version:
 Severity:  -               |  Resolution:
 Keywords:                  |
----------------------------+-----------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/dane/trac/ticket/36#comment:1>
dane <http://tools.ietf.org/dane/>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 28 Sep 2011 07:29:09 -0700

> I don't agree with that.  It's actively harmful to use type 2 certificates (TA assertions) without DNSSEC, so DNSSEC needs to be MUST USE for that class of TLSA record.

+1

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 29 Sep 2011 09:54:16 -0700

On Tue, Sep 27, 2011 at 7:00 PM, Richard L. Barnes <[email-masked]> wrote:
> Paul beat me to it.  With type 0/1 certs, the attacker can only block the DANE repudiation.
> That's why there's not strictly a need for DNSSEC in that case.

Even though this is the case, I do not like the idea of relaxing the
requirement for DNSSEC to just some types of TLSA record.  I prefer
the operational simplicity of "MUST use DNSSEC" and the client-side
implementation simplicity of "MUST ignore all TLSA records that are
DNSSEC-insecure".

zw

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 29 Sep 2011 09:56:11 -0700

>  conformance requirements (c.f. ticket:26).

Agree entirely (and I vote for "both").  Might want some wiggle room
in the wording to allow for Adam's DANE-stapling scheme instead of
client doing its own DNSSEC processing.

zw

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 30 Sep 2011 09:28:56 +0200

> implementation simplicity of "MUST ignore all TLSA records that are

+1
Maintaining when and in what circumstances TLSA should/should
not/must/must not be signed is adding complexity that is more likely to
become broken than the simple rule now that it MUST allways be signed,

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Sep 2011 09:24:37 -0700

On Sep 30, 2011, at 12:28 AM, Antoin Verschuren wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

On the topic of complexity, I note that this only adds one bit that must be checked for one certificate type. Under the proposal, for certificate type 2, you must also check if DNSSEC was used. If you receive a type 0 or 1, you don't even check if DNSSEC was used. (I will nudge Martin on my proposed addition to make that clearer.)

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Sep 2011 09:26:14 -0700

A nudge on one part of message.

>> for a fraudulently issued cert and create a false sense of security.

Would your concern be dealt with if we added wording saying "if a type 0 or 1 cert is received without DNSSEC, the application MUST NOT make any UI or log assertion that the certificate is more trusted than it would normally have been from TLS"?

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Sep 2011 12:47:32 -0400 (EDT)

> Would your concern be dealt with if we added wording saying "if a type 0 or 1 cert is received without DNSSEC, the application MUST NOT make any UI or log assertion that the certificate is more tru…

That comes close to "An application SHOULD ignore a TLSA record if received without DNSSEC".
At which point, the step to MUST is pretty small.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Sep 2011 10:00:00 -0700

> That comes close to "An application SHOULD ignore a TLSA record if received without DNSSEC".

Oh, please. First, it is only about type 0 and 1. Second, there is nothing about ignoring, just about not highlighting the security. There is nothing "close" at all.

It's clear that all you care about is type 2 and, in the future, type 3ish that is for non-cert keys. No one is forcing you to implement a client that accepts type 0 or 1. Others have expressed a strong interest in types 0 and 1, and that's what this proposal addresses.

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Fri, 30 Sep 2011 10:56:23 -0700

On Fri, Sep 30, 2011 at 9:24 AM, Paul Hoffman <[email-masked]> wrote:
>>> [...] I do not like the idea of relaxing the
> On the topic of complexity, I note that this only adds one bit that must be
> checked for one certificate type. Under the proposal, for certificate type 2,
> you must also check if DNSSEC was used. If you receive a type 0 or 1,
> you don't even check if DNSSEC was used.

No, because the DANE client has to reject the TLS handshake regardless
of cert type if it gets a DNSSEC-bogus or DNSSEC-stripped response.
Therefore, your proposal involves looking at DNSSEC status twice:
first before parsing the record, and then again afterward.  (Obviously
the actual signature check only has to happen once.)

Under my/Antoin/Paul W's preferred scheme, you only have to look at
DNSSEC status once, before parsing the record.  Fewer steps, easier to
code correctly.

zw

---

From: Martin Rex <[email-masked]>
Date: Fri, 30 Sep 2011 19:56:55 +0200 (MEST)

Paul Hoffman wrote:
> Would your concern be dealt with if we added wording saying
> "if a type 0 or 1 cert is received without DNSSEC, the application
> MUST NOT make any UI or log assertion that the certificate is
> more trusted than it would normally have been from TLS"?

I may have to think a little more about the details, but it somehow
does not feel right.

This suggestion would make a DANE-aware TLS client behave equivalent
to a pre-DANE client for such servers.  Although this would not
*add* any additional false sense of security, there is the underlying
expectation "my TLS client is DANE-aware", creating a level of
expectation that could then no longer be met.  One of these
expectations (my personal favourite) is that fraudulently or accidentally
issued TLS server cert will never be considered valid by the TLS client
if the DNS admin has published TLSA records for his server.

With respect to (additional) UI chrome for DANE-confirmed server
certs, we might have to distinguish specific DNSSEC failure cases.

 - is the TLS client DNSSEC capable, but can not obtain the necessary
   DNSSEC records? (due to a home gateway, firewall ... or an attacker)

 - did the TLS client obtain all existing DNSSEC records, but there simply
   are not any TLSA records provided by the DNS admin

 - the client obtained TLSA records without DNSSEC protection, but
   none of those TLSA records are supported by the TLS clients DANE
   implementation -- what does it mean (and is that what consumers
   will expect)?

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Sep 2011 11:19:30 -0700

> of cert type if it gets a DNSSEC-bogus or DNSSEC-stripped response.

I don't think that is right, but I want to check your logic. Is your scenario that an attacker injects a type 0 or type 1 TLSA record and either leaves in DNSSEC (bogus) or strips it (stripped)? If so, what is the attacker's motive? He will not achieve anything because TLS was dropped. This attack is no different than sending a bogus A record to a TLS proxy that cannot impersonate the intended server, or to anyplace where TLS won't happen correctly.

If that isn't your attack scenario, what is?

> the actual signature check only has to happen once.)

No, our proposal doesn't involve looking at DNSSEC ever if the type is 0 or 1.

> DNSSEC status once, before parsing the record.  

Agree.

> Fewer steps, easier to

Again, I believe the new proposal adds one step: "if you received a type 2 response, make sure it was covered with DNSSEC". That's the same number of steps as "if you received any response, make sure it was covered with DNSSEC".

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Sep 2011 11:27:23 -0700

> if the DNS admin has published TLSA records for his server.

OK, I can start to see your concern. Would "my browser is now TLSA aware, so it is protecting me against things which I don't understand" be a reasonable paraphrase? If so, I agree that not forcing every response to be DNSSEC-assured would probably not meet the expectations of those users.

Having said that, *every* security improvement that is being discussed won't meet those expectations. Any TOFU-based proposals in the websec WG have the same problems. For that matter, all versions of TLS that allow fallback have the same problems. This seems like too high of a bar for some, but others might want the bar that high.

>   implementation -- what does it mean (and is that what consumers

That kind of list is exactly what I want to avoid. It leads to the same madness as the UI chrome for plain PKIX: "that cert was valid yesterday, but it expired today, and even though I have no indication that the key has been compromised, I'm suggesting you reject it" and its ilk.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 30 Sep 2011 14:31:33 -0400

> No, our proposal doesn't involve looking at DNSSEC ever if the type is 0 or 1.

A validating resolver is going to look at the DNSSEC anyway, isn't it?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Sep 2011 11:52:55 -0700

> A validating resolver is going to look at the DNSSEC anyway, isn't it?

Certainly. The question is whether the *application* needs to know whether or not DNSSEC validated on the DNS records, such as through some future DNS API or through the application itself being a DNS validating resolver.

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Fri, 30 Sep 2011 13:40:23 -0700

Meant to send this to the list.

---------- Forwarded message ----------
From: Zack Weinberg <[email-masked]>
Date: Fri, Sep 30, 2011 at 1:39 PM
Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed
To: Paul Hoffman <[email-masked]>

On Fri, Sep 30, 2011 at 11:19 AM, Paul Hoffman <[email-masked]> wrote:
> I don't think that is right, but I want to check your logic. Is your scenario that
> an attacker injects a type 0 or type 1 TLSA record and either leaves in
> DNSSEC (bogus) or strips it (stripped)? If so, what is the attacker's motive?
> He will not achieve anything because TLS was dropped. This attack is no
> different than sending a bogus A record to a TLS proxy that cannot
> impersonate the intended server, or to anyplace where TLS won't happen
> correctly.

In the hypothetical, we're allowing unauthenticated type 0 or type 1
records; however, a site admin who chooses to deploy DNSSEC with those
record types reasonably expects that this will prevent an attacker
from removing said records or substituting their own.

Suppose that victim.example has deployed DNSSEC, and the zone contains
a type 0 TLSA record limiting www.victim.example's server certificates
to CA "alpha".  Suppose a network attacker who has, somehow, obtained
a certificate for www.victim.example signed by CA "beta".  Both
"alpha" and "beta" are in the root pool of all clients of interest.
The attacker interposes on DNS traffic for www.victim.example, strips
all DNSSEC and TLSA records, and modifies the A record to point to its
own server, which claims to be www.victim.example and provides the
certificate from CA "beta" as authentication.

A DANE client that ignores DNSSEC validation under any circumstances
-- note that in this scenario, it doesn't get any TLSA records back at
all! -- will not defend against this attack; but a client that treats
DNSSEC "bogus" or "stripped" states as a hard failure, regardless of
TLSA contents, will defend.

> Again, I believe the new proposal adds one step: "if you received a type 2
> response, make sure it was covered with DNSSEC". That's the same
> number of steps as "if you received any response, make sure it was
> covered with DNSSEC".

I hope I have demonstrated that this is inadequate.

zw

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 30 Sep 2011 23:49:23 -0700

> TLSA contents, will defend.

To simplify matters a bit, note that RFC 4033 "bogus" includes what you
are calling "stripped".

> I hope I have demonstrated that this is inadequate.

You and Paul are arguing past each other.  Paul is assuming a validating
resolver that doesn't even give you a response unless it is "secure" or
"verified insecure"; in that case, you're already protected from
tampering with signed TLSA records.  If you get verified-insecure
records of usage 0 or 1, you do not gain or lose any security by
processing them, so it hardly matters whether you do.  (This is in the
general case where you don't have a better-protected path to DNS than to
the TLS server.)

What is easiest to implement in practice depends on the DNS library.  In
light of that, I would not stipulate that clients MUST NOT process
verified insecure records of usage 0 or 1.  I think we may be better off
stating and justifying what is actually needed, rather than putting in a
MUST because we feel like it and running the risk that implementors
second-guess us incorrectly.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 30 Sep 2011 23:54:51 -0700

On Fri, 2011-09-30 at 11:52 -0700, Paul Hoffman wrote:
> Certainly. The question is whether the *application* needs to know
> whether or not DNSSEC validated on the DNS records, such as through
> some future DNS API or through the application itself being a DNS
> validating resolver.

Be a little careful with this... libunbound gives you the RRset
regardless and makes you check that the "bogus" flag in the result
structure is unset.  This is a design weakness in libunbound, but that's
what we have to work with.

-- 
Matt