Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt

From: "Richard L. Barnes" <[email-masked]>
Date: Sun, 12 Jun 2011 17:52:21 -0400

This version addresses a variety of comments raised during the earlier last call.  The diff can be found here:
<http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-use-cases-03.txt>

On Jun 12, 2011, at 5:50 PM, [email-masked] wrote:

> A new version of I-D, draft-ietf-dane-use-cases-03.txt has been successfully submitted by Richard Barnes and posted to the IETF repository.
> 
> Filename:	 draft-ietf-dane-use-cases
> Revision:	 03
> Title:		 Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)
> Creation date:	 2011-06-12
> WG ID:		 dane
> Number of pages: 12
> 
> Abstract:
>   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.
> 
> 
> 
> 
> The IETF Secretariat

---

From: Warren Kumari <[email-masked]>
Date: Mon, 13 Jun 2011 07:32:01 -0600

I would like to thank Richard again for authoring this -- I personally think that he did a really good job of capturing / documenting the use cases and integrating the provided comments…

This document has already successfully passed WGLC (and we have clarification that the "restrictive" case is within out charter), but as a courtesy we'd like to give the folk that provided comments / feedback a chance to confirm that your point was captured (and not mangled during integration).

Please provided confirmation or *clearly* explain what was *misunderstood* by Thursday June 16th, 00:00UTC. Silence will count as confirmation / acceptance.

Once again, this is *NOT* the time to reopen discussions, WGLC already happened (and there was strong consensus)

W

On Jun 12, 2011, at 3:52 PM, Richard L. Barnes wrote:

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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Jun 2011 13:32:18 -0400 (EDT)

> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-use-cases-03.txt>

It seems my previous comments have not been integrated at all. Since Richard also did
not provide feedback to them, I am not sure if he missed them or if he (or the WG)
disagreed with them. Since various people quoted links to my previous comments during
WGLC, I am somewhat confused what happened to these. Could Richard of the chairs clarify
this for me?

I have two real issues, and some typo fixes.

1) Use of DANE without DNSSEC

 	"Nonetheless, using DANE in this way without also using DNSSEC
 	represents provides a very small incremental security feature. Many
 	common attacks against TLS connections already require the attacker
 	to inject false A or AAAA records in order to steer the victim client
 	to the attacker's server. An attacker that can already inject false
 	DNS records can also fake DANE information (without DNSSEC) by simply
 	spoofing the additional records required to carry the DANE
 	information."

The text was changed to even further reduce the non-dnsse case to "very small incremental
security feature". I still believe more then just I are advocating for "no DANE
without DNSSEC". I still believe this section should be removed, and no non-DNSSEC
case of DANE should be supported or argued for. See also section 1. where it states:

 	"With the advent of DNSSEC [RFC4033], it is now possible for DNS name
 	resolution to provide its information securely, in the sense that
 	clients can verify that DNS information was provided by the domain
 	for DNS-based Authentication of Named Entities (DANE) is to use the
 	DNS and DNSSEC to provide additional information about the
 	cryptographic credentials associated with a domain, so that clients
 	can use this information to increase the level of assurance they
 	receive from the TLS handshake process. This document describes a
 	set of use cases that capture specific goals for using the DNS in
 	this way"

It clearly states here this docment presents a way to use DNSSEC,
not a way to insecurely publish cryptographic material in a better then
nothing method.  Telling people to use cryptographic material sent without
modification protection is just wrong. It's worse then allowing sha1,
which we don't allow any new draft to do. This part of the use case also
violates section 4. Other Requirements "minimal dependancies" that states:

 	"Minimal Dependencies: It should be possible for a site to deploy
 	 DANE without also deploying anything else, except DNSSEC."

2) DNS control means full domain control

 	"Continuing to require PKIX validation also limits the degree to which
 	DNS operators (as distinct from the owners of domains) can interfere
 	with TLS authentication through this mechanism. As above, even if a
 	DNS operator falsifies DANE records, it cannot masquerade as the
 	target server unless it can also obtain a certificate for the target
 	domain."

This text is still very wrong. As I explained before, the DNS
administrator can remove the draft-ietf-dane-protocol-7 Section
2.1. Certificate Type Field 2 and replace it with a type 1 (EEcert)
or type 3 (pubkey) bypassing the CA limitation.  There is nothing DANE
can do to prevent the DNS operator from doing so.

 	"Because these constraints do not increase the scope of PKIX-based
 	assertions about domains, there is not a strict requirement for
 	DNSSEC. Deletion of records removes the protection provided by this
 	constraint, but the client is still protected by CA practices (as
 	now). Injected or modified false records are not useful unless the
 	attacker can also obtain a certificate for the target domain."

The DNS operator could introduce a CNAME pointing to a domain under their
control, and issuing a type 2 CA backed certificate for the CNAME target
to get a "CA PKIX" assured DANE reference, so this statement is also wrong.

I strongly suggest to updating/removing the sections that suggest DANE
without DNSSEC adds any kind of security. It does not. Both attempts to
describe these above are incorrect.

