Subject: [dane] how about not talking about DNSSEC Re: #36: Only requiring DNSSEC where it is needed

From: bert hubert <[email-masked]>
Date: Tue, 4 Oct 2011 08:27:37 +0200

On Thu, Sep 29, 2011 at 09:56:11AM -0700, Zack Weinberg wrote:
> >  A related issue is whether clients MUST (1) attempt a DNSSEC query, (2)
> >  fail the handshake unless the query completes with "secure" or "verified
> >  insecure" state, and (3) if a "secure" nonempty TLSA RRset is returned,
> >  process it as described in the spec.  This requirement goes hand in hand
> >  with the current statement that clients MUST fail the handshake if the
> >  server cert does not match any TLSA RR; one is not meaningful without the
> >  other.  So I think we should make both or neither of these behaviors
> >  conformance requirements (c.f. ticket:26).
> 
> Agree entirely (and I vote for "both").  Might want some wiggle room
> in the wording to allow for Adam's DANE-stapling scheme instead of
> client doing its own DNSSEC processing.

Hi everybody,

DANE is great stuff, and it specifies how you could trust certificates.

The DANE material is in turn protected by DNSSEC, so you could trust the
DANE material.

I see zero reason to burden the DANE standard with details how how DNSSEC
SHOULD or MUST be used.

This can only hurt us in the long run, say, if DNSSEC standard or practice
changes. Especially the latter.

Any hopes that implementors might not do the right thing unless they "MUST"
do now weigh up to the downsides mentioned above.

So how about we say as little as possible on DNSSEC? 

	Bert

---

From: Lutz Donnerhacke <[email-masked]>
Date: Tue, 4 Oct 2011 08:43:16 +0200

> I see zero reason to burden the DANE standard with details how how DNSSEC

I agree.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Oct 2011 08:48:45 -0400

> So how about we say as little as possible on DNSSEC?

I totally agree.

I don't think DNSSEC out to the end point client is even desirable. It
might be for a Web browser, it is certainly not desirable for embedded
devices. Since only about 10% of the computers in my house are desktop
or laptop devices and the proportion is dropping sharply, I don't see
a good case to nail DANE to one DNS security approach.

If any new protocol is going to get early adopters it is always in
areas that are currently unserved or underserved. Web Services and
embedded devices are the areas that will be relevant.

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

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 4 Oct 2011 05:57:08 -0700

> a good case to nail DANE to one DNS security approach.

I disagree, STRONGLY here.  

The recursive resolver is a failure from a security standpoint: unless the owner of the end system also owns the recursive resolver, the resolver itself must not be trusted.

Beyond OpenDNS tricks and NXDOMAIN wildcarding,  we STILL have major ISPs who are using the recursive resolver to man-in-the-middle intercept Yahoo and Bing (and Google until Google puts a stop to it with Captchas and/or legal threats).

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Oct 2011 09:10:27 -0400

> The recursive resolver is a failure from a security standpoint: unless the owner of the end system also owns the recursive resolver, the resolver itself must not be trusted.

The recursive resolver is always a trusted component in a network.
Even with DNSSEC it has the power to DoS a site. NSEC3 allows the
client to detect a DoS, but it can't find out where the site is
without circumventing the resolver.

The recursive resolver SHOULD be trustworthy.

Now that does not mean 'running it yourself' since nobody I know is
capable of doing that since humans do not come with ethernet ports and
can't do RSA in their head.

The recursive resolution needs to be done by a trustworthy server and
the communication between the client and the server needs to be
trustworthy.

But given that I can barely get my netduinos to do RSA2048 once during
startup, I really can't expect them to be verifying DNSSEC chains on
every network transaction. Nor can I push out ICANN root updates to
them in a feasible fashion.

