--On Friday, September 06, 2013 06:20 -0700 Pete Resnick <presnick@xxxxxxxxxxxxxxxx> wrote: > Actually, I disagree that this fallacy is at play here. I > think we need to separate the concept of end-to-end encryption > from authentication when it comes to UI transparency. We > design UIs now where we get in the user's face about doing > encryption if we cannot authenticate the other side and we > need to get over that. In email, we insist that you > authenticate the recipient's certificate before we allow you > to install it and to start encrypting, and prefer to send > things in the clear until that is done. That's silly and is > based on the assumption that encryption isn't worth doing > *until* we know it's going to be done completely safely. We > need to separate the trust and guarantees of safeness (which > require *later* out-of-band verification) from the whole > endeavor of getting encryption used in the first place. Pete, At one level, I completely agree. At another, it depends on the threat model. If the presumed attacker is skilled and has access to packets in transit then it is necessary to assume that safeguards against MITM attacks are well within that attacker's resource set. If those conditions are met, then encrypting on the basis of a a key or certificate that can't be authenticated is delusional protection against that threat. It may still be good protection against more casual attacks, but we do the users the same disservice by telling them that their transmissions are secure under those circumstances that we do by telling them that their data are secure when they see a little lock in their web browsers. Certainly "encrypt first, authenticate later" is reasonable if one doesn't send anything sensitive until authentication has been established, but it seems to me that would require a rather significant redesign of how people do things, not just how protocols work. best, john