3) Some typos:

The DANE mechanism must allow a clients -> The DANE mechanism must allow a client

case a denial of service -> cause a denial of service

Paul

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 13 Jun 2011 14:08:00 -0700

On Mon, Jun 13, 2011 at 10:32 AM, Paul Wouters <[email-masked]> wrote:
...
>         DANE without also deploying anything else, except DNSSEC."

These were my words, and I didn't mean them to exclude the possibility
of DANE without DNSSEC; I just wanted to avoid *further* dependencies.
 In particular, I think takeup of DANE by administrators of existing
TLS-secured sites will be severely harmed if adding TLSA records to a
zone breaks the service unless other things (outside the zone file)
are reconfigured simultaneously.

That said, I think you're right to advocate for DANE-with-DNSSEC as
the only supported operational mode, just because it means neither
specifiers nor implementers have to worry about whether
DANE-without-DNSSEC information is usable in any given context.

zw

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Jun 2011 17:22:03 -0400 (EDT)

> DANE-without-DNSSEC information is usable in any given context.

It's worse then worry about implementers though. I haven't found a
single use case where non-DNSSEC DANE adds any security, as the use
cases in the current draft are broken as I explained.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Jun 2011 18:59:23 -0400

If Alice is going to connect to the site en clair anyway, a DANE key without
DNSSEC offers more security.

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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Jun 2011 20:20:30 -0400 (EDT)

On Mon, 13 Jun 2011, Phillip Hallam-Baker wrote:

> If Alice is going to connect to the site en clair anyway, a DANE key without DNSSEC offers more security.

It offers as much as the "may contain traces of peanuts" on the snickers wrapper....

If the attacker can spoof the DNS anser for the A record or DANE record, having the
DANE record there adds no security. Really, the only marginal case you can argue
for is that she is safe against all attackers that can spoof the A record, but not the
DANE record. But once this is deployed, even LulzSec will know how to spoof a DANE
record.

People seem to think this is orthogonal to opportunistic encryption, but it is not.
Alice can already do opportunistic https without DANE, so the protection against
passive attacks is already there. Agains active attacks, DANE without DNSSEC adds
nothing.

Paul

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 13 Jun 2011 19:07:11 -0700

You may treat some of the comments below as IETF last call statements if you
wish:

1.  I cannot say that I like the title of section 3.3.  To me a
Domain-Issued Certificate is not the same as making a trust anchor assertion
which is what I think the section is really about.  To me a Domain-Issued
Certificate would still be a true statement if Alice got a sub-CA to Charlie
and issued here own certificates.  I would prefer that this used more PKIX
style terminology as what this section is addressing is publishing trust
anchors.

2.  Along the same lines I would like to change the title of section 3.2 -
even a CA constraint is a constraint on a certificate.  This might be better
stated as Service Certificate Constraint

3.  I find the statement referring to security consideration of section 3.1
from 3.2 difficult as they are not clearly defined as such.   Given that I
cannot easily find the security considerations - they are not in section 7
and are not labeled then it does not make sense.  Implications might be a
better word here.  Also I think that if you really consider them to be
considerations they should be referenced from section 7.

4.  In section 3.2  the following text exists: " She would like to provide a
way for visitors to her
   site to know that they should expect alice.example.com to present the
   specific certificate issued by Charlie."  But there is nothing inherit
here that says it was issued by Charlie.  I would suggest s/the specific
certificate issued by Charlie./a specific certificate./

5.  I am not happy with the Combination text.  I am not sure that one would
need to use combination for the stated case.  That is a CA statement would
be sufficient to state that a specific CA would be used.  It would be more
accurate to deal with the case of either specifying both a CA and a service
certificate.  Or specifying both a CA and a trust anchor certificate.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 13 Jun 2011 19:08:37 -0700

I think the (extremely small) advance is that while you may not be talking
to somebody you should be.  At least nobody else can eaves drop on it.  I
tend to agree that this is a best an extremely marginal improvement.  I
would rather be told that I cannot talk securely that be in this situation.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Wouters
> Sent: Monday, June 13, 2011 5:21 PM
> To: Phillip Hallam-Baker
> Cc: IETF DANE WG list
> Subject: Re: [dane] New Version Notification for
draft-ietf-dane-use-cases-
> 03.txt
> If the attacker can spoof the DNS anser for the A record or DANE record,
> having the DANE record there adds no security. Really, the only marginal
case
> you can argue for is that she is safe against all attackers that can spoof
the A
> record, but not the DANE record. But once this is deployed, even LulzSec
will
> know how to spoof a DANE record.
> 
> People seem to think this is orthogonal to opportunistic encryption, but
it is
> not.
> Alice can already do opportunistic https without DANE, so the protection
> against passive attacks is already there. Agains active attacks, DANE
without
> DNSSEC adds nothing.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 13 Jun 2011 21:43:46 -0400

Hi Paul,

Thanks for checking the revised version.

> 1) Use of DANE without DNSSEC

