Subject: [dane] CNAMES and Wildcards

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

Following the discussion in the WG meeting, my position is this:

* DANE can go forward to WGLC without the wildcard and alias issues being
fully addressed but it should not become a standards track RFC until they
are fully addressed.

There are two routes forward:'

1) Fix the problems in the DANE WG using the approach proposed.
2) Propose the fix to DNSEXT and wait for it to be progressed there.

I do not see any reason to make progress in DANE dependent on DNSEXT. DANE
is fully competent to make proposals with respect to the handling of the
TLSA record in my view. Clearly a proposal to adopt this approach as a
general approach to other prefixed RRs is something that DNSEXT should
consider, but that is  not relevant to DANE.

Since DANE requires the client to be able to process DNSSEC RR chains, the
ability to acquire and process CNAME records is already present in the spec.

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

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 31 Jul 2011 07:51:06 -0700

On Jul 30, 2011, at 9:30 PM, Phillip Hallam-Baker wrote:

> * DANE can go forward to WGLC without the wildcard and alias issues being fully addressed but it should not become a standards track RFC until they are fully addressed.

Can you be more specific about what you mean by "fully addressed"? Jakob and I did a pass at that in the current document, showing how DANE works with CNAMEs, DNAMEs, and wildcards, but are quite open to the WG telling us to change it or add more. (We have queued some minor changes for the next draft for typos in the appendix.)

> I do not see any reason to make progress in DANE dependent on DNSEXT. DANE is fully competent to make proposals with respect to the handling of the TLSA record in my view. Clearly a proposal to adopt this approach as a general approach to other prefixed RRs is something that DNSEXT should consider, but that is  not relevant to DANE.

This disagrees with what you say above about "should not become a standards track RFC". There are many standards-track RFCs that deal with CNAMEs and wildcards just like DANE does, except without the additional explanation we have added.

> Since DANE requires the client to be able to process DNSSEC RR chains, the ability to acquire and process CNAME records is already present in the spec.

Quite right.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 31 Jul 2011 11:23:31 -0400

On Sun, Jul 31, 2011 at 10:51 AM, Paul Hoffman <[email-masked]>wrote:

> Can you be more specific about what you mean by "fully addressed"? Jakob
> and I did a pass at that in the current document, showing how DANE works
> with CNAMEs, DNAMEs, and wildcards, but are quite open to the WG telling us
> to change it or add more. (We have queued some minor changes for the next
> draft for typos in the appendix.)

By fully addressed I mean that there is a defined algorithm for resolving
DANE DNS RRs that is compatible with administrative use cases for use of
Wildcare and alias (CNAME, DNAME) records.

The current appendix suggests options but does not mandate a particular
behavior. Thus DNS administrators deploying DANE cannot rely on these
records actually working.

> > I do not see any reason to make progress in DANE dependent on DNSEXT.
> DANE is fully competent to make proposals with respect to the handling of
> the TLSA record in my view. Clearly a proposal to adopt this approach as a
> This disagrees with what you say above about "should not become a standards
> track RFC". There are many standards-track RFCs that deal with CNAMEs and
> wildcards just like DANE does, except without the additional explanation we
> have added.

That is not relevant for the following reasons:

1) It is the deployment experience from use of those prefix records that
motivated the work to define this mechanism.

2) At the time there was no proposed solution that would enable correct
handling of the RRs.

3) The only prior proposal that involved restrictive trust statements in the
DNS is the DKIM policy mechanism.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 31 Jul 2011 08:44:13 -0700

On Jul 31, 2011, at 8:23 AM, Phillip Hallam-Baker wrote:
> By fully addressed I mean that there is a defined algorithm for resolving DANE DNS RRs that is compatible with administrative use cases for use of Wildcare and alias (CNAME, DNAME) records.

OK, then can you say specifically what you mean by "compatible with administrative use cases"? That phrase is not used in the WG's use cases document that has gone through the WG and IETF Last Calls.

> The current appendix suggests options but does not mandate a particular behavior.

Can you say why it should mandate particular behavior that is different than for, say, DKIM or SRV which also rely on name prefixing? 

> Thus DNS administrators deploying DANE cannot rely on these records actually working.

Why not? They work fine for the rest of the DNS: why makes TLSA special here?

If TLSA is actually different than normal RRtypes, we should say that in a prominent place in the protocol document. Proposed wording is welcome.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 31 Jul 2011 13:51:38 -0400

Sent from my iPhone

> OK, then can you say specifically what you mean by "compatible with administrative use cases"? That phrase is not used in the WG's use cases document that has gone through the WG and IETF Last Call…

There are many problems with the way this WG has proceeded. I raised the concern then, I stated the degree of my concern. I have not retracted.

I do not agree that consensus has been demonstrated on any point whatsoever.

This appears tome to be a new interpretation of the use cases document. Thus I am re-raising those concerns with respect to use cases which must not proceed either. I will be raising these in IETF last call.

