Subject: RE: [Fwd: New Version Notification for draft-crocker-dnssec-algo-signal-00]

From: "Scott Rose" <[email-masked]>
Date: Wed, 25 Jun 2008 13:08:48 -0400

> Specific comments:
>
> You specify a priority order in section 2 for algorithms  - but
> in section 4 the phrasing is "most preferred" without limiting
> the number of "most preferred".  I assume you want "the single
> highest priority algorithm present" or do you want to permit the
> two or three highest priority ones?  Maybe the option should
> indicate the number requested?
>
Yes, but it also depends on local policy (on the server).  I would expect
that only one set of RRSIGs in a response.

> Section 3  2nd para -  "or has a trust anchor for" - should
> probably be "and has a trust anchor for"
>
Will fix.

> Section 3 - you dealt with the combination of this option with
> one flag bit (the DO bit) - but how about the rest.  E.g, is this
> compatible with the CD bit and what happens when the server
> receives such a combination?  You get a start on it in section 5
> - but see my following comment.  (Hmm.. thinking about this - why
> would you set this option in any query where the CD bit ISN'T set?)
>
You probably shouldn't.  The text probably isn't clear enough on that.  Only
a validating resolver should be setting the AU option.

> Section 4 - You're missing a discussion about what happens with
> stacking intermediate resolvers.  Can an intermediate validating
> resolver querying another intermediate validating resolver set
> this option?   (e.g. one server pointed at another through stub
> or forward style directives).   Does it need to do something different?
>
Sorry - must not have fleshed it out enough.  I know I probably need to add
more descriptive text.  Maybe another section for middleboxes.

I would say "yes" if it is a validing resolver (and sets the CD bit).

> Section 5 - its unclear that a caching server can guarantee that
> it can answer an AU query out of cache - for example, the AU
> query that comes in from a client lists algorithms in a different
> priority order than the caching server was listing them upstream.
>  Does the AU client return the data it has (its priority 1 data
> RSA/SHA256) or does it requery for the priority 1 data from the
> client (e.g. RSA/SHA1) even though the client is willing to
> accept RSA/SHA256 as priority 2?
>
I feel a cache should answer with whatever is in the cache and not re-query.
Also, a caching recursive server should not use the AU option in order to
insure all RRSIGs are obtained and stored in the cache.

> In general, I'm concerned about the interactions with the already
> somewhat fragile DNSSEC data model.  Its unclear that this adds
> enough benefit given the need to really scrub through all the
> large numbers of permutations this will add to the logic tables.
>

We wrote this up to start the discussion on algorithm rollover,
multi-algorithms and larger response sizes in DNSSEC.  I don't expect the
logic table to grow too large because there will only most likely be 2-3
algorithms in use (in general) at any time:  the "old" one, the "new" one
folks are migrating to, and an optional "new/private" one.

Steve and I can hopefully get out a new version during IETF in July.  I will
work in these comments.

Scott

> Mike
>
>
>
>
>
>
>
>
> At 09:22 AM 6/20/2008, Scott Rose wrote:
> >FYI:
> >
> >A new individual submission from Steve Crocker and myself.  It
> details a possible crypto algorithm signaling method for a client
> to list the algorithms it knows about to a server.  The goal is twofold:
> >
> >1. hopefully reduce response size from zones signed with
> multiple algorithms
> >
> >2. track the implementation of new algorithms in client software
> to get a better understanding of when complete a rollover from a
> weaker algorithm to a new stronger algorithm.
> >
> >Please read the draft and send comments to us.  We would like to
> ask the WG if this can become a DNSEXT WG document during the
> Dublin meeting (if agenda permits).
> >
> >Thanks,
> >Scott
> >
> >
> >X-Account-Key: account2
> >X-Mozilla-Keys:
>
> >Return-Path: <[email-masked]>
> >Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196])
> >        by fs4.antd.nist.gov (8.13.6/8.13.6) with ESMTP id m5KCxX1m018163
> >        for <[email-masked]>; Fri, 20 Jun 2008 08:59:33 -0400
> >Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227])
> >        by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id m5KCxN68005896
> >        for <[email-masked]>; Fri, 20 Jun 2008 08:59:24 -0400
> >Received: from spamav2.nist.gov (spamav2.nist.gov [129.6.13.239])
> >        by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m5KCxJYh019115
> >        for <[email-masked]>; Fri, 20 Jun 2008 08:59:19 -0400
> >Received: from mail.ietf.org (mail.ietf.org [64.170.98.32])
> >        by spamav2.nist.gov (8.14.1/8.14.1) with ESMTP id m5KCxJZA002939
> >        for <[email-masked]>; Fri, 20 Jun 2008 08:59:19 -0400
> >Received: by core3.amsl.com (Postfix, from userid 30)
> >        id 6B2263A6A82; Fri, 20 Jun 2008 05:59:17 -0700 (PDT)
> >From: IETF I-D Submission Tool <[email-masked]>
> >To: [email-masked]
> >Cc: [email-masked]
> >Content-Type: text/plain; charset="utf-8"
> >Mime-Version: 1.0
> >Message-Id: <[email-masked]>
> >Date: Fri, 20 Jun 2008 05:59:17 -0700 (PDT)
> >X-Proofpoint-Virus-Version: vendor=fsecure
> engine=1.12.7160:2.4.4,1.2.40,4.0.166
> definitions=2008-06-20_02:2008-06-19,2008-06-20,2008-06-20 signatures=0
> >X-PP-SpamDetails: rule=spampolicy2_notspam policy=spampolicy2
> score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0
> adultscore=0 classifier=spam adjust=0 reason=mlx
> engine=5.0.0-0805090000 definitions=main-0806200038
> >X-PP-SpamScore: 0
> >X-NIST-MailScanner: Found to be clean
> >X-NIST-MailScanner-From: [email-masked]
> >Subject: New Version Notification for draft-crocker-dnssec-algo-signal-00
> >X-NIST-MailScanner-Information:
> >X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version
> 0.93.1 on fs4.antd.nist.gov
> >X-Virus-Status: Clean
> >X-UID: 53783
> >X-Keywords:
>
> >
> >
> >A new version of I-D, draft-crocker-dnssec-algo-signal-00.txt
> has been successfuly submitted by Scott Rose and posted to the
> IETF repository.
> >
> >Filename:       draft-crocker-dnssec-algo-signal
> >Revision:       00
> >Title:          Signaling Cryptographic Algorithm Understanding in DNSSEC
> >Creation_date:  2008-06-20
> >WG ID:          Independent Submission
> >Number_of_pages: 8
> >
> >Abstract:
> >The DNS Security Extensions (DNSSEC) was developed to provide origin
> >authentication and integrity protection for DNS data by using digital
> >signatures.  These digital signatures can be generated using
> >different algorithms.  Each digital signature added to a response
> >increases the size of the response, which could result in the
> >response message being truncated.  This draft sets out to specify a
> >way for clients to signal to a server which cryptographic algorithms
> >they prefer in a DNSSEC response by defining an EDNS option to list a
> >client's preferred algorithms.
> >
>
> >
> >
> >The IETF Secretariat.
>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 25 Jun 2008 11:20:50 -0700