I added the paragraph you note to more correctly describe the impact of using DANE without DNSSEC, as you, Jim, and Jeff all noted:
Wouters: http://www.ietf.org/mail-archive/web/dane/current/msg02559.html
Schaad: http://www.ietf.org/mail-archive/web/dane/current/msg02564.html
Hodges: http://www.ietf.org/mail-archive/web/dane/current/msg02579.html

Can we agree that the current draft accurately describes the (admittedly minor) effect of using DANE without DNSSEC?  If this document has an accurate description, then I think the discussion of whether or not this behavior should be allowed can be addressed to the protocol document itself.

> can do to prevent the DNS operator from doing so.

You're correct that this is an attack, but it doesn't use "Use case 1" DANE information, which is what the referenced text is talking about.  Bypassing the CA limitation in the manner you describe requires using "Use Case 3" DANE information, for which DNSSEC is required.

> to get a "CA PKIX" assured DANE reference, so this statement is also wrong.

This is not correct.  It depends on the application.  All of the applications described in RFC 6125 say "CNAME canonicalization is not done", in which case this attack would not be effective.

So neither of these proposed attacks has any bearing on "Use case 1" DANE information.

> case a denial of service -> cause a denial of service

Thanks, I've corrected these in my working copy.

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Jun 2011 22:16:08 -0400

No, if we could get to the point where 90% of the Internet traffic was
soft-scrambled with TLS, the task of attackers would be much harder. Only
MITMs could attack. That cuts down the attack surface considerably.

On Mon, Jun 13, 2011 at 8:20 PM, Paul Wouters <[email-masked]> wrote:

> having the
> against

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Jun 2011 01:55:47 -0400 (EDT)

On Mon, 13 Jun 2011, Phillip Hallam-Baker wrote:

> No, if we could get to the point where 90% of the Internet traffic was soft-scrambled with TLS, the task of attackers would be much harder. Only MITMs
> could attack. That cuts down the attack surface considerably.

I am not disagreeing that 90% of port 80 -> 443 would be good, but that was not the point
below. You stated "If Alice is going to connect to the site en clair anyway". My point
was that if she is going cleartext anyway, whether there is dane or not, protected by
dnssec or not, would not make a difference to the attacker.

I still do not understand any of the use cases for DANE without DNSSEC. Perhaps someone
who does see this could explain it to me in clear steps that Alice is taking and where
Malice is twarted by a DANE key without DNSSEC protection......

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Jun 2011 15:37:07 -0400 (EDT)

> Can we agree that the current draft accurately describes the (admittedly minor) effect of using DANE without DNSSEC?  If this document has an accurate description, then I think the discussion of wh…

I thought the use cases document should lead to the technical spec, and not the other way around?
If we're ignoring the use-cases specified here, i wonder why this whole exercise was started to
begin with.

> You're correct that this is an attack, but it doesn't use "Use case 1" DANE information, which is what the referenced text is talking about.  Bypassing the CA limitation in the manner you describe…

When I read use case 3.1, isn'tt it about restricting which CA can sign for a TLS EE cert from DNS,
for both endusers and CA's ? DNS could still be spoofed there. It could be spoofed to the CA that
was doing the DNS check, thereby bypassing it, and it can be spoofed to the enduser to point to
the other CA once the first spoof caused Malice to obtain that "signed by wrong but qualified CA".
I still don't see how lack of DNSSEC still adds security.

btw. I missed an earlier typo:

Note that this check does not guaranteed that -> Note that this check does not guarantee that

> This is not correct.  It depends on the application.  All of the applications described in RFC 6125 say "CNAME canonicalization is not done", in which case this attack would not be effective.

Then it can still change or delete the DANE record.

> So neither of these proposed attacks has any bearing on "Use case 1" DANE information.

I still don't agree with your philosophy though. You are saying "we have a new security feature
that narrows down the security further, but it is okay if this is bypassed because we still
have the other security feature that did not narrow things down as much". It basically adds
nothing in the case where it matters (when under attack) and does not prevent any of the
incompetent/rogue CAs from issuing bad certs either.

On top of that, it adds a very dangerous mode of "dane without dnssec can be okay" philosophy,
which I'd argue is inheritantly more dangerous in its potential effects compared to the assets
of this one miniscule corner case with a well behaving CA that's not under attack.

Paul

---

From: Warren Kumari <[email-masked]>
Date: Tue, 14 Jun 2011 14:22:25 -0600

On Jun 13, 2011, at 6:20 PM, Paul Wouters wrote:

> It offers as much as the "may contain traces of peanuts" on the snickers wrapper….

I am wildly allergic to peanuts -- while the warning may be vague (and non-authorative) I will choose NOT to eat the snickers bar (it is a DoS on my tasty treat consumption). This is (IMO) much better than not providing me any information and having me keel over in anaphylactic sock.

W

---

From: Warren Kumari <[email-masked]>
Date: Tue, 14 Jun 2011 14:24:24 -0600

