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

[Phillip Hallam-Baker <[e-mail]>]

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/