Subject: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal

From: Patrik Fältström <[email-masked]>
Date: Wed, 25 May 2011 14:51:09 -0400

As the wg shepherd on the document draft-ietf-dnsext-dnssec-algo-signal, I am hereby informing we today start a four week working group last call.

Abstract

   The DNS Security Extensions (DNSSEC) were developed to provide origin
   authentication and integrity protection for DNS data by using digital
   signatures.  These digital signatures can be generated using
   different algorithms.  This draft sets out to specify a way for
   validating end-system resolvers to signal to a server which
   cryptographic algorithms they support.

The authors have informed me that there is one issue they specifically would like to have comment on: how the option effects the hop-by-hop nature of EDNS.  They believe they addressed those concerns in the updated Section 3.4 about recursive resolver considerations.

The wg last call ends on June 22, 2011.

   Patrik

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 25 May 2011 12:09:33 -0700

I have read this document and support its publication. I have reservations about its actual utility, but in the absence of any better proposal to help zone administrators decide when to change algorithms, this approach seems reasonable and worthy of standardization.

--Paul Hoffman

---

From: Edward Lewis <[email-masked]>
Date: Wed, 25 May 2011 16:16:37 -0400

At 14:51 -0400 5/25/11, Patrik Fältström wrote:
>As the wg shepherd on the document draft-ietf-dnsext-dnssec-algo-signal, I
>am hereby informing we today start a four week working group last call.

I'm assuming you mean this document:
http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-algo-signal-01

I don't support this document even though I support this ideal:

#   This proposed EDNS option serves to measure the acceptance and use of
#   new digital signing and hash algorithms.

(That is - I don't think this document achieves its goal.)

I get that it is good to know what the right 
algorithm (in the DNSSEC sense) to use is.  But I 
don't like the thought that a client's algorithm 
request would be used to alter the contents of an 
response.  It would be better to be aware of 
algorithms, what's deployed, and what to signed 
with in a strategic posture, not a tactical 
posture.

In the document there is this in section 5:

#   When an authoritative server sees the DAU option in the OPT meta-RR
#   in a request the normal algorithm for servicing requests is followed.

However, in 3.1 it says this:

#   Typically, stub resolvers rely on an upstream recursive server (or
#   cache) to provide a response; any algorithm support on the stub
#   resolver's side SHOULD be honored (if possible) by an upstream
#   recursive cache.

What if a server is both authoritative and an 
upstream recursive cache?  If, "honored" (in the 
latter draft fragment) means to send only the 
algorithm that is in the stub's request OPT RR, 
there's a conflict with "normal...servicing."

I feel that this draft has the potential to open 
up a can of worms with interactions between 
signaling bits (namely DNSSEC OK in EDNS0 and the 
CD bit in the header) and having to deal up and 
down the authority to (validating) forwarder to 
(validating) cache to stub resolvers.

I don't think that algorithm roll (or choice) is 
the issue we thought it was a few years ago when 
the idea behind this draft came up, i.e., I don't 
see the draft solving a real problem.  For 
example, it could be more likely that a 
recommendation will come out to change key size 
from 1024 to 2048 than change from SHA-1 to 
SHA-256.  Recent haggling over hash algorithms 
has convinced me that attacks on hash algorithms 
aren't much of a threat because of the limited 
syntax of DNS records.  Perhaps even less of a 
threat than the difference in key lengths.

I don't think this option is needed now, and 
could cause architectural pain later on.

PS :

Section 4 shouldn't be there (at least not 
standalone).  And there is no reference or 
definition of "middlebox."

This is incorrect in 3.4.1:

#   A validating recursive resolver MUST set the DO bit [RFC4035] to
#   indicate that it wishes to receive DNSSEC RRs in the response.  If

Try this, as an example:  "$ dig @a.dns.jp jp dnskey"

(No EDNS0, no DO, but I get DNSKEY records back.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?