> I am wildly allergic to peanuts -- while the warning may be vague (and non-authorative) I will choose NOT to eat the snickers bar (it is a DoS on my tasty treat consumption). This is (IMO) much bet…

Whoops, I'm sorry all -- as I hit send I realized that this is NOT the right time or place to be tripping down this rathole…

Please ignore my last email….

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Jun 2011 18:55:15 -0400

On Tue, Jun 14, 2011 at 3:37 PM, Paul Wouters <[email-masked]> wrote:

>  Can we agree that the current draft accurately describes the (admittedly
>> minor) effect of using DANE without DNSSEC?  If this document has an
>> accurate description, then I think the discussion of whether or not this
>> behavior should be allowed can be addressed to the protocol document itself.
>>
>

Usually a use cases and requirements document has a statement about the
constraints under which the application will be employed.

In this case there are two separate DNSSEC requirements:

1) Domain name owner to deploy DNSSEC
2) Client to have access to the DNSSEC information

Making #1 a requirement is a technical decision for the spec. I have no
particular problem with that.

#2 is a constraint that has to be addressed. There has to be a sensible
story for what to do when the client does not have DNSSEC information
available.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 15 Jun 2011 15:57:26 +0200

> Malice is twarted by a DANE key without DNSSEC protection......

Youtube AS hijack.  No A record was spoofed, but the traffic still went
to hijackers.

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: Paul Wouters <[email-masked]>
Date: Wed, 15 Jun 2011 11:13:27 -0400 (EDT)

> Youtube AS hijack.  No A record was spoofed, but the traffic still went

Ahh indeed. The traffic was send to the same (stolen) IP range, and a dane
record (not stolen and no massive dns polution) could have made a difference
if youtube had made use of https.

Richard, why don't we put something like this in the use-case document as a
clear case instead of mixing it up with CA policies in use case 1.

Alice runs a large https farm that is popular worldwide. Malice twarts all
the traffic, for example via a BGP hijack, but is not in a position to spoof
DNS traffic. Malice can receive the HTTPS traffic but needs to setup forged
certificates because she does not have Alice's private key for the HTTPS cert.
Alice publishing the public key or cert via DANE so that her customers will be
warned/prevented from connecting to HTTPS servers under Malice's control.

Paul

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 15 Jun 2011 14:27:43 -0400

You don't need to do it with BGP, someone on the same shared medium can easily hijack your TCP connection without having to touch the DNS.
--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Jun 2011 15:21:31 -0400

One area where BGP is a concern is in the hacker response to DNSSEC.

While DNS spoofing is bad, the effects are generally localized. One concern
with use of DNSSEC without additional security measures is that the DNSSEC
control can be bypassed by attacking at the BGP layer. Attacks at the BGP
layer have much wider consequences and at this point efforts towards BGP
security are focused on preventing DoS attacks rather than enabling
end-to-end security.

Ergo it seems to me at least that if there is going to be DNSSEC enforcement
there has to be some means of binding keys in the DNS. Otherwise all that
DNSSEC is doing is to force the attacker to switch from an attack with
limited side effects to one with very large side effects.

On Wed, Jun 15, 2011 at 2:27 PM, Richard L. Barnes <[email-masked]> wrote:

> You don't need to do it with BGP, someone on the same shared medium can
> easily hijack your TCP connection without having to touch the DNS.
> --Richard
>
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Jun 2011 15:48:20 -0400 (EDT)

> You don't need to do it with BGP, someone on the same shared medium can easily hijack your TCP connection without having to touch the DNS.

But then the DANE record without DNSSEC can also be forged, because
the attacker can see/modify the DNS packets. So its is not a good
example of DANE without DNSSEC.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Jun 2011 15:50:44 -0400 (EDT)

On Wed, 15 Jun 2011, Phillip Hallam-Baker wrote:

> concern with use of DNSSEC without additional security measures is that
> the DNSSEC control can be bypassed by attacking at the BGP layer.

Can you explain how this works in a concrete example?. Assume an ISP
nameserver with DNSESC root key preloaded, and no PKIX.

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 15 Jun 2011 12:53:36 -0700

On Jun 15, 2011, at 12:21 PM, Phillip Hallam-Baker wrote:

> While DNS spoofing is bad, the effects are generally localized. One concern with use of DNSSEC without additional security measures is that the DNSSEC control can be bypassed by attacking at the BGP layer. Attacks at the BGP layer have much wider consequences and at this point efforts towards BGP security are focused on preventing DoS attacks rather than enabling end-to-end security.

Pardon my ignorance, but I don't get the point here...

DNSSEC is designed specifically so that the validator can either prove a single possible path of trust exists from the root(s) of trust to the target name OR that the point where the path of trust breaks, that it is provably a break in trust where the parent cryptographically asserts that it has no key material for the child.

A full MitM attack (aka, your BGP attack) is thus provably detectable if its tampering with DNSSEC records, and any application (EG, DANE) which uses DNSSEC to distribute key material should naturally scream-bloody-murder and fail if it found an unasserted break in the chain of trust.

