Subject: [dnsext] -03 version of algo-signal posted

From: "Rose, Scott W." <[email-masked]>
Date: Tue, 7 Jul 2009 10:42:54 -0400

"Official" -03 version of algo-signal posted:
http://www.ietf.org/internet-drafts/draft-crocker-dnssec-algo-signal-03.txt

This is different that the working version Steve sent to the list recently.
It goes back to the original (-00) version in that the algorithms are a list
in the OPT RR, not a single value with assumptions.

Please refer to this version for future discussions.
Scott

===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
===================================

--
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: [email-masked]
Date: Tue, 7 Jul 2009 16:05:22 +0100

> Please refer to this version for future discussions.

I don't see any mention of whether this attribute is suitable for use in 
responses (perhaps to indicate the list of algorithms that are potentially 
available from the server?) 

If the intent is that this option should _not_ be returned to the client, 
IMHO it would make sense for the draft to explicitly say so.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Alex Bligh <[email-masked]>
Date: Tue, 07 Jul 2009 16:17:53 +0100

--On 7 July 2009 10:42:54 -0400 "Rose, Scott W." <[email-masked]> 
wrote:

> It goes back to the original (-00) version in that the algorithms are a
> list in the OPT RR, not a single value with assumptions.

Why have ALG codes as a list of octets in descending order, rather
than (as Ray Bellis suggested) a length field plus a bitfield of up
to 252 bits (with bits beyond the supplied bitfield to be treated
as zero)? It would appear to me that this will in general
be shorter.

-- 
Alex Bligh

---

From: "George Barwood" <[email-masked]>
Date: Tue, 7 Jul 2009 19:52:16 +0100

You don't discuss whether DNSKEY RRsets should be pruned to match
the client preference. Are servers allowed to do this? It would
mean that the server would need to have signatures for different
variations of the DNSKEY RRset, but that's not an obvious
problem ( except that  unusual queries for ANY or RRSIG could yield
very long responses ).

In section 3.1, "The only exception is for validating stub resolvers..."
doesn't make sense, because it's not an exception to the previously stated
rule, which concerns non-validating resolvers.

"Caches MUST NOT set the AU option on any outgoing query from the
 cache when performing recursion on behalf of a stub client."

Does this not depend on local policy, and the service offered by the cache?
For example the cache may know that there are no validating stubs to be 
served.
Also, the cache could track the algorithms that an RRset has been queried 
for, and
send a further request to if another client requests a different algorithm.
Why exclude this possibility?

"In these cases a client might be able to detect an attack if the target 
zone has a
 DS RR in its delegating parent with the desired algorithm."

Well now, does this work or doesn't it?
I think the natural RRset to look at is the DNSKEY RRset, not the DS,
which is merely the means of authenticating the DNSKEY RRset
( the parent zone may support a different set of algorithms ).

I don't know whether the standard already requires that all algorithms in 
the
DNSKEY RRset must be supported ( in the sense that RRSIGs must be issued ).
I think that must be the case, but if not, that should be an extra condition 
on
servers that support algo-signal, and clients must check that the expected 
RRSIGs
are sent, and presumably fail if they are not sent.

George

---

From: "George Barwood" <[email-masked]>
Date: Tue, 7 Jul 2009 20:05:07 +0100

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "Rose, Scott W." <[email-masked]>; <[email-masked]>
Cc: "Alex Bligh" <[email-masked]>
Sent: Tuesday, July 07, 2009 4:17 PM
Subject: Re: [dnsext] -03 version of algo-signal posted

> as zero)? It would appear to me that this will in general

I think that's because the normal use is a single algorithm.
The client ( I think ) knows which algorithms the server
supports. When fetching the DNSKEY RRset, it's determined
by the parent DS records, otherwise it's determined by the
DNSKEY RRset itself.

So the client will normally just choose the single algorithm it
wants, unless it wants to check multiple algorithms, which
is probably overly paranoid. I cannot imagine a client
wanting to check more than 2 algorithms.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 07 Jul 2009 20:12:05 +0100

> by the parent DS records, otherwise it's determined by the

A single octet for length plus a single octet for one algorithm
is the same length as a single octet for length plus a bitfield
covering the first 8 (i.e. all currently defined) algorithms.

-- 
Alex Bligh

---

From: [email-masked]
Date: Wed, 8 Jul 2009 09:41:57 +0100

