Subject: RE: Last Call: 'A Lightweight UDP Transfer Protocol for the the I nternet Registry Information Service' to Proposed Standard (draft-ietf-cr isp-iris-lwz)

From: "Gray, Eric" <[email-masked]>
Date: Thu, 17 Aug 2006 11:23:19 -0400

Sam,

	I thought the Security Area Directorate was limited to 
determining if the description of security risks is adequate
and that determination of whether security is adequate - for
adequately described security risks - would be up to the end
consumer.

	Is that not correct?  Certainly it will be the case that
- if product consumers disagree with a finding within the IETF
- they may very well go ahead and buy products that the IETF
has determined not to have "adequate security."  In that case,
what the IETF has rejected on the basis of security concerns,
will become a defacto standard without the "blessing" of the
IETF.

	I'm sure this is an old, often rehashed, argument - but
I just wanted to be sure about your comments...

--
Eric 

--> -----Original Message-----
--> From: Sam Hartman [mailto:[email-masked]] 
--> Sent: Thursday, August 17, 2006 11:03 AM
--> To: Mark Townsley
--> Cc: [email-masked]; [email-masked]
--> Subject: Re: Last Call: 'A Lightweight UDP Transfer 
--> Protocol for the the Internet Registry Information Service' 
--> to Proposed Standard (draft-ietf-crisp-iris-lwz)
--> 
--> >>>>> "Mark" == Mark Townsley <[email-masked]> writes:
--> 
-->     Mark> Sam Hartman wrote:
-->     >> I notice that this transport provides no 
--> authentication of the
-->     >> data that is retrieved.
-->     >> 
-->     >> The security considerations needs to discuss the potential
-->     >> attacks if an attacker modifies this public data.  
--> The security
-->     >> considerations section also needs to point to best 
--> practice for
-->     >> avoiding UDP reflection attacks.  It is not good 
--> enough to say
-->     >> "Do what other people do."
--> 
--> s/reflection/amplification sorry
--> 
-->     Mark> " 1.  If a request requires authentication, 
--> confidentiality,
-->     Mark> or other security, use another transfer protocol."
--> 
-->     Mark> It seems to me that the intent is to not provide
-->     Mark> authentication here. This seems more fundamental 
--> than a fix
-->     Mark> by reference.
--> 
--> Sure.  What I'm asking for is that they explain what the 
--> consequences
--> of providing no authentication are.  I'll then evaluate those
--> consequences and either conclude that authentication is not required
--> for this data for an Internet deployment or come back with another
--> comment that the security is inadequate.  But the first step of
--> determining whether the security is adequate is to 
--> determine the risk.
--> 
--> _______________________________________________
--> Ietf mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Aug 2006 11:44:55 -0400

>>>>> "Gray," == Gray, Eric <[email-masked]> writes:

    Gray,> Sam, I thought the Security Area Directorate was limited to
    Gray,> determining if the description of security risks is
    Gray,> adequate and that determination of whether security is
    Gray,> adequate - for adequately described security risks - would
    Gray,> be up to the end consumer.

first, this document is in last call.  It's very clear to me that I
can make a last call comment as an IETf contributor that I think the
security is inadequate.

I don't have time right now to come up with text I believe to be
formally correct that describes when I would feel comfortable entering
a security discuss.  I refer you to the IESG discuss criteria document
as a good starting point.

--Sam

---

From: Andrew Newton <[email-masked]>
Date: Thu, 17 Aug 2006 12:11:52 -0400

> can make a last call comment as an IETf contributor that I think the

To be quite honest, I was unsure which hat you were wearing when you made 
your statement.  I'm also unsure if it matters.

All that being said, I agree that the security considerations section is 
missing quite a bit.  It should explain the consequences of using this 
protocol from a security point of view.  And the big thing it left out, is 
that not only should it mention that there are alternatives, but it should 
explicitly state what they are.  In this case, the security considerations 
section ought to specifically point to XPC, which is also from the CRISP wg 
and being IETF last called at the moment.  That draft is 
draft-ietf-crisp-iris-xpc-04.txt; a review of it would be helpful.

-andy