> Beyond OpenDNS tricks and NXDOMAIN wildcarding,  we STILL have major ISPs who are using the recursive resolver to man-in-the-middle intercept Yahoo and Bing (and Google until Google puts a stop to…

'STILL'?

I thought that sort of thing was increasing rather than decreasing.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 4 Oct 2011 09:37:26 -0400 (EDT)

On Tue, 4 Oct 2011, Phillip Hallam-Baker wrote:

> I don't think DNSSEC out to the end point client is even desirable.

We disagree. Just like telnet is not desirable, DNS without DNSSEC is no
longer desirable.

> it is certainly not desirable for embedded devices.

Just like firewalls (or a decent IP stack) was not desirable for SCADA
devices? In fact, for embedded devices, people WANT DNSSEC (with raw
public keys) because it is easier to validate then a 4KB cert blob when
you don't even have a MMU.

> embedded devices are the areas that will be relevant.

Agreed. Which makes the raw public keys with dane so important....

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 4 Oct 2011 09:47:56 -0400 (EDT)

> you don't even have a MMU.

As an example, the RIPE Atlas probes do not have the memory to fetch a TLS
certificate blobs.....

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 4 Oct 2011 08:03:24 -0700

> without circumventing the resolver.

Exactly:  Circumvent the resolver whenever there is a DNSSEC failure.  Well, whenever there is any failure from it.

EG, Xerocole happily says that their NXDOMAIN wildcarding solution works with DNSSEC just fine.  It simply returns a wildcard without any signature information, trusting that the end-host will not validate it.

The recursive resolver portion of the infrastructure made sense 20 years ago.  20 years ago the code paths to do an on-the-endhost recursive resolver counted for a lot more, and load and bandwidth mattered a lot more.

Today?  Why not have every end host run its own resolver?

> The recursive resolver SHOULD be trustworthy.

But it IS NOT trustworthy.

> can't do RSA in their head.

It does mean "run by the same ownership".  

> them in a feasible fashion.

No, but in that case you could expect it to run its own direct fetch and bypass the recursive resolver.  

I would rather see end hosts NOT validating DNSSEC BUT bypassing the recursive resolver, than relying on the recursive resolver to validate DNSSEC.

An adversary who can manipulate the received to end host's DNS reply when it is bypassing the recursive resolver is already in an amazingly powerful position, and for all but DANE-type applications where DNSSEC is used to validate key material the adversary has effectively won even without manipulating DNS information.

> I thought that sort of thing was increasing rather than decreasing.

Given that most lawyers call this interception wiretapping (which has criminal as well as civil penalties), most people who find out about it STRONGLY object to it, AND the business model behind the interception (change responses to redirect through affiliate networks) has been shown non-viable as the affiliate networks themselves strongly object to this when they find out, the continued interception is quite notable that it is continuing at all.

The only temporary increase was Earthlink, but they backed off within 2 days of public disclosure, so it hasn't been increasing.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 4 Oct 2011 11:19:55 -0400

> As an example, the RIPE Atlas probes do not have the memory to fetch a TLS

Bad example.  ATLAS probes are based on the Lantronix XPort Pro platform, which has this on its spec page:
"
SSLv3 and SSHv2 Client & Server, Selectable 128/256/512/1024 Bit certificates
"
<http://www.lantronix.com/device-networking/embedded-device-servers/xport-pro.html>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 4 Oct 2011 12:22:37 -0400 (EDT)

> <http://www.lantronix.com/device-networking/embedded-device-servers/xport-pro.html>

The developers found it to be impossible with their memory footprint, which is more
then just running a single TLS client from busybox..... Or perhaps lantronix tested
with self signed PKIX, and not with a real life giant blob of PKIX with a few
intermediary CAs.

The point is, embedded devices are severely constrained in memory and cpu. PKIX-TLS
can be impossible as real-life examples (over vendor specs) have shown.

Paul

---

From: James Cloos <[email-masked]>
Date: Tue, 04 Oct 2011 16:20:04 -0400

>>>>> "NW" == Nicholas Weaver <[email-masked]> writes:

NW> Today?  Why not have every end host run its own resolver?

There are still memory issues for just-big-enough virtuals and for
embedded systems.  But I've been using and advocating resolvers on
each desktop/workstation/server type host since the mid '90s.

Some environments have local-only zones; the resolving/verifying
ns would require separate glue for those (in addition to the root
glue) and a way to know when, if portable, it is in a location
where said local zones could resolve.

At the very least every administrative domain should have its own
resolving (and now validating) nameserver.  Or set of them, when-
ever there are multiple hosts on the lan.

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

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 04 Oct 2011 21:18:03 -0700

> So how about we say as little as possible on DNSSEC? 

It's true that we could frame the spec in terms of an abstract integrity
protection scheme for DNS data rather than specifically referring to
DNSSEC, but I'm not sure what realistic gain in generality you foresee
that would justify the decrease in directness.

We do need to stipulate that additive assertions MUST NOT be processed
unless they are integrity protected, otherwise DANE would regress
security.  It is also our duty to point out that, if clients wish to
gain security from integrity-protected restrictive assertions, they must
(1) fully enforce the rules of the integrity protection scheme to
confirm the presence or absence of such assertions, failing closed if
unable to do so, and (2) process such assertions when present.

These two points constitute the essential DANE security model.  If we
are making other statements about DNSSEC, those might merit
reconsideration.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 04 Oct 2011 21:21:19 -0700

> a good case to nail DANE to one DNS security approach.

The case is "the spec might as well be more direct", unless you can name
an DNS security approach other than DNSSEC to which we would want to
generalize.  Note that delegation over a secure channel to an external
DNSSEC resolver the client chooses to trust does not count as a
different approach with respect to the discussion of DNSSEC in the spec.

-- 
Matt

---

From: bert hubert <[email-masked]>
Date: Wed, 5 Oct 2011 09:28:02 +0200

> that would justify the decrease in directness.

It works like this. Standards are a lot like government laws. When we have a
law that governs certain things, lawmakers try not to write the law to be
too specific, since that would lead to frequent legislative activity just to
keep things working. If you define a car too narrowly, people will find ways
to build cars that are not "Cars".

If we just specify DANE, and leave open how to make sure the data you get is
the authentic data, we can leave all the rest to *other* standards.

This leaves a lot of room for innovation. Trusted channels, DNSSEC
successors, perhaps even 'stapled' certificates.

If we however interweave DANE with DNSSEC, we will get a standard that is
overbearing. It not only tells us how DANE works, it tells us how to
specifically use DNSSEC.

And while DNSSEC right now is the most obvious way to do it, it need not be
the only way. I am also not sure that the DNSSEC advice we would dish out
now will stand the test of time as well as the DANE fundamentals.

> are making other statements about DNSSEC, those might merit

I agree fully. In general, we might simply say that only authenticated data
MUST be used.  Everything else doesn't get you anywhere.

	Bert

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 05 Oct 2011 09:24:56 +0100

Some AD input on this in aspect of the thread:

DANE MUST define an interoperable protocol.

Note - I'm not saying anything about whether anything needs to
be mandatory to use in any particular circumstance, I'm saying
that the WG is tasked with defining an interoperable way to do
some stuff that requires integrity of some DNS data. And afaik,
we don't have thousands of DNS integrity mechanisms from which
to choose.

Just saying: "sprinkle dust; get DNS integrity" is not sufficient
for DANE IMO. The WG need to specify how that integrity, which
is at least sometimes required, can be achieved, and you need
to do that in an interoperable way that covers the "last mile"
issue.

So I don't think you really have a "say nothing about DNSSEC"
option to be honest.

S.

---

From: Henry Story <[email-masked]>
Date: Wed, 5 Oct 2011 14:10:21 +0200

> So how about we say as little as possible on DNSSEC? 

I think there is something to this: Separate semantics and behaviour. Just have one
short RFC that describes the information that goes into DNS, explain what it means in terms such as:

  the owner of the domain asserts that for service S the public key used by that service is pk

  or 

  the owner of the domain asserts that for service S the X509 certificate used by that service is xxx

  or

  the owner of the domain asserts that for service S the X509 certificate used by that service is signed by CA c

Then have another document that describes how clients should behave, or how they should reason about this. 

I think how clients should behave is nearly obvious once you have the pieces in place, at least obvious per application and context. So of course if those data structures are on DNS unprotected, then you don't gain much
security with having the info there. On the other hand if the info is 

The logic of such trust thinking is probably beyond an IETF group, and should be moved to a space where logicians and engineers can get together to specify things of this nature.

Henry

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

Social Web Architect
http://bblfish.net/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 5 Oct 2011 11:27:58 -0400

In other words, make sure that the spec is bound to 'DNS Security' not
DNSSEC version 2011.

That is my view as well.

If I was working on DNSSEC at the mo I would be arguing against tight
coupling lest DANE end up constraining change options in DNSSEC.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 5 Oct 2011 12:13:59 -0400 (EDT)

> to do that in an interoperable way that covers the "last mile"

I think DANE should state that when DNSSEC is required, it should
be DNSSEC including last mile protection. It should not try to
specify how to solve the last mile issue on the client.

Is that what you meant? I first read this as "DANE should specify
the last mile solution", which I thought was out of scope for DANE.

Paul

---

From: bert hubert <[email-masked]>
Date: Wed, 5 Oct 2011 23:01:58 +0200

> So I don't think you really have a "say nothing about DNSSEC"

Ok - how about specifying that DNSSEC is an appropriate way to get
authenticated data? And to only trust authenticated data?

That would get all the benefits, and none of the downsides (ie, tying down
either DNSSEC or DANE unnecessarily).

	Bert

-- 
PowerDNS Website: http://www.powerdns.com/
PowerDNS Community Website: http://wiki.powerdns.com/

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Oct 2011 17:12:10 -0400

> to do that in an interoperable way that covers the "last mile"

It's worth observing, at the same time, that the DNSSEC documents
_themselves_ punt on this issue.  RFC 4035 says this:

4.9.3.  Handling of the AD Bit

   A non-validating security-aware stub resolver MAY chose to examine
   the setting of the AD bit in response messages that it receives in
   order to determine whether the security-aware recursive name server
   that sent the response claims to have cryptographically verified the
   data in the Answer and Authority sections of the response message.
   Note, however, that the responses received by a security-aware stub
   resolver are heavily dependent on the local policy of the
   security-aware recursive name server.  Therefore, there may be little
   practical value in checking the status of the AD bit, except perhaps
   as a debugging aid.  In any case, a security-aware stub resolver MUST
   NOT place any reliance on signature validation allegedly performed on
   its behalf, except when the security-aware stub resolver obtained the
   data in question from a trusted security-aware recursive name server
   via a secure channel.

So, if you know the policy of your upstream resolver (and it's good
enough), and you know you got the AD bit over a secure channel, then
and only then may you rely on that validation.  I know of one large
vendor that claims it supports DNSSEC validation, and this is exactly
the mechanism they're using (via IPSec-delivered policy controls at
client configuration time, and IPSec-based connections from those
clients to the recursive resolver).  So we can't exactly wave this
away as a corner case, and they're still not doing DNSSEC at the end
point.  Won't help you at home, of course, but if you're in your
Enterprisey Office Land, it presumably would.

