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:hartmans-ietf(_at_)mit(_dot_)edu]
--> Sent: Thursday, August 17, 2006 11:03 AM
--> To: Mark Townsley
--> Cc: ietf(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org
--> 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 <townsley(_at_)cisco(_dot_)com> 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
--> Ietf(_at_)ietf(_dot_)org
--> https://www1.ietf.org/mailman/listinfo/ietf
-->
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf