Subject: [dane] Fixing DANE to resolve properly with DNS

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Jul 2011 10:17:36 -0400

At present the draft makes no mention of CNAME, the only mention of
wildcards is

"Wild Cards -- Covered in the TLSA request syntax.

Redirection  -- Covered in the TLSA request syntax."

You may think this answers the question, I do not. This is proof by
unsubstantiated assertion.

The issues that concern me are use cases of the form:

1) A DNS administrator wishes to create an equivalence between two DNS names
such that all resources that are associated with one will apply to the
other.

e.g. alias www.example.com to example.com

www.example.com               CNAME example.com

_443._tcp.example.com         TLSA  ....

Problem: No means is specified that will allow a client to discover the TLSA
record.

Attempting to resolve for _443._tcp.www.example.com results in 'not found'.
So the administrator is required to specify:

www.example.com               CNAME example.com

_443._tcp.www.example.com     TLSA  ....

_443._tcp.example.com         TLSA  ....

This is bad because it means that we now have two points where the TLSA
record has to be maintained. The value of having an alias is lost.

Possible solution:

One way to solve this is to note that any client is going to have to also
look up the A record for the service. Thus if the A record lookup returns an
alias, the client is required to retry the lookup for the canonical name.

A typical lookup is thus going to be:

Phase 1:

Query1:   www.example.com ? A
Query2:  _443._tcp.www.example.com ? TLSA

Both queries fail but we get a CNAME as an additional record (and likely the
A record). So we perform a second phase:

Query1:   example.com ? A
Query2:  _443._tcp.example.com ? TLSA

This appears to work with any form of aliasing. The rule that I think
applies to prefixes is that they only work on a canonical name. So don't
look for them till they are canonical.

2) Wildcards

Wildcards are much harder to deal with because they began as a server
feature, not as part of the protocol. There is no midpoint wildcard
(x.*.y.z)

A wildcard of the form *.example.com is going to play havoc with any
prefixed record as it will resolve for any prefix.

Conclusion: TLSA records SHOULD NOT be wildcarded.

To create the effect of a wildcard TLSA record the approach that should be
used is to apply the wildcard to an alias, for example:

*.example.com                       CNAME wildcard.example.com

_443._tcp.wildcard.example.com      TLSA  ....

wildcard.example.com                A 127.0.0.1

Attempting to resolve any domain in example.com (other than
wildcard.example.com) will now result in a wildcarded CNAME being returned
that provides a canonical name to which the prefix can be applied.

These approaches are actually general and can be applied when any prefixed
record is being used.

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

---

From: Jakob Schlyter <[email-masked]>
Date: Sun, 17 Jul 2011 20:35:41 +0200

17 jul 2011 kl. 16:17 skrev Phillip Hallam-Baker <[email-masked]>:

> 1) A DNS administrator wishes to create an equivalence between two DNS names such that all resources that are associated with one will apply to the other.
> 

Why not add a CNAME for the prefixed name? E.g., 
_443._tcp.example.com. CNAME _443._tcp.example.com.

> 2) Wildcards
> 
> Wildcards are much harder to deal with because they began as a server feature, not as part of the protocol. There is no midpoint wildcard (x.*.y.z)
> 
> A wildcard of the form *.example.com is going to play havoc with any prefixed record as it will resolve for any prefix.
> 

I'm not too sure this is a real problem, given that people already played havoc by using wildcards in the first place. A lot of other services are already broken when wildcards are used. 

> To create the effect of a wildcard TLSA record the approach that should be used is to apply the wildcard to an alias, for example:
> 
> Attempting to resolve any domain in example.com (other than wildcard.example.com) will now result in a wildcarded CNAME being returned that provides a canonical name to which the prefix can be applied.

Sure, although that would work only if the TLSA client can detect the address was the result of a CNAME. 

  Jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Jul 2011 18:30:30 -0400

On Sun, Jul 17, 2011 at 2:35 PM, Jakob Schlyter <[email-masked]> wrote:

> 1) A DNS administrator wishes to create an equivalence between two DNS
> names such that all resources that are associated with one will apply to the
> other.
>
> e.g. alias <http://www.example.com>www.example.com to <http://example.com>
> example.com
>
>
> <http://www.example.com>www.example.com               CNAME
> <http://example.com>example.com
>
> _443._ <http://tcp.example.com>tcp.example.com         TLSA  ....
>
>

That defeats the purpose of CNAME, if you are going to do that you might as
well just copy all the entries from one node to the other. Maintaining the
CNAME links is going to be pretty much as hard as copying the destination.

