Subject: [dane] Behavior in the face of no answer?

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 May 2012 14:55:24 -0700

I've been reading -20 and I'm not sure I understand the behavior that section
4.1 is supposed to say. Consider the following case:

I am trying to connect for the first time to https://www.example.com/,
which is signed. I go to retrieve the TLSA record, but when I do so,
the request times out. What do I do? There seem to be two options:

(a) Treat this as a hard failure and abort the connection.
(b) Treat this as if I have an empty TLSA response and continue with ordinary
TLS.

I claim that the right response from a security perspective is clearly (a): hard
fail. If you agree with me, then jump to "2. DOCUMENT TEXT" below. If not, keep
reading.

1. SECURITY ANALYSIS
The basic security setting in which CA constraints and service certificate
constraints are useful is one in which:

(a) The attacker has a valid certificate for the target domain, but not
the same as the certificate issued to the real server.
(b) The attacker has enough control of the network to get the victim
to connect to his server.

Generally, (b) means that the attacker is on-path to the client or the
server.

What makes DANE work is that it provides an independent cryptographically
verifiable check on the server certificate, thus excluding the attacker's
certificate. Even if the attacker can force traffic to him, then, the
certificate
won't be acceptable. If the attacker can force you to ignore the
information in DANE, then DANE offers minimal security guarantees.
If clients treat TLSA RR requests without responses (i.e., timeouts) as
if they were empty TLSA responses and continue with TLS as usual,
then any attacker who can block DNS responses (i.e., anyone who
is on-path to the victim, at least) can downgrade you to ordinary TLS.
So, I think it follows that non-responses (or SERVFAILS or any other
resolver error) must be treated as hard failures and cause aborts.

Note that the security context for DANE is different from
that of many DNS contexts, because in many such contexts,
non-response means you just don't resolve so you fail hard
anyway. But here, you fail to a weaker security position.

2. DOCUMENT TEXT
As I said above, I find the document kind of hard to read on this point.
S 4.1 refers to the RFC 4033 definitions and says that Bogus must
be hard-failed and that Insecure and Indeterminate must be treated
as if there were empty TLSA sets and you continue with TLS. So,
the question is whether non-response is Bogus or not. Here's
what 4033 says (http://tools.ietf.org/html/rfc4033#section-5)

 Bogus: The validating resolver has a trust anchor and a secure
      delegation indicating that subsidiary data is signed, but the
      response fails to validate for some reason: missing signatures,
      expired signatures, signatures with unsupported algorithms, data
      missing that the relevant NSEC RR says should be present, and so
      forth.

But in this case we don't have an invalid response, but instead a
non-response, so its not clear to me this falls into Bogus.

I'm not steeped in all the DNSSEC lore, so maybe there is a wide
agreement that nonresponse == bogus, but I don't get that clearly
out of the document. IMO, DANE would benefit from stating this
clearly.

-Ekr

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 3 May 2012 15:03:32 -0700

> fail. If you agree with me, then jump to "2. DOCUMENT TEXT" below. If not, keep

I agree: If A www.example.com resolves but the TLSA record times out (which is required for it to even reach this state in a benign or malicious form), Thats Bad (tm).

And I agree that the text should probably say "Treat nonresponsive as Bogus"

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 3 May 2012 15:20:47 -0700

> out of the document. IMO, DANE would benefit from stating this

From the earlier thread on this topic, I do not think there is "wide agreement" on what is and is not bogus. RFC 4033 and 4035 don't even agree about it.

Just because I like actual proposals for text, I believe what ekr is proposing is changing the current:
   o  If the DNSSEC validation state on the response to the request for
      the TLSA RRset is bogus, this MUST cause TLS not to be started or,
      if the TLS negotiation is already in progress, MUST cause the
      connection to be aborted.
to:
   o  If the DNSSEC validation state on the response to the request for
      the TLSA RRset is bogus, or if a response is not received or the
      response has no data, this MUST cause TLS not to be started or,
      if the TLS negotiation is already in progress, MUST cause the
      connection to be aborted.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 May 2012 18:37:49 -0400

> >From the earlier thread on this topic, I do not think there is "wide agreement" on what is and is not bogus. RFC 4033 and 4035 don't even agree about it.

I'm not sure I agree about this.  There is a possible difference in
4033 and 4035 on the meaning of "indeterminate", but I don't know
anyone who disagrees about "bogus": you ought to be able to validate
it, and for some reason, you can't.  Whatever the reason is, it's
bogus.

In this case, what you're talking about is "didn't get an answer".

>       connection to be aborted.

I get the analysis, but I feel rather uncomfortable with it.  If you
can't get responses from the DNS, surely you have other problems, to
begin with?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 3 May 2012 18:45:11 -0400 (EDT)

>      connection to be aborted.

I'm not sure I understand "has no data" in the context of DNSSEC with
a validation path (eg DS at the parent).

A response with no data, where there is a DNSSEC chain of trust, is
per definition bogus, as your response, even for 'no data' has to come
with the signed proof (NSEC/NSEC3)

I would just leave out "or the response has no data"

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 May 2012 15:44:57 -0700

> can't get responses from the DNS, surely you have other problems, to

Well, I absolutely have a problem.... I'm under active attack :)

However, if you choose option (a) and hard fail, then all the attacker
can do is create a failure. However, if you choose option (b) then
the attacker is able to cause you to connect to his server even
though the domain operator is trying to serve you a DNSSEC-signed
DANE record which tells you not to accept that cert (if you
could only get that record).

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 May 2012 15:49:19 -0700

> I would just leave out "or the response has no data"

I should probably mention that the analysis I am offering applies to any
other non-cryptographically verifiable error case, such as ICMP
errors, unverifiable SERVFAILs, etc. It's not clear to me if these
are all treated as Bogus but in this context I claim they must
be.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 May 2012 01:03:35 +0200 (MEST)

> are all treated as Bogus but in this context I claim they must

While I do agree with your analysis, I'm inclined to believe that
an unconditional hard-fail is as realistic for DANE as a hard-fail
is for OCSP response failures.  A non-marginal number of
TLS clients (WinXP using MSIE) is IMHO not even attempting OCSP
lookups at all.  And while I personally use FF 3.6, I have
OCSP purposely disabled and Certificate Patrol installed.

The difficulty with DNSSEC is that there are many firewalled networks
with either private DNS universes as well as NATed networks with DHCP and
local, DNSSEC-unaware recurive DNS resolvers, where a DANE hard-fail
approach might result in severe usability issues.

Is there any reliable data on the availability of 100% correctness
of DNSSEC records from places with full&transparent internet
connectivity to DNSSEC-capable recursive DNS resolvers?

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 3 May 2012 16:11:51 -0700

> a validation path (eg DS at the parent).

A response of SERVFAIL is a response, and it has no data in it.

> with the signed proof (NSEC/NSEC3)

That is a reasonable interpretation. Can you point to somewhere in 4033-5 where it says that clearly?

> I would just leave out "or the response has no data"

I would like to as well, but I think the text above reflects ekr's problem statement.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Thu, 3 May 2012 19:25:37 -0400 (EDT)

> connectivity to DNSSEC-capable recursive DNS resolvers?

I've been running my laptop with dnssec-trigger+unbound for a long
time now, and it is pretty good. There are some networks where DNS is
too broken, but the port 80 or tls443 fallback via unbound to trusted
fedoraproject.org resolvers is working remarkably well to even getadnssec
data on those networks - though at times the dns over tls is too slow
and the website gives an error.

However, some more automation and userfriendliness on the hotspot
handling is needed.

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 May 2012 22:00:27 -0400

> A response of SERVFAIL is a response, and it has no data in it.

Aha.  That's not what many people think of when they say "no data".
See section 1 of RFC 2308.  SERVFAIL is actually an error response.
Since SERVFAIL was sort of overloaded in DNSSEC, maybe you want to
call that out.  But what are you going to do with things like NOTIMP,
then?

But I think it still may be possible to get a validated NODATA
response, if you're a non-validating security-aware stub resolver and
your upstream decided not to send you the NSEC or NSEC3 record, but
sent you a response with AD=1, and you had a secure connection.  I
think this would be _stupid_, but I think it's protocol-legal.  (I am
not aware of any implementation that works this way.  Also, I haven't
checked this interpretation tonight, and am therefore prepared to be
wrong.)

> That is a reasonable interpretation. Can you point to somewhere in 4033-5 where it says that clearly?

As I say above, I think it depends on whether you think a response
with AD=1 and some assurances about the last hop qualify.  If you
don't, then Paul W is right.

A
-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 May 2012 22:10:44 -0400

> could only get that record).

No, I think I still don't understand.  Under (b), how can the attacker
get you to connect to "his server"?  The attacker can get you to
connect to some server and foil your attempt to use the TLSA-provided
credential, but how do you go to the wrong server?

You can't get the A or AAAA record if the attacker is fiddling with
the DNS, because that RRset will fail DNSSEC validation in the first
place.  Remember, we're already depending on DNSSEC.  If you _can_ get
the right address, then the problem is that you use the wrong
certificate (i.e. you fall back to the X.509 chain)?  Unless the X.509
chain is somehow subverted, though -- but how is that any more of a
danger than "compromised key in TLSA"?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 3 May 2012 19:14:33 -0700

> danger than "compromised key in TLSA"?

An IN-path adversary doesn't need to manipulate the A or AAAA records to get you to connect to their server.

Since the adversaries of concern are likely to be in-path, not just on-path, this is a serious concern and DANE when it can't get the record it MUST hard fail lest it be useless in the face on an in-path attacker, which is critical since the goal of all this cryptomagic is to deal with in-path attackers.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 May 2012 22:36:02 -0400

> An IN-path adversary doesn't need to manipulate the A or AAAA records to get you to connect to their server.