Put simply, a BGP attack doesn't bypass the DNSSEC control, it rather points out that DNSSEC is only useful for distributing key material or other material in a PKI-ish like fashion (e.g. DANE).  Because otherwise, any application which uses A records is either trivially vulnerable to the Man-in-the-middle or doesn't rely on DNS being correct, regardless of how the attacker became a MitM (Take over the recursive resolver, packet inject, BGP, whatever).

Oh, and BGP attacks can be done without noticable side effects, having been on a test network where such an attack was done.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 15 Jun 2011 17:17:34 -0400

Agreed, not a great example.  But you would need an additional set of tools, so at least it's an annoyance for the attacker :)

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Jun 2011 17:39:55 -0400

The attacker wants to reroute the Facebook Website.

Instead of manipulating the facebook.com A record, the attacker decides to
reroute the Facebook IP address by advertising a bogus route.

Securing the DNS name to IP mapping is not worth much unless you can also
secure the mapping of the IP address to the endpoint.

While BGP attacks can be done without major collateral damage by experts in
the lab, the effect of less expert attackers who don't much care about that
damage on the open network is likely to be rather less happy.

My point was merely that all these things are connected and it is not very
useful for folk to be making absolute statements about what is essential.

You are not going to be able to defeat every attacker with one single
scheme. But a scheme that can defeat 80% of hackers can still have real
value in mitigating risk.

The problem with declaring DNSSEC essential is that it is not going to be
available everywhere you would want it.

On Wed, Jun 15, 2011 at 3:53 PM, Nicholas Weaver
<[email-masked]>wrote:

> > While DNS spoofing is bad, the effects are generally localized. One
> concern with use of DNSSEC without additional security measures is that the
> DNSSEC control can be bypassed by attacking at the BGP layer. Attacks at the
> BGP layer have much wider consequences and at this point efforts towards BGP
> DNSSEC is designed specifically so that the validator can either prove a
> single possible path of trust exists from the root(s) of trust to the target
> name OR that the point where the path of trust breaks, that it is provably a
> break in trust where the parent cryptographically asserts that it has no key
> material for the child.
>
> A full MitM attack (aka, your BGP attack) is thus provably detectable if
> its tampering with DNSSEC records, and any application (EG, DANE) which uses
> DNSSEC to distribute key material should naturally scream-bloody-murder and
> fail if it found an unasserted break in the chain of trust.
>
>
> Put simply, a BGP attack doesn't bypass the DNSSEC control, it rather
> points out that DNSSEC is only useful for distributing key material or other
> material in a PKI-ish like fashion (e.g. DANE).  Because otherwise, any
> application which uses A records is either trivially vulnerable to the
> Man-in-the-middle or doesn't rely on DNS being correct, regardless of how
> the attacker became a MitM (Take over the recursive resolver, packet inject,
> BGP, whatever).
>
>
> Oh, and BGP attacks can be done without noticable side effects, having been
> on a test network where such an attack was done.
>
>

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 15 Jun 2011 19:07:38 -0400

On Mon, 2011-06-13 at 07:32 -0600, Warren Kumari wrote:
> This document has already successfully passed WGLC (and we have
> clarification that the "restrictive" case is within out charter), but
> as a courtesy we'd like to give the folk that provided comments /
> feedback a chance to confirm that your point was captured (and not
> mangled during integration).
> 
> Please provided confirmation or *clearly* explain what was
> *misunderstood* by Thursday June 16th, 00:00UTC. Silence will count as
> confirmation / acceptance.
> 
> Once again, this is *NOT* the time to reopen discussions, WGLC already
> happened (and there was strong consensus)

No action was taken on my comments here:

https://www.ietf.org/mail-archive/web/dane/current/msg02578.html

Also, between -02 and -03, the document gained some paragraphs about
using DANE to restrict certificate issuance by CAs.  As a use case, this
is outside our charter and I don't remember it ever being discussed on
the list.  Of course, once DANE information is published, nothing stops
CAs from looking at it as part of their fraud checks.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 15 Jun 2011 19:15:14 -0400

On Wed, 2011-06-15 at 19:07 -0400, Matt McCutchen wrote:
> the list.

Never mind, I found the thread now:

https://www.ietf.org/mail-archive/web/dane/current/msg02583.html

I guess I missed commenting then.  I do not object to leaving the use
case in the document pending a decision on whether it is really
appropriate for DANE to do this.

-- 
Matt

---

From: Scott Schmit <[email-masked]>
Date: Thu, 16 Jun 2011 00:20:28 -0400

> Youtube AS hijack.  No A record was spoofed, but the traffic still went

Sure, but assuming that you're connecting via HTTPS rather than HTTP
(DANE doesn't even kick in if HTTPS isn't being used), even PKIX would
flag a problem with this kind of MITM, unless the hijackers also got the
private keys. Honestly, if that's the threat, DANE won't help either.

I guess you could claim that they could trick a CA into a misissue, but
I'm having a hard time seeing how that attack is easier/cheaper than
attacking a DNS server hosting an unsigned zone.

