Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt

From: [email-masked]
Date: Tue, 06 Mar 2012 08:29:35 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title           : Signaling Cryptographic Algorithm Understanding in DNSSEC
	Author(s)       : Steve Crocker
                          Scott Rose
	Filename        : draft-ietf-dnsext-dnssec-algo-signal-04.txt
	Pages           : 8
	Date            : 2012-03-06

   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 and hash algorithms they support.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-04.txt

---

From: "Marc Lampo" <[email-masked]>
Date: Wed, 7 Mar 2012 09:54:36 +0100 (CET)

Hello,

Suggestion.

In 6. Traffic Analysis Considerations

"... should monitor DNS query
   traffic and record the values of the DAU/DHU/N3U option(s) in
   queries. ..."

--> Suggest to add that also monitored are :
    - (number of) DNS Queries, with EDNS0 OPT record, but without any 
signalling done

Motivation :
The difference in number of queries with and without Algo-Signalling
shows how reliable the signalling information is.

Kind regards,

Marc Lampo
Security Officer
EURid (for .eu)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 06 March 2012 05:30 PM
To: [email-masked]
Cc: [email-masked]
Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the DNS Extensions Working Group 
of the IETF.

---

From: Miek Gieben <[email-masked]>
Date: Fri, 9 Mar 2012 10:07:48 +0100

[ Quoting <[email-masked]> at 08:29 on Mar  6 in "[dnsext] I-D Action:..." ]
>    cryptographic algorithms and hash algorithms they support.

I read a comment in the draft that this option list can get very long, which
indeed is true. 

How about the following scheme:

A resolver indicates the highest algorithm number it understands and thus *also*
all *previous* algorithms. This way the whole option can be shortened to 4
bytes:

 0: OPTION-CODE
 1: DAU byte value
 2: DHU byte value
 3: N3U byte value

And maybe this option can be renamed to Crypto Understood.

A drawback is that a number of current specified features aren't available
with this scheme.

Regards,
    Miek Gieben

---

From: Miek Gieben <[email-masked]>
Date: Sun, 11 Mar 2012 11:02:32 +0100

> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-04.txt

I've read the draft and I support it. Below are a few things I found.
(And I still have this question:
http://www.ietf.org/mail-archive/web/dnsext/current/msg12286.html)

| These signaling options can be
| used by zone administrators as a gauge to measure the successful
| deployment of code that implements a newly deployed digital signature
| and hash algorithm, DS hash and NSEC3 hash algorithm used with
| DNSSEC.                      
                               
This sentence has some funny wording.
                               
| A validating stub resolver already (usually) sets the DO bit
                               
already (usually), either already of usually?
                               
| 5. Server Considerations     
                               
What if the server can not comply to the clients wishes? Does
it need to send back an empty DUA edns0?
                               
| The goal of this option is these options are to signal new algorithm
| uptake in client code to allow zone administrators to know when it is
| possible to complete an algorithm rollover in a DNSSEC signed zone.
                               
It this the goal? Because with this option we can also facilitate
hash rollovers in nsec3.

 Regards,

-- 
    Miek Gieben

---

From: Warren Kumari <[email-masked]>
Date: Sun, 11 Mar 2012 23:14:26 -0600

I supported this draft and provided some comments^w nits back in version -02 (http://www.ietf.org/mail-archive/web/dnsext/current/msg11472.html)

I still support this draft, and find the current (-04) version cleaner and easier to read…

W

On Mar 6, 2012, at 10:29 AM, [email-masked] wrote:

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

--
Don't be impressed with unintelligible stuff said condescendingly.
    -- Radia Perlman.

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 11 Mar 2012 23:26:44 -0600

Thanks!

FWIW, as the individual that (still) has the task of verifying the consensus around this draft, I have started walking around the individuals I have seen commenting and asked them to explicitly look at this -04 version and let this list, me and/or the editors know their view.

So if you have comments, positive or constructive negative, please let me, the editors and/or the list know.

But ensure you read the latest version, which at the moment is -04.

   Patrik

---

From: Scott Rose <[email-masked]>
Date: Mon, 12 Mar 2012 09:08:06 -0400

> And maybe this option can be renamed to Crypto Understood.

That was the layout of the previous versions, but without the NSEC3 hash understood (only added it this version).  The problem was that it violated the basic format for EDNS options (Code, Length, Data).  It could be:

0: OPTION-CODE
1: DATA LENGTH
2: DAU byte length
3: DHU byte length
4: N3U byte length

One reason we made it three unique options was so clients could mix and match if they wanted.  Especially since there is only one NSEC3 hash algorithm code assigned for now.

Scott

---

From: Scott Rose <[email-masked]>
Date: Mon, 12 Mar 2012 10:22:07 -0400

> already (usually), either already of usually?

Yes, both are poorly written.  I'll re-write in next version.  The second should be: "A validating stub resolver already sets the DO bit..."

> It this the goal? Because with this option we can also facilitate

Correct - that was left out and should be re-added.

Thanks,
Scott

---

From: Miek Gieben <[email-masked]>
Date: Tue, 13 Mar 2012 09:07:31 +0100

[ Quoting <[email-masked]> at 09:08 on Mar 12 in "Re: [dnsext] I-D Act..." ]
> One reason we made it three unique options was so clients could mix
> and match if they wanted. Especially since there is only one NSEC3
> hash algorithm code assigned for now.

Upgrading hashes in NSEC3 is hard, upgrading NSEC3 (to whatever) is harder
still.

How about an extra option that lists which authenticated denial of existence
records are understood. Something along the lines:

An option code that signals which negative resource records an resolver
can handle. When DNSSEC was first designed NXT, was defined, this was
later renamed to NSEC. Later still NSEC3 was defined. Upgrading to a new
authenticated denial of existence record is very hard. The upgrade to NSEC3
involved an algorithm roll, which is not desirable as we only have 8 bits in
the algorithm field. So we define to following:

NXU                         (NXDOMAIN Understood)
2                           (length is always 2 octect)
Type code of the highext NX 
record understood.
    
This defaults to '50'.

 Regards,

-- 
    Miek Gieben

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Mar 2012 19:21:22 +1100

In message <[email-masked]>, Miek Gieben writes:
> [ Quoting <[email-masked]> at 09:08 on Mar 12 in "Re: [dnsext] I-D A=
> ct..." ]
> Type code of the highext NX=20
> record understood.
>    =20
> This defaults to '50'.
> 
>  Regards,
> 
> --=20
>     Miek Gieben
 
If you want to solve upgrading NSEC3's hash algorithm or BNAME etc.
then that needs to be carried in the DS record so the zone can be
treated as insecure.  Defining DS hash types which have additional
fields would be one way forward that is backwards compatible.

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

---

From: Miek Gieben <[email-masked]>
Date: Tue, 13 Mar 2012 09:39:26 +0100

[ Quoting <[email-masked]> at 19:21 on Mar 13 in "Re: [dnsext] I-D Act..." ]
> fields would be one way forward that is backwards compatible.

That's even better.

Regards,
Miek Gieben