Subject: Re: WG Last Call: TKEY

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sun, 06 Feb 2000 23:26:09 -0500

Hi Ed,

From:  Edward Lewis <[email-masked]>
Message-Id:  <v03130300b497b4f47765@[10.33.10.14]>
In-Reply-To:  <[email-masked]>
References:  Your message of "Wed, 29 Dec 1999 13:38:20 EST."            
	     <v03130301b48ffb165e74@[207.172.149.178]>
Date:  Tue, 4 Jan 2000 09:50:00 -0500
To:  "Donald E. Eastlake 3rd" <[email-masked]>
Cc:  [email-masked]

>At 1:23 AM -0500 1/4/00, Donald E. Eastlake 3rd wrote:
>>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.
>
>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.)
>
>>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.
>
>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.

Well, I suppose it all depends on your point of view.  I do consider
requests to move requirements around in a document to be more minor
than requests to add or delete requirements...

However, I must say that the process of reviewing and re-organization
this material was a lot more work than I thought it would be and has
lead, in my opinion, to a lot more improvement than I though it would.
In fact, I found cases that said "SHOULD" which have to say "MUST" to
actually achieve security.

I belive the next version of the draft, which I hope to add the final
touches to later tonight, will be a really substantial improvement.

>...

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

I've banished "host" from the document.

>...
>
>>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.
>
>>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
>>   for the reason given.  FORMERR is given if the query specified no
>>   encryption key.
>
>Is FORMERR placed in the TKEY error field or the message header?

There are three reasons for the error field in TKEY.

Originally the draft permitted multiple TKEY RRs in a request and you
could therefore have multiple errors in a response (it was restricted
in number and variety so you could tell the responses apart).  This
reason has gone away with the simplification to one TKEY per DNS
message.

Second, TKEY Errors can be > 15 so in some casee they do not fit in
the DNS message header RCODE field.

Third, there is a provision for spontaneous inclusion of TKEY in a
response.  This is optional to implement but such spontaneous
inclusion might sometime require a non-zero error code unrelated to
the DNS message header RCODE.

Based on all this it seems best to not use the DNS header RCODE field,
so the current -dnsind-tkey-03.txt draft on page 7 where the error
codes are listed says the following which I essentially plan to retain
in the next draft:

   When an extended RCODE appears in the TKEY in a response, the DNS
   header RCODE field indicates no error.

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

Thanks,
Donald
===================================================================
 Donald E. Eastlake 3rd                    [email-masked]
 65 Shindegan Hill Rd, RR#1                 [email-masked]
 Carmel, NY 10512 USA     +1 914-276-2668(h)    +1 508-261-5434(w)

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Feb 2000 09:10:30 -0500

>actually achieve security.

This is what I thought would happen.  By following a stricter discipline
(e.g., no requirements in intro, discussions), I have found that the result
is much better.  Not only do the aesthetics improve, the reorganization
effort often finds other places where one can tighten the work.  I think
the reason is that the author sees the requirements from another angle,
performing another round of requirements analysis.

>   header RCODE field indicates no error.

I think it is wise to report an error just once, lest you start seeing
messages with multiple error codes, leading to confusion by the reader.
Writing a "good" client that understands the error codes is very hard once
we start indicating multiple failures.

OTOH, reporting "no error" in the header field is probably misleading, is
there a "error inside" value?  That being said, I think having "no error"
in the header field is better than having some other specific error code
there.

---

There is a paper by Ferguson & Schneier called "A Cryptographic Evaluation
of IPsec," unfortunately I have a copy for which I cannot give a published
reference[1] (it was handed to me).  In this, they[2] criticize IPsec from
a security/cryptographic point of view.  I think that some of the
interesting points are the claims that the documentation of IPsec prevents
good security analysis, as well as the protocol's complexity making it hard
to ensure that security is "attained."  The reason I am riding the DNS
security documents hard is to try and avoid the same criticisms if DNS
security.

[1] There is a URL: www.counterpane.com under the title.
[2] Assuming the paper did not forge their typed names...;)

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda
"It takes years of training to know when to do nothing" - Dogbert 1/21/00

Opinions expressed are property of my evil twin, not my employer.