I therefore think that Bert's suggestion downthread is not a bad idea.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Martin Rex <[email-masked]>
Date: Wed, 5 Oct 2011 23:32:29 +0200 (MEST)

> Enterprisey Office Land, it presumably would.

If your Enterprixey Office Land lives in a seperate DNS universe
(with Internet DNS completely unavailable on the internal network)
which is the most reasonable configuration if you're running a
seperate network, then a "trustworthy" resolver is a non-solution.

My preferred solution would be to tunnel all the necessary DNS
records through a TLS extension, where it will transparently
work as good as TLS itself and be independent of any firewalls,
HTTP-CONNECT proxies, DNS forwards and whathaveyou.

And I would be glad if my favourite browser would support a sensible
TLS server cert pinning and alternatively TLS server-supports-DANE-via-TLSext
pinning.  The root-key-rollover for DNS-disconnected browsers/clients
would need a solution, though.

-Martin

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 06 Oct 2011 01:03:47 +0100

Hi Andrew,

Trying to clarify...

> I therefore think that Bert's suggestion downthread is not a bad idea.

I was trying (perhaps not well) to say that it would not be
acceptable for DANE to simply assert that some DNS data needs
integrity without specifying how to achieve that.

It could be that the WG adopt the kind of position you relate above
(smelly as it is, IMO for non-enterprise use-cases) but the main
point is that it a) has to be specified and b) has to be
interoperable.

Again, I am not saying which specific DNS data needs what specific
mechanism to protect it when - that's stuff the WG know way better
than I do. I'm also not saying the WG need to pick one and only
one way to do stuff, (good though that is), nor am I saying when
the WG's favorite mechanisms MUST|SHOULD|MAY need to be applied.

I'm just saying that whatever you guys figure out, it needs to
be good enough for a fairly crappy programmer (like me, I'm qualified
there:-) to be able to use the resulting RFC(s) to achieve interop and
so that deployments of that code could (if I've not screwed up as
a mediocre programmer) achieve whatever the WG consider the
necessary security properties.

I continue to disbelieve that simply asserting "integrity required"
is sufficient for the above and that, in the end, the WG *will* need
to talk about DNSSEC and how it relates to DANE data.

S.

PS: Yeah - sometimes our new sandcastles are built on our less
than ideal old sandcastles. I'm sure that'll still be true long
after I'm retired as well.

---

From: Henry Story <[email-masked]>
Date: Thu, 6 Oct 2011 10:02:17 +0200

> necessary security properties.

IT all depends what kind of programmer you are. If you are the one that needs to 
program the piece to know what data to put where in DNS then you can have one
RFC specialising in the meaning of the data. 

Then you can have another RFC on how to secure it.

Then another one on how to build a client.

Those are three separate tasks. By trying to combine them, you make your life very complicated in this group.

Social Web Architect
http://bblfish.net/

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 06 Oct 2011 09:09:42 +0100

> Those are three separate tasks. By trying to combine them, you make your life very complicated in this group.

I said nothing about how things get reduced to text in
RFCs. There are, as you say, loads of ways to do that.
The "how to secure it" work however, has to be done,
and not in the infinitely far future IMO.

S.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 6 Oct 2011 09:48:46 -0400

> point is that it a) has to be specified and b) has to be

It sounds to me, then, that the only sane thing for DANE to say is
MUST use DNSSEC, and leave it at that.  RFC 4035 tells you at the
moment what you need to do to secure the last hop.  If there's an
update to DNSSEC such that that changes, the "MUST use DNSSEC" for
everything DANE says need not change (because it can get included by
reference).  I know there are those in this thread who think that's
already too prescriptive, but as I have previously argued, I can't
imagine anyone using TLSA without DNSSEC, which is the only technology
we have for DNS integrity assurance right now.

I would be quite stronly opposed to a lot of operational advice about
how to use DNSSEC going into any documents from this WG.  It's
completely off-charter, and there's a perfectly good chartered WG over
in OPSAREA whose job that is.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 6 Oct 2011 11:05:22 -0400

To be clear, do you mean "MUST use DNSSEC for all types of DANE record", or that when there is a record that requires DNSSEC, we just need to say "use DNSSEC"?

Thanks,
--Richard

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 6 Oct 2011 12:12:46 -0400

> To be clear, do you mean "MUST use DNSSEC for all types of DANE record", or that when there is a record that requires DNSSEC, we just need to say "use DNSSEC"?

I guess the latter.  I still think people would be mad to use any DANE
record without DNSSEC, but I know not everyone agrees and I certainly
am not going to argue about that decision.

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 Oct 2011 14:41:53 -0400 (EDT)

> am not going to argue about that decision.

You cannot conclusively answer "when there is a record" without dnssec.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 6 Oct 2011 14:31:50 -0700

When Jakob and I discussed the idea of making DNSSEC optional for certificate
types 0 and 1 while still making it mandatory for type 2, we focused on the
security effects on relying parties (clients) but not zone owners (servers). A
few people objected to our proposal based on concern for the zone owners, and
we agree that they too should be considered when making the decision about
requiring DNSSEC.

If the WG agrees with this change, the following explanation (or something like
it) should appear in the document. Please let us know what you think.

==========

Relying Parties

Scenario RP-with: If a TLSA record of type 0 and 1 is received with DNSSEC,
then the relying party is sure that the zone owner is specifying that
particular certificate.

Scenario RP-without: If a TLSA record of type 0 and 1 is received without
DNSSEC, then the relying party can still safely use the TLSA record to limit
the PKIX validation. In Scenario RP-without, an attacker cannot make the
relying party use a certificate that would have otherwise been unusable for
authenticating the TLS server.

Zone Owners

Scenario ZO-with: If a TLSA record of type 0 and 1 is hosted with DNSSEC, then
the zone owner has done everything they can to assure integrity of the content
of the records to the relying party.

   Scenario ZO-with-RP-with: In scenario ZO-with, if the relying party uses
   DNSSEC, they will either receive the published TLSA records or, if the
   records were modified by an attacker, they will not get the records at all.
   In Scenario ZO-with-RP-with, an attacker gains no advantage by changing the
   data or stripping the signature because the result of doing so are the same
   as Scenario RP-without.

   Scenario ZO-with-RP-without: In scenario ZO-with, if the relying party does
   not use DNSSEC, then the relying party can still safely use the TLSA record
   to limit the PKIX validation; for an attacker, the results of Scenario
   ZO-with-RP-without are the same as Scenario RP-without.

Scenario ZO-without: If a TLSA record of type 0 and 1 is hosted without
DNSSEC, the result is always the same as for Scenario RP-without.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Fri, 7 Oct 2011 00:07:49 +0200 (MEST)

> then the relying party is sure that the zone owner is specifying that

Correct.

> authenticating the TLS server.

Still wrong.

A TLSA record of type 0 or 1 is entirely useless without DNSSEC,
because it can be fabricated at will by an active attacker.

