Re: [saag] NULL encryption mode in RFC 5202-bis

[ianG <[e-mail]>]

On 8/07/2014 05:54 am, Tom Henderson wrote:
> Hi all,
> 
> Apologies for cross-posting, but Stephen Farrell raised a DISCUSS
> (seconded by Kathleen Moriarty) in the IESG evaluation of RFC 5202-bis:
>   Using the Encapsulating Security Payload (ESP) Transport Format with
> the Host Identity Protocol (HIP).  Stephen asked me to raise this
> question for discussion on both the HIP and SAAG lists.
> 
> Stephen's discuss questions the specification of "MUST to implement" for
> the NULL encryption option of the ESP_TRANSFORM parameter:
> 
> http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-05#section-5.1.2
> 
> Stephen asks why is this a MUST to implement?  The history behind this
> that I'm aware of is that since HIP does not have an AH, only ESP, the
> ESP with NULL encryption mode can provide authentication.


IIUC, this derives from old arguments that encryption is expensive so
there might be a use case [0] where it is desirable to turn it off, and
users should have that option because it's cost free.

This is more or less a deprecated argument.  Encryption is no longer
expensive.  The history of users is that they don't have a need to turn
it off, they aren't equipped to make the decision properly, and giving
them one more knob to play with creates one more support headache.

And, it isn't cost free:  null ciphers introduce a lovely downgrade
attack, and marginal internal fault possibilities.

It also relates to a bygone age where active MITM was believed a greater
enemy than passive eavesdropping, so auth was king.  History hasn't been
kind to that view.


> It was also
> stated in previous drafts that this mode supports debugging.


If it is debugging, the advice is backwards, IMHO.  NULL ciohers should
not be mandatory to implement.  Developers will do what they will, if
they need a mode like that they will add it, they don't need to be told
they must do it.

Better advice would be that that production code MUST be shipped with
all dangerous debugging modes stripped out, not implemented.



iang



[0] curiously, a modern use case might be found in Bitcoin where
encryption isn't needed because the tx are all published anyway.  I find
this a tough mental barrier.