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

From: Scott Rose <[email-masked]>
Date: Fri, 20 Jun 2008 09:22:17 -0400

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

Subject: New Version Notification for draft-crocker-dnssec-algo-signal-00
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 20 Jun 2008 05:59:17 -0700 (PDT)

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.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 23 Jun 2008 12:36:31 -0400

Hi Scott - I took a look at this and comments follow.  On the topic of whether or not to make this a WG document, I wouldn't oppose it, but if we're triaging new work, I also wouldn't put it very high up on the priority list. I'm not sure it will have all that much benefit for the amount of implementation required and I'm also not sure that it meets the "do no harm" test - it might do no harm, but it appears to be a complicating extension and may actually add to fragility by restricting the signed data available to get an answer at various places.

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?

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

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?)

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?

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?

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.

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:
>
>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)
>Content-Type: text/plain; charset="utf-8"
>Mime-Version: 1.0
>Message-Id: <[email-masked]>
>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]
>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:                                                                                                    
>
>

--
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/>