On Feb 28, 2013, at 18:09 , Eric Burger <[email protected]> wrote:
> Isn't the problem that when the protocol was written (thinking in the > abstract), no one knew it was going to be used for foo, and foo did not have > the proper security properties? You are right, it is almost a policy problem, > not a technology problem, that the wrong protocol was chosen. I am not sure > we can anticipate all uses of a protocol and warn against stupidity. we can't, you are right. A single sentence in the protocol "this protocol is not intrinsically secure; if security is needed, use, or layer on, a different protocol" might be enough. in 'privacy considerations' I think we need to explore the privacy consequences of using protocols 'appropriately'. And there are, and it's no longer OK not to worry about them as we design protocols. > > -- > Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF > LEMONADE for mobile email! See <http://www.standardstrack.com/ietf/lemonade/> > > On Feb 28, 2013, at 5:39 PM, SM <[email protected]> wrote: > >> At 17:07 28-02-2013, Eric Burger wrote: >>> I think the point is we have a clue, and we disagree. What is a person >>> without a clue to do? >> >> The person can convince Alissa and Hannes to suggest text. :-) >> >> At 17:14 28-02-2013, David Singer wrote: >>> I think you're being a bit brief here. It's not a security problem with >>> the design of the protocol; if it carries data in the clear, it never >>> pretended to be secure. It's a problem that it was the wrong protocol to >>> be used, for sure. We're concerned about intrinsic security and privacy >>> problems in our specifications, not the mis-use of them (though we can >>> warn, I guess). >> >> Sorry about that. There is usually a security policy. This is not part of >> the protocol; it's about what security measures should be taken. >> >>> ditto. There was nothing wrong with the design of the unencrypted line; it >>> was the wrong 'protocol' to use. >> >> Yes. The issue is related to information classification and disclosure. >> >> BTW, the cases can be argued both ways. Given that privacy is complex it is >> easier to explain some points in terms of security. >> >> Regards, >> -sm > _______________________________________________ > ietf-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-privacy David Singer Multimedia and Software Standards, Apple Inc. _______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