> covering the first 8 (i.e. all currently defined) algorithms.

As it happens the spec for EDNS0 options already includes a *two* byte 
length field.  Your point still holds, though :)

FWIW, with the bitmap method a client supporting everything up to and 
including NSEC3/SHA-1 would need a one byte bitmap, and one supporting 
SHA-2 would need two bytes.

Ray

---

From: "George Barwood" <[email-masked]>
Date: Wed, 8 Jul 2009 13:05:28 +0100

The simple list of bytes wins with "private" algorithms ( assuming they are supported ).

A client selecting a single private algorithm uses 15 bytes more with the bitmap representation.

----- Original Message ----- 
From: [email-masked] 
To: Alex Bligh 
Cc: [email-masked] 
Sent: Wednesday, July 08, 2009 9:41 AM
Subject: Re: [dnsext] -03 version of algo-signal posted

> covering the first 8 (i.e. all currently defined) algorithms.

As it happens the spec for EDNS0 options already includes a *two* byte length field.  Your point still holds, though :) 

FWIW, with the bitmap method a client supporting everything up to and including NSEC3/SHA-1 would need a one byte bitmap, and one supporting SHA-2 would need two bytes. 

Ray

---

From: Alex Bligh <[email-masked]>
Date: Wed, 08 Jul 2009 18:37:05 +0100

>From the draft:

> 3.  Client Considerations
>
>    A validating end-system resolver sets the AU option in the OPT
>    meta-RR when sending a query.  The validating end-system resolver
>    SHOULD set the value(s) to be the largest algorithm code that the
>    validator understands (excluding Reserved codes and values greater
>    than 252).

I took it from that that we are only using algorithm codes 1 to 8(ish)
today (though in future that may rise), but perhaps I have this wrong.

-- 
Alex Bligh

---

From: "Rose, Scott W." <[email-masked]>
Date: Wed, 8 Jul 2009 14:24:33 -0400

