Subject: Re: IESG feedback on dnsext-ad-is-secure

From: Edward Lewis <[email-masked]>
Date: Sun, 16 Jun 2002 00:55:13 -0400

At 11:42 PM -0500 6/15/02, Ted Lemon wrote:
>Does this make any sense to you, or am I making a mistake about this 
>somewhere?   I don't understand your point about bad keys, so maybe 
>I'm missing something.

You and Greg are hitting on the same point - that the information 
conveyed by the AD bit is important to the application.  My response 
now is that this is an API issue, not a protocol issue.

Perhaps there is a benefit there, but I certainly didn't get it from 
the draft.  I usually think in terms of server to server to stub 
interactions, but I rarely consider what happens at the application 
level.

Quoting the message that started this all, at 3:54 PM +0200 6/10/02, 
by Erik Nordmark I see that my failure to grasp that this was an 
application API issue may lay in comments already leveled against the 
draft:

>The document doesn't explain the expected usage of the AD bit
>by the receiver. This makes it hard to evaluate the benefits.
>Is the intent that the application be notified? If so, what are some
>examples of what the application will do based on the value of the bit?
>
>The applicability of the document isn't clear. If the document is
>going to move forward it would need a "safe" applicability statement.
>For example, while the blind trust in a resolver might make sense e.g. in
>an enterprise network, it doesn't seem to make sense in the home/ISP
>setting where the ISP would run the resolver.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

--
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: Edward Lewis <[email-masked]>
Date: Sun, 16 Jun 2002 13:51:24 -0400

At the urging of some off-list messages, I was urged to re-read the 
draft and figure out why I'm running so contrary to the consensus.

I still find the draft lacking, as was noted in Eric's message, but 
after considering the post-IESG feedback mail thread, the AD bit 
makes more sense.

The problem is that I have been afraid of putting the bit into 
"general use."  Perhaps it is the specification style of the draft, 
but it is not until the last paragraph of the Security Considerations 
is the crucial text:

    Resolvers (full or stub) that blindly trust the AD bit without
    knowing the security policy of the server generating the answer can
    not be considered security aware.

So, the authors assume that there is no need to transfer policy 
because the receiver already know the sender's policy.  And I take 
"knowing" to include "I know the administrator of that server and if 
I get burned, I can ask her to update the keys."

In addition, this passage, which I *have been* aware of, doesn't 
appear until the last paragraph of section 3.  This should be brought 
forward in the document.

    A resolver MUST NOT blindly trust the AD bit unless it communicates
    with the server over a secure transport mechanism or using message
    authentication such as TSIG [RFC2845] or SIG(0) [RFC2931] and is
    configured to trust the server.

So, if the AD bit constricted to be meaningful only between mutually 
consenting resolver and server, defining it to mean that the server 
followed the DNSSEC policy makes sense.

The up shot for me is that I would support this redefinition of the 
bit if the authors make the restrictions "buried" late in the 
document are promoted to the introduction.

Perhaps buried is a strong term, but I really dislike any 
specification or constraint language in the "* considerations" that 
hasn't appeared earlier.  I prefer to just put analysis in those 
sections, e.g., listing the consequences of voiding parts of the 
specifications.  In this instance, the security considerations should 
mention that blindly trusting the AD bit may result in trusting an 
unverifiable (even out of band) server, etc.

Finally - if the intent of the AD is to enable applications to report 
the use of validated data, then this ought to be mentioned in the 
introduction.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Edward Lewis <[email-masked]>
Date: Sun, 16 Jun 2002 17:07:31 -0400

I can't even let myself have the last word.  Given the following 
passage, I would urge the addition of this in section 2:

"The AD bit SHOULD NOT be set unless TSIG/SIG(0) is being used to 
protect the response."  "SHOULD" appears because local policy might 
dictate otherwise.  This is would reinforce the notion below.

At 1:51 PM -0400 6/16/02, Edward Lewis wrote:
>but it is not until the last paragraph of the Security 
>Considerations is the crucial text:
>