Ah, ok, so we're talking about someone who can both intercept and
redirect your connection to a target address and block DNS responses
from getting to you but who cannot re-engineer DNS responses for you
(obviously, because it'd fail at the root trust anchor).  Ok, now I
get it.

> Since the adversaries of concern are likely to be in-path, not just
> on-path, this is a serious concern and DANE when it can't get the
> record it MUST hard fail lest it be useless in the face on an
> in-path attacker, which is critical since the goal of all this
> cryptomagic is to deal with in-path attackers.

Surely this is a matter of local policy?  That is, it's probably a
pretty good idea if it fails, and if you know what you are doing you
probably want to say "fail if I can't get a TLSA response at all"; but
during deployment and roll-out (as someone already argued up-thread)
this is simply an unrealistic requirement: people are going to be
behind broken devices for some years now, and a protocol-required hard
fail requirement will either be ignored or else will delay deployment
until we complete upgrading the Internet.  I suggest while we are
waiting for that, we might want to work on DNS2 and TLS2.  If that's
not enough, I'm sure we can find some more windmills.  Alternatively,
we could just let people fall back to the infrastructure we have.

Note that there remain _plenty_ of DNS servers deployed in the wild
which, if you ask them for an RRTYPE they don't know about, spit up
with NOTIMP, SERVFAIL, and all manner of other crappy nonsense.  (We
were just having a bunfight about that over in SPFBIS a month or two
ago.)  Turning off TLS for anyone whose client knows about TLSA, but
who is trying to go to a service offered by someone employing a broken
DNS server like this, is not reasonable.

Speaking as an operator, I can tell you that if the protocol says
"hard fail if I don't get a TLSA answer", I will tell all my customers
not to use TLSA; the alternative is to make my customers mad at me the
day someone's connection from some crappy hotel network fails.  I'd
hate to be put in that position.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 May 2012 04:42:13 +0200 (MEST)

Andrew Sullivan wrote:
> with NOTIMP, SERVFAIL, and all manner of other crappy nonsense.

You seem to be unaware that returning SERVFAIL and more so NOTIMP
to requests for unknown RRTYPES is *PERFECTLY* conformant with
rfc1034/rfc1035.  So if anything is _broken_, its clients who can
not cope with such responses (as can be seen with the IPv6 dualstack
in Windows2003).

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 May 2012 20:18:41 -0700

> (obviously, because it'd fail at the root trust anchor).  Ok, now I

Yes, this seems like the only threat model of real concern here,
since if you are dealing with an attacker who cannot do this,
then there is no need to authenticate their cryptographic keys
at all: you can just use unauthenticated DH (or RSA) key
exchange.

> hate to be put in that position.

While I understand that these operational constraints, I'm having
trouble understanding what security benefit DANE offers if one behaves
as you suggest, since it seems the attacker can simply force you to
ignore any records that DANE provides.

Perhaps it would be useful to go back to first principles and ask
about the threat model. Can you describe a set of capabilities which
would allow successful attack on TLS in the current environment
but would not allow attack with DANE if TLSA nonresponse
for signed domains is treated as if there are verifiably no TLSA
records?

Thanks,
-Ekr

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 May 2012 07:20:42 -0400

> not cope with such responses (as can be seen with the IPv6 dualstack

I'm not unaware of this (although I think there is rather less
consensus about the correctness of those RCODE responses than you seem
to be suggesting).  I just think it's crappy.  RFC 3597 was published
in 2003.  There is no excuse any more for a server of any sort to be
incapable of handling unknown RRTYPEs.  I get the arguments about
provisioning systems, and I think they're real problems.  But by now,
if your _server_ doesn't handle unknown RRTYPEs it is plainly garbage,
and ought to be off the Net.

The fundamental problem, of course, is that people who are told to go
develop a DNS server in a weekend read RFC 1034 and RFC 1035 --
usually selectively, it appears to me -- and nothing else.  I wish I
had a good idea about what to do about this.  (That's all I'll say
about it here, though, because it's plainly off-topic.)

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 May 2012 07:29:22 -0400

> ignore any records that DANE provides.

As a client, you could be making a decision about what is more likely:

    1.  The attacker is able to undermine some CA.

    2.  The attacker is actually on-path and going to undermine my
    connection.  

In many cases, one might decide that (1) is more likely than (2), and
therefore decide that TLSA is a better thing to rely on.  During
deployment, however, one might be willing to think that (1) is less
likely than, "I am in a coffee shop, and these people bought crappy
infrastructure."  In that case, one might want to be able to fall back
to the way we actually do this today.  

I imagine that, over time, the tolerance for the broken infrastructure
will go down, and the fall-back decision will be less and less
attractive.  But if the protocol says that once a client supports
TLSA, any not-fully-modern DNS environment just means "no TLS", then
we will be promulgating a standard that cannot be deployed.  We might
as well not publish it.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 4 May 2012 05:12:54 -0700

>    2.  The attacker is actually on-path and going to undermine my

Since the attacker is often a government, its 1+2.  For a CA attack to be useful, you probably need 1+2, as without 2 you still need to be able to get the victim to go to your site which, even in the absence of DNSSEC, requires being an on-path attacker in most circumstances.

A CA attack without effectively 2 is useless.

This is why browser's have given up on the other solution for the bad CA problem: Certificate Revocation Lists.  Because an attacker can block the CRL check, and the CRL check is NOT mandatory (they are unreliable enough that its not treated as a hard fail), CRLs are useless for blocking attackers.

> we will be promulgating a standard that cannot be deployed.  We might

DNSSEC at all requires client validation, and client validation REQUIRES that the client be able to bypass the significant-probability-broken recursive resolver already.  DANE doesn't really add to that:  If the client can fetch DNSSEC signed records, TLSA won't be a problem.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 May 2012 09:08:46 -0400

On Fri, May 04, 2012 at 05:12:54AM -0700, Nicholas Weaver wrote:
> 
> DNSSEC at all requires client validation

No it does not.  You keep insisting that because you have in mind the
model of any DNS client in any network, but not every situation is
like that.  I personally think that end-point validation is the best
way to do things, but the protocol is written in such a way that it is
not required, and we can't make it so by wishing.

> , and client validation
> REQUIRES that the client be able to bypass the
> significant-probability-broken recursive resolver already.

Yes.

> DANE
> doesn't really add to that: If the client can fetch DNSSEC signed
> records, TLSA won't be a problem.

But I note that in my DNSSEC Trigger application, I have the ability
to turn it off -- and sometimes it disables itself.  This tells me
that the most-robust end-point validation tool we have already
concedes that it isn't perfect.  The proposal appears, AFAICT, to make
that known-bad path a critical dependency not just for TLSA, but for
doing TLS _at all_.  The way I read the proposal, if you can't get a
TLSA then you fail the TLS connection.  In some number of networks,
what you're arguing for is "no TLS, ever" for any TLSA-enabled
application.  Is that really the direction we want to go?  Because I
predict the result is going to be that everyone turns off TLSA in
their systems on the first day of failure, and then the protocol is dead.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 May 2012 06:48:20 -0700

>    2.  The attacker is actually on-path and going to undermine my

I'm confused by this answer: DANE (for the two constraints modes)
only offers security value if *both* of these things are true. If the
first is not true, then a PKIX certificate is sufficient to distinguish
between valid users and attackers and in the second is not true,
then even an attacker with an invalid certificate cannot get
your packts.

> to the way we actually do this today.

Again, this is logical, but as far as I can tell it obviates the security
provided by DANE. I'd like to repeat the question I asked in my
previous message: can you describe a set of attacker capabilities
which would be sufficient for an attacker to mount a successful
attack on TLS pre-DANE but would not post-DANE, provided
that clients react to TLSA non-response by falling back to pre-DANE
behavior?

Thanks,
-Ekr

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 4 May 2012 07:42:56 -0700

> This is why browser's have given up on the other solution for the bad CA problem: Certificate Revocation Lists.  Because an attacker can block the CRL check, and the CRL check is NOT mandatory (the…

For those not familiar with the context for the paragraph above:

http://www.imperialviolet.org/2012/02/05/crlsets.html

Chrome is abandoning the use of CRL lists for the browser, because of the "soft fail" nature, which means that CRLs only work when not under attack.  DANE for CA certificates with "fail open" is just the same as a CRL check.  And DANE effectively requires client-side validation.

Which means there are three cases:

A:  Client can't receive ANY DNSSEC at all when communicating directly with the network [1]

B:  Client can't receive ANY TLSA signed records...

C:  Client CAN receive valid DNSSEC and TLSA records but CAN'T get a TLSA (or NSEC/NSEC3 proof that it won't find one) for the site in question.

C clearly MUST be treated as an attack, and DANE MUST be fail closed in this case.

A and B are different.  It COULD be a broken network, or it could be an attack  (And based on Netalyzr, I think B is rare, its mostly A).  But an attacker can always make his attack look like A, so 'fail open' is clearly wrong.

So here's my proposal: Actually check the network for b0rkenness!

The browser, on startup, or when the local IP address changes, conducts the following test:

It checks, using three known sites with TLSA records (provided by the browser vendor, with deliberate redundancy to prevent a TLD outage from being a problem), to see if it can receive and validate a TLSA record using DNSSEC for at least one of the three sites.

If yes, any failure to fetch the proper TLSA record or NSEC proof results in immediate 'fail open' when TLSA records are not received, as it is case C.

If no, DANE goes into a "Fail Scary" mode, akin to how browsers treat self signed certificates:

The browser MUST notify the user that the network is broken: its not allowing the browser to fetch DNS records needed to authenticate connections.  The user MAY override it and disable DANE validation, but the user is on notice that:

1)  The network is not allowing secure communication
2)  Its the network's fault, so go blame your network kit

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 May 2012 10:44:26 -0400

> then even an attacker with an invalid certificate cannot get

Yes, of course.

Your proposal is that, if I have a TLSA-enabled client, I
automatically lose TLS support _for anything_ in the event I'm in a
network with poor DNS support.  I was trying to argue that there is
another sensible alternative: I could make a decision to allow TLSA
responses not to work in some cases, because I think it is more likely
that the network is broken than that (1) and (2) are both true.  But
I might in general not trust CAs, and think that (1) is more likely
that (2) most of the time, and therefore normally want to prefer
TLSA.  Therefore, I ought to be able to decide to proceed in the face
of the failure to get a TLSA record at all.

Perhaps one would argue, however, that this amounts to saying, "I need
to be able to turn TLSA off."  I could live with that.

I am still opposed to anything that says we have to treat some
reponses that are not DNSSEC-bogus "as bogus", because I think it
muddies the DNSSEC evaluation waters even more than they already are.
Could we come up with another way of saying this?  How about this:

    In the event that all DNS queries for the TLSA record time out, or
    return with RCODE 1 or RCODE 4-15, TLS MUST NOT be started or,
    if the TLS negotiation is already in progress, MUST cause the
    connection to be aborted.  Under these conditions, a user agent
    MUST disable TLSA queries in order to undertage a TLS connection.

Note that this does _not_ cause the connection to fail under the case
we usually call "NODATA".  The case I mentioned yesterday, where AD is
set and the upstream doesn't give you the DNSSEC data and you have a
NODATA response is, AFAICT, just a case where there is no TLSA RRset
and shouldn't result in TLS failure.  FWIW, I think the above is
probaby too strong, but as long as we have something expicitly telling
people that, if they thing DNS is broken where they are they need to
turn of TLSA processing (i.e. a clue to implementers that they need
this knob), I can live with it.

> that clients react to TLSA non-response by falling back to pre-DANE

No, and I never thought that was the point of TLSA.  I thought the
point of TLSA was to enable people to use TLS, provably securely
but without the X.509 PKI infrastructure, if they wanted to.
Usability enhancements are security improvements too, IMO.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 May 2012 08:10:40 -0700

> of the failure to get a TLSA record at all.

Again, I don't understand your reasoning here. It's not a matter of 1
*versus* 2. If you proceed in the face of no TLSA record, I claim you
might as well not do the TLSA check.

>    MUST disable TLSA queries in order to undertage a TLS connection.

I don't really see how to operationalize this in a client in a useful way.

> and shouldn't result in TLS failure.

But the problem is that this is indistinguishable from the case where there
*was* a TLSA RRSET and you have a network attacker.

>  FWIW, I think the above is

I'd rather not get bogged down in the exact RFC 2119 language and
discussion of what knobs must be provided just yet. But I do think it's
useful to think about this from the perspective of the implementor.
For convenience, consider the case of the browser. Currently, the
browser's algorithm is simple: check the PKIX cert and if it's valid,
connect and if not show a scary red dialog. [I'm ignoring cert pinning
for now.] And it's generally agreed that one should only proceed
past the scary dialog if either (a) you don't care who you are
connecting to, like in a captive network portal or (b) you are really
sure you are in a secure network environment.

Now, consider the perspective of an implementor who adds DANE
support for usages 0 and 1. The first arm of the decision, PKIX valid,
now becomes three branches.

- Verifiably no TLSA records via DNSSEC or Insecure/Indeterminate zone:
  continue with PKIX validation.
- Verifiable TLSA records via DNSSEC: PKIX validation plus the TLSA check
- Non-response: ???

Now, the implementor has three choices in this final arm:

1. Proceed with the TLS connection. (soft fail)
2. Show the scary red dialog. (hard fail)
3. Refuse to connect under any conditions (really hard fail, the way you
do with pinning).

I claim that if you do (1) you might as well not bother with the TLSA
check at all, since the attacker can just bypass it. I assume you are
saying that one should do (2)? I think that's fine, as long as that's
also how you treat other TLSA failures, such as certs which aren't
in the TLSA list. If you treat this case preferentially, then attackers
will just simulate it.

Important note: I am not claiming that route (2) is good. If the
infrastructure is indeed as bad as you say, then users will find
themselves having to click through all the time and DANE is likely
not a useful signal.

> Usability enhancements are security improvements too, IMO.

TLSA includes two types of records:

1. Records which constrain the set of valid certificates but which still
require PKIX validation of the certificate (Usages 0 and 1).
2. Records which allow a client to use keying material which would
otherwise not pass PKIX validation (Usages 2 and 3).

What we're talking about here is Usages 0 and 1. I agree that the
analysis is different for usages 2 and 3.

-Ekr

---

From: Tom Ritter <[email-masked]>
Date: Fri, 4 May 2012 11:37:53 -0400

> It checks, using three known sites with TLSA records (provided by the browser vendor, with deliberate redundancy to prevent a TLD outage from being a problem), to see if it can receive and validate…

I don't think will actually help anything.  The attacker will just
block ALL TLSA records, not just for the target site he intends to
MITM.

Fail-close vs Fail-open when you can't get the TLSA record is OCSP
hard-fail vs soft-fail all over again.  I'd like Hard fail, but no
matter what we say, no browser will implement it.  If mandating
hard-fail in the spec causes clients to NOT implement DANE (as opposed
to just ignoring the recommendation) - I don't think we should do it.

HOWEVER!  WE HAVE A SOLUTION!  Actually, Chrome has a solution, and it
already works. http://www.imperialviolet.org/2011/06/16/dnssecchrome.html
DNSSEC Stapled Certificates

Put the DNSSEC chain *in the TLS certificate*.  This won't be blocked
by a MITM, and if you receive a self-signed certificate with a valid
TLSA chain in it, it's valid.  The TLSA chain is signed, so it doesn't
matter _how_ you receive it, as long as the signatures all match up.

Now this is a solution to the broader problem of delivering the TLSA
record to the client for verification, it's not a solution to
hard-fail vs soft-fail for TLSA queries. (I already gave my opinion on
that.)  And it's clear that this solution should not go into this RFC,
and that we need to either:

 - recommend soft-fail (bad)
 - recommend hard-fail (potentially bad, if it stops adoption)
 - punt, and let everyone do what they're going to do already: soft-fail

But this idea, which I think could turn into a RFC fairly easily, get
implemented in browsers in relatively short order, and get implemented
in webservers in considerably longer order - can solve the general
problem.