The problem is harder when you have outsourcing. If I CNAME
www.hallambaker.com to my blogger blog, I want that to map to anything
Google then do from then on without having to do any more config. In fact I
would have to change my DNS hosting to do any more config.

Support for CNAME means supporting the use cases CNAME is designed to meet,
not merely proposing a mechanism that works technically but looses the point
of CNAME entirely.

> A wildcard of the form *. <http://example.com>example.com is going to play
> havoc with any prefixed record as it will resolve for any prefix.
>
> I'm not too sure this is a real problem, given that people already played
> havoc by using wildcards in the first place. A lot of other services are
> already broken when wildcards are used.
>

I think you need to be a bit more specific to make that argument.

Wildcards work just fine for HTTP. If you are proposing a spec to work with
HTTP you probably want to make it work with wildcards.

 I am proposing a mechanism here that makes it work properly.

My personal criteria for whether I support the draft in IETF last call is
whether it actually works with DNS or not.

If the spec does not actually work with aliases or wildcards then I am not
going to be able to build on it myself so I won't be able to recommend it
for any status higher than experimental.

Again, I am proposing a fix here, not just raising a problem.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 17 Jul 2011 15:50:11 -0700

On Jul 17, 2011, at 7:17 AM, Phillip Hallam-Baker wrote:

> At present the draft makes no mention of CNAME, the only mention of wildcards is
> 
> You may think this answers the question, I do not. This is proof by unsubstantiated assertion.

Actually, we didn't think it answered the question; we just got lazy. We should add more about this in the next draft, definitely.

> Problem: No means is specified that will allow a client to discover the TLSA record.
> 
> Attempting to resolve for _443._tcp.www.example.com results in 'not found'. So the administrator is required to specify:
> 
> This is bad because it means that we now have two points where the TLSA record has to be maintained. The value of having an alias is lost.

It does mean that there are two points where the TLSA record has to be maintained, and that is a security feature. In addition to your example, consider:

www.example.com CNAME www.notexample.notcom
_443._tcp.www.example.com TLSA ...

If the zone administrator for www.example.com can specify what the certificates should be validated for www.notexample.notcom, that is a serious security flaw.

> Possible solution:
> 
> One way to solve this is to note that any client is going to have to also look up the A record for the service. Thus if the A record lookup returns an alias, the client is required to retry the lookup for the canonical name.
> 
> Both queries fail but we get a CNAME as an additional record (and likely the A record). So we perform a second phase:
> 
> Query1:   example.com ? A
> This appears to work with any form of aliasing. The rule that I think applies to prefixes is that they only work on a canonical name. So don't look for them till they are canonical.

The first part is definitely correct: the prefixes only apply to the actual name of the host. I don't see the reason for the second part, however. Why not look up the prefixed name? If you get NXDOMAIN and an alias for the unprefixed name, you have lost nothing.

> Conclusion: TLSA records SHOULD NOT be wildcarded.

Please be more specific. Do you mean "the host name for which there is a prefixed TLSA record SHOULD NOT also be wildcarded" or "the host name that contains a prefix and that has a TLSA record SHOULD NOT be wildcarded"?

> These approaches are actually general and can be applied when any prefixed record is being used.

Have they been dealt with in other IETF protocols that use prefixes? It would be great if we can reuse words from those RFCs.

--Paul Hoffman

---

From: Scott Schmit <[email-masked]>
Date: Sun, 17 Jul 2011 18:53:06 -0400

> alias, the client is required to retry the lookup for the canonical name.
<snip>
> used is to apply the wildcard to an alias, for example:
<snip>
> These approaches are actually general and can be applied when any prefixed

I agree with this approach -- this is how I saw it working too.

-- 
Scott Schmit

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Jul 2011 20:33:37 -0400

> > Both queries fail but we get a CNAME as an additional record (and likely
> the A record). So we perform a second phase:
> >
> > Query1:   example.com ? A
> The first part is definitely correct: the prefixes only apply to the actual
> name of the host. I don't see the reason for the second part, however. Why
> not look up the prefixed name? If you get NXDOMAIN and an alias for the
> unprefixed name, you have lost nothing.
>

Looking up the prefixed name is not the problem, having to specify it for
each alias is the problem.

Better statement would be 'don't stop looking for them till you have a
canonical name'.