What the attacker can not "fabricate" is to get the Server cert signed
an arbitrary CA from the TLS X.509 PKI.  But that is entirely irrelevant
here, we are discussing _only_ DANE operation.  And DANE without DNSSEC
is entirely useless, because there is no additional protection
compared to pre-DANE clients, therefore looking at the records at
all is a complete waste of CPU cycles.

-Martin

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 6 Oct 2011 15:43:10 -0700

> because it can be fabricated at will by an active attacker.

Against an active network attacker who can intercept and fabricate any
packet, I agree.

However, an unauthenticated (but assumed-legitimate) type 0/1 record
might offer additional protection against a limited network attacker
who can reterminate TLS sessions but can *not* tamper with DNS
traffic, and who additionally *does* have an improperly issued
certificate for the server whose communications they wish to
intercept.

Whether this is a realistic attacker I do not know, but I'm inclined
to rate it unlikely.  I can imagine scenarios where the attacker can't
touch UDP for some reason, but it seems to me that an attacker who has
an improperly issued certificate and the means to use it at all is
likely to be able to do arbitrary packet manipulation. Also, this
should be weighed against the false sense of security that
unauthenticated type 0/1 records might produce, when facing an
attacker who *can* forge unauthenticated DNS responses, and the
possibility of a novel DoS by generating completely bogus ones.