>folks are migrating to, and an optional "new/private" one.

I agree with Mike's concern about the small benefit for the possibly 
large configuration risk. I get more concerned when I see predictions 
that clearly underestimate the number of algorithms expected in use. 
There is already strong interest in two (RSA-SHA1 because it's there 
now, RSA-SHA2 because it's the right way to go), and will likely be 
interest in at least two others from large customers (DSA and ECDSA). 
That's four in the immediate future, not even counting what happens 
if there is a partially effective attack on any of those.

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael StJohns <[email-masked]>
Date: Wed, 25 Jun 2008 22:40:13 -0400

>insure all RRSIGs are obtained and stored in the cache.

So you're saying that the only entity that should use the AU option is a validating end system?  If that's the case - I'd suggest stating that up front as pretty much the first thing said. 

Mike

---

From: Michael StJohns <[email-masked]>
Date: Wed, 25 Jun 2008 22:43:29 -0400

At 02:20 PM 6/25/2008, Paul Hoffman wrote:

> There is already strong interest in two (RSA-SHA1 because it's there now, RSA-SHA2 because it's the right way to go), and will likely be interest in at least two others from large customers (DSA and ECDSA). That's four in the immediate future, not even counting what happens if there is a partially effective attack on any of those.

It's actually worse than that. For ECDSA, the general recommendation is to use the matching strength of hash so ECDSA on a 224bit curve uses the SHA224 hash, on the 256 bit curve, SHA256, etc.

Mike

---

From: Scott Rose <[email-masked]>
Date: Thu, 26 Jun 2008 08:52:06 -0400

> So you're saying that the only entity that should use the AU option is a validating end system?  If that's the case - I'd suggest stating that up front as pretty much the first thing said. 

That is the intension, sorry if it didn't seem clear.  I'll make it more 
direct in the revision.  It does not seem like a good idea to have a 
non-validating stub dictate which algorithms its upstream validating 
cache must request if it does not know what algorithms it supports.

When I mentioned that I believed there would be "only 2-3 algorithms in 
use", I meant in a zone.  While there could be multiple algorithms used 
in the DNS, I can't see too many zones having more than 2-3 algorithms 
in use at a given time.  Right now, there are several defined, but only 
2 that are commonly used (and both are RSA/SHA-1).

Scott

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------

---

From: Michael StJohns <[email-masked]>
Date: Thu, 26 Jun 2008 13:14:59 -0400

At 08:52 AM 6/26/2008, Scott Rose wrote:
>That is the intension, sorry if it didn't seem clear.  I'll make it more direct in the revision.  It does not seem like a good idea to have a non-validating stub dictate which algorithms its upstream validating cache must request if it does not know what algorithms it supports.

I re-read the document and you used "client" and "validating resolver".  Both unfortunately ambiguous even in context.  

An [end-system | intermediate] [validating [| non-validating]] [caching [| non-caching]] [recursive | (non-recursive | stub) ] resolver.  *sigh*

I went back and tried to find an unambiguous term that is common across most documents and the closest I came was "end-system resolver".  Anyone else have a term of art that's better and that's unambiguous regardless of context?  "Client resolver" isn't as it could include an intermediate resolver during a discussion of  protocol interactions..  "Stub resolver" is unambiguous, but expressly excludes an end-system resolver that can do recursion.