Subject: Re: DNSEXT WGLC Summary: SIG(0)

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Mon, 10 Apr 2000 11:22:49 -0400

I've edited and submitted the document as per WG consensus so it
should be announced in a few days.  However, I did have one techncial
comment below...

From:  Olafur Gudmundsson <[email-masked]>
Message-Id:  <[email-masked]>
Date:  Wed, 22 Mar 2000 10:35:26 -0500
To:  DNSEXT WG Mailing list <[email-masked]>

>The last call period on this document has concluded. 
>
>Only one issue was raised during the WGLC period. Currently the draft 
>allows multiple SIG(0)'s to be attached to a message. There where calls
>to restrict this to one SIG(0) per message. The consensus of the 
>Working group is that SIG(0) MUST be restricted to one. 
>The arguments against this restriction where:
>1. The client does not know what algorithm the server supports
>2. Allow Multiple Inheritance of capabilities to a key generated in    a
>TKEY exchange. 
>
>The working group rejects the first one as the client can query the server
>for its appropriate key set and use that to select one of clients key to 
>sign message. 

I don't see how that would work.  The question is what algorithms are
actually supported by the DNS server code at the server.  This does
not have any necessary relation to any TKEY RRset anywhere.  Zones can
be signed with any variety of algorithms even if none of the DNS
servers for that zone are security aware.  KEY RRs that specify the
DNS or ANY protocol stored under a server name probably reflect
algorithms supported by that server but there could easily be no such
KEYs.  And how can you find all of the names for a server?  Even if
you had all of its IP addresses, you would have to do an inverse
lookup throughout the entire DNS for those addresses to find all the
domain names for a server...

However, I think that implementation of and configuration of private
keys for more than two or occasionally three algorithms will be
very unusual so it is practical for the client to just try the few
algorithm possibilities successively.  And in many cases there will be
some relationship between the client and server such that the client
can be configured to use the "right" protocol...

>About the second argument there was some discussion on if this is a good
>idea but because the rules governing how inheritance of capabilities is 
>NOT defined yet, the working group consensus is that this is better 
>to not address at this time but this issue can be revisited later in
>a separate document. 
>
>No other substantial comments where received during the last call. 
>
>Donald please update document to reflect the WG consensus.
>
>It is the sense of the WG that the document is ready for advancement 
>and will be forwarded to IESG after update. 
>
>There will be an opportunity to address the WG last call of this 
>document in Working Group meeting in Adelaide. 
>
>Olafur
>
>
>>This is a last call on this document, SIG(0) updates RFC2535 in 
>>the definition of transaction signatures. The changes are mostly 
>>to make SIG(0) more like TSIG in implementation and result of 
>>implementation experience. 
>>SIG(0) is required for TKEY exchange when no existing shared secret
>>between two DNS entities exist. 

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 11 Apr 2000 16:44:43 -0400

>domain names for a server...

But we are looking for the host keys for the SERVER not zone keys. 
thus we can look this up as no host should list no-null keys for
algorithm it can not use. 

	Olafur