Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ???

[Merike Kaeo <[e-mail]>]

And so I reply to myself but got curious and wanted evidence.  I found first references of AH/ESP and NULL in 1996 June IPsec archives.  http://www.sandelman.ottawa.on.ca/ipsec/1996/06/msg00030.html

And while  some interesting tidbits, the joggle for my memory banks was that there was a bunch of discussion on where AH would be used with ESP and whether ESP only would also be relevant.  And while I couldn't find exact reference to the March 1998 interop testing in North Carolina that showed issues with AH not traversing NATs I am fairly certain that was the case and why in practice people starting using ESP-Null.  (it wasn't in the notes for the follow-up IETF IPsec meeting).

Someone else from that time may also be able to chime in.

- merike


On Dec 8, 2013, at 8:19 PM, Merike Kaeo <[e-mail]> wrote:

> 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 <[e-mail]> wrote:
> 
>> On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/perpass
> 
> _______________________________________________
> perpass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/perpass