In conclusion, I still don't like unauthenticated TLSA records of any
kind.  Also, I don't have time to close-read the proposed text right
now, but my initial impression is that it tends to confuse rather than
clarify.  (I do still intend to completely rewrite the spec for
clarity's sake, but I don't know when I'm gonna get to it.)

zw

---

From: Douglas Otis <[email-masked]>
Date: Thu, 06 Oct 2011 16:17:25 -0700

On 10/6/11 3:43 PM, Zack Weinberg wrote:
> On Thu, Oct 6, 2011 at 3:07 PM, Martin Rex<[email-masked]>  wrote:
Martin and Zack make a good point.

A MitM attacks are not uncommon.  These may result from exploited 
network functions, corrupted spanning trees, adjacent compromised hosts, 
CPE equipment, etc, etc.  Since DANE improves security by avoiding 
reliance on otherwise untrustworthy network elements, why avoid a need 
to deploy DNSSEC on which DANE is intended to rely?

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 6 Oct 2011 16:43:46 -0700

On Oct 6, 2011, at 3:07 PM, Martin Rex wrote:

> an arbitrary CA from the TLS X.509 PKI.  

Are you saying that there is no useful attack for an attacker? If so we are agreeing; if not, I don't see what useful attack you are proposing.

> But that is entirely irrelevant

Following that line of argument, certs type 0 and 1 *with* DNSSEC are "a complete waste of CPU cycles", yes? Asked another way, what additional value to the relying party is a type 0 or 1 certificate association if they are sure that it came from the domain?

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Fri, 7 Oct 2011 01:45:46 +0200 (MEST)

Zack Weinberg wrote:
> 
> I don't have time to close-read the proposed text right
> clarify.

I did not understand the new proposed text about zone owners at
all and would probably have to read it carefully a few more times
in order to figure out what it means and whether that makes sense...

> Martin Rex wrote:
> to rate it unlikely.

I consider those scenarios where it could help unrealistic and statistically
insignificant and I'm more worried about the negative side effects.

What does it take for an attacker to make a client talk to a fake server
in posession of a fraudulent server cert from the TLS X.509 PKI that
will succeed PKIX cert path validation?

Either the attacker has to successfully spoof DNS A records (make your
client connect to the fake server) or the attacker has complete control
over the network or networking gear and can transparently MITM your
network connections with the network addresses of the real server.

An attacker could use it for his advantage when a DANE-aware TLS client
would believe in fake TLSA records, because by spoofing TLSA records
the attacker could ensure that the DANE-aware TLS client will abort
all connections to he *REAL* server with an error an only establish
connections with the fake server without a warning.  This is particularly
true if the client configures the IP-Address of the real server
in the local /etc/hosts (so that the A record can not get spoofed).

Believing in insecure TLSA would ensure that all connections to the
real server that the attacker did not manage to transparently MITM
will get aborted with a DANE-validation error, whereas all
connections to the fake server will succeed without error.

Personally, I do not even see evaluating insecure TLSA records of type 0/1
in the "obscurity" domain, but in the "pure faith" domain.

About as effective as putting up a warning sign like this:
http://lechatnoirboutique.com/proddetail.php?prod=FSNoticeAttackCity

-Martin

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 06 Oct 2011 16:48:58 -0700

> in the local /etc/hosts (so that the A record can not get spoofed).

For avoidance of doubt, this is essentially the scenario I was imagining 
when I said that unauthenticated type-0/1 TLSA could provide a false 
sense of security in the presence of a network attacker who could forge 
DNS records.

zw

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 6 Oct 2011 16:49:24 -0700

> Against an active network attacker who can intercept and fabricate any

I'll ask the same question I ask Martin: what attack is made possible by such an attacker that has any value to the attacker?

> Whether this is a realistic attacker I do not know, but I'm inclined

It seems reasonably likely to be of value to me. Assume the relying party talks to the same TLS host twice, and an attacker becomes active between those two events. If the TTL on the TLSA record from the first event is still in effect for the second event, the attack fails.

> I can imagine scenarios where the attacker can't

An attacker who can create a DoS by generating bogus TLSA records can do the same with bogus A records. TLSA does not introduce anything new there, does it?

> now, but my initial impression is that it tends to confuse rather than

That would be bad; please so find time to read it and poke holes in any of the attack scenarios.

> (I do still intend to completely rewrite the spec for

That would be much appreciated as well.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Fri, 7 Oct 2011 02:10:43 +0200 (MEST)

Zack Weinberg wrote:
> kind.

Believing in completely unprotected assertions rarely makes sense
in security protocols.

If the Server would be sending an X.509 cert with a stripped digital
signature, should the TLS client believe in the assertion to be correct
anyway (not being able to verify it against trust anchors) or
unconditionally abort?

If the client's OCSP request would be answered with an unsigned
OCSP response, should the client still evaluate the response or
ignore it?

If the client downloaded a CRL where the digital signature had been
removed, should it still be evaluating the CRL or entirely ignore it?

I firmly believe that it is (a) a bad idea to add TLSA records
to zones that are not DNSSEC signed and (b) a bad idea to
evaluate TLSA records for which the DNSSEC signature verification
could not be performed (that includes NXDOMAIN rather than NSEC/NSEC3
responses).

-Martin

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 Oct 2011 20:18:52 -0400 (EDT)

> It seems reasonably likely to be of value to me. Assume the relying party talks to the same TLS host twice, and an attacker becomes active between those two events. If the TTL on the TLSA record fr…

This scenario adds nothing to caching the PKIX certificate with
using HSTS. If you assume the client already connected once and
can re-use cached information, there is nothing TLSA adds to that.
You can then even obtain a TLSA within the PKIX cert that is actually
covered by a signature from the PKIX CA chain.

It further assumes a browser that is not restarted or keeps cache
between runs.  And the attacker would only just have to wait TTL seconds
and forge the next request for the TLSA record and return NXDOMAIN
(unvalidated!) anyway, so at best it is a temporary stop-gap.

It's simply not worth the complicated scenario descriptions of "zones",
"scenarios" and RP-without and ZO-with-RP-without terminology.

This is becoming rather the 0.001% corner case for use of DANE without
DNSSEC.  I will claim that implementors making mistakes on when DNSSEC
validation can be absent will cause a higher failure error then the
temporary gain from this obscure corner case.

I'm not in favour of distributing public keys or hashes without
cryptographic protection in general and then using such information
to make cryptographic decisions (comparing hashes). It's bad practise.

Paul

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 06 Oct 2011 17:19:00 -0700

On 2011-10-06 4:49 PM, Paul Hoffman wrote:
> I'll ask the same question I ask Martin: what attack is made possible
> by such an attacker that has any value to the attacker?

Well, there's the attack Martin just described, against a site that has 
*not* deployed TLSA, where the attacker poisons the victim's DNS cache 
with a TLSA record that specifies *the attacker's* (forged) certificate, 
thus achieving DoS precisely when their own MITM is inactive. 
(Precisely the inverse of the scenario you described, where the local 
DNS cache *protects* from an attacker who can't forge these records.)

It is my impression that local DNS caches don't last very long, which 
makes both sides of that coin not all that compelling to me.  What I 
_am_ worried about, though, is a server operator who deploys an 
unauthenticated TLSA0/1 record and honestly believes that this will 
defend against a MITM armed with a forged certificate, because the 
possibility that the MITM can tamper with the DNS has not occurred to 
them!  Remarkable foolishness?  Perhaps, but nobody ever went broke by 
overestimating the foolishness of any given group of people, eh?

> Assume the relyingparty talks to the same TLS host twice, and
 > an attacker becomes active between those two events. If the TTL
 > on the TLSA record from the first event is still in effect for
 > the second event, the attack fails.

See above re: expiry of local DNS caches.

> An attacker who can create a DoS by generating bogus TLSA records
 > can do the same with bogus A records. TLSA does not introduce
 > anything new there, does it?

A records can be pinned in /etc/hosts; TLSA forgery might permit a DoS 
against someone who's been so diligent as to do so.  (I imagine that 
very, very few people do this, but it is a possibility.)

>> Also, I don't have time to close-read the proposed text right
>> now, but my initial impression is that it tends to confuse
 >> rather than clarify.
>

It would help me if you said approximately where you mean to add this to 
the current draft.

zw

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 Oct 2011 20:24:09 -0400 (EDT)

On Thu, 6 Oct 2011, Zack Weinberg wrote:

> Well, there's the attack Martin just described, against a site that has *not* 
> deployed TLSA, where the attacker poisons the victim's DNS cache with a TLSA 
> record that specifies *the attacker's* (forged) certificate, thus achieving 
> DoS precisely when their own MITM is inactive. (Precisely the inverse of the 
> scenario you described, where the local DNS cache *protects* from an attacker 
> who can't forge these records.)

The idea PaulH presented I think was one where an insecure dane record can
reduce the scope of PKIX validated certs, not assert anything outside the PKIX
scope, so in this scenario the DANE record would be ignored, because it is
outside the scope of what the PKIX chain said was valid.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 6 Oct 2011 17:30:53 -0700

On Oct 6, 2011, at 5:24 PM, Paul Wouters wrote:

>> Well, there's the attack Martin just described, against a site that has *not* deployed TLSA, where the attacker poisons the victim's DNS cache with a TLSA record that specifies *the attacker's* (forged) certificate, thus achieving DoS precisely when their own MITM is inactive. (Precisely the inverse of the scenario you described, where the local DNS cache *protects* from an attacker who can't forge these records.)
> 

Exactly right. Zack: you do understand that this proposal is to not require DNSSEC on types 0 and 1 *only*, yes?

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 6 Oct 2011 17:38:44 -0700

> covered by a signature from the PKIX CA chain.

Correct. TLSA is useful for HTTP-over-TLS that does not use HSTS, as well as (foo-that-is-not-HTTP)-over-TLS as well.

> (unvalidated!) anyway, so at best it is a temporary stop-gap.

Just to be clear, we are not assuming an HTTP browser. Also, the description above applies if the client restarts; it only does not apply if the DNS cache is flushed. And, yes, it is only a temporary stop-gap, but one that we do not have today.

> "scenarios" and RP-without and ZO-with-RP-without terminology.

That terminology is there for folks who say that there is an attack introduced by cert types 0 and 1 being not covered by DNSSEC. The terminology does not change the protocol.

> temporary gain from this obscure corner case.

If you are only concerned with HTTP browsers that use HSTS, I might agree. However, the WG is supposed to be dealing with all TLS clients, such as those for SIP, email, and so on.

> to make cryptographic decisions (comparing hashes). It's bad practise.

If we thought that DNSSEC was already well-deployed to clients today or next year, I would agree with you. But we all know it is not. Thus, this proposal.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Fri, 7 Oct 2011 03:26:47 +0200 (MEST)

Paul Hoffman wrote:
> 
> That terminology is there for folks who say that there is an attack
> introduced by cert types 0 and 1 being not covered by DNSSEC.
> The terminology does not change the protocol.

I think we're talking past each other, and may simply have to
agree to disagree to end this debate.

If you believe the PKIX folks (and in particular the commercial CA
operators) then DANE cert types 0 and 1 are entirely useless
(i.e. needless complexity) because subverting a CA is impossible.

DANE cert types 0 and 1 are only really useful against attackers
for which (1) obtaining TLS server certs that validate und
TLS X.509 PKI is quite doable and either (2a) reliably DNS-spoofing
your TLS client is easy or (2b) reliably MITM your TLS clients
network connections is easy.  Under those premises it really does
not make sense to deceive yourself that unprotected TLSA records
provide any security value at all.  I firmly believe they do not,
but they will likely create the dangerously false impression that
unsigned DNS records are trustworthy in any way.

> 
> If we thought that DNSSEC was already well-deployed to clients today
> or next year, I would agree with you. But we all know it is not.
> Thus, this proposal.

Then let's put our energy into creating an TLS extension for conveying
the necessary DNSSEC records from the TLS server to the TLS client
inband.

By creating the dangerously misleading impression that DNS replies
are trustworthy without DNSSEC, you will only further delay adoption
of both, DNSSEC and DANE.

-Martin

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 6 Oct 2011 19:04:52 -0700

On Thu, Oct 6, 2011 at 5:30 PM, Paul Hoffman <[email-masked]> wrote:
>> scope,

Yes, I understood that.

>> so in this scenario the DANE record would be ignored, because it is

Not if the attacker has an improperly issued server certificate that
does in fact chain to some root certificate the victim relies on.
That's already a disaster, but unsecured TLSA records potentially make
it *worse*, by causing the RP not to trust the legitimate server's
certificate anymore.  That is my understanding of Martin's scenario.

> Exactly right. Zack: you do understand that this proposal is to not require DNSSEC on types 0 and 1 *only*, yes?

Yes. I have been arguing that even that is a bad idea from the beginning.

zw

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 6 Oct 2011 19:07:33 -0700

On Thu, Oct 6, 2011 at 5:38 PM, Paul Hoffman <[email-masked]> wrote:
> If you are only concerned with HTTP browsers that use HSTS, I might agree.
> However, the WG is supposed to be dealing with all TLS clients, such as
> those for SIP, email, and so on.

I do not see why non-HTTP clients are any more or less vulnerable than
HTTP clients in the scenarios we are talking about.  Please elaborate.

zw

---

From: Scott Schmit <[email-masked]>
Date: Fri, 7 Oct 2011 10:22:26 -0400

> Following that line of argument, certs type 0 and 1 *with* DNSSEC are "a complete waste of CPU cycles", yes? Asked another way, what additional value to the relying party is a type 0 or 1 certifica…

If DNSSEC is required, there are two failure cases:
A) The DNSSEC data is secure, but the PKIX chain doesn't match
B) The DNSSEC data is bogus