-tom

---

From: Warren Kumari <[email-masked]>
Date: Fri, 4 May 2012 11:57:11 -0400

<chair hat>

Hi there all,

First off, thanks for keeping this civil. This is an important issue (and one that we've skirted around in the past..), lets try and prevent it becoming contentions as well :-)

So, it seems (to me!) that both Eric and Andrew have perfectly sane and defendable positions, but diametrically opposed.
This is (IMO) something that we are going to have to resolve before this is published, so I am asking our AD to consider holding off...

</chair hat> 

So, how does the WG feel about a knob that can be turned to choose behavior? Something that can be set for the less secure manner for now, and then (the default) changed later? 
Security conscious / at risk folk would be able to turn the knob now...

Worst idea ever?

W

On May 4, 2012, at 11:10 AM, Eric Rescorla wrote:

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 May 2012 08:56:39 -0700

> to just ignoring the recommendation) - I don't think we should do it.

But then what is the security value of the restrictive DANE usages?

> matter _how_ you receive it, as long as the signatures all match up.

This is only useful for usages 2 and 3 (the additive ones). In the case
of usages 0 and 1, the attacker is delivering his own certificate and
just won't send any TLSA records.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 May 2012 09:08:53 -0700

> Security conscious / at risk folk would be able to turn the knob now...

Before we discuss how to proceed, I think it would be useful to get agreement
on the security analysis. I claim that for Usages 0 and 1, treating
TLSA non-response
as if no TLSA records exist means that DANE adds minmal/no security
value for those
usages. If people disagree with that, I would like to hear someone describe
a threat model under which DANE with this policy would prevent attacks
that would otherwise succeed.

Until we agree on that, I don't think there's much point in discussing what the
document ought to say.

-Ekr

---

From: Adam Langley <[email-masked]>
Date: Fri, 4 May 2012 12:18:20 -0400

On Fri, May 4, 2012 at 12:08 PM, Eric Rescorla <[email-masked]> wrote:
> usages.

I believe that you're completely correct.

Browsers are not going to enable DANE hard fail in the short or medium
term because of the fraction of clients that have broken DNS and can't
fetch the records.

Therefore, browsers are not going to see a security benefit from DANE.
The DNSSEC stapled certificates that Tom points to are addressing a
very different use case: people who would otherwise use self-signed
certificates and who get annoyed that we throw errors for them.

However, browsers are not the world. Other clients, which may benefit
from a smaller, more controlled, deployment may be able to enforce
DANE hard-fail and see security benefits.

I would personally suggest that the spec requires hard fail, or at
least discusses the fact that, without hard-fail, the security
benefits are moot. Implementations frequently ignore requirements in
specs, but rarely add to them!

Cheers

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 May 2012 09:32:32 -0700

> specs, but rarely add to them!

My preference is that the spec discuss the issue, propose hard-fail as an option, and explain that without hard-fail the benefits for usage 0 and 1 can be circumvented but that the client is no worse off than without DANE. It's important to emphasize that this is about usage 0 and 1, and that a different security analysis applies to types 2 and 3 (well, 3 certainly; I need to think about 2).

I would prefer that we not require hard fail while assuming some implementers will not follow our requirement, since that leads to us being dishonest about what we expect. If we believe (as Adam says) that implementations ignore these types of requirements, let's be honest about that and let the implementer know what it means to ignore the suggested action.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 May 2012 12:53:15 -0400

On Fri, May 04, 2012 at 09:32:32AM -0700, Paul Hoffman wrote:
> 
> My preference is that the spec discuss the issue, propose hard-fail
> as an option, and explain that without hard-fail the benefits for
> usage 0 and 1 can be circumvented but that the client is no worse
> off than without DANE. It's important to emphasize that this is
> about usage 0 and 1, and that a different security analysis applies
> to types 2 and 3 (well, 3 certainly; I need to think about 2).

I agree with this.

> I would prefer that we not require hard fail while assuming some
> implementers will not follow our requirement,

I also strongly agree with this.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 May 2012 12:55:12 -0400

> *was* a TLSA RRSET and you have a network attacker.

It certainly isn't.  If you're depending on your upstream validator,
you need to trust it.  If you don't trust it, don't depend on the
upstream, in which case you're not going to offload validation.

A NODATA answer is _not_ just like "no response at all" if the answer
passed validation, and if it didn't pass the the specification already
covers this case.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 May 2012 19:24:36 +0200 (MEST)

Andrew Sullivan wrote:
> Martin Rex wrote:
> to be suggesting).  I just think it's crappy.

Not at all crappy, it's perfectly valid.

If you look at this:

http://tools.ietf.org/html/std13

that is an IETF "Full Standard" (and the above does not even mention
any updates at all).

>
> RFC 3597 was published in 2003.

So what?  That seems to be a totally irrelevant RFC.  

The document itself is only proposed, so it pales in comparison
to STD, but what's the real issue, there is not the slightest sign
that it has anything to do with STD13!  There is neither meta-data
nor any mentioning in the Abstract/Intro that this document is
supposed to apply to STD13 (rather than being just another optional
and irrelevant extension).

>
> There is no excuse any more for a server of any sort to be
> incapable of handling unknown RRTYPEs.

Just the opposite.  According to the IETF process, STD13 clearly
suggests that NOTIMP is the most reasonable response to a request
for an unknown RRTYPE.

>
> I get the arguments about

I don't know what documents are looking at, but STD13 is pretty clear,
your _clients_ are the ones that are broken.

> develop a DNS server in a weekend read RFC 1034 and RFC 1035 --

= STD13.  That is what standards at maturity level "full standard"
were made for.

> about it here, though, because it's plainly off-topic.)

Follow the IETF process.

So first of all, the same housekeeping that was done with

   821 -> 2821 -> 5321
   822 -> 2822 -> 5322

will have to be done for DNS, i.e. all real(!!) updates&changes that
are relevant to the base DNS standard will have to be merged into
a new set of 2-3 documents and "completely replace" STD13.

After that is accomplished, it will take 10-15 years for the
installed base of STD13 to die of age or get updated.

-Martin

---

From: Paul Wouters <[email-masked]>
Date: Fri, 4 May 2012 13:39:19 -0400 (EDT)

> to the way we actually do this today.

Where "fall back" in this case means, "click OK to the 10 certificate
warnings popping up from my facebook, twitter, encrypted.google.com and
other tabs" that just got MITM's to the coffee shop "press ok to
continue" portal page on a self signed cert on port 443.

That scenario is lost with PKIX as well as TLSA.

>From the protocol point of view, this should be a hard fail. However,
I do not believe in the soft vs hard fail distinction in browsers, and
those vendors seem to implement things more in a scale from silently
ignore to adding more red colour depending on how hard they believe
the failure to be.

Overriding a protocol hard fail is really the overriding local policy
of the application. But in the protocol specification, hard fail should
mean hard fail, and it should not take that local policy into account.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 4 May 2012 13:41:27 -0400 (EDT)

> This is why browser's have given up on the other solution for the bad CA problem: Certificate Revocation Lists.  Because an attacker can block the CRL check, and the CRL check is NOT mandatory (the…

But CRLs are cached, so once you got it from a working connection, it
does offer some protection once you move into a hostile network and
you already have the cached CRL of the cert they try to use on you.

> DNSSEC at all requires client validation, and client validation REQUIRES that the client be able to bypass the significant-probability-broken recursive resolver already.  DANE doesn't really add to…

Unless specifically targetted and filtered (or not understood)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 4 May 2012 13:43:05 -0400 (EDT)

On Fri, 4 May 2012, Andrew Sullivan wrote:

> to turn it off -- and sometimes it disables itself.

It should never disable itself. Please try to reproduce with verbosity
turned on full in dnssec-trigger.conf and get us the output.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 4 May 2012 13:46:17 -0400 (EDT)

> Security conscious / at risk folk would be able to turn the knob now...

The knob is already there and called "local policy override"

And we'll have this discussion all over again for HASTLS, if that ever
proceeds.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 May 2012 11:59:25 -0700

> passed validation, and if it didn't pass the the specification already

I'm sorry, I think we're still talking past each other. If you treat
non-response
the same way as you treat a validated empty RRSET, then a network
attacker can get the same effect (i.e., no DANE checks) by simple
suppressing DNS resolution.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 May 2012 21:02:11 +0200 (MEST)

Eric Rescorla wrote:
> 
> Before we discuss how to proceed, I think it would be useful to get
> agreement on the security analysis.

Analysis (about what the attacker could do) is correct, but ...

>
> I claim that for Usages 0 and 1, treating TLSA non-response as if no
> TLSA records exist means that DANE adds minmal/no security value for
> those usages. If people disagree with that,

I do not fully agree to the conclusion.
With the exact same logic, when comparing DV-certs to EV-certs, you
could say that EV-certs add minimal/no security value.

