Apologies in advance for top-posting. I keep meaning to get caught up on this mailing list but never quite manage it. However, the IPsec NULL is something that I see so misrepresented everywhere that I wanted to chime in. It was to the best of my recollection developed after the 1998 bake-off in Cary North Carolina (I was there) to enable integrity protection thru NAT's. AH had issues transversing NAT devices which if some others of you were around will remember was a technology that was just taking off at that time. It was felt that using the NULL encryption gave you at least integrity protection for the data even though it did not protect the IP addresses (or anything else that was part of the IP header that wasn't morphed in transit). However, for anyone who is very well versed with IPsec, you will note that if a SPD requires IP src and dst address as well as SPI, then the IP addresses are implicitly protected. Note that the NAT traversal protocol had its beginnings from that 1998 event as well.
Also please remember that at the time IPsec was being developed there were still global import/export restrictions relating to cryptographic protection. Not just in the US mind you….I have a table in a book I wrote in 1999 that actually listed a bunch of countries and the restrictions at that time. There typically wasn't a restriction on key length for cryptographically protected integrity protocols but there was one for cryptographically protected confidentiality (i.e. encryption) protocols. In the US it was 40 bit restriction on encryption. I believe for some *limited* subset of countries this is still true for US export controls on cryptography today. Anyhow…just to get some of the history straight. And I speak as someone who was at cisco at the time and did a lot of performance and interoperability testing….and sat in the back of the room at *all* of the IPsec meetings since the original BoF back in 1993/4 and discussed issues in background (I don't write code….but can find bugs :)). And as someone who spent well over a decade trying to get vendors and users to understand issues of IPsec implementations and usability in a v6 world [while an independent consultant]. I gave up 4 years ago. And FWIW, for IPsec the primary deployment issues are in implementation terminology and interoperable defaults. I will gladly argue that point over beers anytime. - merike On Dec 8, 2013, at 5:52 PM, Phillip Hallam-Baker <[email protected]> wrote: > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