> Please be more specific. Do you mean "the host name for which there is a
> prefixed TLSA record SHOULD NOT also be wildcarded" or "the host name that
> contains a prefix and that has a TLSA record SHOULD NOT be wildcarded"?

I mean that in general no TLSA record should ever be wildcarded, nor should
any SRV, URI, ESRV, or any other record that takes a prefix.

The only case where wildcarding a TSLA record is going to make sense is if
the statement you want to make is for all TCP ports at a DNS name.

The more general wildcard would be for all services running a specific
protocol: _443._tcp.*.example.com

To get that effect you need to introduce a layer of indirection and that is
why fixing the CNAME semantics is vital. You can create a CNAME for *.
example.com and that can point to  a location that has the TLSA record.

> Have they been dealt with in other IETF protocols that use prefixes? It
> would be great if we can reuse words from those RFCs.
>

No, it has generally been held that this is an insoluble protocol problem.

Retry on the canonical name is the simplest approach for DANE. For SRV and
URI the objective is to support Web Services and the approach described in
ESRV is more appropriate.

That also has a two phase discovery approach but with two different RR
types. The first phase uses the GSRV record which is never prefixed, the
second looks for the ESRV record which is salways prefixed and always bound
to a canonical name.

The reason fixing SRV and URI does not help much on their own is that they
are examples of advanced discovery services rather than an exhaustive
enumeration of all possible advanced discovery services. The choice of
discovery mechanism should be made by the site, not the Web Service protocol
designer.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 17 Jul 2011 18:00:05 -0700

On Jul 17, 2011, at 5:33 PM, Phillip Hallam-Baker wrote:

> Better statement would be 'don't stop looking for them till you have a canonical name'.

That seems like good advice. We can add that.

> I mean that in general no TLSA record should ever be wildcarded, nor should any SRV, URI, ESRV, or any other record that takes a prefix.

This seems like advice ("think carefully before wildcarding a TLSA record") rather than a mandated (SHOULD/MUST) requirement. We can add that.

> The only case where wildcarding a TSLA record is going to make sense is if the statement you want to make is for all TCP ports at a DNS name. 

And that seems like a good reason to wildcard at the first prefix.

> The more general wildcard would be for all services running a specific protocol: _443._tcp.*.example.com
> 
> To get that effect you need to introduce a layer of indirection and that is why fixing the CNAME semantics is vital. You can create a CNAME for *.example.com and that can point to  a location that has the TLSA record.

Sounds right.

> No, it has generally been held that this is an insoluble protocol problem.

Good enough.

--Paul Hoffman

---

From: Scott Schmit <[email-masked]>
Date: Sun, 17 Jul 2011 21:38:13 -0400

On Sun, Jul 17, 2011 at 03:50:11PM -0700, Paul Hoffman wrote:
> > 1) A DNS administrator wishes to create an equivalence between two
> > DNS names such that all resources that are associated with one will
> > apply to the other.
> > 
> > Attempting to resolve for _443._tcp.www.example.com results in 'not
> > found'. So the administrator is required to specify:
> > 
> > This is bad because it means that we now have two points where the
> > TLSA record has to be maintained. The value of having an alias is
> > lost.
> 
> It does mean that there are two points where the TLSA record has to be
> maintained, and that is a security feature. In addition to your
> example, consider:
> 
> If the zone administrator for www.example.com can specify what the
> certificates should be validated for www.notexample.notcom, that is a
> serious security flaw.

This could be a security tradeoff made by the owner of example.com. If
the TLSA record is present at www.example.com, then it can be enforced
on www.notexample.notcom. If it's not present, the TLSA record at
www.notexample.notcom is used instead. If I own both example.com and
notexample.notcom, I'm obviously not going to worry about nefarious acts
by myself.

That said, this opens a new question: if I have a chain of CNAMEs, how
many TLSA record sets am I required to look at to decide if the
certificate I get is the right one? For each name in the chain? Just the
first one? Just the last one? The first and the last?

If we have to check all of them, then I worry about how complicated the
check is going to be. An earlier email about the use case draft
mentioned that it should allow for expressing multiple constraints at
once (AND) as opposed to multiple independent constraints (OR) like we
have now in the dane draft.

When we combine that with the rollover requirement, and the need to
check each name in a CNAME chain, you end up needing to check the AND of
the simultaneous constraints (mechanism not yet explained in the current
draft), the OR of sets of constraints (for rollover), and the AND of
each constraint set in the CNAME chain. I'm not sure how well-tested
that code path will be in most clients.