---

From: Donald Eastlake 3rd <[email-masked]>
Date: Sun, 16 Jun 2002 20:08:22 -0400 (EDT)

On Sun, 16 Jun 2002, Edward Lewis wrote:

> Date: Sun, 16 Jun 2002 13:51:24 -0400
> From: Edward Lewis <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: IESG feedback on dnsext-ad-is-secure
>
> ...
>
> ...

It is common for their to be resolvers, such as those on machines within
a company, that are more or less required to follow the
resolution/security policies of corporate level or border recursive
servers, whether they know, like, or approve of such resolution/security
policies.

Donald

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Mon, 17 Jun 2002 00:24:18 -0400

At 01:51 PM 6/16/2002, Edward Lewis wrote:
>At the urging of some off-list messages, I was urged to re-read the draft 
>and figure out why I'm running so contrary to the consensus.
>
>I still find the draft lacking, as was noted in Eric's message, but after 
>considering the post-IESG feedback mail thread, the AD bit makes more sense.

Finally a constructive comments on the draft from Ed, I guess the
unreported yelling and cursing at him at the Black Helicopter meeting
helped :-)

>The problem is that I have been afraid of putting the bit into "general 
>use."  Perhaps it is the specification style of the draft, but it is not 
>until the last paragraph of the Security Considerations is the crucial text:
>
>So, the authors assume that there is no need to transfer policy because 
>the receiver already know the sender's policy.  And I take "knowing" to 
>include "I know the administrator of that server and if I get burned, I 
>can ask her to update the keys."
>
>In addition, this passage, which I *have been* aware of, doesn't appear 
>until the last paragraph of section 3.  This should be brought forward in 
>the document.
>
>The up shot for me is that I would support this redefinition of the bit if 
>the authors make the restrictions "buried" late in the document are 
>promoted to the introduction.

Will gladly do this,

>Perhaps buried is a strong term, but I really dislike any specification or 
>constraint language in the "* considerations" that hasn't appeared 
>earlier.  I prefer to just put analysis in those sections, e.g., listing 
>the consequences of voiding parts of the specifications.  In this 
>instance, the security considerations should mention that blindly trusting 
>the AD bit may result in trusting an unverifiable (even out of band) 
>server, etc.
>
>Finally - if the intent of the AD is to enable applications to report the 
>use of validated data, then this ought to be mentioned in the introduction.

s/application to report/stub resolvers to report to applications/

The original motivation for this draft was to enable REMOTE TRUSTED
recursive resolvers to signal validation status to local stub resolver,
thus enabling it to pass this information on to the application.
The use of this bit by protocol elements (read resolvers) was limited
to policy directives by applications such as:
         accept only validated KEY records
         accept any CERT records

These issues are API issues and well outside DNS protocol, but it
is important that DNS protocol carry this information to leaf notes
that depend on "servers" to do the heavy lifting of DNSSEC.

         Olafur

         Olafur

---

From: Edward Lewis <[email-masked]>
Date: Mon, 17 Jun 2002 08:47:48 -0400

At 9:14 AM +0200 6/17/02, Simon Josefsson wrote:
>
>Should it really restrict it to TSIG/SIG(0) only?  What if I run IPSEC
>to my local DNS cache, and the DNS cache understands this?

Yeah - I wasn't about to exhaust the run of possibilities.  And 
that's why I used "SHOULD NOT."

'Course the question is how to implement the choice.  It could be a 
run-time option, with the default to clear the bit unless the in-bad 
protections are used.  I don't think it would be proper to delve into 
whether one implementation or another can or can not detect the IPsec 
security associations in use.

...But the spirit of the comment should account for your suggestion.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 17 Jun 2002 09:14:56 +0200

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

---

From: Brian Wellington <[email-masked]>
Date: Mon, 17 Jun 2002 15:36:15 -0700 (PDT)

> to my local DNS cache, and the DNS cache understands this?

Or if the client and cache are on the same machine.  I think I trust the 
loopback interface without crypto.

Brian