Subject: WG Last Call: TKEY

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 17 Dec 1999 15:48:42 -0500

The TKEY document has been revised to reflect all comments received by the
author. This document specifies how two DNS entities can create a shared
secret value to authenticate transactions between them. 

This is a WG last call ending January 4'th 2000. 

The draft is: 
http://www.ietf.org/internet-drafts/draft-ietf-dnsind-iana-tkey-02.txt

There are no known defects in this version of the document, but it depends 
on the TSIG document which is still in IESG review. Please send 
comments to the list.

This document is to be published as an standards track RFC, if you 
disagree with that please state your reasons against that in a message
to the mailing list. 

--------
Olafur Gudmundsson - NAI Labs 			(443)-259-2389 
The Security Research Division of Network Associates, Inc.
[email-masked]  [email-masked]  Private: [email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 20 Dec 1999 17:02:36 -0500

> http://www.ietf.org/internet-drafts/draft-ietf-dnsind-iana-tkey-02.txt

Typo correct URL is 
http://www.ietf.org/internet-drafts/draft-ietf-dnsind-tkey-02.txt

	Sorry
--------

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 22 Dec 1999 15:13:09 -0500

>http://www.ietf.org/internet-drafts/draft-ietf-dnsind-tkey-02.txt

Donald updated the draft 
http://www.ietf.org/internet-drafts/draft-ietf-dnsind-tkey-03.txt

The deadline of the Last call is also extended by popular demand to
2000/January/9

	Olafur

--------

---

From: Edward Lewis <[email-masked]>
Date: Wed, 29 Dec 1999 13:38:20 -0500

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

[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?]

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

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

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