> Let me try another, more concise phrasing. When one adds secruity to a > protocol, the goal is to enable it to operate in a hostile environment with > the same semantics that it offered in a non-hostile environment. Of course a > secure version of a protocol will exhibit some differences in its operation > from an insecure version, especially when one compares the two version in > attacks scenarios.
So, this theory of semantics is interesting --and worth thinking about a little. What is the "semantic of a protocol?" In saying this, we could mean several things. 1. We are trying to secure the semantics of the protocol in terms of what the protocol actually tells us. 2. We are trying to secure the semantics of the protocol in terms of the way in which it tells us something. So compare this to a telephone conversation. In the first sense, I'm told over the telephone that it is raining today. To check, I put my hand out the window to see if the person on the other end of the phone is right. I've used an out of band mechanism to check the validity of the information itself. Or I could encrypt the data path. I've now used an in-band system to verify the information was received correctly (as transmitted). Which semantic is it we're supposed to be securing here? The validity of the database, or the correct transmission of the information end-to-end? If it's the correct transmission of the information, then why have we left some information out? Because it's "too hard?" How hard it is isn't a question on the table --if you're going to validate the transmission of the data, then you need to validate the transmission of all the data. "Too hard" isn't a valid excuse. But other times we seem to be talking about the validity of the database -the so-called "man in the middle attack." What I see happen is the range of semantics we're talking about slips back and forth quite a bit. Most attacks are, I think, simply movements in the semantic range --so you've protected the door, I'll now attack the human with the key. Either: 1. We're trying to secure the bits on the wire end-to-end (even though they don't exist end-to-end). Okay, so leave out the "man in the middle attack" as a requirement, because this has nothing to do with securing the bits on the wire. 2. We're trying to secure the validity of the database. Okay, so leave out the problem of ensuring the data itself isn't changed on the wire, and find a way to validate the database --policy and all. We're playing to the middle here, and the middle is rather muddled. Russ _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