I believe it is OK for DANE to be a building block for security,
rather than a security silver bullet (something I believe doesn't exist).

What value is offered depends entirely on whether you use that extra
information of entirely ignore it.  If it's ignored, then there is
no value, and that should not come as a surprise.

Web Browsers provide visual cues to differentiate DV/EV-certs (since
very few users look at the certificate details. 

Another possibility (previously mentioned) would be to get rid of
the PKIX-style Alzheimer approach to security and memorize characteristics
from previous encounters with peers an reuse those memories on
re-encounters, similar to how evolution taught mammals develop
trust relationships.

Any new IETF protocol that treats smooth migration of the
installed base as serious and important as IPv6 does it for users
of IPv4, will see a similarly rapid migration&adoption of the
technology by consumers that IPv6 has been seeing over the last decade.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 May 2012 12:05:19 -0700

> could say that EV-certs add minimal/no security value.

It's precisely for this reason that EV certs add minimal security value.

> very few users look at the certificate details.

There's very little evidence that users treat these indicia differently.
Adding yet another indicator seems to make the cognitive overload
problem even worse.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 May 2012 12:12:37 -0700

> It's precisely for this reason that EV certs add minimal security value.

I should mention that there are potentially settings in which they add
more security value, e.g., EV-lock. Also, at least in principle they
allow a user to have some trust in the organization name as
opposed to the DN, which is not something that DANE provides.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 May 2012 21:33:41 +0200 (MEST)

Eric Rescorla wrote:
> 
> Martin Rex <[email-masked]> wrote:
> >
> > Eric Rescorla wrote:
> >>

Browsers memorize megabytes of useless stuff, but seem to have
difficulties memorizing a few kilobytes of useful and important
stuff.

Currently, the value of EV-certs is vitally dependent on cooperation
of the human brain of the user at the TLS client to either react
to the visual cues or look at & perform plausibility checks on the
additionally vetted information, comparing it to the original intent.

Browsers (and to some extent TLS clients in general) should be able
to perform some of that all by themselves rather than "outsourcing"
it to users, since users quickly become bored by such activity
and start cheating/ignoring.

As long as the majority of Web-sites & their users get to login-pages
by clicking a URL on a page received through HTTP rather than HTTPS,
the hard-fail instead of a soft-fail DANE discussion does not add
value, but instead might turn out to be a coffin nail.

-Martin

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 May 2012 15:44:35 -0400

> suppressing DNS resolution.

I likely wasn't clear enough.  I was not advocating treating
non-response that way.   I was saying that "non-response" and "an
empty answer" (i.e. an empty answer section in the DNS response)
are not to be treated the same; somewhere else in the discussion it
seemed that they were being collapsed.  

I believe it is possible to get a useful response that has nothing in
the Answer, Authority, and Additional sections only if you trust your
upstream, you trust the connection somehow, you set CD=0, and you get
AD=1 on the response.  In that case, I believe it is a legitimate
NODATA response (though I don't know of any implementation that works
this way), and it is validated.  It means there is no TLSA record at
that owner name, just like if you used CD=1 and got back an answer
with (say) an NSEC3 record in the Authority.  If I sound tentative,
it's because I haven't in the last 48 hours walked through the
relevant RFCs in order to be perfectly sure that this is what a NODATA
response looks like for a non-validated security-aware stub relying on
upstream validation.  But I think this is right.

In any case, if all of those necessary conditions aren't satisfied,
then the answer is either bogus or indeterminate and you should react
accordingly.  This is already covered in the existing draft.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 May 2012 12:48:15 -0700

> accordingly.  This is already covered in the existing draft.

Now I'm really confused. What do you think the draft says about "no response"

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Fri, 4 May 2012 16:03:54 -0400 (EDT)

On Fri, 4 May 2012, Andrew Sullivan wrote:

> this way), and it is validated.

How many months until Rogers (or OpenDNS, or...) starts spitting out AD=1
on their DNS rewriting schemes?

>From RFC3655:

    The AD bit SHOULD be used by the local resolver if and only if it has
    been explicitly configured to trust the remote resolver.  The AD bit
    SHOULD be ignored when the recursive name server is not trusted.

So your scenario really only happens when you bring up a VPN and connect
back to a trusted network. At that point, you can trust the AD bit, but
you also no longer have DNS breakage/filtering happening, so the point
is moot.

The other scenario is an application talking to the local resolver that
returns the AD bit, which just moves the DNS connectivity problem from the
application to the local resolver, but runs into the same hard/soft
fail issue, except the browser knows even less about the reasons for
the failure or success, and can give less feedback to the user to make
an educated guess as to the severity of the failure to be hard or soft.

Regardless, all of this is not DANE specific, and IMHO does not belong
in the DANE document.

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 May 2012 16:10:35 -0400

> Now I'm really confused. What do you think the draft says about "no response"

Nothing, at the moment.  You've made this point quite clear.  I
thought that's what we were discussing.

The draft currently _does_ have something to say about no _answer_
-- i.e. a NODATA DNS response.  What that means is that there isn't a
TLSA RR at that owner name, so you should use something else (probably
traditional TLS processing).  

Best,

a

-- 
Andrew Sullivan
[email-masked]

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 4 May 2012 13:12:12 -0700

> on their DNS rewriting schemes?

Xerocole already says "Just do it"...

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 May 2012 16:21:27 -0400

> on their DNS rewriting schemes?

I wasn't arguing that you should trust it, or that this is a good
state of affairs.  But we can't write the specification such that it
is incompatible with DNSSEC as specified, however little I personally
like the AD bit.

> you also no longer have DNS breakage/filtering happening, so the point

As Martin Rex argues elsewhere in this thread, a NOTIMP response to an
RR you don't know is not obviously inconsistent with RFCs 1034 and
1035.  Ekr's position would cause a system that depended on
intermediate-resolver validation, the AD bit, and a resolver that can't
handle unknown RRTYPEs, to cause all TLS negotiation to fail for
TLSA-aware clients.  This isn't "will cause TLSA not to work", it's
"can't use TLS at all on that system".  I have no idea whether there
are such configurations in the wild, but they're pefectly acceptable
under the standards we have.  It seems to me, therefore, that one
needs to be able to turn off TLSA use under such circumstances, if
we're going to say that such failures must "fail hard".

Yes.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Fri, 4 May 2012 23:40:56 +0300

> Adding yet another indicator seems to make the cognitive overload

An informal, non-scientific survey of some of my coworkers revealed that about half hadn't noticed green indicators, some had, but had no idea what these were, and a few noticed that the company name was indicated. None knew that the CA was actually vouching for the company name being correct. These are people who work at a security vendor. I think you'd do worse in the general population.

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Fri, 4 May 2012 16:52:55 -0400 (EDT)

On Fri, 4 May 2012, Andrew Sullivan wrote:

> This isn't "will cause TLSA not to work", it's
> "can't use TLS at all on that system".

But you cannot tell the difference between maliciously "not supporting"
and "pretending to not support so you will not request TLSA".

> I have no idea whether there

These can certainly happen. But an application or device can then use
its own validating resolver. This only becomes a problem when there is
both a broken old DNS deployment, AND additional firewalling preventing
one from bypassing that old DNS deployment. I'm willing to call those
networks "broken by design", and I'm fine with hard failing. But I don't
have to man a support desk.

This does assume that if an application that wants to support TLSA would
have to have a validating resolver built in to fall back to, along with
a root key. Alternatively, the local policy could be that if generic
DNSSEC is failing (eg a query to the a root server for a root zone record
fails to come back with proper RRSIG/NSEC* records) that no attempts to
use TLSA are done. But that is a local policy decision, one that I would
override to hard fail (but my father probably would be ok with)

Paul

---

From: Yoav Nir <[email-masked]>
Date: Sat, 5 May 2012 00:02:33 +0300

> term because of the fraction of clients that have broken DNS and can't
<snip />
> specs, but rarely add to them!

I disagree. I would hate for this group to publish a spec with a MUST level requirement that we fully expect all browsers to ignore. At best this should be a SHOULD with an explanation that not doing this eliminates usages 0 and 1. 

I can think of a heuristic for this. Suppose we have to domain names, one with a valid TLSA record, the other without. The browser could query the DNS for a TLSA record for both of these, and if both answers are received, then TLSA works. In that case, a timeout can rightfully become a hard fail. If no response is received to either query, then either the DNS is broken or the attack is already going on. In that case the user should be warned with the likelier of the two - that the DNS seems to be broken, and certain kinds of attack are possible.

Yoav

---

From: Ondrej Mikle <[email-masked]>
Date: Sun, 06 May 2012 03:18:48 +0200

> I also strongly agree with this.

I also agree with the above points.

I'll chime in with some data: we've been collecting data (with Ralph Holz) on
behavior of various authoritative NS (about 15 RR types for each domain, with
DNSSEC enabled).

>From the ongoing scan, out of 70M currently finished .com domains, SERVFAILs
appeared for ~8.6M distinct domains. My interpretation of such high percentage
is that those are forgotten/unmaintained domains (for comparison, percentage for
.cz TLD is < 1%). We'll cross-check the failing answers against lists such as
Alexa top 1M (to see how "relevant" they are) and do a rescan of the failures.

>From the preliminary data it follows that no vendor of a TLS client would honor
hard-fail if it was a "MUST" (though I don't like the possible downgrade attacks).

Another goal of the scan is to find statistics on average/maximum size of
DNSSEC-stapled structure (as Jim Schaad asked -
https://www.ietf.org/mail-archive/web/dane/current/msg04694.html), which is
heavily influenced by number of zones traversed by CNAMEs/DNAMEs (ask away if
you're interested in other stats).

Ondrej Mikle

---

From: Warren Kumari <[email-masked]>
Date: Mon, 7 May 2012 10:46:28 -0400

> Xerocole already says "Just do it"...

Win!

W

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 7 May 2012 07:54:48 -0700

>> Xerocole already says "Just do it"...

For those overall interested in the business of DNS NXDOMAIN and other modifications, the outsourced companies, the ISPs, the profitability claims ($1-3 per customer per year), etc, our paper from last year covers this space.  I think I posted a note to other DNS groups last year, but I don't think I posted it here:

http://www.icir.org/christian/publications/2011-foci-dns.pdf

"Redirecting DNS For Ads and Profit"

This is also why I am so cynical about recursive resolver validation, rather than end-host validation, and assert that the recursive resolver should be considered an adversary.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 May 2012 08:01:56 -0700

> This is also why I am so cynical about recursive resolver validation, rather than end-host validation, and assert that the recursive resolver should be considered an adversary.

The current DANE spec explicitly allows both models. It would be great in the future for there to be more work done on end-host validation, but the lack of that work should not hinder people who can get benefit from DANE now.

--Paul Hoffman

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 7 May 2012 08:23:06 -0700

> The current DANE spec explicitly allows both models. It would be great in the future for there to be more work done on end-host validation, but the lack of that work should not hinder people who ca…

The cynic in me observes that without end-host validation, DANE is just a connectionless version of the existing browser Certificate Revocation List protocol:  A seatbelt which fails when you actually need it, but only works when you don't.  The only advantage is cacheability and a 1RTT interface when its cached.

In general there is very little benefit from storing cryptographic material in DNS without client-side validation.  I will argue absence client-side validation, the DNSSEC protection of such data, DANE included, is almost useless.

DNSSEC validation on the recursive resolver in lieu of end-host validation for cryptographic material is only useful under the following conditions:

A) The adversary is only between the recursive resolver and the Internet, but can never be between the victim and the recursive resolver.

B) The recursive resolver validates and is a system that can actually be considered trustworthy.

C) The protocol is "fail hard" on SERVFAIL or other 'unable to get the key material in a DNS fetch'.

Since A is a questionable assumption, B is ALMOST nonexistent if you aren't a Comcast customer, and it seems that the DANE community doesn't believe in C despite a host of evidence as to why they should, that DANE even considers recursive resolver validation a deployment model is downright silly to me.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 May 2012 08:43:11 -0700

If you believe that we should only standardize the perfect, not the good, that's fine. Others seek to standardize the good which can be upgraded to the perfect with no flag days, which is what is proposed here.

--Paul Hoffman

---

From: Adam Langley <[email-masked]>
Date: Mon, 7 May 2012 10:47:00 -0400

> you're interested in other stats).

My (very rough) rule of thumb is that it's ~2.5KB.

Getting from . to a TLD is ~600 bytes. The TLDs tend to have a two key
structure (I assume because updating DS records at the root is very
hard?), and that's about another ~1200 bytes. Most of the time I
assume that the record is sitting one zone above the TLD and that the
zone only has a single key. So that ends up being about 2000-2500
bytes in total.

Cheers

AGL

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 7 May 2012 08:56:27 -0700

> If you believe that we should only standardize the perfect, not the good, that's fine. Others seek to standardize the good which can be upgraded to the perfect with no flag days, which is what is p…

No, I believe we should standardize the good.

If you wish to standardize the almost useless but can be upgraded to good with no flag day, but which upgrading to good requires replacing or bypassing a significant amount of brokenness on the Internet, say so.

Because DANE without nearly-hard-fail [1] on no data, not just BOGUS data, AND client-side validation, is no different that browser CRLs in terms of protection to the users in the face of an actual attack.

[1] namely, allow the user to bypass but scream bloody murder about it...

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 May 2012 12:08:24 -0400

On Mon, May 07, 2012 at 08:23:06AM -0700, Nicholas Weaver wrote:
> 
> The cynic in me observes that without end-host validation, DANE is
> just a connectionless version of the existing browser Certificate
> Revocation List protocol:

Not every browser is in a home or public network with an ISP's
corrupted resolver upstream.  Just because that is the main network
model you test doesn't make it the Internet, as I already pointed out
in this thread.

MSFT's main DNSSEC offering depends on IPSec and doing validation in
the central resolver.  That approach -- which I personally happen not
to like -- is enabled by the DNSSEC specifications.  Their stuff isn't
unusual in enterprise deployments.  We don't get to pooh-pooh that for
DANE just because we don't like it.  If we think that model is broken,
then we need to deprecate it.  If we're not going to deprecate it --
and I wish you luck -- then DANE needs to work for that DNSSEC
deployment, too.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 May 2012 09:11:11 -0700

> No, I believe we should standardize the good.

Good!

> If you wish to standardize the almost useless but can be upgraded to good with no flag day, but which upgrading to good requires replacing or bypassing a significant amount of brokenness on the Int…

I didn't say so because I don't consider the current proposal "almost useless". I hear that you do.

> Because DANE without nearly-hard-fail [1] on no data, not just BOGUS data, AND client-side validation, is no different that browser CRLs in terms of protection to the users in the face of an actual…

It is very different, but I hear that you don't believe that. Many of us believe that there can be integrity-protected communication with recursive resolvers that do DNSSEC, even if that is not common today.

--Paul Hoffman

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 7 May 2012 09:30:16 -0700

> It is very different, but I hear that you don't believe that. Many of us believe that there can be integrity-protected communication with recursive resolvers that do DNSSEC, even if that is not com…

This requires 

a)  Changing the on the wire protocol to the recursive resolver.   Changes to both the recursive resolver and the clients.  And changes to how clients are configured to use DNS servers in order to establish this secure channel.  (sDHCP anyone?)

b)  If on port 53, the same problem with borken middleboxes as doing DNSSEC on the client.  Even on different ports over an IPsec tunnel you may have middlebox issues.

c)  Can only be used in environments where the recursive resolver can legitimately be placed within the trusted base for communication.

And if thats your argument, then DANE should have the following caveats:

In the absence of client validation, recursive resolver validation only provides a meaningful security benefit for DANE records if:

1)  The recursive resolver is trustworthy as defined by local network policy.  ISP-provided and third party public recursive resolvers MUST NOT be considered trustworthy.

2)  Client to recursive resolver communication is over a secure channel.  Establishing and securing such a channel is outside the scope of this document.

---

From: John Gilmore <[email-masked]>
Date: Mon, 07 May 2012 16:16:37 -0700

I think that if the DANE TLS implementation can't get either a
dnssec-validated TLSA rrset, or a dnssec-validated absence of a TLSA
rrset, then to meet its security responsibilities, it has to fail to
connect.

Where the document is imprecise about that (or requires too many
indirections through obscure corners of the DNSSEC RFCs to understand
the implications) then I think we should say that more
straightforwardly in our RFC.