For A, the RP knows that one of the following is true:
A1) One of the CAs trusted by the RP's TA list is compromised
A2) One of the DNSKEYs in the DNSSEC chain is compromised
A3) There's been a misconfiguration

A3 is a constant issue. Putting that aside, the RP can weigh the
relative probability of A1 or A2 and determine if it wants to proceed
anyway. Depending on the size of the unconstrained TA/trusted CA pool,
A1 is probably far likelier than A2. If A2 is likelier to you than A1,
you probably aren't going to bother use DANE.

For B, the RP knows that one of the following is true:
A3) There's been a misconfiguration
B1) It's under attack
B2) It's on a network that is "benignly" manipulating DNS (see B1)
B3) It's using DNS servers that don't comply with the latest specs
    (so stop relying on them & retry)

Because DNSSEC is required in this scenario, we can't even compare the
record to the PKIX cert chain. Something is clearly wrong.

If we make DNSSEC optional for type 0/1, we have these cases:
A) The DNSSEC data is secure, but the PKIX chain doesn't match
B) The DNSSEC data is bogus
C) The DNSSEC data is unsecure, and the chain doesn't match
D) DNSSEC was used, the RP ignores DNSSEC, and the chain doesn't match
   (not sure if anyone is proposing this or not)

For C, the RP knows that one of the following is true:
A1) One of the CAs trusted by the RP's TA list is compromised
A3) There's been a misconfiguration
C1) One of the authoritative servers in the NS chain is compromised
C2) One of the DNS resolvers the RP is relying on have been poisoned
C3) Some other MITM is manipulating the DNS traffic

Again putting aside A3, the RP must weigh the probability of C1-3 vs A1.
C1-3 is relatively easier. Of course, perhaps both A1 and one of C1-3 is
true. In any case, A1 is no longer clearly more likely than the
alternatives. So now DANE is only useful when it isn't needed?

For D, depending on what form the "DNSSEC is optional for 0/1" takes, it
may be allowable for a DANE client to ignore the DNSSEC information
completely, in which case you not only get all the failure cases from C,
but also A & B because you didn't recognise them.

But if you require that a DANE client check DNSSEC, but allow for
unsecure (not bogus) records, you get all the downsides of DNSSEC
checking (B2, B3, increased probability of A3) as well as C1-3 for the
unsigned data.

I don't think the benefit is really worthwhile.

I suppose a consequence of requiring DNSSEC for all cases is that the
market chooses not to use DANE because too much stuff breaks DNSSEC.
That's a risk. But if DANE is watered down to be too little benefit, the
market will choose something else anyway.

-- 
Scott Schmit

---

From: Martin Rex <[email-masked]>
Date: Sat, 8 Oct 2011 01:57:03 +0200 (MEST)

> B) The DNSSEC data is bogus

"DNSSEC data is secure" lumps two situations together, and
"PKIX chain doesn't match" also appears to lump two situations together.
(the latter seems to be a defect of the dane-protocols I-D).

The traditional server certificate check consists of a few independent
checks:

   (a1)  PKIX cert path validation of server cert (rfc5280, section 6.1ff)
   (a2)  matching of server cert with server hostname
        (rfc2818 section 3.1 or rfc6125)

   (b) matching against "pinned" server cert
       (e.g. rfc6125 section 6.2.2
        or http://www.w3.org/TR/wsc-ui/#sec-interactively

Secure DNSSEC responses also come in various flavours
   (I)  NSEC/NSEC3  ("proof of non-existence")
   (II) TLSA records

> A1) One of the CAs trusted by the RP's TA list is compromised

Huh?  If an attacker has compromised a CA, then both PKIX cert path
validation and traditional server name matching with succeed.

And there is no way for the RP to *know* anything here, that would more
likely amount to coffee ground reading rather than scientific certainty.

> A2) One of the DNSKEYs in the DNSSEC chain is compromised

At he moment, it is probably *much* easier to sneak records into the
database that feeds the DNSSEC zone signing process than to
attack the crypto functions or keys. 

> A3 is a constant issue.

Agreed.

>
> Putting that aside, the RP can weigh the relative probability
> of A1 or A2 and determine if it wants to proceed anyway.

I don't know whether you think of code or user when you write
"RP can weigh".  Personally, I'm violently opposed for *code*
attempting heuristics here, and I was under the impression that
"RP" refers only to code, and never to "decision based on
risk assessment by a(n interactive) human user".

> Again putting aside A3, the RP must weigh the probability of C1-3 vs A1.

Rather than attacking the crypto stuff,
an attacker might break into the real server, steal the real servers
TLS server credential and then mount an attack on TLS clients where
it can transparently MITM the network traffic.
PKIX cert path validation, server identity matching and DNSSEC-protected
TLSA records will all validate.  No need to attack any of the latter.

MITM attacks on TLS clients aren't that hard, in particular on
mobile clients.  IPv6 neighbour discovery was a nice enabler
for transparent connection MITM.  :-/

transparent MITM of network connections is standard functionality
of networking gear.  WLAN access points with captive portals
do it all the time.

-Martin

---

From: Scott Schmit <[email-masked]>
Date: Fri, 7 Oct 2011 22:47:01 -0400

> (the latter seems to be a defect of the dane-protocols I-D).

I'm not sure where you're trying to go with this. I was responding to
Paul's question about what value signing usage 0/1 TLSA records has.

You're right that we could have secure denial of existence, but in that
case, we fall back to standard PKIX processing, and DANE is no longer
relevant. The matching I was referring to was DANE matching, not PKIX
processing to ensure that the certificate matches the domain name. If
the latter fails, the certificate isn't going to work with or without
DANE, so it's not a DANE failure case.

> validation and traditional server name matching with succeed.

Yes, but the DANE matching won't.

> likely amount to coffee ground reading rather than scientific certainty.

For the record, I never claimed that the RP knows *which* is the
case. But if that's how you read "know", substitute "has good reason to
believe" instead.

As I'm sure you realize, we're trying to weigh the trade-offs of
requiring or not requiring DNSSEC protection of usage 0/1 TLSA records.
Security isn't black & white, it's about risk assessment. In my email, I
tried to enumerate the failure cases & the possible causes.

The RP must weigh the likelihood of the various causes and decide what
to do in response. Of course, most users aren't equipped to make that
decision, so it's done by the software developers on their behalf in the
form of the client itself.

We need to think about how protocol changes affect that risk assessment
to determine if the reward is worthwhile.

> attack the crypto functions or keys. 

Right. I meant "the CA-like entities that sign DS records". Still, I'd
argue that if you don't control what your key signs, you don't really
have control over your key and it's effectively compromised until you
regain control.

I hope this clears up any confusion.

-- 
Scott Schmit

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Oct 2011 11:42:43 -0700

It truly doesn't feel like there is rough consensus in favor of our proposal, so Jakob and I withdraw it. Based on the feedback received, we will certainly try to clarify the use of DNSSEC in the next draft.