It seems like the best way to do it that gets what everybody wants is to
check the first name in the chain that has TLSA records and ignore any
after that.

-- 
Scott Schmit

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Jul 2011 21:53:35 -0400

> > certificates should be validated for www.notexample.notcom, that is a

I don't see the problem here. The alias is from www.example.comto
www.notexample.notcom

Anyone can point any domain anywhere they please, but they cant affect the
interpretation of the target when someone types that in.

At the moment anyone can point a CNAME at paypal.com. Does that really
matter?

There might be a security issue somewhere there. HTTP world is complex and
there are a lot of really bad security assumptions built into some of the
scripting stuff. But I doubt there is anything here going to be unique to
DANE.

> first one? Just the last one? The first and the last?

How many CNAMEs are you going to go to to find the A record?

Its going to be the same number. Either you eventually get to a canonical or
you give up.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 17 Jul 2011 20:24:00 -0700

On Jul 17, 2011, at 6:53 PM, Phillip Hallam-Baker wrote:

> I don't see the problem here. The alias is from www.example.com to www.notexample.notcom
> 
> Anyone can point any domain anywhere they please, but they cant affect the interpretation of the target when someone types that in.
> 
> 
> At the moment anyone can point a CNAME at paypal.com. Does that really matter? 

Earlier on this thread, you argued that the owner www.example.com should be able to make an alias to example.com that would have the person resolving think that the TLSA record for www.example.com is also the one for example.com. "This is bad because it means that we now have two points where the TLSA record has to be maintained. The value of having an alias is lost." Do you believe that the owner www.example.com should be able to make an alias to www.notexample.notcom that would have the person resolving think that the TLSA record for www.example.com is also the one for www.notexample.notcom? The next time the person goes to www.notexample.notcom, assuming that the aliased TLSA record's TTL has not expired, they won't try to get the TLSA record, and will instead use the one that came from www.example.com.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Jul 2011 23:48:49 -0400

On Sun, Jul 17, 2011 at 11:24 PM, Paul Hoffman <[email-masked]>wrote:

> > Anyone can point any domain anywhere they please, but they cant affect
> the interpretation of the target when someone types that in.
> >
> >
> Earlier on this thread, you argued that the owner www.example.com should
> be able to make an alias to example.com that would have the person
> resolving think that the TLSA record for www.example.com is also the one
> for example.com. "This is bad because it means that we now have two points
> where the TLSA record has to be maintained. The value of having an alias is
> lost." Do you believe that the owner www.example.com should be able to
> make an alias to www.notexample.notcom that would have the person resolving
> think that the TLSA record for www.example.com is also the one for
> www.notexample.notcom? The next time the person goes to
> www.notexample.notcom, assuming that the aliased TLSA record's TTL has not
> expired, they won't try to get the TLSA record, and will instead use the one
> that came from www.example.com.
>
>
Absolutely not.

The pointers go in one direction.

Data that is bound to www.example.com is valid for that domain and no other.
Any client that made use of that data for www.notexample.notcom in any other
context than that of following an alias from www.example.com is wrong.

Data that is bound to www.notexample.notcom applies to
www.example.comthough. That is the point of the CNAME.

So probably a good idea to have a comment to the effect that caches have to
store the data in sensible form here. It is certainly wrong and stupid to do
it the other way, but people have repeatedly done such things in DNS code in
the past.

One corner case that comes up is what to do if there is data in both places,
which should take precedence?

---

From: Scott Schmit <[email-masked]>
Date: Mon, 18 Jul 2011 08:23:00 -0400

On Sun, Jul 17, 2011 at 11:48:49PM -0400, Phillip Hallam-Baker wrote:
> One corner case that comes up is what to do if there is data in both
> places, which should take precedence?

If you reread my email (the one you replied to), you'll see that I
already brought up this point and proposed a solution.

-- 
Scott Schmit

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 18 Jul 2011 08:27:03 -0400

> The pointers go in one direction.

I'll note that there have been suggestions in the past (but no I-D as
far as I've seen) to put an ALIAS record on the target side, as a kind
of assurance that the target of the xNAME knows that it is such a
target.  Would there be any value in pursuing that line of thinking?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 Jul 2011 09:42:00 -0400

> already brought up this point and proposed a solution.

I was trying to capture it for the writeup. It is easy enough to solve but
everyone needs to solve in the same way or there will be ambiguity.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 Jul 2011 09:46:13 -0400

> target.  Would there be any value in pursuing that line of thinking?