-- 
Scott Schmit

---

From: James Cloos <[email-masked]>
Date: Thu, 16 Jun 2011 01:20:42 -0400

>>>>> "SS" == Scott Schmit <[email-masked]> writes:

SS> (DANE doesn't even kick in if HTTPS isn't being used)

You really need to write TLS there; DANE applies not just to https, but
to anything layered over TLS, including cases when TLS is negotiated
after the sockets are up.

(At the very least, smtp, pop3, imap, ftp, xmpp and http -- including
protocols like ipp which are layered upon http -- support STARTTLS.)

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 16 Jun 2011 11:06:35 +0200

Hi Richard,

The usecase draft must describe cases where DNSSEC-validated data is
used to secure a connection.  Something that gives real security, thus
the user of the data securely knows that the data is DNSSEC validated,
with as example it validated itself (home user) or with VPN (some
companies perhaps).

(And I doubt the VPN because the VPN may well start with DNSSEC to get
its key information).

Using unsecured data, or the same data in absence of DNSSEC validation
is not useful.  These sections must be taken out of the document, apart
from saying that the use of unsecured data or non-validated data is not
allowed to be used to claim some gain in trustworthiness (because none
has been gained).

Making small hurdles that you describe now with unsecured data, although
theoretically fun, are not useful for dane.

Best regards,
   Wouter

On 06/15/2011 11:17 PM, Richard L. Barnes wrote:
> Agreed, not a great example.  But you would need an additional set of
> tools, so at least it's an annoyance for the attacker :)
> 
> --Richard
> 
> 
>>> You don't need to do it with BGP, someone on the same shared
>>> medium can easily hijack your TCP connection without having to
>>> touch the DNS.
>> 
>> But then the DANE record without DNSSEC can also be forged,
>> because the attacker can see/modify the DNS packets. So its is not
>> a good example of DANE without DNSSEC.
>> 
>> Paul
> 
> _______________________________________________ dane mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dane

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 22 Jun 2011 09:26:38 +0200

> private keys. Honestly, if that's the threat, DANE won't help either.

Please bear in mind that this was an example of situation where DANE
helps (a little, but still helps) even without DNSSEC.

> I guess you could claim that they could trick a CA into a misissue, but

There's no government Pakistani CA?  I would expect one in my browser :)

> attacking a DNS server hosting an unsigned zone.

Oh, yes, it's much easier to do.  You don't have to hack anything.
Poorly configured upstream is still common and all you need to do is to
send proper BGP update.  Otherwise why would folks talk about RPKI again
and again for some years now (applies to RIPE meetings) :).

O.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 22 Jun 2011 09:30:57 +0200

> Oh, and BGP attacks can be done without noticable side effects, having been on a test network where such an attack was done.

http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf

In fact the attack is very smart if done right and cannot be detected
from within hijacked IP space (because your router prevents the AS path
loops).

O.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Jun 2011 08:18:53 -0400

Again, the issue is not whether attackers could make attacks without major
collateral damage, it is whether they would choose to do so.

So far the evidence is that collateral damage is not a concern.

On Wed, Jun 22, 2011 at 3:30 AM, Ondřej Surý <[email-masked]> wrote:

> > Oh, and BGP attacks can be done without noticable side effects, having
> been on a test network where such an attack was done.
>
>

---

From: "Hill, Brad" <[email-masked]>
Date: Wed, 22 Jun 2011 12:11:58 -0600

Not to encourage the use of DANE without DNSSEC, but there are more common and obvious scenarios that “look like” this attack.

Split-tunnel VPNs (selected traffic over VPN, remainder over untrusted interface) are increasingly common, and are increasingly “always on”.   “DirectConnect” in Win7 is such a system.

In such configurations, it’s entirely likely (coffee-shop attack) that an attacker will be a Dolev-Yao class MitM between Alice and Bob, and Alice and public, well-known CAs, but not between Alice and her DNS, which is on the same medium but IPSec or otherwise protected, or between Alice’s DNS and Bob’s DNS which is on a different medium.

-Brad

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Wednesday, June 22, 2011 5:19 AM
To: Ondřej Surý
Cc: [email-masked]
Subject: Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New Version Notification for draft-ietf-dane-use-cases-03.txt)

Again, the issue is not whether attackers could make attacks without major collateral damage, it is whether they would choose to do so.

On Wed, Jun 22, 2011 at 3:30 AM, Ondřej Surý <[email-masked]<mailto:[email-masked]>> wrote:

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]<mailto:[email-masked]>    http://nic.cz/
 tel:+420.222745110<tel:%2B420.222745110>       fax:+420.222745112<tel:%2B420.222745112>
 -------------------------------------------
_______________________________________________
dane mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dane

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Jun 2011 15:28:01 -0400

Good point, it is important to distinguish between 'DANE + DNSSEC' and DANE
+ DNS Security'.

DNS Security is likely to be necessary to provide useful security in DANE.
DNSSEC is only one way that may be achieved, it is not the only way.