--Paul Hoffman

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 14 Oct 2011 15:48:22 +0200

> in OPSAREA whose job that is.

+1 on this position from me.

DNSSEC is the technology for securing DNS we have now in IETF.  If there
is anything shiny, the DANE could be updated to use this.  Hence I am
against being too general by saying non-specific "DNS security".

O.
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 14 Oct 2011 15:52:33 +0200

On 7. 10. 2011, at 0:43, Zack Weinberg wrote:

> touch UDP for some reason

Doesn't have to be such complicated scenario.  It could be the attacker
who sits close(r) to the server "wire", but not close enough to the DNS
"wire".

O.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 14 Oct 2011 16:02:03 +0200

> network connections with the network addresses of the real server.

Let's see...

youtube.com HTTP servers are in 209.85.148.0/24 (advertised as 209.85.128.0/17
in BGP), but youtube.com DNS servers are in 216.239.34.0/24 (advertised as /24).

So an attacker could f.e. hijack 209.85.148.0/24, but you will still get
protection from DANE unless the attacker also hijacks 216.239.34.0/24.

And it's not that unrealistic scenario, since similar hijack already had
happened in the past.

O.

---

From: Martin Rex <[email-masked]>
Date: Fri, 14 Oct 2011 16:38:53 +0200 (MEST)

O. wrote:
> youtube.com HTTP servers are in 209.85.148.0/24 (advertised as
> 209.85.128.0/17 in BGP), but youtube.com DNS servers are in
> 216.239.34.0/24 (advertised as /24).
> 

You're missing the point.

The TLS/DANE client will be unable to distinguish an attacker sitting
close to the server and an attacker sitting close to itself, so
the client has ZERO chance to know whether an _unprotected_ TLSA record
that it received is original or was spoofed/inserted by an attacker.

Btw. for inserting/spoofing DNS records it is *NOT* necessary to MITM
network connections (although this facilitates a few things).

-Martin

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 14 Oct 2011 16:44:16 +0200

> You're missing the point.

Looks like we both are :).  Lemme clarify.

> that it received is original or was spoofed/inserted by an attacker.

I know, but you (or Zack) have argued that it has a zero value, because
the TLS CERT and TLSA DNS record will be spoofed at the same time.

I am just arguing that there are some use cases where even unprotected
TLSA record will make things better.  I think we agree that it doesn't
make things worse, don't we?

Ondrej

---

From: Henry Story <[email-masked]>
Date: Fri, 14 Oct 2011 16:23:37 +0200

> against being too general by saying non-specific "DNS security".

Of course DNSsec is the right thing for security. But I think the aim of this is just
to split the work in two:

 1. Just speak about the DNS data structures. publish an RFC for that
 2. Write another RFC that explains how this ties to DNSEC in particular

The point is that it is obvious that if you put your data in DNS with the sec, then
the claims made by your DNS cannot be relied upon. 

Every endpoint just makes a claim. If you cannot trust the endpoint or you cannot
trust that you received the message from the endpoint then you cannot trust the claim.
That is simple to understand. 

The other thing is what a TLS client should do when it receives
claims from multiple parties. Well what it will do will of course depend on who it trusts
the most, and how it wishes to combine trust assertions. This is clearly quite an open field.
If a CA is super trustworthy and the DNS provider is not at all then it may be better to ignore
the dns provider. If it is the other way around, then the DNS provider gets the advantage. 
If both agree then we are in heaven.

 Henry

Social Web Architect
http://bblfish.net/

---

From: Henry Story <[email-masked]>
Date: Fri, 14 Oct 2011 16:46:09 +0200

Btw, just an other point. Splitting the syntax form the semantics has been done
before at the IETF: The Atom Working group produces 1 spec on the Atom Syntax,
and then one on the atom protocol.

Henry

Social Web Architect
http://bblfish.net/

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 14 Oct 2011 08:01:45 -0700

> and then one on the atom protocol.

This is a terrible idea for a new DNS RRtype. The example that Henry gives is a poor one for the DANE WG. The format was meant to be able to be read and written in many different fashions; the protocol document was for exactly one way of writing the format. (I am quite familiar with the situation given that I was co-chair of the WG...)

--Paul Hoffman

---

From: Henry Story <[email-masked]>
Date: Fri, 14 Oct 2011 17:08:39 +0200

> This is a terrible idea for a new DNS RRtype. The example that Henry gives is a poor one for the DANE WG. The format was meant to be able to be read and written in many different fashions; the prot…

Why is it a terrible idea? DNS is not any different than any other publication mechanism. It's archaic ok, but really it just published data. So all you are doing by publishing something there is making a statement, just as you are by putting an atom feed or document on the web. 

The nice thing is that you could have one part done already, and then move to the more complicated piece of proofs and trust, which are independent of what is being said.

Henry

Social Web Architect
http://bblfish.net/

---

From: Martin Rex <[email-masked]>
Date: Fri, 14 Oct 2011 17:09:05 +0200 (MEST)

> the TLS CERT and TLSA DNS record will be spoofed at the same time.

On the contrary.  The ONLY purpose of DNS TLSA records of usage 0/1
is to provide a means to the DNS admin to repudiate certs that
look fine under TLS X.509 PKI validation.

And that functionality is entirely lost without DNSSEC, because
an attacker could spoof TLSA records if the client would accept them
without DNSSEC, and the client has no means to notice that it was
spoofed.

It is vital that when the client can not DNSSEC validate TLSA records
exactly as if DANE validation was impossible to perform.  And once
you are at that point, looking at the contents of unprotected TLSA
records is a waste of time, and implementers who do will regularly
fail to implement it in the fashion "no DANE validation possible".

> make things worse, don't we?

No, it will not make things better, but it can easily make things much worse.
Unless a TLSA client is able to DNSSEC validate the response, it has no
clue whether it received all the information that the DNS admin put in
there.  It could be that some of those middleboxes (home gateways,
firewalls and what-have-you) fail to forward only specific records
(instead of all records of a type), so if you fail a TLS connect
because the (non-malicious, just dense) middle box on your path
and beyond your control does not forward specific records, then
we've newly created an interop problem.  Given that we *KNOW* that
there are a number of serious problems with forwarding of DNS data
in the installed base, we should not go down this path.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 16 Oct 2011 12:17:22 -0400

+1

At this point it seems highly unlikely that DANE will be deployed in the
browser using only DNS transport for the reasons stated by the browser
providers. The legacy DNS infrastructure is just not good enough to rely on
it as a mechanism for key distribution.

The Kaminsky/Langley approach of pickling out the chain into the cert (or
the OCSP token) is likely to be the preferred mode of DANE use for a very
considerable time.

Separating these concerns is going to be essential to achieving deployment.

On Fri, Oct 14, 2011 at 11:08 AM, Henry Story <[email-masked]>wrote:

> > This is a terrible idea for a new DNS RRtype. The example that Henry
> gives is a poor one for the DANE WG. The format was meant to be able to be
> read and written in many different fashions; the protocol document was for
> exactly one way of writing the format. (I am quite familiar with the
> situation given that I was co-chair of the WG...)
>
> Why is it a terrible idea? DNS is not any different than any other
> publication mechanism. It's archaic ok, but really it just published data.
> So all you are doing by publishing something there is making a statement,
> just as you are by putting an atom feed or document on the web.
>
> The nice thing is that you could have one part done already, and then move
> to the more complicated piece of proofs and trust, which are independent of
> what is being said.
>
>
>
> Henry
>
>
> >
> > --Paul Hoffman
> >