> problem ( except that  unusual queries for ANY or RRSIG could yield

Probably shouldn't - the entire RRset is needed to validate RRSIGs, but a
validator doesn't necessary need every RRSIG to validate the RRset.

> Why exclude this possibility?

Changing in -04 to state that clients MUST NOT when the stub client is not
DNSSEC aware or is DNSSEC-aware and setting the CD bit.

> ( the parent zone may support a different set of algorithms ).
Changed - yes I believe the attack will be seen, so "In these cases a client
will be able to detect an attack if the target zone has a DS RR in its
delegating parent and with the desired algorithm."

> are sent, and presumably fail if they are not sent.

Ok - will work on getting that into the -04 version

Thanks,
Scott

---

From: "George Barwood" <[email-masked]>
Date: Wed, 8 Jul 2009 19:53:13 +0100

Yes, the current draft clearly excludes private algorithms.

I could have been more explicit : "if they are supported in a revised 
draft".

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "George Barwood" <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>; "Alex Bligh" <[email-masked]>
Sent: Wednesday, July 08, 2009 6:37 PM
Subject: Re: [dnsext] -03 version of algo-signal posted

---

From: Alex Bligh <[email-masked]>
Date: Wed, 08 Jul 2009 19:58:55 +0100

> I could have been more explicit : "if they are supported in a revised

How would either end know they were using the same private
algorithm?

It's clearly not a huge issue, but given there have been rather
a lot of messages on here concerned with DNS packet sizes, I
thought it worth mentioning (even though it's the request
not the response)

-- 
Alex Bligh

---

From: ALAIN AINA <[email-masked]>
Date: Sat, 25 Jul 2009 18:48:38 +0000

> Please refer to this version for future discussions.

some comments of the document:

The draft does not discuss these points:

1-  The DNSKEY RRset selection in  response to match the AU of the  
clients:

- a zone has:

   A dnskey with alg 1 and another dnskey with alg2
   The signed zone will have RRSIGs on the keyset with alg1 and alg2

If the client says that it only understands alg1, should the key with  
alg2 be removed to the keyset when returning the answer to the  
client ? if not what should be the behavior the client regarding the   
key with alg2 (unknown) ??

[keyset]

example.	DNSKEY	256 3 3 .......
example.	DNSKEY	256 3 5 ......
example.       DNSKEY        257 3 5
...........

[RRSIG on the keyset ]

example.	RRSIG	DNSKEY 3 1  ....
example.	RRSIG	DNSKEY 5 1 ....
example.        RRSIG   DNSKEY 5 1......
.........

2-  DS  selection to match the AU of the client.

as above should the parent NS remove the DS RR  with unknown alg when  
answering query with a certain understood alg ? if not what should the  
behavior of the client with a DS RR with unknown alg?

To be able to alter dnskey and DS RR, there is a need to  have  
separate RRSIGs of keyset and DSset per alg. Not obvious.

All of these get simplified if we change the wordings "understood  
algorithms" to "preferred algorithms", which mean that the client  
understand at least all mandatory algorithms but prefer one or more.  
But in the case part of the objectives of the draft can't be achieved.

Other issues:

3-  The server considerations says :

"If the zone containing the QNAME is signed with a cryptographic  
algorithm(s) that are not present in the ALG-CODE value in the client  
query
the authoritative server SHOULD include any or all RRSIGs in the  
response regardless of algorithm used to generate them."

  Shouldn't server respond in such situation with a  RCODE 21 (BADALG)  
and set  the available alg(s) in  AU ?

4- And for compatibility with client which won't implement the AU and  
so won't sent the  OPT RR,  i see  servers  acting as describe  above.

--alain

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 28 Jul 2009 09:39:13 +0100 (BST)

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Sundry comments and questions, some of which repeat points already 
raised on this list.

Generally: this appears to be a reasonable solution, but I'm not yet 
convinced this is a problem we need to solve.

With going back to a list of codes (or a bitmap), why insist on 
ordering?

I think private algorithms should be supported, at least to the
granulatity of the type codes, if not looking deeper for the
identifiers.

Section 3: why is there a 2119 SHOULD?  Why not let a client set 
algorithms beyond what the client understands?  A clear reference to 
section 5 and explaining the differences v. "end system resolver" 
might be appropriate, since I'm not sure that term has occured before 
in the DNSSECbis doc set.

Similarly, why not "MAY" set fewer than understood?

In section 4, be clear that the DNSKEY RRset must not be broken up. 
Perhaps s/DNSSEC RRs/RRSIG RRs/

In section 5, "Caches ... when performing recursion on behalf of a 
stub client."  How does a cache know whether its client is a stub?  I 
think this phrase is a no-op and the instruction can be generalized. 
(Alternatively, the doc couold be restuctured, giving one set of 
resolver rules with a conditional clause...)

"the cache SHOULD follow the AU option request and only include the
RRSIGs generated using the algorithm equal to or less than the value
in ALG-CODE."
What does equal to or less than mean here?  Again, having gone back to 
a list, how about removing the referring to ordering?

5.1 is there a standard definition for "intermediate proxy resolver"?
If not, perhaps another term is more appropriate?

Security considerations: "In these cases a client might be able to 
detect an attack if the target zone has a DS RR in its delegating 
parent with the desired algorithm."  Wouldn't looking at both the DS 
and DNSKEY RRsets be more appropriate?  The current text seems to have 
the potential to lead folks astray.  It might be worthwhile to repeat 
the mandatory algorithm rules in this doc.

-- Sam

---

From: "Rose, Scott W." <[email-masked]>
Date: Tue, 28 Jul 2009 13:50:57 -0400

> With going back to a list of codes (or a bitmap), why insist on
I was thinking preference mainly.  A way for clients to express which algos
they would rather see.  Not sure if it's necessary, but maybe.

> Similarly, why not "MAY" set fewer than understood?
We'll take that under consideration.  Also, terminology has always been an
issue here when describing roles.
 
> Perhaps s/DNSSEC RRs/RRSIG RRs/
Ok - will add text.

> resolver rules with a conditional clause...)
The only way would be to look for the RD bit.  That is no guarantee. May
adjust text around that instead of stub/full wording.

> If not, perhaps another term is more appropriate?
There has always been issues with terminology in DNS drafts.  Will see if we
can adjust role descriptions in this doc or just define everything better.

Scott

---

From: Basil Dolmatov <[email-masked]>
Date: Tue, 28 Jul 2009 14:22:20 +0400

Samuel Weiler wrote:
>
>
> With going back to a list of codes (or a bitmap), why insist on ordering?
>
Hope that is just the remnants in the text.

And going to the bitmap ( "set" in Pascal terms or "enum" in C terms) in 
not "going back" it is "going the right way". ;)

dol@