On Wed, Jun 22, 2011 at 2:11 PM, Hill, Brad <[email-masked]> wrote:

> Not to encourage the use of DANE without DNSSEC, but there are more common
> and obvious scenarios that "look like" this attack.  ****
>
> ** **
>
> Split-tunnel VPNs (selected traffic over VPN, remainder over untrusted
> interface) are increasingly common, and are increasingly "always on".
>   "DirectConnect" in Win7 is such a system.****
>
> ** **
>
> In such configurations, it's entirely likely (coffee-shop attack) that an
> attacker will be a Dolev-Yao class MitM between Alice and Bob, and Alice and
> public, well-known CAs, but not between Alice and her DNS, which is on the
> same medium but IPSec or otherwise protected, or between Alice's DNS and
> Bob's DNS which is on a different medium.****
>
> ** **
>
> -Brad****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Phillip Hallam-Baker
> *Sent:* Wednesday, June 22, 2011 5:19 AM
> *To:* Ondřej Surý
> *Cc:* [email-masked]
> *Subject:* Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New
> Version Notification for draft-ietf-dane-use-cases-03.txt)****
>
> ** **
>
> collateral damage, it is whether they would choose to do so.****
>
> ** **
>
> So far the evidence is that collateral damage is not a concern.****
>
> ** **
>
> On Wed, Jun 22, 2011 at 3:30 AM, Ondřej Surý <[email-masked]> wrote:**
> **
>
> https://www.ietf.org/mailman/listinfo/dane****
>
>
>
>
> --
> Website: http://hallambaker.com/****
>

---

From: Matt DeMoss <[email-masked]>
Date: Wed, 22 Jun 2011 16:28:48 -0400

DirectAccess looks IPSec-based:
http://www.microsoft.com/windows/enterprise/products/windows-7/features.aspx#directaccess

Does anyone know of any ISPs or public services offering IPSec + DNS?

It might be simpler for users with a legacy OS to support.

2011/6/22 Phillip Hallam-Baker <[email-masked]>:
>> and obvious scenarios that "look like" this attack.
>>
>>
>>
>>   "DirectConnect" in Win7 is such a system.
>>
>>
>>
>> Bob's DNS which is on a different medium.
>>
>>
>>
>> -Brad
>>
>>
>>
>> Phillip Hallam-Baker
>> Subject: Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New
>> Version Notification for draft-ietf-dane-use-cases-03.txt)
>>
>>
>>

---

From: "Hill, Brad" <[email-masked]>
Date: Wed, 22 Jun 2011 14:50:07 -0600

Re: 1) yes, it is IPv6 over IPv4 + IPSec

Re: 2)  I am not.  However, considering that DNS + Certificate Based IPSec is available even on WinXP, it could be a start at tackling the last mile problem for legacy OSs.  You'd have to disable DHCP-advertised DNS servers, which could break access to some local resources, but I bet that would affect only a very tiny % of home users.   Breaking laptops with legacy OSs in captive portal scenarios is a bigger concern, but that can probably be addressed with a patch to the browser, not the OS.

-----Original Message-----
From: Matt DeMoss [mailto:[email-masked]] 
Sent: Wednesday, June 22, 2011 1:29 PM
To: Phillip Hallam-Baker
Cc: Hill, Brad; [email-masked]
Subject: Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New Version Notification for draft-ietf-dane-use-cases-03.txt)

2011/6/22 Phillip Hallam-Baker <[email-masked]>:
>> Not to encourage the use of DANE without DNSSEC, but there are more 
>> common and obvious scenarios that "look like" this attack.
>>
>>
>>
>> In such configurations, it's entirely likely (coffee-shop attack) 
>> that an attacker will be a Dolev-Yao class MitM between Alice and 
>> Bob, and Alice and public, well-known CAs, but not between Alice and 
>> her DNS, which is on the same medium but IPSec or otherwise 
>> protected, or between Alice's DNS and Bob's DNS which is on a different medium.
>>
>>
>>
>> -Brad
>>
>>
>>
>> Subject: Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: 
>> New Version Notification for draft-ietf-dane-use-cases-03.txt)
>>
>>
>>
>> Again, the issue is not whether attackers could make attacks without 
>> major collateral damage, it is whether they would choose to do so.
>>
>>
>>
>> > Oh, and BGP attacks can be done without noticable side effects, 
>> > having been on a test network where such an attack was done.
>>
>>
>> from within hijacked IP space (because your router prevents the AS 
>> path loops).
>>
>> O.
>> --
>>  Ondřej Surý

---

From: Stephen Kent <[email-masked]>
Date: Wed, 22 Jun 2011 16:53:11 -0400

At 9:30 AM +0200 6/22/11, OndÞej Sur˜ wrote:
>>  Oh, and BGP attacks can be done without 
>>noticable side effects, having been on a test 
>>network where such an attack was done.
>

