On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig <[email protected] > wrote:
> 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 > It was for testing and it all happened long before any of the evidence of the NSA peddling bongoed crypto suggests that it was going on. I think it highly unlikely that anything of the sort was going on before 9/11 and my sources claim that the change came much later, if it happened at all. I really don't think that any of the people involved in IETF process have had a hand in knowingly peddling bongoed crypto either. But as I have been making plain in another forum, the slides openly bragging about such an operation have had a serious cost in terms of erosion of trust. I think any interference would have been 'action at a distance'. Rather than come here and make the case for protecting some hole that was going to be used to propagate Flame, I would expect the NSA people running the DoD CA would call up their contacts in IETF space and make up some story about their operational difficulties caused by still running the old Netscape CA that hasn't been maintained for a decade now or some such hokum. I can't see how that sort of cover story would work for peddling a NULL cipher. There are some vulnerabilities I think can be laid at their door but not that one. We did that one to ourselves. IPSEC is sufficiently complicated that interop is a non trivial problem. Or at least the people who implemented it found it to be so. Some people tried to make the same suggestion for S/MIME (and people might remember my reaction). Having a NULL cipher for interop testing was not an unfounded proposal but it was certainly never one I supported. Remember that IPSEC has always supported an 'authentication only' mode. So turning on encryption with a null cipher was not an obvious difference. In fact it would probably have made sense to have killed the integrity only option at the start and just had a null cipher. Perhaps we should write a draft and move it to HISTORIC, just to avoid any confusion. > 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. > That is a different argument and maybe there is a case to be made for relying on HTTPS. I don't like that approach, in fact I super-encrypt within HTTPS quite often and always super-authenticate end to end in my Web Services. -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