I tend to think it is a much lower priority than getting security policy
fixed in general. In fact I think that is going to be a pre-condition as any
use of this scheme is going to be optional and thus face the downgrade
attack issue.

One problem any scheme of that type is going to face is the fan-in problem.
There could be a million CNAMEs pointing to the same name. So any reverse
alias scheme has to use prefixes as well...

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 18 Jul 2011 20:24:06 +0200

> _443._tcp.www.example.com TLSA ...

I'd prefer if the CNAME is used for the address only and a separate CNAME for the certificate association.  This way, the domain name holder can choose if he wants to delegate both addressing (A/AAAA) and TLSA, or just one of them.

  Jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 Jul 2011 15:43:29 -0400

How can you make that work with wildcards?

On Mon, Jul 18, 2011 at 2:24 PM, Jakob Schlyter <[email-masked]> wrote:

> maintained, and that is a security feature. In addition to your example,
> consider:
>
> <http://www.notexample.notcom>www.notexample.notcom
> I'd prefer if the CNAME is used for the address only and a separate CNAME
> for the certificate association.  This way, the domain name holder can
> choose if he wants to delegate both addressing (A/AAAA) and TLSA, or just
> one of them.
>
>   Jakob
>
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>
>

---

From: Martin Rex <[email-masked]>
Date: Tue, 19 Jul 2011 00:04:51 +0200 (MEST)

> At the moment anyone can point a CNAME at paypal.com. Does that really

No, it doesn't matter.  CNAMEs are completely irrelevant _and_ invisible
to server endpoint identification in TLS.  They slow down
the gethostbyname() call to obtain an IP-Address but are otherwise
invisible to the app.

All of the occurrences of CNAME in http://tools.ietf.org/html/rfc6125
read

    CNAME canonicalization is not done.

-Martin

---

From: Tony Finch <[email-masked]>
Date: Tue, 19 Jul 2011 19:06:27 +0100

> CNAME links is going to be pretty much as hard as copying the destination.

No. The CNAME links are exactly parallel, of the form

original		CNAME	target
_443._tcp.original	CNAME	_443._tcp.target

The CNAME target will be much less volatile and subject to operational
change than the contents of the A, AAAA, and TLSA records. Outsourcing
makes no difference.

There are other protocols that have this non-problem, e.g. DKIM.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet: Northwest becoming cyclonic then north, 4 or 5, occasionally
6. Slight or moderate. Rain or showers. Moderate or good.

---

From: Tony Finch <[email-masked]>
Date: Tue, 19 Jul 2011 19:13:19 +0100

Phillip Hallam-Baker <[email-masked]> wrote:
> store the data in sensible form here.

That kind of recommendation is for dnsop and is off-topic for this wg.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay: Northwest, backing west or southwest for a time, 5 to 7. Moderate or
rough. Showers then rain. Good, becoming moderate or poor.

---

From: Tony Finch <[email-masked]>
Date: Tue, 19 Jul 2011 19:15:04 +0100

> alias, the client is required to retry the lookup for the canonical name.

That would require a DANE client to use custom resolution code instead of
just using a generic lookup function.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon: Cyclonic becoming northerly 4 or 5, increasing 6 or 7 for a time in
far southwest. Moderate or rough. Rain then showers. Moderate or poor,
becoming good.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Jul 2011 14:29:27 -0400

No, in this case the cache being referred to was an in-application cache.

The Security Considerations have to cover the whole protocol. Even it DNSops
also has to address it, the protocol docs have to alert them to the
dependency.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Jul 2011 14:30:59 -0400

> just using a generic lookup function.

Not a problem, DANE libraries are going to have to have DNSSEC processing
anyway.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Jul 2011 14:50:10 -0400 (EDT)

On Tue, 19 Jul 2011, Phillip Hallam-Baker wrote:

> Not a problem, DANE libraries are going to have to have DNSSEC processing anyway. 

Or look for the AD bit on the localhost dnssec resolver.

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 19 Jul 2011 11:51:39 -0700

> Or look for the AD bit on the localhost dnssec resolver.

The system APIs currently don't support this, so why not bake the resolver library into the app if you have to change the API anyway, because the AD bit is a fiction unless you know exactly what is doing the validating.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 19 Jul 2011 21:12:37 +0200

> How can you make that work with wildcards?

Your suggestion to look up the prefixed names based on the canonical hostname would indeed work. However, if we would implement that, I do believe that the TLSA RR of the original hostname should take precedence.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Jul 2011 16:20:33 -0400

