Hi Stephen, Hi Nicholas, it would be interesting (as a history lesson) if someone could tell us why the group at that time decided to develop a NULL encryption mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have no heard
In context of our discussion on this list the answer will give us a lot of guidance for the future. Even 2 years ago I had lots of people arguing in the OAuth working group that authentication and integrity protection is sufficient and that we do not need confidentiality protection. So, I wouldn't be surprised if the same argument showed up 10 years earlier. We have to look forward, with our knowledge of the changed threat landscape, so that we make better design choices in ongoing and future IETF work. Ciao Hannes On 12/08/2013 08:49 PM, Stephen Farrell wrote: > > > On 12/08/2013 03:55 PM, Nicholas Weaver wrote: > > > On Dec 7, 2013, at 4:09 PM, Bruce Perens <[email protected]> wrote: > >> Well, we do have some HTTP uses where encryption that hides the > >> content won't be allowed, and thus authentication is important. > >> > >> We can't have encryption when we use HTTP over Amateur Radio in > >> the US and many other countries. There is self-policing on ham > >> frequencies that requires that people be able to copy other > >> people's transmissions, and encryption defeats that. Obviously > >> we don't put confidential data on those frequencies, that belongs > >> on your cell phone. So, an authentication-only WiFi protocol is > >> needed for Amateur Radio, and possibly an authentication-only > >> version of TLS. > > > NO!!!! > > > The reason is downgrade attacks. A huge problem with the IPSec > > standard is that NULL encryption was allowed in there, and also > > known weak modes (single DES, 720b D/H etc). Its one of the > > primary reasons why John Gilmore and therefore others feel the > > IPSec process was sabotaged by the NSA. > > Really? That makes no sense to me. I've never heard any report of a > use of IPsec that "accidentally" used a NULL or weak cipher. Have > you? And Jeff Schiller I think convincingly repudiated claims that > either the development process for IPsec or the output were > saobtaged in any such way. > > I wasn't much involved myself but my impression was that we (the > IETF security community) shot ourselves in the foot a bit via > complexity and various refusals to prioritise progress and > deployment over purity. > > We need to carefully balance security and pragmatism here IMO if > our goal is to make for a more secure and privacy friendly Internet. > > I also think that throwing "sabotage" into the mix damages that > discussion so should be avoided. > > S. > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