---

From: Warren Kumari <[email-masked]>
Date: Mon, 17 Oct 2011 14:04:12 -0400

Apologies for terseness, grumpy tone not intentional -- very limited Internet access.
On Oct 16, 2011, at 12:17 PM, Phillip Hallam-Baker wrote:

> +1
> 
> At this point it seems highly unlikely that DANE will be deployed in the browser using only DNS transport for the reasons stated by the browser providers. The legacy DNS infrastructure is just not good enough to rely on it as a mechanism for key distribution.
> 
> The Kaminsky/Langley approach of pickling out the chain into the cert (or the OCSP token) is likely to be the preferred mode of DANE use for a very considerable time.

While cool and sexy, I don't think that it can be called DANE -- from the charter:

"Objective:

Specify mechanisms and techniques that allow Internet applications to
establish cryptographically secured communications by using information
distributed through DNSSEC for discovering and authenticating public 
keys which are associated with a service located at a domain name.
"

and 
"This working group will develop mechanisms for zone operators to
present bindings between names within their control and public keys, in
such a way that these bindings can be integrity-protected (and thus
shown to be authentically from the zone operator) using DNSSEC and
used as a basis for authentication in protocols that use domain names as
identifiers."

If the WG is sufficiently motivated we can discuss charter amendment, but I think it would be better to first complete the "how to do this with DNS" (the D in DANE) before starting on "how to do this with foo"

W

> On Fri, Oct 14, 2011 at 11:08 AM, Henry Story <[email-masked]> wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Oct 2011 14:32:27 -0400

I think there are two sets of issues

1) To what degree and in what ways can a DANE statement be trusted without
authentication

2) How is DNSSEC used as a mechanism to establish the authenticity of a DANE
statement?

I agree with Stephen that DANE has to do (2). Even if I am not going to use
DNSSEC itself as my authentication scheme, I am going to use something that
maps onto DNSSEC in some way.

So just lijke DANE has to specify how it is used with TLS, DANE has to
specify how it is used with DNSSEC. But that does not mean that it is
acceptable to state MUST use DNSSEC.

On Wed, Oct 5, 2011 at 12:13 PM, Paul Wouters <[email-masked]> wrote:

> ______________________________**_________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/dane<https://www.ietf.org/mailman/listinfo/dane>
>

---

From: Martin Rex <[email-masked]>
Date: Mon, 17 Oct 2011 20:43:03 +0200 (MEST)

Warren Kumari wrote:
> 
> Phillip Hallam-Baker wrote:
> > 
> > At this point it seems highly unlikely that DANE will be deployed in
> > the browser using only DNS transport for the reasons stated by the
> > browser providers. The legacy DNS infrastructure is just not good
> > enough to rely on it as a mechanism for key distribution.
> > 
> > The Kaminsky/Langley approach of pickling out the chain into the 
> > cert (or the OCSP token) is likely to be the preferred mode of DANE
> > use for a very considerable time.

Or a TLS extension (i.e. the Server returning all necessary DNSSEC
records marshalled into a ServerHelloExtension after the client indicated
support and willingness to receive this information by offering the
extension in a ClientHelloExtension.

> If the WG is sufficiently motivated we can discuss charter amendment,
> but I think it would be better to first complete the "how to do this
> with DNS" (the D in DANE) before starting on "how to do this with foo"

I agree with PHB that DANE should limit itself to describe which
DNSSEC records are necessary and need to be verified in what fashion,
and that we entirely exclude the mechanims of how to obtain them
from the DANE spec.  domain (53/udp) and domain (53/tcp) are just
two possibilities for obtaining DNSSEC information, but they're
certainly not the only ones.  The DANE spec ought to be entirely
independent of the transport through which the DNSSEC records
are obtained and focus on the operations necessary to validate
the information.

The security properties of DNSSEC are by intention to make it
independent from transport (data origin authentication and data
integrity protection) so that it properties are not affected by
intermediate DNS server caching this data.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 17 Oct 2011 20:59:06 +0200 (MEST)

> acceptable to state MUST use DNSSEC.

I disagree here.

I would very much like DANE to require DNSSEC validation (MUST), and
ignore DANE-related DNS records (really, really SHOULD NOT) that are
not DNSSEC validated.

But I'm violently opposed to mandating that DNSSEC records must be
obtained by a DANE client over domain (53/udp) or domain (53/tcp)
transports.

It should be at the discretion of DANE clients to cache whichever DNSSEC
records they see fit -- and to obtain DNSSEC records through alternative
means, e.g. through a TLS extension, OCSP extension or Server Cert extension.
Personally I dislike Server cert extensions where it incurs frequent
server cert changes (this is alien to server cert pinning)
and I dislike OCSP requests by the client, because of their privacy
issues, unless the OCSP responses are conveyed by the peer himself,
e.g. through a stapled-OCSP-responses TLS extension.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Oct 2011 19:59:06 -0400

What if people want to use Convegence rather than DNSSEC?

I have a real problem with placing exclusive reliance on a PKI where the
operator is attempting to reserve the right to drop names from the registry
without a court order.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Oct 2011 23:13:42 -0400 (EDT)

> What if people want to use Convegence rather than DNSSEC?

Then they are not using DANE. Out of scope for this draft and WG.

> I have a real problem with placing exclusive reliance on a PKI where the operator is attempting to reserve the right to drop names from the registry without a court order.

That problem is also out of scope for DANE. If the registry drops your domain,
you no longer have a domain. No DNS, no DNSSEC, no DANE. Choosing your operator
or registry is out of scope for DANE.

Can we please stay or target here. Thanks.

Paul

---

From: Warren Kumari <[email-masked]>
Date: Tue, 18 Oct 2011 08:04:34 +0200

Warren Kumari
------
Please excuse typing, etc -- This was sent from a device with a tiny keyboard.

> Then they are not using DANE. Out of scope for this draft and WG.

+lots

> Can we please stay or target here. Thanks.

+even more lots...

Folk are welcome to use Convergence,  stapling, pickling, a wet noodle, etc., but this is not the right forum to discuss them. If we don't get a move on with DANE itself, the other solutions may end up becoming the standard - which may be perfectly fine, but it would be sad if that occurred purely because standards developed in the IETF take too long...

So, as Paul said, let's stay on topic...

W

---

From: Henry Story <[email-masked]>
Date: Tue, 18 Oct 2011 08:22:16 +0200

>> Then they are not using DANE. Out of scope for this draft and WG.

Convergence is working in a RESTful web way I believe. So in that case it would probably use a different format to express the same semantic content. DANE is clearly a DNS technology. No harm in working with the old way of doing things, and defining it for this framework. They can all complement each other.

> Folk are welcome to use Convergence,  stapling, pickling, a wet noodle, etc., but this is not the right forum to discuss them. If we don't get a move on with DANE itself, the other solutions may en…

That is exactly why I suggested that DANE Should publish the formats needed to express what is being said, and explain with those formats mean declaratively: who is stating what about whome.  That could be done within a month. Then you can move on to the more complicated problems of what should happen, and who should trust whome in another document. So this would just be a way of speeding up the release of the DANE groups work.

Henry

Social Web Architect
http://bblfish.net/