In browsers there will likely be a switch to "Use DANE TLS" just like
today there's a preference checkbox in Firefox for "Use SSL 3.0" and
"Use TLS 1.0".  When behind a broken coffeeshop gateway, the human may
need to manually turn off that switch.  But trying to operate in a
place that makes secure communication impossible should make enough
trouble for the user that they'll also complain to the coffeeshop
owner to fix their $*(@#@ gateway - or pick a different coffee shop
next time.

	John

---

From: Yoav Nir <[email-masked]>
Date: Tue, 8 May 2012 08:04:23 +0300

> owner to fix their $*(@#@ gateway - or pick a different coffee shop

I agree.

However, I'm wondering how many of the Firefox users who click "I understand the risks" actually understand the risks.

Also a likely scenario is that the user unchecks the "use DANE TLS", complains to the owner, and leaves the box unchecked forever.

The fact that there's quite a few places where you'll have to uncheck the box, and users are unlikely to find it by themselves, Firefox and the other browsers are not likely to have this box checked out of the box. To work securely, the UI has to pop up a warning that this place has insecure DNS, and you can disable the check for this session if you "understand the risks", and it turns back on automatically when you go somewhere else.

Even that is unlikely to be implemented, as browsers are moving in the direction of bothering the user with geek-speak less.

Yoav

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 May 2012 17:04:46 +0200 (MEST)

> owner to fix their $*(@#@ gateway - or pick a different coffee shop

Some of the users may simply continue using a browser version
that still works in their coffeshop, i.e. downgrade and disable
browser updates.

-Martin

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 8 May 2012 11:53:00 -0400

> rrset, then to meet its security responsibilities, it has to fail to

This is a strong statement, and is perhaps what ekr was asking for
too.  It's that "fail to connect" that bugs me.  For it means that, if
a client is TLSA-aware and it happens to find itself in some sort of
environment in which TLSA records don't work, or DNSSEC records don't
work, or both, there is exactly one thing it can do: foil all TLS
connection attempts.

> need to manually turn off that switch.

Just to be clear, what that does it cause the user to turn the browser
into a TLSA-unaware client.  If I had to bet, I'd bet that it will
persist and that it will itself become a barrier to operation.

It feels to me like this discussion lies right on the barrier of
"protocol" and "local policy", and that may be the reason it appears
to be intractable.  On the one hand, I can't believe anyone wants a
requirement that actually increases the chances people will make
connections without TLS, by making TLS impossible in some networks
where it sort of works today.  On the other hand, I understand (and
agree with) the analysis pointing out the attack available if a
complete non-response causes fall-through to traditional TLS
processing.  I'm wondering whether implementation or deployment advice
(perhaps in another document) is something that's not just nice to
have, but needed.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 May 2012 20:41:48 +0100

Yoav Nir <[email-masked]> wrote:
>
> I can think of a heuristic for this. Suppose we have to domain names,
> one with a valid TLSA record, the other without. The browser could query
> the DNS for a TLSA record for both of these, and if both answers are
> received, then TLSA works. In that case, a timeout can rightfully become
> a hard fail. If no response is received to either query, then either the
> DNS is broken or the attack is already going on. In that case the user
> should be warned with the likelier of the two - that the DNS seems to be
> broken, and certain kinds of attack are possible.

I think the "DNSSEC works but TLSA doesn't" heuristic may also be useful.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet, Irish Sea: Variable 3 or 4 becoming northeast 4 or 5,
occasionally 6 later. Slight or moderate. Rain or showers. Good, occasionally
poor.

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 May 2012 20:46:28 +0100

Ondrej Mikle <[email-masked]> wrote:
>
> From the ongoing scan, out of 70M currently finished .com domains,
> SERVFAILs appeared for ~8.6M distinct domains.

We're running validating resolvers and we haven't noticed that level of
failure. What proportion of authoritative servers with working DNSSEC
return SERVFAIL for what QTYPEs?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Faeroes, South-east Iceland: Northeasterly backing northwesterly 5 or 6,
occasionally 7 in Faeroes. Moderate, occasionally rough in Faeroes. Wintry
showers. Moderate or good.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 8 May 2012 15:47:10 -0400 (EDT)

> work, or both, there is exactly one thing it can do: foil all TLS

We really have no other choice. Your mother did not tell you when you
were young "Always lock the door if you are the last one leaving the
house, except when you think someone else might arrive home first, in
which case put the key under the door mat". She just said "always lock
the door" and you left the key under the mat sometimes anyway.

> (perhaps in another document) is something that's not just nice to

Let's leave those decisions to the browser vendors. They've gone through
this before and will go through this again. Ultimately, the biggest real
use-case is the hotspot case, and currently, it is mostly the browser
that detects this first. That has to change, and once the OS detects
this first, it can provide hints to the browser, and ultimately, even
have the browser start a sandboxed sign-on window to authenticate and
allow contained spoofed DNS before opening up the entire machine to DNS
and port HTTP(S). If networks are still DNSSEC broken after
authentication, and they are blocking port 53 and they are blocking fall
back resolvers over port 80 and/or 443, then really, what else is there
to do then hard fail?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 8 May 2012 15:49:29 -0400 (EDT)

> I think the "DNSSEC works but TLSA doesn't" heuristic may also be useful.

I don't think you can use that at all.

You will still run into DNS implementations that cannot do TLSA or generic
records that are not malicious, and I don't really know how you would
distinguish those from malicious TLSA breakage, so you cannot really
draw any conclusion from such state.

Paul

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 May 2012 21:14:21 +0100

> draw any conclusion from such state.

What is the overlap between servers that support DNSSEC but not RFC 3597?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forth, Tyne, Dogger: South 4 or 5, becoming variable 3 or 4. Slight,
occasionally moderate at first. Showers. Moderate or good.

---

From: Scott Schmit <[email-masked]>
Date: Tue, 8 May 2012 20:50:06 -0400

> What is the overlap between servers that support DNSSEC but not RFC 3597?

RFC 4034 requires use of RFC 3597 for unknown types, so the overlap is
supposed to be an empty set.

-- 
Scott Schmit

---

From: Paul Wouters <[email-masked]>
Date: Tue, 8 May 2012 21:00:08 -0400 (EDT)

> supposed to be an empty set.

But we all know there are many embedded devices with badly written DNS
proxy software that do things like comparing packets to known byte
streams without actual understanding of bit values.

Paul

---

From: Ondrej Mikle <[email-masked]>
Date: Thu, 10 May 2012 08:51:47 +0200

> return SERVFAIL for what QTYPEs?

The scans finished, here is a breakdown of what those SERVFAILs represented.
Short summary: As I expected, most of the domains are most likely
parked/unmaintained/speculative (by some whois queries, still SERVFAIL etc.)
Thus no reason for admin to care about them - that also means users won't ask
for them either.

Total amount of .com domains scanned: ~102M

1. SERVFAILS due to NS fetch failed and other RRs failed (disjunct)
     10114651 - NS fetch failed - the scanner skips the domain altogether
      2373284 - unique count of domains with SERVFAIL for at least one other RR
     12487935 total

2. NS fails on FQDNs contained in Alexa/Quantcast TOP 1M
      19574 alexa
      26087 quantcast

3. Unique domain count with at least one SERVFAIL for non-NS RR present in
Alexa/Quantcast TOP 1M
     18977 alexa
      6017 quantcast

The errors from "valuable/important" domains seemed transient (just bad time to
ask, probably). We'll still redo the SERVFAILs once/twice more.

Other (maybe interesting) common "weird pattern" is using 127.0.0.1 or 0.0.0.0
for A targets. I'm guessing those are domains used for development (so that it
connects to developer's machine). Can anyone think of other reason?

Apart from the above, there is definitely more brokenness. Mostly various
corner cases not explicitly/exhaustively covered by RFCs (tough rare in numbers).

Ondrej Mikle

---

From: Tony Finch <[email-masked]>
Date: Thu, 10 May 2012 10:41:33 +0100

> Thus no reason for admin to care about them - that also means users won't ask

For our purposes we need a breakdown of the "other RR" cases. The fact
that 10% of domains have broken delegations is sad but it isn't going to
confuse a DANE implementation into thinking there is an attack.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Faeroes: Northerly 4 or 5, occasionally 6 later in east. Moderate, becoming
rough later in far east. Wintry showers. Good.

---

From: Ondrej Mikle <[email-masked]>
Date: Thu, 10 May 2012 15:25:47 +0200

> confuse a DANE implementation into thinking there is an attack.

Sorry for the confusion, turns out the idea of posting the numbers before
everything is polished was not that great.

Don't get me wrong, I want to get DANE working as soon as possible. I even think
having some brokeness is not that bad (SW vendors may likely disagree). Many of
the scenarios described in this thread cause DoS with hard-fail, otherwise cause
downgrade attacks. But what about asking "how much" brokeness is there and "how
much" brokeness due to forcing hard-fail is "tolerable"? (so that we don't have
to make binary DoS-xor-downgrade-attack choice).

Simple proposal complementary to probing authNSs: TLSA will be implemented as
soft-fail at first, followed by a "TLSA day" (analogy of IPv6 day) where for
instance Google will place a small piece of code to test users' resolvers
(Google has unique position of having interest in TLSA and capability to do the
measurement of clients' resolvers).

The above paragraph is an engineering solution, not suitable as text for RFC,
but I fail to see any better alternative to binary option
hard-fail/downgrade-attack.

<apologies beforehand for following rant>

It's been the same with CRL and OCSP (hard fail - possible DoS, otherwise no
effect). In every client that supports it, I set OCSP to be required. Errors are
rather rare.

Unfixable exceptions which I'd just mark "problem of somebody else - we don't care":
- captive portals - central idea of being built on MitM is broken on so many
levels (why not just 802.1x? - I had always less problems with that)
- broken DNS resolver implementations - I've always seen them exclusively with
captive portals, but there few other "plastic home router boxes" for sure

If we keep piling up workarounds/special-code-branches for thoroughly broken
infrastructure pieces instead of showing error, things will get even more messy
and exploitable.
Take "transvalid" certificates as an example - TLS server doesn't send complete
chain, works for admin, works for most users, but not users with clean browser
profile. Hard to debug even for seasoned admins (who may be not experts in PKIX
implementation quirks). Too permissive protocol handling has track record of
leading towards vulnerabilities (OID decoder permitting leading 0x80 bug for
instance).

Solution (big maybe): software should _point_fingers_ with as
end-user-readable-messages-as-possible at whoever is responsible - resolver fail
at ISP/captive portal, CA for OCSP responder, etc.

There have been couple of attempts to detect such broken-by-design elements like
captive portals (e.g. ooni-probe). Brokeness should be pushed away, not worked
around - maybe some "You-misunderstood-Jon-Postel"-protocol-fascists action is
in order :-) (like the campaign against IE6)

</end rant>

Ondrej Mikle

---

From: John Gilmore <[email-masked]>
Date: Fri, 11 May 2012 09:46:23 -0700

> streams without actual understanding of bit values.

I don't personally know this.  If we're going to design a protocol
around such devices, let's at least get some details instead of vague
generalizations that "we all know".

Can you provide some actual names of such devices, preferably with
links to people complaining about their badly written DNS proxies?
What is the practical effect of the limitations in their DNS proxies?
How widely deployed are they, and where?  Are these endpoint devices
or routers?  Has the mfr released updated firmware for them?  Etc.

Are these proxies only in the data stream while the box is trying to
interpose itself into "your first web access" to force you to log in?
Or are the proxies permanently affecting every end user's ability (on
that network) to send and receive arbitrary packets on port 53?

	John

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 11 May 2012 10:04:16 -0700

> or routers?  Has the mfr released updated firmware for them?  Etc.