Targets of the attacks will not notice it, but 
other observers will, in general.
The issue here is that an attacker cannot know, 
with high certainty, which other ASes may engage 
in monitoring BGP data, and if one tries to list 
all such ASes, the path will become very long, 
thus less attractive, and not suitable for 
traffic diversion. Note that IDR has approved an 
I-D that deprecates AS sets, so
one cannot game the system by putting the AS #'s 
of potential monitoring sites into an AS set, to 
avoid making the path longer :-). So, in general, 
an attack of this sort is not really invisible.

Steve

---

From: Martin Rex <[email-masked]>
Date: Fri, 24 Jun 2011 10:42:45 +0200 (MEST)

Richard L. Barnes wrote:
> I added the paragraph you note to more correctly describe the impact
> of using DANE without DNSSEC, as you, Jim, and Jeff all noted:
> minor) effect of using DANE without DNSSEC?

Excuse me while I panic (about this potentially ambiguos wording).

DANE without DNSSEC has value infinitesimal close zero at best in some
cases adds significant complexity and has a serious potential to harm
by confusing or misleading implementors and consumers.

In general, the information conveyed could be used for two significantly
distinct purposes:

  (1) positive confirmation that a server certificate should be considered
      valid

  (2) negative indication that a server certificate should be considered
      invalid for that server

I see (1) without DNSSEC as a real security problem creating a false
sense of security

And I also see (2) without DNSSEC as a security problem, because it
means creating interop problems based on a vague hunch that may have
been crafted by an attacker.  I don't think that PKIX suggest that
you should honour revocations on CRLs where the CRL signature is
missing or signature verification fails for whatever reason, and
I really don't see why restriction management through DANE should
be any different -- in particular when the server certificate
was signed under a CA from the traditional "TLS X.509 PKI".

And while we're fighting with the details, we probably should not
forget the bigger picture.  There seems to be the notion (that I share)
that when it is about average Human Users using Web Browsers,
successfully completing the TLS handshake even when the server endpoint
identification fails might often be preferable than the alternative,
that a determined user retries entirely without HTTPS.

If the reference identifier for an HTTPS request is not from a 
locally trusted source (which applies to 95% of the requests already
today, and will apply to 99.99% of the requests once search engines
are used via HTTPS exclusively), so the security value of the server
endpoint identification may questionable anyway.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Jun 2011 07:52:10 -0400

DANE without DNSSEC can be 100% secure.

The question is whether DANE can be secure without SOME form of DNS
authentication. The protocol by which that is implemented in the relying
party is a very different matter.

This is a standards process and it is pretty important to be precise on such
matters.

For embedded systems, DANE might well be of most utility as a means of
offloading PKI processing from the endpoint device.

Yeah, I know about the end-to-end security principle. I have discussed it at
length with Dave Clark and others from that era. What most people think is
the end to end principle is not what they proposed or described in their
papers.

---

From: Martin Rex <[email-masked]>
Date: Fri, 24 Jun 2011 17:24:40 +0200 (MEST)

> DNSSEC is only one way that may be achieved, it is not the only way.

What you really need is data end-to-end data integrity protection
plus data originiator authentication of the TLSA record from the
responsible DNS admin to the TLS client that performs the server
endpoint identification.

It would be foolish to infer from any small intermediate
hop-to-hop link going through a protected tunnel (like IPsec),
that this makes the lack of security of unsigned TLSA records
non-marginally less insecure / less dangerous.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 24 Jun 2011 23:20:52 +0200 (MEST)

Hill, Brad wrote:
> Re: 2)  I am not.  However, considering that DNS + Certificate Based
> IPSec is available even on WinXP, it could be a start at tackling the
> last mile problem for legacy OSs.  You'd have to disable DHCP-advertised
> DNS servers, which could break access to some local resources, but I bet
> that would affect only a very tiny % of home users.   Breaking laptops
> with legacy OSs in captive portal scenarios is a bigger concern,
> but that can probably be addressed with a patch to the browser, not the OS.

Captive portals break everything except web browser anyway,
so improving the browser captive-portal awareness, maybe hinting the
user through chrome indicators, might be a way forward on this one.

That probably wont work for MSIE on WinXP/XP-64.  Since Microsoft
seems to have mostly abandoned SChannel&CryptoAPI improvements for XP,
you might be better of with Firefox, Opera or Google Chrome 
on that platform anyway (TLS AES ciphersuites, full SHA-2, SNI,
details about TLS errors).

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Jun 2011 20:56:36 -0400

You have no idea what my application constraints are and thus you are not
qualified to give an opinion on what security model is appropriate for my
application.

Aside from my work for Comodo, I have for many years been working on the
problem of how to establish a security model for embedded devices. I don't
want to be configuring PKI in every lightbulb I deploy thank very much.
Deployment has to be completely automatic. Anything more than scanning a
device for a barcode is unacceptable.

[Ob Disclosure: I have pending patent applications on how to deploy crypto
in lightbulbs and fully reserve my rights etc.]

>From the specification point of view it should be sufficient to state that
the DNS responses must be trustworthy in order for the DANE key to be
considered trustworthy. Trying to do anything more is counterproductive.