Subject: [dnsext] Does DNSSEC mean BNAME is undeployable?

From: Andrew Sullivan <[email-masked]>
Date: Tue, 10 Aug 2010 10:13:23 -0400

Dear colleagues,

When discussing the "aliasing" items for the DNSEXT charter, Olafur
and I came to the conclusion that BNAME, as currently written, is
simply incompatible with DNSSEC as currently deployed.  That seems to
me, speaking without hat, like a pretty big argument against adoption.

Olafur hasn't seen this message, because he's on vacation, so whatever
I get wrong here is all my fault and you shouldn't blame him.  This is
nevertheless my understanding of what emerged from a meeting he and I
had last week.  I'm posting it now in the interests of moving this
work along.  I'm posting as co-chair, but as a
befuddled-more-than-usual (!) one.  In re-reading some previous
discussion, I think this actually rehashes some of those arguments.
It's likely a testament to my own dimness that I didn't get this
before; but in case this is helpful to others, I'm posting anyway.

In summary, to implement BNAME and be compatible with all the existing
validating resolvers already deployed, it will be necessary to have
CNAME and DNAME records available at that same owner ("domain") name
in the DNS.  This is functionally equivalent to CNAME+DNAME, and
therefore there is no practical reason to prefer the BNAME proposal.

Remember that we have largely concluded that DNSSEC validators MUST
understand DNAME (this is I think implicit in RFC 2672 and is stated
baldly in draft-ietf-dnsext-rfc2672bis-dname).  This means that all
the validators in the world can handle DNAME, and that therefore if
they get a synthetic CNAME that is unsigned, they can validate it by
validating instead the DNAME.  

The BNAME draft as it stands attempts to place a similar requirement
on validators:

   [. . .] In order to make BNAME valid in DNSSEC verification, the
   DNSSEC enabled resolvers and servers MUST support BNAME.  The
   synthesized CNAME in the answer section for the BNAME will never be
   signed.  DNSSEC validators MUST understand BNAME, verify the BNAME
   and then checking that the CNAME was properly synthesized in order
   to verify the synthesized CNAME.

This is, of course, not going to work: there is no way to require,
retroactively, that deployed code support an RRTYPE with specialized
server-side rules and modified DNSSEC rules.  Any existing validator
will treat a BNAME-derived synthetic CNAME inside a signed zone as
bogus.  We may not know what all the problems are that need solving,
but we have strong reason to suppose that BNAME is partly supposed to
be a solution for problems in or near the root.  This would mean
either that validation from the very beginning of deployment would
experience failures, or that we'd have a validator-upgrade flag day.
Neither seems acceptable.

