Subject: Re: WG Last Call: TKEY

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 04 Jan 2000 01:23:06 -0500

Hi Ed,

From:  Edward Lewis <[email-masked]>
Message-Id:  <v03130301b48ffb165e74@[207.172.149.178]>
In-Reply-To:  <4.1.19991222150900.00c81c50@localhost>
References:  <4.1.19991220170146.00a5b980@localhost>
	     <4.1.19991217151818.0091b8e0@localhost>
Date:  Wed, 29 Dec 1999 13:38:20 -0500
To:  Olafur Gudmundsson <[email-masked]>
Cc:  [email-masked]

>At 3:13 PM -0500 12/22/99, Olafur Gudmundsson wrote:
>>Donald updated the draft

The update had only two very minor changes in it, one giving a
recommended CLASS of ANY for TKEY to be parallel with TSIG, and the
other fixing a one word typo.  I wouldn't normally do an update for
such a minor change but your personal email to me of 10 December
pointing out the typo said you thought the rest of the document was
OK.  So I though it was stable.

The new changes you have come up will mostly seem like minor
improvements.  So if I don't have a specific response below, it means
I plan to include that change if there aren't any opposing comments on
the mailing ist.

>>      3. Exchange via Resolver Query.............................8
>>      3.1 Query for Server Assigned Keying.......................8
>>      3.2 Query for Diffie-Hellman Exchanged Keying..............9
>>      3.3 Query for GSS-API Established.........................11
>>      3.4 Query for Querier Assigned Keying.....................11
>>      3.5 Query for TKEY Deletion...............................12
>
>Since DH and delete modes are required and the others are not, I'd
>rearrange the outline to be:
>
>3.1 <- 3.2 Query for Diffie-Hellman Exchanged Keying..............9
>3.2 <- 3.5 Query for TKEY Deletion...............................12
>
>Get the mandatories out of the way.
>
>3.3 <- 3.3 Query for GSS-API Established.........................11
>3.4 <- 3.1 Query for Server Assigned Keying.......................8
>3.5 <- 3.4 Query for Querier Assigned Keying.....................11
>
>Pairing the last two since they are complimentary ideas.
>
>>1.1 General Principles
>>
>...
>>   require mutual agreement. In the absence of such agreement, servers
>>   MUST return errors such as NotImp or Refused for an attempt to use
>>   TKEY and resolvers are free to ignore any TKEY RRs they receive.
>
>I have a problem with requirements (MUST's, et.al.) in the Introduction.
>Later in the document, in the Security Considerations, there are more
>requirements.  I strongly encourage the concentration of requirements or
>conformance statements in the meat of the document.  This eases deriving a
>test plan from the specification document.
>
>>   Server and resolvers supporting
>>   this specification MUST implement the Diffie-Hellman key agreement
>>   and the key deletion modes.
>
>"Server and resolvers conforming to this specification MUST implement the
>Diffie-Hellman key agreement mode and MUST implement the key deletion mode."
>--At least add "mode" after "agreement" and make "modes" singular.  This
>makes clear that two modes are mandatory.
>
>>           4       resolver/querier assignment
>>          5 key deletion
>>          6-65534   - available, see IANA considerations section
>>          65535     -reserved
>
>Table is misformatted.
>
>>2.1 Key Naming
>>
>>   At any host only one octet string of keying material may be in place
>>   at the same time for any particular key name.
>
>This sentence is confusing.  By a host do you mean a resolver, server,
>both, neither?  In trying to offer a rewording of this, I find I don't grok
>the idea here.

What is being refered to here is any process that caches TSIG secret
keying material, that is, material which this draft provides a way to
agree on via DNS messages which include a TKEY RR.  Assuming this is
the DNS server, there is normally only one of them on a host.  It
might be a "stub resolver".

However, I guess it could be some miscellaneous application which is
directly sending DNS queries and gettign DNS responses wants to use
TKEY to boostrap to being and to use TSIG for some remote server(s).

(There's no reason to define Host here.  Host is a well defined IETF
term used all over the place.  See the Host Requirements RFCs or Host
Resources MIB or DHCP or ...  A Host is the end refered to in the
end-to-end principle.  All communications terminating at a Host
generally fate share.  (See RFC 1958 section 2.3.) )

>[I don't know if this a relelvant comment or not: What about a
>multi-interfaced/ multi-addressed machine (or a machine owning an interface
>that has a reverse map entry with multiple PTR's)?  Is there a rule
>governing the mapping of a domain name to the resolver?]

Yes, Hosts can have multiple IP address / interfaces.  If they fate
share, they are one Host.  When you say "an interface ... reverse map
...  multiple PTR's" I assume you mean an IP address that reverse maps
to PTR's to multiple forward names.  That should only be true if the
address is a legitimate address for each of those names.  Yes, there
can be multiple names that map to the same IP and are thus names for
the same Host.  You can pick any of the names for constructing key
names.  Even if the name you pick has multiple address records stored
at it that go to different Hosts, there shouldn't be any key name
duplication, at least in the random name case.  I supose you could get
a duplicate key name if there are two client Hosts accessible via the
same name making request to one or more servers with the same name
using the other suggested method of key naming but I don't think it
would cause a problem.

>>        If the key is generated as the result of a query with root as
>>        its owner name, they the server SHOULD create a pseudo-random
>                            |
>............................n
>
>>
>>        [RFC 1750] based unique name ending with a name of the server
>
>"pseudo-random based unique name"?  I don't grok this either.

I guess it should say something more like "... create a globally
unique domain name, to be the key name, by suffixing a pseudo-random
[RFC 1750] label with a domain name of the server host."

>>        host.  For example 89n3mdg072pp.server.example.com.  If
>>        generation of a new pseudo-random name in each case is an
>>        excessive computation load or entropy drain, a serial number
>>        prefix can be added to a single pseudo-random name generated an
>                                                                       |
>.......................................................................t
>
>>3.1 Query for Server Assigned Keying
>>
>>   for the reason given.  FORMERR is given if the query specified no
>>   encryption key.
>
>FORMERR is not defined in the document, yet it is also referenced in
>following sections.

Format Error is defined in RFC 1035 but I'm not sure just where the
"FORMERR" name for it it defined.  It's used in the TSIG draft as
well.

>>   If the error field is zero, the client host supplied Diffie-Hellman
>>   KEY should be echoed back and a server host Diffie-Hellman KEY RR
>        ||||||
>        SHOULD
>
>While I am at it, "echoed back" is repetitively redundant.
>
>>        keying material =
>>             XOR ( DH value, MD5 ( query data | DH value ) |
>>                             MD5 ( server data | DH value ) )
>>
>>   where XOR is a byte wise left justified xor padding the shorter octet
>>   stream with zeros, DH value is the Diffie-Hellman value derived from
>>   the KEY RRs, "query data" and "server data" are the TKEY RR data
>>   fields sent by those parties, and "|" is concatenation.
>
>I'd replace that one sentence with something like:
>
>Where XOR is an exclusive-OR operation and "|" is byte-stream
>concatenation.  The shorter of the two operands to XOR is byte-wise left
>justified and padded with zero-valued bytes to match the length of the
>other operand.  DH value is the Diffie-Hellman value derived from the KEY
>RRs. Query data and server data are the values sent in the TKEY RR data
>fields.
>
>(Keep the rest of that paragraph too.)
>
>>3.4 Query for Querier Assigned Keying
>...
>>   keying data and a KEY RR specifying the server host public key used
>
>"Keying data" is too similar to "keying material."  I can't think of a
>replacement, "initialization" and "salt" come to mind, but they pertain to
>specific algorithms (I think).
>
>>3.5 Query for TKEY Deletion
>>
>>   a TKEY RR with the key's name.  If the server has no record of a key
>>   with that name, it returns BADNAME.
>
>What does a resolver do with a BADNAME?  I would guess this is the same as
>a successful key delete request.  So, why bother?  Why not have the server
>just send back okay to an unknown key?

I think error reporting is a good idea.  It may some day give you a
clue as to why things are failing.  Unless there are further requests,
I don't plan to change this.

>>5. Methods of Encryption
>...
>>   decyrption which recovers the originally encrypted data.  The KEY RR
>
>    decryption
>
>>6. IANA Considerations
>>
>>   changes.  I.E. a mode value assigned for an Experimental Standard
>
>              I.e.,
>
>Page 18 is blank, the footer prints in the upper/middle part of the paper.
>
>>
>>Donald E. Eastlake, 3rd                                        [Page 18]
>
>
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                                NAI Labs
>Phone: +1 443-259-2352                      Email: [email-masked]
>
>"Trying is the first step to failure." - Homer Simpson
>"No! Try not. Do... or do not. There is no try." - Yoda
>
>Opinions expressed are property of my evil twin, not my employer.

Donald
===================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668   [email-masked]
 65 Shindegan Hill Rd, RR#1
 Carmel, NY 10512 USA

---

From: Edward Lewis <[email-masked]>
Date: Tue, 4 Jan 2000 09:50:00 -0500

>OK.  So I though it was stable.

I remember that.  Sorry about sending so many comments after saying I
thought it was ok.  I can't explain why I flip-flopped, but I'd rather get
comments out during the last call then be considered a consistent person
;).  (This is why I could never run for political office.)

>I plan to include that change if there aren't any opposing comments on

I don't consider the comment to remove requirements from the Introduction
and Security Considerations to be minor ones.  My irritation on this point
stems from RFC 2065/2535 and trying to derive a test plan from that
document.  Because of the inconsistency in the presentation of the
requirements, it is hard to derive a plan of what needs to be tested to
show compliance.  I'm now trying to make sure that that DNS security
documents are clear and software shown to be compliant, so that we can make
DNS more secure.

If we bother to add security to DNS, but the specs are so vague as to make
implementations weak and therefore vulnerable, what's the use?

>(There's no reason to define Host here.  Host is a well defined IETF

Yes, there is no reason.  That was kind of my point.  I was hoping you'd
not use "host" in 2.1, substituting resolver or server - actually, I wasn't
all that clear.  But talking about a "host" in 2.1 is misleading.

>might be a "stub resolver".

"Normally" - yes, but you are writing a spec.  Cover all the legal cases,
this is one example of a weakness in the spec.

>Yes, Hosts can have multiple IP address / interfaces.  If they fate

You can ignore the blabbering I had about this.  I was trying to
demonstrate the absolute confusion I had over your use of the term "host."
I would have only expected to see host-based (security) requirements in
something like IPSEC.

>From the context in which FORMERR appears in your document, you make it
seem like this would be reported in the TKEY error field.:

>   If the error field of the response TKEY is non-zero, the query failed

Is FORMERR placed in the TKEY error field or the message header?