Its very ubiquitous, and the biggest problem is the CPE (Customer Premesis Equipment, aka the @#)(@*#)$ NAT!).

www.icir.org/christian/publications/2011-satin-netalyzr.pdf

See section IV

A good 9%+ can't handle unknown RTYPES, TXT records, or requests with EDNS0.

Almost all NATS have DNS proxies that they return as the address of the DNS server always, so they can give an IP address even when they aren't connected.

A good 10% of clients are behind a firewall that attempts to enforce DNS semantics when trying to directly contact a remote authority server.  

A good 4% of clients can't fetch >512B DNS but unfragmented with EDNS0, an unknown RTYPE, and/or TXT records when DIRECTLY querying the remote server (bypassing b0rken recursive resolvers, see above)

We don't know what fraction of these are correct in terms of DNSSEC, but its on the todo list.

We don't know what fraction can use TCP DNS unmolested, but again, its on the todo list.

Also, not reported yet (we haven't analyzed the data fully), but updates in CPE frankly don't occur.  Only Apple even sort of tries (you still need to open the AirPort utility tho for updates to happen), and SOME cable operator provided NAT/cable modems are maintained by the cable operator.  Otherwise, its very often "the crud that shipped is the crud that runs"

E.G, we see nearly 800 sessions (a good fraction of a percent of the tests which are executed) where the configured resolver is runing dnsmasq-1.18, which was released in 2003-2004! 

We're now also fetching UPnP strings these days and we see a distressing variety of unupdated kit.

> that network) to send and receive arbitrary packets on port 53?

The latter.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 11 May 2012 14:37:51 -0400 (EDT)

> www.icir.org/christian/publications/2011-satin-netalyzr.pdf

There is also:

www.icann.org/en/groups/ssac/documents/sac-035-en.pdf
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/DNSSEC/DNSSEC_Support_by_Home_Routers.pdf
http://ripe60.ripe.net/presentations/Dietrich-DNSSEC_Support_by_Home_Routers_in_Germany.pdf
https://www.iis.se/docs/Health-Status-DNS-and-DNSSEC-20120321.pdf

etc. etc.

There are a lot of failure modes. One important one used to be the
dnsmasq software shipped with many commercial vendors, though that
one has now been fixed, though no one installs firmware updates so
it takes years for these kind of brokenness to disappear.

The Atlas probe project at RIPE will hopefully be able to tell us a lot more
in the near future as well.

Regardless, to get back on the topic, there will be devices that can
do DNSSEC but that do not handle the Generic record format.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 May 2012 19:12:23 -0700

There doesn't seem to be convergence here, and the WG chairs and AD have asked the authors to propose wording that might bring consensus. The following text may be insufficient, but it's the best I can do at the moment, and if it isn't good enough, having you propose specific changes may be helpful.

This proposed text tries to pull together:

- Ekr's security analysis

- The desire for a MUST that is likely to be deployed, not ignored

- Acknowledgement that if the user doesn't know TLSA is being used, they are not losing anything from the attack

(And, yes, I think that the chairs should be doing this bit instead of Jakob and I. Oh, well.)

An attacker who is able to divert a user to a server under his control is also
likely to be able to block DNS requests from the user or DNS responses being
sent to the user. Thus, in order to achieve any security benefit from
certificate usage 0 or 1, an application that sends a request for TLSA records
needs to get either a valid signed response containing TLSA records or
verification that the domain is insecure or indeterminate. If a request for a
TLSA record does not meet one of those two criteria but the application
continues with the TLS handshake anyway, the application has gotten no benefit
from TLSA and should not make any internal or external indication that TLSA
was applied. If an application has any indication that TLSA is in use (such as
through a configuration setting), that application MUST not start a TLS
connection or abort a TLS handshake if either of the two criteria above are
not met.

Livable? Better specific suggestions?

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 May 2012 19:31:03 -0700

On Mon, May 14, 2012 at 7:12 PM, Paul Hoffman <[email-masked]> wrote:
> was applied.

I think this is generally fine, modulo Stephen's concerns about types 2 and 3,
which I haven't worked through yet.

> If an application has any indication that TLSA is in use (such as

I feel like this is confusing. There are two senses in which TLSA might
be "in use". (1) The application is trying to retrieve it. (2) The DNS server
is serving it. We're clearly in the first case, and it's the second which
is unknown to us b/c under control of the attacker. Perhaps you
mean to say "Applicaions SHOULD offer a setting to allow users to
set strict TLSA checking, in which case..."

---

From: Paul Wouters <[email-masked]>
Date: Mon, 14 May 2012 22:45:02 -0400 (EDT)

> Livable? Better specific suggestions?

Livable. I am a little confused about "signed TLSA", "insecure" or
"indeterminate" together with "the two criteria". Did you mean
"signed TLSA" and "insecure" as one criteria ("dnssec worked") or did
you mean "indicator" and "indeterminate" as the two criteria? How about:

    an application that sends a request for TLSA records will get
    either a valid signed response (containing TLSA records or not)
    or reaches an indeterminate state (for instance by lack of DNS
    replies)

    [...]

    that application MUST not start a TLS connection or abort a TLS handshake
    if TLSA processing is configured and the result was indeterminate.

I'm also not sure why the statement is limited to certficate usage 0 and
1. Is that because you assume no PKIX alternatives are available and
thus it always has to abort for insecure/indeterminate?

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 May 2012 19:55:35 -0700

>   or reaches an indeterminate state (for instance by lack of DNS

I don't think this is what we want.. There appear to be five relevant
states:

* secure, bogus, indeterminate, or insecure [specified in section 4.1]
* no response, DNS error, etc. [the state in question here]

The relevant point here is that in the case where you were expecting
DNSSEC but you get some error in the last category, then in order
to get security benefit from restrictive modes, you must treat that as
if it were bogus. That's different from cases where you weren't
expecting DNSSEC (insecure, indeterminate), and therefore you
should just be ignoring the TLSA records.

> thus it always has to abort for insecure/indeterminate?

The security logic is different for restrictive records and additive records.
Say that you're not willing to hard fail on TLSA failures but you're willing
to suppress error warnings if you get resolvable records of type 2 and 3.
Then you are getting security benefit for those records, but you're not
getting any security benefit if type 0 or 1 records exist.

With that said, I haven't completely worked through 2 and 3, so it might
be that they have some restrictive value, in which case the above
analysis applies.

Arguably, it would be best to serve two different classes of records to
make this clearer.

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 May 2012 00:23:13 -0400 (EDT)

> * no response, DNS error, etc. [the state in question here]

We had these discussions before, where there is a disagreement about
some cases where you are not getting some responses and what state it
is supposed to be. I'm not sure we all agreed in the end - I thought
some people argued that "indeterminate" does not really exist.

> DNSSEC but you get some error in the last category

if you expect a dnssec signed answer (eg because you have a validated
parental DS) but you did not, the reseult is what? bogus? But if there
might be a zone cut in between the parental DS you have (eg the root)
and the zone, it is indeterminate? I think for TLSA, these should both
be treated the same, as bogus.

> should just be ignoring the TLSA records.

You cannot know when you were NOT expecting DNSSEC unless you do DNSSEC
and you a get a validated anwser that leads to an end of the trust chain
before it reaches the domain you were interested in. So an attacker
would also prevent you from knowing that. And if you know a domain is
insecure, you don't even need to query for TLSA records, unless your
model assumes a full validator logic built into the browser, as opposed
to using a trusted validator on localhost.

Are we expecting browsers to just query for TLSA records and ignore
those received without AD bit? Or are we expecting them to implement
full resolver logic?

Right now, a browser can just query for TLSA records to its local
resolver, and make a decision based on the AD bit. If any filtering
of DNSSEC is taking place, the local resolver should be returning
SERVFAIL. Do we want the browser to extract more details with CD? Or
should they just hard/soft fail based on their local settings? Should
they find out if this would be "bogus" or "indeterminate", or is there
no point?

> getting any security benefit if type 0 or 1 records exist.

Now I'm completely lost. Usage 0 and 1 is for pinning PKIX, so if you
want to use TLSA to avoid rogue CA's, you can't suppress those error
warnings. It's really the same as disabling TLSA. Or else we're going to
have to teach browsers to remember previous TLSA state and only warn
when we knew the site used to publish TLSA, but now we are
indeterminate.

> Arguably, it would be best to serve two different classes of records to

I'm not sure that matters, because if you cannot get those records, eg
an indeterminate answer, you cannot make a decision based on a supposed
different class of record you can't receive.

The only way out to signal something about hard/soft fail for TLSA
outside the DNS would be to put a market in the certificate. But then
we're back to square one with rogue CAs.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 May 2012 21:50:35 -0700

> some people argued that "indeterminate" does not really exist.

Well, it's a listed category in 4033. If it's a null category, that's fine.

> parental DS) but you did not,

Did not what? The case in question is that you get no answer or an
ICMP response or something.

> the reseult is what? bogus? But if there

Yes, I tend to agree, but it's clear that there's not consensus on this
point, so I'm focusing on describing the technical situation.

> would also prevent you from knowing that.

Yes, that's true, but I'm not sure I see the relevance. Obviously, under
non-attack conditions you would expect to see this with some frequency.

> And if you know a domain is

Which after all, might happen.

> those received without AD bit? Or are we expecting them to implement

Personally, I expect browsers to not query for TLSA records at all,
for the reasons that AGL indicated earlier.

> they find out if this would be "bogus" or "indeterminate", or is there

I don't understand any of this. Even if you trust your resolver, there
are certainly ways for an attacker to suppress the response, so it's
always going to be the case that you need to know what to do
when you get no response. This is true whether the browser has
validation logic or not.

> warnings. It's really the same as disabling TLSA.

Yes, hence my original post.

Once again, *I* think it's silly to implement TLSA and then act in a way
that allows an attacker to force you back to the posture you would
have been in if you didn't implement TLSA. However, apparently
there is no consensus on that point. What we're discussing now
(at the chair's request) is how to characterize the security implications
of that implementation choice.

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 May 2012 01:17:09 -0400 (EDT)

On Mon, 14 May 2012, Eric Rescorla wrote:

> What we're discussing now

I understand that, but the proposed text is trying to define certain
states that are distinguishable to give different advise, and I tried
to show that one cannot distinguish some of those states. You cannot tell
implementarors that "indeterminate" is different from "bogus", and
that a browser can give different feedback depending on those two
states. Not from a security context anyways.

I'll try come up with an alternative text.

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 May 2012 07:13:18 -0400

> should just be ignoring the TLSA records.

I think the reason I find this discussion difficult is that I don't
get this "expecting" thing.  With DNSSEC, you have _no idea_ what to
expect.  What you do is ask for something, and get a response or an
error.  Either it is validatable or not.  You can expect a
DNSSEC-signed response on the basis of the DS at the parent side.

In the cases you're talking about here, however, you still don't know
what to expect even if the A or AAAA record you fetched before was
signed and validated and so on.  You might get NOTIMP, for instance.
As Martin Rex argued, that response is strictly consistent with the
relevant RFCs even if many of us think that it's the wrong way for a
server to reply.  I agree that a TLSA answer in that case adds nothing
to the security; but "just ignore the TLSA records" (which, _ex
hypothesi_, you didn't get under the scenario) would seem to be an
argument for "fall through to traditional TLS processing".  I thought
that's what you wanted _not_ to happen?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 May 2012 07:21:58 -0400

On Tue, May 15, 2012 at 12:23:13AM -0400, Paul Wouters wrote:
> parental DS) but you did not, the reseult is what? bogus? 

Yes.

> But if there
> and the zone, it is indeterminate? 

If you're not sure whether there is a zone cut because you fell off
the end of a chain without determining that you were into provably
insecure space, then it's bogus.  Otherwise, it's insecure, not
indeterminate.  (DLV or a TA could make the space secure again, of
course, across a probably insecure boundary, in which case it's a
matter of the validation state again.)  For our purposes, you can
think of "Indeterminate" as "I don't have a trust anchor".  This is
the meaning in RFC 4033, which discusses the matter from the POV of
the resolver.

> they find out if this would be "bogus" or "indeterminate", or is there

It is possible that the browser could also use some future
to-be-invented API that provided the details without having to have a
full service resolver built in.

> when we knew the site used to publish TLSA, but now we are

Surely, that's just as bad an idea; the fact that the DNS used to
contain a AAAA record is no guide to whether a site is supporting
IPv6 today, by way of analogy.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 May 2012 05:16:39 -0700

> that's what you wanted _not_ to happen?

Let's take a step back.

You're a resolver.

You generate a request for a given RR, say an A record. It comes back
with no signature at all. Under one set of information about the state
of the world (call that S), you generate a resolution failure. Under
another set of information (call that I) you consider it a result to
the application but tell it that the request isn't DNSSEC signed. When
I say "expecting DNSSEC", I mean condition "S"

Because the signature is what secures the DNSSEC response (assuming
 end-to-end resolution), when you get an unsigned response, no
response, or an error like NOTIMPL, if you are in condition S you need
(at least if you want to be secure) to make the most pessimistic set
of assumptions about what the response would have been if whatever
error (or attacker behavior) caused you to get what you got had not
supervened. On the other hand, if you are condition I, then you
should be returning a response. It's still not cryptographically
secure, but there is no reason to believe it would have been.

Presumably DNSSEC does in fact know how to distinguish these cases,
else any unsigned response of any kind would lead to resolution
failures. What we are talking about is extending that logic to a
different set of security requirements.  What makes this case
different is that in the case of the A record, the most pessimistic
response is "does not exist". In the case of the TLSA record (types 0
and 1), the most pessimistic response is "exists and forbids the
certificate I am about to get".

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 May 2012 08:19:24 -0400 (EDT)

> IPv6 today, by way of analogy.

Yes, it is as bad as the cert partrol plugin that tracks PKIX states
in a browser. But it's better then disabling TLSA at all in the face
of DNS errors (where we assume most errors are genuine network errors
and not attacks).

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 May 2012 10:55:06 -0400

> I say "expecting DNSSEC", I mean condition "S"

Are you talking about a case where by, for local policy reasons, if
you don't get a DNSSEC-validating response, you produce an error
(probably the functional equivalent of SERVFAIL) for consumption by
the calling application?  The reason I ask is this:

> failures.

How?

If you're talking about the description of the world as I interpreted
above, then unsigned responses of any kind _would_ lead to resolution
failures.  That's why nobody would turn that knob on except in very
narrow circumstances.

If you're talking about normal operation of a validating resolver,
then you can distinguish between "this response is signed and
validatable, and everything in the delegation chain is too" (secure);
"this response is signed but not validatable in some way", or, "this
response is not signed but I can prove it should be" (bogus); "this
response is not signed and I can prove that it needn't be"
([probvably] insecure); "I don't know about this case"
(indeterminate).  But these states don't extend to the errors (except
Name Error).

In the case of an error or simple non-response, you just don't have
the data.  You can't draw any conclusion.  Normally, you don't have
to, of course: if you don't know the A record or SRV record or
whatever, you can't do anything more, and your action fails.  (This is
not "does not exist", but "I can't find it".  For a naive user this
difference might not matter; "the site is broken".  But it does matter
for the purposes of caching and so on.  The possibility of a bad cache
is part of why I don't want to say "treat as bogus" for this purpose.)

In the DANE case, as you point out, what we're doing is adding to the
DNS supplementary data about a different data path.  That's the reason
that, when you get an error or don't get a response, you need to draw
a conclusion.  This is an unusual thing to do with the DNS.

I therefore think you're right that, if for use case 0 or 1, the
responsible deployer would want the attempted connection to fail.
That's the security the additional data (the TLSA record) is supposed
to offer.  I've argued that approach is dangerous except in really
unusual circumstances, because it seems likely to result in surprising
random failures sometimes.  One of those failures is bound to cause
people to say, "Turn TLSA off," and then we lose all the TLSA
features.  Alternatively, it will cause people faced with a TLS
negotiation failure to fall back to no-TLS versions of whatever
they're using (which is probably spelled "http" for this worry), and I
think that's worse.  Surely, some people will deploy TLSA in use 0 or
1 without understanding the failure modes ("more security is better",
"turn it up to 11", and so on).

It seemed to me that the proferred additional text explained the above
(the upshot being that use 0 and 1 are both very close to useless).  

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 May 2012 10:57:21 -0400

> of DNS errors (where we assume most errors are genuine network errors

I think ekr is arguing that use cases 0 and 1 are different than use
cases 2 and 3; it seems to me that in use cases 2 and 3, if you can't
get an answer out of the DNS you're already screwed: you can't proceed
with a TLS connection, because you don't have the necessary material
to do the negotiation.  What did I miss?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 May 2012 11:55:15 -0400

I know, replying to myself. 

> a conclusion.  This is an unusual thing to do with the DNS.

An off-list conversation with Paul Hoffman (thanks, Paul) leads me to
try to make this more precise.  What we are doing in the DANE case,
with uses 0 and 1, is to add constraints to the operation of another
protocol.  That is, use 2 and 3 provide a full-blown change to another
protocol.  E.g., 3 says "use this cert or key" so you don't end up
following an X.509 chain of trust when doing your TLS negotiation.
But 0 and 1 don't do that; instead they say, "Do your PKIX work as
normal, but here's an additional constraint." 

This adding of constraints is the thing that is unusual to do with the
DNS.  Paul convinced me pretty quickly that this is not the first time
we've done it, but it's unusual enough that when we do it we may not
realise what we're doing.  (On reflection, for instance, I think that
SPF, when used with a mail server that rejects the mail at EHLO due to
SPF failure, amounts to a case like this.)

I am currently calling these cases "constraint assertions in the DNS"
because I don't have a nicer name.  I think those calling for funny
handling of normal DNS conditions like error messages have identified
a fundamental need in constraint-assertion cases, because if one
cannot receive a message about the existence of such a constraint
assertion, one has a problem.  

This doesn't leave me more certain of what to say in the draft, but at
least I have a clearer idea of what's at issue.  Does anyone else
think this way of thinking about the difference is helpful?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 15 May 2012 09:06:31 -0700

Yes.  

It say either "Hard Failure" or "Annoy the @#)(*#@ User Failure" on inability to fetch a proper DNSSEC validating record when one is expected.

Because the TLS system in practice already has a constraint system, Certificate Revocation Lists, which say "Despite the certificate being valid, don't use these certificates".  The CRL check is a "fail open" (proceed if unable to contact the CRL server), its now viewed as useless and is being discontinued at least in Chrome, and I'd expect other browsers to follow suit.

Since the existing "add constraint" system is now considered useless because of the "fail open" nature, any new constraint system MUST be either "fail closed" or "fail annoying" if it can't get the necessary records from DNS.

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 May 2012 18:52:15 +0200 (MEST)

> set strict TLSA checking, in which case..."

Similar to OCSP, any hard-fail requirement is going to create a
significant usability issue, and at worst, cause users to fallback
from a HTTPS-but-not-DANE-verifiable URL for a login page to
a plain HTTP login page -- which is making things *MUCH* worse.

I do not believe in DANE hard-fail without a DNSSEC records stapling
TLS extension (similar to the OCSP stapling TLS extension).
 
And as a fallback, browsers could use a TLSA & server-cert lock, i.e.
memorizing information from the last visit of a site and using that
to perform server endpoint identification in case that DNSSEC lookups
fail when roaming.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 May 2012 09:55:27 -0700

> to perform server endpoint identification in case that DNSSEC lookups

At which point it's hard to understand how this is better than cert pinning
via HSTS.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 May 2012 19:04:34 +0200 (MEST)

> At which point it's hard to understand how this is better than cert pinning

Such a TLSA & server-cert lock is supposed to be transient substitute for
the lack of DNSSEC connectivity.  That memorized information will need
to be updated whenever full DNSSEC connectivity is available.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 May 2012 10:05:46 -0700

> to be updated whenever full DNSSEC connectivity is available.

And the HSTS information can be updated whenever you go to the server.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 May 2012 19:20:14 +0200 (MEST)

> And the HSTS information can be updated whenever you go to the server.

In case that you are referring to this:

  http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

it seems to only convey an indication from the server to the client
to use HTTPS rather than HTTP to access the server.

DANE/TLSA is supposed to provide an (independent) confirmation from the 
DNS admin, that the server certificate presented by the server is the
*real* one.

I somehow fail to see what these two have in common.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 May 2012 10:49:45 -0700

>  http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

http://tools.ietf.org/wg/websec/draft-ietf-websec-key-pinning/

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 May 2012 11:32:15 -0700

(Going back a bit in the discussion, using the only wording we have.)

> which I haven't worked through yet.

Nor have I, but at least we're sure that we agree on 0 and 1.

> set strict TLSA checking, in which case..."

I don't think people have been talking about suggesting that the application let the user choose between strict and not-strict; I think most people here are against that. But I agree that the sentence is confusing because it makes "configuration setting" a subset of TLSA indication. Instead of that sentence, I propose:

If an application has a configuration setting for turning on TLSA use,
or has any indication that TLSA is in use (regardless of whether or not
this is configurable), that application MUST not start a TLS
connection or abort a TLS handshake if either of the two criteria above are
not met.

This does not say "and you might have hard failure configurable", but instead says "if the user might think that TLSA is in use, you have to hard fail if they are not getting the security that they might expect".

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 May 2012 15:32:44 -0400

> (Going back a bit in the discussion, using the only wording we have.)

<chair>
Thank you -- and I ask that if folk are unhappy with the current wording they  propose alternate. Simply grumping (and repeating yourself) isn't nearly as effective at communicating what you actually *mean* as providing suitable text...
</chair> 

> I don't think people have been talking about suggesting that the application let the user choose between strict and not-strict; I think most people here are against that.

This may be my fault -- a long time back (in this thread) I proposed having implmentations  default to not-strict and then, in a few years (once there is less DNSSEC breakage by CPE, etc), vendors would turn the knob to strict mode. Educated / security concious users would also be able to turn the knob if they so  desired.

This was just an idea, and perhaps a bad one!

> But I agree that the sentence is confusing because it makes "configuration setting" a subset of TLSA indication. Instead of that sentence, I propose:
> 

This sounds good to me, but what does the user do in this case?  Simply remove the s from https:// (assuming a browser)? Do we need to mention anything, or leave this up to the application? There is already stuff like HSTS / web sec, etc for this…

Yes, I should be proposing text here, but I'm not really taking a stand, rather trying to get feedback...

W

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 15 May 2012 12:57:26 -0700

> This was just an idea, and perhaps a bad one!

CPE bugs should be regarded as "Forever Day".

Instead, any client-side DNSSEC application must take pains to both map the brokenness and be prepared to work around it, including: bypassing the configured recursive resolver to use a DNSSEC passing external resolver or just fetching directly, switching to TCP, and even connecting to DNSSEC passing resolvers which are configured to use a non-standard port.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 May 2012 16:01:11 -0400

> CPE bugs should be regarded as "Forever Day".

Yes, there are likely to be broken CPE for a really long time, but a: the percentage should be dropping over time (years) and b: other brokenness should also be decreasing over time.

> Instead, any client-side DNSSEC application must take pains to both map the brokenness and be prepared to work around it, including: bypassing the configured recursive resolver to use a DNSSEC pass…

These are all options, but way outside of what we can (or should) describe in this document…

W

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 May 2012 22:08:53 +0200 (MEST)

> And the HSTS information can be updated whenever you go to the server.

But the HSTS has a clear hen-and-edd problem:  You can _only_ get updates
when the verification based on the previous information is still possible,
otherwise your browser will not establish the communication channel that
is a pre-requisite to obtain the updated information.

To me it looks like it will be pretty easy to lock yourself out, since
you have no influence about how frequently the client accesses a site.
(that is like replicating the DNS root key rollover problem for every
single site).

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 May 2012 13:24:48 -0700

> you have no influence about how frequently the client accesses a site.

1. The pins expire, so you advertise both old and new pins (but continue
to use the old key) until all old pins have expired.
2. There are techniques for breaking the pin.

I'm not suggesting that this draft is perfect, but really these are
fairly obvious
objections that have been discussed extensively in websec.

-Ekr

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 May 2012 16:29:16 -0400

On May 15, 2012, at 4:24 PM, Eric Rescorla wrote:

> objections that have been discussed extensively in web sec.

Agreed, and if folk would like to object further, I'd suggest:
1: *reading* the docs and discussions in web sec and then, if you still have a beef, 
2: taking the discussion to web sec…

W

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 May 2012 16:29:25 -0400

> This does not say "and you might have hard failure configurable", but instead says "if the user might think that TLSA is in use, you have to hard fail if they are not getting the security that they…

Does anyone have any *specific* updates to this text that they would like to provide?
Can you live with this text (note: I didn't say "Are you infinitely happy with this text", just "Can you live with"…) 

W

---

From: John Gilmore <[email-masked]>
Date: Tue, 15 May 2012 18:16:29 -0700

> connection or abort a TLS handshake if either of the two criteria above are

An attacker who is able to divert a user to a server under his control
is also likely to be able to block DNS requests from the user or DNS
responses being sent to the user.  Thus, in order to achieve any
security benefit from certificate usage 0 or 1, the protocol requires
that when DNS responses have not arrived or are not valid, the TLS
connection must not succeed.

To proceed with a DANE TLSA transaction, an application MUST get
either a Secure response containing TLSA records for the relevant
domain name, a Secure response proving that there are no TLSA records
for the relevant domain name, or verification that the domain name is
Insecure.  (Secure and Insecure are defined in section 4.3 of RFC
4035.)

If the response(s) from a TLSA record query do not meet any of the
above criteria, but the application continues with the TLS handshake
anyway, the application is in violation of this protocol
specification.  It MUST NOT make any internal or external indication
that the DANE TLSA protocol is in effect.  If an application has any
indication that the DANE TLSA protocol is in use (such as through a
configuration setting), that application MUST NOT start a TLS
connection, and MUST abort any pending TLS handshake, if none of the
criteria in the previous paragraph are not met.

(End of text for somewhere in RFC.)

It isn't clear where in the RFC this text would go.  Some of it
seems to be explanatory and other parts seem to be normative.

My comments are that this text is not usable, even after my
modifications.  It chats about motivations.  It tries to define a
protocol specification, saying what the application should do to
follow that spec.  It then says "if you violate this spec in this
particular way, don't call it DANE TLSA".  Then it says that twice, or
three times.  I don't see the point of that.  If they violate the spec
in any other way, they shouldn't call it DANE TLSA either.

I would remove the last paragraph entirely.  I would move the first
paragraph off into a security-related section.  I'd keep the short
paragraph beginning "To proceed with a DANE TLSA transaction,".

I think it's progress to have text that defines the VALID ways to
proceed with the protocol, rather than getting lost in the weeds of
all the possible INVALID ways to fail.

	John

---

From: John Gilmore <[email-masked]>
Date: Tue, 15 May 2012 18:24:18 -0700

> connection must not succeed.

It's easy for a Man in the Middle to subvert cert usage 3 this way
too.  They just issue themselves a cert signed by some subverted
public CA, block your TLSA DNS responses, and then if you proceed with
TLS, you'll accept the key signed by the subverted public CA, since
you never saw the record that says "This server is secured by THIS
PUBLIC KEY RIGHT HERE, and not anything else."

This attack also works against cert usage 2.  Thus I'm not sure why
this proposed graf even mentions cert usages 0 and 1, except perhaps
to remind the PKIX fans among us that proceeding in the face of DNS
blockage causes even their favorite forms of TLSA to be vulnerable.

Thus I'd revise that text (for a security section somewhere) to:

An attacker who is able to divert a user to a server under his control
is also likely to be able to block DNS requests from the user or DNS
responses being sent to the user.  Thus, in order to achieve any
security benefit from DANE TLSA, the protocol requires that when DNS
responses have not arrived or are not valid, the TLS connection must
not succeed.

	John

---

From: John Gilmore <[email-masked]>
Date: Tue, 15 May 2012 19:13:16 -0700

> But it's better then disabling TLSA at all in the face

"Genuine network errors" from buggy proxies or intentional firewalls
or intentional or accidental censorship systems ARE attacks.  They are
attacks on the fundamental end-to-end premise of the Internet.

The default state of the networking world, pre-Internet, is that
network providers felt free to block or modify data in transit, for
their own convenience, profit, whim, or by accident.  They'd control
what services you could access, what channels you could watch, etc,
etc, etc.  It was assumed that the owner of the communications channel
had every right and every business reason to limit who you were allowed
to talk to, and on what topics.

The Internet changed all that, making it clear what a huge benefit the
public could derive from a system that delivered end-users' data
end-to-end, unmodified, from anywhere, to anywhere.  Finally you could
access YOUR CHOICE of data and services from anywhere -- not "this
service is only available on France Telecom's Teletext system" and
"You can't email that guy because he's on MCI Mail and you're on The
Source".  Now that Moore's Law's newly available crunchons enabled
today's complex radio modulations and equally complex presentation
protocols, you can get all those same services wirelessly, instead of
what the incumbent providers kept designing over and over ("You can
only get this WAP-based information service on AT&T mobile phones" and
"To watch this TV show that you've already paid for, you have to be
physically plugged into this coaxial cable.")

Since the public rise of the Internet in the '90s was not
cryptographically secured end-to-end, providers eventually realized
that they could somewhat go back to their old ways of messing with
end-users' data for their own convenience, profit, whim, or by
accident.  Like Comcast blocking BitTorrent traffic by forging RST
packets, AT&T Mobile deliberately dropping packets when it had the
capacity to carry them, just to discourage "unlimited" usage, or
certain carriers declining to carry packets for "over the top" video.
Or shipping buggy DNS proxies that mess up Port 53 UDP traffic in
their subnet.  Most users didn't notice, which allowed the providers
to often get away with censoring the ones who did notice.

DNSSEC and DANE are just part of the leading edge of a trend to secure
Internet traffic end-to-end.  This will make more such blockages and
modifications much more apparent -- turning them from
possibly-unnoticed inconveniences into denial-of-service failures.

But the end result will be that (1) users will realize they are being
censored; (2) providers will clean up the accidental and whim-related
censorship; and (3) users will migrate to providers who offer them
reliable end-to-end service without interruptions for the provider's
convenience or profit.

And in that way, the Internet will route around these attacks on the
end-to-end principle.

This is a good thing, despite the distributed pain involved in fixing
all those broken devices and misguided providers.

	John

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 May 2012 12:14:59 +1000

In message <[email-masked]>, Martin Rex writes
> a plain HTTP login page -- which is making things *MUCH* worse.

No. It is NOT similar to OCSP.  OSCP answers come from somewhere
else.  For 99.99% of TLSA answers they come from the *same* zone
as the address/CNAME/SRV records of the server you are connecting
to.  If you can get one you should to 99.99% be able to get the
answer to the other.

If you get a answer to the address query but not the TLSA query you
will almost certainly have a broken DNS proxy and if I was a web
browser vendor I would be putting up a big message saying:

	You appear to have a broken DNS proxy.  Please contact
	you DNS proxy vendor for a fix.  For more information
	click hear: http://browser.vendor/broken_DNS_proxy.html

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 May 2012 09:53:54 +0200 (MEST)

Warren Kumari wrote:
> > 
> > I don't think people have been talking about suggesting that the
> > application let the user choose between strict and not-strict;
> > I think most people here are against that.
> 
> This may be my fault -- a long time back (in this thread) I proposed
> having implmentations default to not-strict and then, in a few years
> (once there is less DNSSEC breakage by CPE, etc), vendors would turn
> the knob to strict mode. Educated / security concious users would
> also be able to turn the knob if they so  desired.
> 

That was a perfectly reasonable one, and is the approach that is being
used for the TLS renegotiation_info extension (rfc5746):

  http://tools.ietf.org/html/rfc5746#section-4

And no, the world did not end because of browsers and other TLS-clients
not being strict about TLS renegotiation (i.e. hard-failing on
servers that do not support it).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 May 2012 11:43:33 +0200 (MEST)

> attacks on the fundamental end-to-end premise of the Internet.

Where have you been during the last 10 years?
There is no such thing an a "fundamental end-to-end premise" on the
Internet.  And if it ever existed, it ceased to exist ~10 years ago.
(and for good, because it would entirely preclude privacy).

> end-to-end, unmodified, from anywhere, to anywhere.

That is not the case here.  Telco's providing Internet Access for
mobile devices regulary block traffic to VoiP providers _and_
regularly prevent your smartphone or tablet from forwarding
IP datagrams to other devices ("tethering") unless you pay extra.

> to often get away with censoring the ones who did notice.

You seem to be unaware of the IETF full Standard "STD-13"

   http://tools.ietf.org/html/std13#section-2.3.4

Those DNS proxies are perfectly Standards-compliant.

Maybe the IETF should come around to merging contents of later documents
with STD-13 and work this successor through document maturity levels to
full standard in order to replace the *CURRENT* STD-13, similar to what
has been done with 821->2821->5321 and 822->2822->5322, so that when
implementations of the *current* STD-13 in the installed base have
died off, one can start complaining about non-support of DNSSEC.

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 May 2012 13:31:50 +0300

> Internet.  And if it ever existed, it ceased to exist ~10 years ago.

15. Most networks have a NAT, including almost all home networks. Most corporate networks have some kind of firewall. If you want end-to-end, you have to roll your own through IPsec or TLS, and even then you're likely to get load balancers at the server side, and the occasional decrypting proxy on the client side.

Yoav

---

From: Henry Story <[email-masked]>
Date: Wed, 16 May 2012 13:46:08 +0200

> all those broken devices and misguided providers.

I completely agree. Thanks for putting it so clearly. 

> 	John

Social Web Architect
http://bblfish.net/

---

From: Henry Story <[email-masked]>
Date: Wed, 16 May 2012 13:55:44 +0200

> 15. Most networks have a NAT, including almost all home networks. Most corporate networks have some kind of firewall. If you want end-to-end, you have to roll your own through IPsec or TLS, and eve…

The point of John Gilmore's inspirational mail is that end-to-end is the aim of
the architecture of the internet. It is because it was architected for end to 
end communication that it has had such positive effects. The reasons these working
groups exist is to remove the technical reasons for this not always being possible, such
as by for example working on ipv6.  When the technical reasons have been moved out of the
way the network effects and political pressure can be built up to solve the deployment
problems. Luckily the network effect works in favour of those who work for freedom.

Henry

Social Web Architect
http://bblfish.net/

---

From: SM <[email-masked]>
Date: Wed, 16 May 2012 07:56:20 -0700

Hi Henry,
>end communication that it has had such positive effects. The reasons 

That is how things were.  How things are is a matter of religion.

>problems. Luckily the network effect works in favour of those who 

Sometimes technical reasons are used as a reason for not doing a 
non-technical change.  The technical folks declare an issue as out of 
scope while the non-technical folks assume that the technical folks 
have considered and addressed the issue.  The message at 
https://www.ietf.org/mail-archive/web/dane/current/msg05009.html 
mentioned some awkward truths.  It could be said that there are good 
reasons for a person not to take a stance by side-stepping the issue(s).

Regards,
-sm

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 May 2012 11:15:29 -0400

I just wanted to +1 on John Gilmore's very well reasoned arguments.

I can not reply to each point myself, and John does it better than I.

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 May 2012 11:19:46 -0400

> attacks on the fundamental end-to-end premise of the Internet.

But (1) bugs are different from intentional blockage and (2) not all
of this is strictly speaking buggy.  The fact that some ancient
gateway can't cope with RRTYPEs it doesn't know is, IMO, a disgrace;
but they can say (correctly) that they just don't implement that RFC,
and be quite right.  I would like the market to reject such devices as
useless, but it hasn't yet.

> reliable end-to-end service without interruptions for the provider's

I suppose that the above is intended to argue that the market will
reject such devices as useless.  I think we have a first mover
principle in the way, however.  These "users" of which you speak would
need to form a fairly detailed theory of operation of the Internet in
order to understand what the problem is.  I don't believe that most of
them will, and I don't think they ought to need to either.  Therefore,
I would prefer that we build documents that permit useful incremental
addition of features to the network.

To drag this back on topic, in light of the above I need to think
harder about the argument, elsewhere in this thread, that uses 2 and 3
are also undermined by the no-answer attack, because if that's the
case then I suspect DANE is undeployable as it stands.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 May 2012 09:56:58 -0700

> blockage causes even their favorite forms of TLSA to be vulnerable.

It's there because I hadn't had time to really think about 2 and 3
but I was sure about 0 and 1.

With that said, it's not true that 2 and 3 are the same as 0 and 1. Imagine
a client which asks for TLSA records and pays attention to 2 and 3 but
ignores 0 and 1. That client could (assuming people actually serve
TLSA records) avoid showing the red screen of death for some
self-signed sites. Surely that is indeed of security value, although
it does not offer any defense against CA compromise.

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 May 2012 14:07:17 -0400 (EDT)

On Wed, 16 May 2012, Eric Rescorla wrote:

> That client could (assuming people actually serve
> TLSA records)

openswan.org and nohats.ca currently serve TLSA records, and
fedoraproject.org will publish these in a few days. nohats.ca
is also using a CA.

for testing, the site rogue.nohats.ca is signed by a different
CA that mismatches the TLSA record.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 May 2012 09:14:07 +1000

> useless, but it hasn't yet.

For the market to reject such devices it needs to be *aware* of such
devices.  When 99.999% of queries are A records the market doesn't
get the feedback it needs to operate.

When you let the faults be seen the buggy software does get removed.
How many load balancers return NXDOMAIN to AAAA queries when there
are A records at the name now?  It used to be a reasonably common
bug.  We let the pain of that bug be visible and the problem is mostly
gone.

I don't know how many times I had to say to a customer reporting a
bug in named because the lookups worked with a different nameserver
that it was a because we supported both IPv4 and IPv6 when the other
vendors didn't and that made the remote bug visible.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 16 May 2012 19:21:56 -0400

On May 16, 2012, at 11:19 AM, Andrew Sullivan wrote:

> To drag this back on topic,

Thank you -- I was away from mail for part of today and this thread was going *way* off-topic…

*Please*, lets try and keep this (and other threads on dane@) on-topic, and civil….

> in light of the above I need to think

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 May 2012 08:59:56 -0400

No, his rather emotional account is wrong.

If Gilmore was right then Tor would also be an attack on the Internet
architecture. It isn't.

Before arguing the end to end principle, I suggest that people
actually wrote what David Clarke wrote rather than second hand lore.
It is actually an argument about complexity and the cost/benefit
tradeoffs that result from placing complexity in one place or the
other. David is a pragmatist, not an ideologue.

Without NAT, the Internet would have run out of IPv4 addresses over
ten years ago. Since the design of IPv6 was intended to prevent OSI
networking from winning the standards race rather than actually
meeting the address space crunch, a solution like NAT was inevitable.

Firewalls have an important function, one that is fully understood and
accepted in the INTER-NETWORKING protocols. The core concept of the
internet is not the end-to-end principle but the idea that the
inter-net is a network of networks. The only core principles of the
Internet are that all the systems use the DNS for naming and IP is
used to exchange messages between networks.

End-to-End IP is not and never has been a core principle of the
Internet as deployed. Until 1993 when the Web appeared there was an
expectation that it would take another decade at least before networks
all converged on using just IP. Email was not designed as an end to
end protocol, it had to contend with a dozen WAN and LAN protocols. It
was only when the Web arrived with the encyclopedia galactica online
but only if you had IP, that the tipping point was established and
there was an advantage to TCP/IP end to end.

But even the Web was designed with the concept of proxies from the start.

A border firewall delineates the boundary between the network I
control and the network that I do not control and am not responsible
for. It is an obviously necessary function. I have over 50 IP
connected devices on my home network and that will almost certainly
rise to 100 as IP enabled phones and thermostats and temperature
monitors are deployed. I do not want to spend any time worrying about
applying patches to such devices. They do not require unrestricted
network access, therefore by the principle of least privilege they
must not have it.

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