A way around this is to solve the problem with a signalling bit (call
it BA, for BNAME Aware) that allows a query originator to signal
whether it can handle BNAME.  If BA=1, then BNAME is handled as
described in draft-yao-dnsext-bname-03.  If BA=0, but DO=1, then the
client gets a synthetic CNAME _and_ a synthetic DNAME.  The synthetic
DNAME needs to be signed as though it were a regular DNAME in the zone
(which either means online signing or that the server supports having
a DNAME and a BNAME at the same owner name, and has differential rules
for which data it hands out).  If BA=0, and DO=0, then the answer is a
synthetic CNAME (and signatures don't matter).

But notice that the approach effectively requires CNAME+DNAME, at
least for existing resolvers that set DO=1.  If that's right, then
there's practically no benefit to BNAME.

An alternative, of course, is to have no backward compatibility
attempts (i.e. no CNAME synthesis &c).  This requires a signalling bit
still, but it does not require any synthesis of other RRs.  The
disadvantage is that no existing resolver can follow the BNAME, so the
value of the effort is questionable.

Also, if this argument is right, DNSSEC effectively means that future
server-side processing rules are going to be very hard to justify --
even harder than they used to be.

I'd appreciate comments on any of this, in light of our plan
(i.e. Olafur's and mine, as chairs) to have a new version of the
charter in time for our self-imposed deadline in September.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 10 Aug 2010 23:29:13 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 10, 2010 10:13 PM
Subject: [dnsext] Does DNSSEC mean BNAME is undeployable?

> me, speaking without hat, like a pretty big argument against adoption.

we will update it soon based on the dnsext discussion.
 
> therefore there is no practical reason to prefer the BNAME proposal.

bname is much clearer.

if you loose cname to have a dname, the user may not know why.
they may configure c+dname together at the some old servers, which leads to unresolable of either cname or dname.

> the validators in the world can handle DNAME, 
>
the chairs said in the meeting that only half (?) of the servers support dname.

dname is not universially support.

>and that therefore if
> bogus.  

section 5.2 of bname draft addresses this problem.

5.2.  BNAME alias algorithm identifiers

   In order to prevent BNAME-unaware resolvers from attempting to
   validate responses from BNAME-signed zones, this specification
   allocates two new DNSKEY algorithm identifiers.  Algorithm Y, DSA-
   BNAME-SHA1 is an alias for algorithm 3, DSA.  Algorithm Z, RSASHA1-
   BNAME-SHA1 is an alias for algorithm 5, RSASHA1.

The BNAME-
   unaware resolvers will not know these new identifiers and treat
   responses from the BNAME signed zone as insecure

>
>We may not know what all the problems are that need solving,
> be a solution for problems in or near the root. 
>

bname is suitable for root.

> This would mean

why a synthetic DNAME is necessary? bname draft has never said a synthetic DNAME.

a synthetic CNAME is enough for the bname-unware clients.

> there's practically no benefit to BNAME.

no, bname does not need dname.

your assumption is totally wrong.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 10 Aug 2010 11:44:46 -0400

No hat.

> they may configure c+dname together at the some old servers, which leads to unresolable of either cname or dname.

The tests we have seen so far don't seem to support that conclusion.
In favour of that conclusion are things like qmail & its
interpretation of CNAME; that line of argument could be productive, if
someone wanted to investigate it.

> the chairs said in the meeting that only half (?) of the servers support dname.

So, to clarify, this is an issue with recursive resolvers that do not
support DNAME.  I didn't participate in the investigation, so the
details will have to wait until Olafur gets back (unles Ondrej wants
to chime in -- I think he was also involved?).  But the key thing is
to note that this is code base, not % of deployed systems.  Moreover,
the systems in question can't support DNSSEC properly, either.

>    allocates two new DNSKEY algorithm identifiers.  Algorithm Y, DSA-

Right, you're quite correct for taking me to task for not pointing
this out.  But this answer is still pretty bad, because what we're
doing in that case is promoting a barrier to DNSSEC validation: if you
don't have a BNAME-supporting validator, you don't get validation.
This issue is part of why I'm anxious to get guidance.

Also, the aliases are inadequate.  You actually need an alias for
every existing algorithm identifier.  That means you need aliases for
all the SHA2 variants and GOST as well (I'm willing to disregard MD5
because we think it oughtn't to be used anyway).
 
> why a synthetic DNAME is necessary? bname draft has never said a synthetic DNAME.

The BNAME draft indeed does not say that.  In case I wasn't clear, the
suggestion is that this approach is needed _instead_ of the way the
BNAME draft is currently written.  The point is that this will allow
validation just as well as it works today, so that everyone in the
world needn't upgrade to BNAME support just to get validation of these
resource records.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 11 Aug 2010 00:10:47 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 10, 2010 11:44 PM
Subject: Re: [dnsext] Does DNSSEC mean BNAME is undeployable?

> someone wanted to investigate it.

there are so many implementaions and versions.

you'd better say which software and which version you tested?

on the other hand,
testing one does not mean that you can prove all.

> because we think it oughtn't to be used anyway).

following your logic, after dnssec, we would not invent the new rrtype.

does dnssec mean the dead of all new rrtype?

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 10 Aug 2010 13:18:42 -0400

No hat.

> testing one does not mean that you can prove all.

This is certainly true, and it's one of the reasons I feel
uncomfortable with CNAME+DNAME.

> does dnssec mean the dead of all new rrtype?

You are failing to make an important distinction, which is between
RRTYPEs that need server-side processing and those that don't.  The
former are a big deal, whereas the latter can be treated trivially as
the unknown type in those systems that don't understand them.  I
actually pointed out this distinction in the first mail in this
thread.  If you don't think that distinction is an important one in
this context, you're going to need an argument to support such a
position.

Speaking only personally (to emphasise), I think the interaction of
BNAME and DNSSEC as it stands is simply an unacceptable trade-off: the
plan is to support a new kinf of aliasing (which could just as easily
be supported by the provisioning layer, IMO) by trading away the
ability to use deployed validating resolvers to tell whether a given
response is legitimate.  I think -- again, speaking personally -- that
we don't want to give up so easily a feature this community has worked
so long and hard to get deployed.

If you think that the problems BNAME is aimed at addressing cannot be
solved just as well by good provisioning tools, you need to make an
argument for why.  I haven't heard such an argument beyond, "None of
the tools we have make this practical."  I haven't yet seen a complete
argument why some apex records + DNAME aren't good enough in the alias
zone.  In my personal, no-hat view, that is a good reason to go
sponsor additional work on tools to support such deployment rather
than to modify the DNS protocol in such a way as to require widespread
adoption before all of the functionality we have (already deployed!
Root is signed!) today is again working.

Speaking as a WG chair, however, I wish to emphasise that the above
preference will not prevent me accepting adoption of some or all of
this work if the WG plainly wants it and we have a clear and complete
statement of what problems we think we are solving.  But I take very
seriously the objection raised by more than one person in Maastricht
that we should not add more complications to the protocol to solve a
small number of cases that can also be addressed in other ways.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 11 Aug 2010 14:12:49 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, August 11, 2010 1:18 AM
Subject: Re: [dnsext] Does DNSSEC mean BNAME is undeployable?

> this context, you're going to need an argument to support such a

whether the rrtype needs the server-side processing or not,

the final result is that the current dnssec resolver does not recognize or support the new rrtype.

does the current dnssec resolovers automatically recognize the new rrtype which does not need the server-side processing?

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 11 Aug 2010 10:25:45 +0200

Hi Jiankang,

> does the current dnssec resolovers automatically recognize the new rrtype which does not need the server-side processing?

Yes.  Also the dnssec signers and authority servers can.

Best regards,
   Wouter

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 12 Aug 2010 15:40:47 +0200

On 10.8.2010 17:44, Andrew Sullivan wrote:
> In favour of that conclusion are things like qmail&  its

qmail delivered email to nic.dname.cz just fine.  (Had to go thru all 
the hoops and loops when building netqmail in chrooted environment. 
Don't make me do that again...)

> to note that this is code base, not % of deployed systems.

We tested some, but they all were fine using synthetized CNAMEs since 
they don't support DNSSEC.

> Moreover, the systems in question can't support DNSSEC properly, either.

Yes, and the argument here is same for BNAME.  If those servers didn't 
get support for DNAME, they will not get support for BNAME either.  And 
if they get proper DNSSEC support (soon) they will likely get a DNAME 
support.

> because we think it oughtn't to be used anyway).

And you need normal and BNAME for every future algorithm.  Or do you 
plan to make BNAME support mandatory for every new algorithm?

> world needn't upgrade to BNAME support just to get validation of these

True and I understood that.  But do you need BNAME at all, if you make 
this sort of backward compatibility?

Ondrej
-- 
  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: Mark Andrews <[email-masked]>
Date: Fri, 13 Aug 2010 12:10:34 +1000

> plan to make BNAME support mandatory for every new algorithm?

I would expect it to be like NSEC3, new algorithms would also indicate
BNAME support.  If we had had known enough about DNSSEC DNAME's original
introduction would have added algorithm aliases.  The type code roll
allowed us to do that a slightly different way.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Aug 2010 00:51:36 -0400

So if a zone contains a DNAME, a resolver that does not understand it
simply has to treat the zone as unsigned?

That might work. But only if any change is made before validation is
pushed out to the edge and before there are applications that rely on
DNSSEC being there.

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

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 13 Aug 2010 09:31:04 +0200

> simply has to treat the zone as unsigned?

No.  Currently the requirement is - if you do DNSSEC, you have to do DNAME.

> That might work.

No, that wouldn't work.  That would mean that you can just spoof DNAME 
and you can spoof whole zone.

O.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 13 Aug 2010 09:43:21 +0200

On 13.8.2010 04:10, Mark Andrews wrote:
> In message<[email-masked]>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= writes:

That might work now.  But I see it as a bad precedent.  If we setup this 
as a usual way how to cope, we would have to create algorithm dupes for 
every (non deprecated) algorithm to the date.  This might grow huge. 
Fortunately you don't have to do Cartesian product for all signaling, 
but you can say that new signal also includes all preceding ones (ie. 
support for BNAME includes support for DNAME and NSEC3).

If this gets ever created we need something like a table with algorithm 
numbers as lines and standards included in columns with fields 
indicating support.  It's already mess that you have some algorithms 
named <something>-NSEC3-<something> and some not (SHA-2 family, GOST) 
and they all include NSEC3 support.

Ondrej

---

From: "Jiankang YAO" <[email-masked]>
Date: Fri, 13 Aug 2010 16:23:27 +0800

----- Original Message ----- 
From: "Ondřej Surý" <[email-masked]>
To: "Mark Andrews" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 13, 2010 3:43 PM
Subject: Re: [dnsext] Does DNSSEC mean BNAME is undeployable?

> support for BNAME includes support for DNAME and NSEC3).

bname follow the difiniton of draft-yao-dnsext-alias-algorithm-00.txt to avoid adding
too many alias algorithms for the new rrtypes.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 14 Aug 2010 00:42:35 +1000

In message <[email-masked]>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= writes:
> >>>> the chairs said in the meeting that only half (?) of the servers support
>  d
> >> name.
> >>>

And how often do we make this sort of change to the DNS?  DNAME was
10 years ago and we have no shortage of algorithm numbers.  No we
are not limited to 256.  We just haven't defined how to encode
algorithm numbers bigger than 254 we know that it is possible
as we currently support a effectively infinite number of algorithms.

> and they all include NSEC3 support.

And you would have a set that indicate BNAME support along with NSEC3
and them some that don't, so what.

	BRSASHA1, BRSASHA256, BRSASHA512, BDSA, BGOST

Mark