If they can see the AD bit they can see the CNAMEs.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Jul 2011 16:24:29 -0400

On Tue, Jul 19, 2011 at 3:12 PM, Jakob Schlyter <[email-masked]> wrote:

> Your suggestion to look up the prefixed names based on the canonical
> hostname would indeed work. However, if we would implement that, I do
> believe that the TLSA RR of the original hostname should take precedence.

I don't much care what the precedence is, just as long as there is one
specified and it is found to be reasonable in the light of implementation
experience.

We also need to decide on the circumstances in which the name shown to the
user (if any) is going to be the source and the circumstances in which it is
the destination.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 19 Jul 2011 16:40:57 -0400

> Or look for the AD bit on the localhost dnssec resolver.

I will point out that the last time the AD bit came up in any DNSEXT
meeting, someone (Rob Austein?) got up at the mic and said something
along the lines of, "We have to get the message across that the AD bit
is for debugging."  I'm aware that a large vendor based in Redmond
thinks otherwise.

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Jul 2011 17:56:09 -0400 (EDT)

> is for debugging."  I'm aware that a large vendor based in Redmond

That is the same as saying "all apps have to link to a dnssec capable
resolver"

Which means, unless they somehow magically share a cache, every app will
be generating queries to validate the entire path to the root. Everytime
they start.

That seems sub-optimal to me.

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 19 Jul 2011 14:57:29 -0700

> That seems sub-optimal to me.

And those get trapped by either the local system resolver cache or the ISP's cache...

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Jul 2011 18:08:52 -0400

> is for debugging."  I'm aware that a large vendor based in Redmond

To the extent that said vendor has a consistent opinion on the matter I
think you will find that it is coming from a group of people that includes
at least one person who hasTuring award for his contributions to computer
security theory.

Now you can disagree with their conclusion but I don't think you can assume
that it is based on ignorance.

---

From: John Gilmore <[email-masked]>
Date: Tue, 19 Jul 2011 17:06:21 -0700

> Or look for the AD bit on the localhost dnssec resolver.

If Microsoft wants to ship insecure software, nobody can stop them;
indeed nobody has been able to stop them for decades.  That doesn't
mean that the DANE group should be designing insecure protocols that
can be subverted by toggling a single bit in an unsecured packet.

And could we tone down the indirect "we won't really tell you who said
this, but you can assume it comes from a giant corporation in a large
northwestern state who has a cubicle next to a guy who got a Turing
award" type of argument?  If you have an argument, please state it
directly.

	John

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 19 Jul 2011 20:15:42 -0400

On Tue, 2011-07-19 at 17:06 -0700, John Gilmore wrote:
> [...] That doesn't
> can be subverted by toggling a single bit

Specious argument.  Think of S_IWOTH on /etc/passwd.

> in an unsecured packet.

Privileged ports on localhost are not subject to interception.  I think
deployers can make an appropriate decision as to whether they want to
accept the claims of a localhost resolver.

-- 
Matt

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Jul 2011 21:36:08 -0400 (EDT)

> And those get trapped by either the local system resolver cache or the ISP's cache...

And if the system resolver is dnssec aware, why not trust the AD bit to localhost?

An ISP cache is nice, but if it means 5 roundtrips over 3G, it still sucks to do that
for every app on my phone.

Paul

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 21 Jul 2011 11:24:04 -0400

> is for debugging."  I'm aware that a large vendor based in Redmond

Strictly speaking what he said was "unprotected AD bit is for debugging 
only". Microsoft uses TSIG to protect the contents of the answer between 
their clients and servers.

for historical background see RF3655
The most important paragraph is in section 3:
    A resolver MUST NOT blindly trust the AD bit unless it communicates
    with a recursive nameserver over a secure transport mechanism or
    using a message authentication such as TSIG [RFC2845] or SIG(0)
    [RFC2931] and is explicitly configured to trust this recursive name
    server.

The secure transport mechanism covers 127.0.0.1 and IPSEC, ssh-tunnel ....

(shameless plug) RFC3655 Section 4 is quite enlightening in the DANE 
context.

	Olafur

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 27 Jul 2011 02:36:30 -0400

> just using a generic lookup function.

Indeed.  We have a choice of requiring the client to peek under the
covers of the DNS or introducing a new DANE-specific signaling mechanism
on top of DNS.  I would tend to prefer the former, but new arguments may
come to light.

libunbound has ub_result::canonname; I don't know about popular
non-validating stub resolvers.

-- 
Matt