> Can you say why it should mandate particular behavior that is different than for, say, DKIM or SRV which also rely on name prefixing? 

Fixing legacy is difficult. Thus it is entirely consistent to say that no more legacy should be created with a known set of problems.

> Why not? They work fine for the rest of the DNS: why makes TLSA special here?

They do not work. The premise is wrong and so is the conclusion.

> If TLSA is actually different than normal RRtypes, we should say that in a prominent place in the protocol document. Proposed wording is welcome

Is it? Is it really?

Seems to me that when you say that it is a way to try to close off discussion rather than a genuine request for text. Each time I have offered text I have been told that the issue has already been decided.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 31 Jul 2011 12:12:11 -0400

Dear colleagues,

I am sorry I was unable to make the DANE meeting on Friday either in
person or remotely.  I was called away on urgent family business.
Nevertheless, I have read the document.  I have yet to read a complete
and coherent critique of the current text in the document.  In particular,

> records actually working.

that requirement is completely bogus.  DNS zone operators have and
have always had a wide degree of operational freedom with their zones.  

The above seems to suggest that DANE might try to require one and only
one way to use DNAME and CNAME records (not to mention wildcards) in a
zone in the presence of RRTYPEs that are the result of DANE work.  But
we don't get to make those rules.  All we can do is say, "Here's what
you need to take into consideration."  It's the operator's zone.  S/he
will do as s/he pleases.  All we can do is suggest tactics to maximize
interoperation.

For instance, my personal advice with respect to wildcards and the
proposals I've seen so far on this mailing list (including those that
have been rejected) is, "Don't do that."  I don't believe anyone will
get wildcards and any such security mechanism right, and I think it is
borrowing trouble to try to use them.  But I'm not the Internet Cops,
and I don't want to be either.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 31 Jul 2011 14:54:20 -0400

> have always had a wide degree of operational freedom with their zones.

They can stuff records in zones.

But they can't predict what effect the records will have unless the
resolution semantics are defined. And if they can't predict the effect of a
configuration they can't use it.

> will do as s/he pleases.  All we can do is suggest tactics to maximize

What is at issue here is a requirement for client application developers.

The operator can't make an informed decision if different client take
different approaches.

That is why it is a standards issue.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 31 Jul 2011 12:11:55 -0700

>> If TLSA is actually different than normal RRtypes, we should say that in a prominent place in the protocol document. Proposed wording is welcome

Yes and yes.

> Seems to me that when you say that it is a way to try to close off discussion rather than a genuine request for text. Each time I have offered text I have been told that the issue has already been…

Proposing text after there is WG consensus is, indeed, counterproductive. There is no WG consensus on this issue which you have just brought up, albeit unclearly. The WG can better find consensus if you propose the actual text you want in the protocol document for this topic.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 31 Jul 2011 16:26:01 -0400

> That is why it is a standards issue.

Then it seems to me you need to send text.  I haven't seen such text,
and in fact I still don't understand even remotely why you think the
current text is wrong.

-- 
Andrew Sullivan
[email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 31 Jul 2011 19:34:08 -0400

> and in fact I still don't understand even remotely why you think the

Sending text would be appropriate if the issue was a disagreement over the
precise wording. In this case we do not appear to have agreement on the
principle so asking for wording seems premature.

The issue with the current wording is that it is a set of options in an
appendix.

I want to see there be precisely one correct approach to resolving TLSA
records and that it be in the main body of the text.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 31 Jul 2011 16:56:00 -0700

On Jul 31, 2011, at 4:34 PM, Phillip Hallam-Baker wrote:

> Sending text would be appropriate if the issue was a disagreement over the precise wording. In this case we do not appear to have agreement on the principle so asking for wording seems premature.

Asking for wording is *never* premature. This WG has gotten into long discussions over issues, only later to discover that the proposer had a different idea than what was discussed. That's a waste of time.

> The issue with the current wording is that it is a set of options in an appendix. 
> 
> I want to see there be precisely one correct approach to resolving TLSA records and that it be in the main body of the text.

Proposed wording for the main body of the text:

   TLSA records are retrieved in exactly the same manner as all other DNS
   records are today.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 31 Jul 2011 21:44:59 -0400

> principle so asking for wording seems premature.

Well, then, perhaps you can explain to me what it is that is wrong
about "TLSA is another RRTYPE like all other RRTYPES, and it resolves
in exactly the same way."  That's what the document says now, and you
keep waving your hand saying that it's wrong.  How?  I'm a simpleton.
Explain to me what the problem is, ideally by walking through an
example.

Do I think there are giant pits underneath this RRTYPE if you use it
carelessly with wildcards and *NAME?  Sure.  But that was part of what
we took on when we undertook this work.  What's special?

A

-- 
Andrew Sullivan
[email-masked]