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

On 07/21/2014 08:51 PM, Henry B Hotz wrote:
> The basic issue, as always, is interoperability. NULL should not be an interoperable *operational* capability.

In this regard, I have a hard time distinguishing between NULL with 
HMAC-SHA256 and CMAC or GMAC.

With this (secure communications) context NULL means no privacy but yes 
authenticity.

>
> Every implementation will have some kind of debugging capability so it can be made operational. Do we require an interoperable debugging capability? I believe the consensus is already leaning to "no".
>
> My own take is that we don't normally do that, and the likely debugging benefit of mandating such a thing is insufficient to justify making it a MUST.
>
>
> On Jul 21, 2014, at 4:57 PM, Paul Lambert <paul@marvell.com> wrote:
>
>> NULL may be useful to some, but should NOT be mandated (should rather than must).
>> It's another knob that could be set incorrectly and bypass the encryption.  Not all products will want or need NULL.
>>
>>
>> Paul
>>
>> ]-----Original Message-----
>> ]From: Hipsec [mailto:hipsec-bounces@ietf.org] On Behalf Of Michael
>> ]Richardson
>> ]Sent: Tuesday, July 08, 2014 11:00 AM
>> ]To: Stephen Farrell
>> ]Cc: hipsec@ietf.org; saag@ietf.org
>> ]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis
>> ]
>> ]
>> ]Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>> ]    > Generic: is it still considered a good plan to have null
>> ]    > confidentiality suites such as these? Or for those to be
>> ]    > Mandatory-To-Implement (MTI)? That clearly was the generic
>> ]consensus as
>> ]    > we have these in a number of protocols. The new reasons to move
>> ]from
>> ]    > that I think are: 1) we no longer need this for debugging purposes
>> ]    > really since libraries and dev tools have moved on and are better
>> ]now,
>> ]    > and we specifically no longer need these for protocols that are no
>> ]    > longer new, 2) BCP188 could be considered to argue against having
>> ]these
>> ]
>> ]There are an incredible number of systems (Linux with stock-in-kernel
>> ]NETKEY IPsec for instance), where it is impossible or very very
>> ]difficult to get a packet capture of the traffic after decryption, but
>> ]before it goes up the protocol stack.
>> ]
>> ]On such systems, if you have a problem in the field with a protocol that
>> ]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out how
>> ]it works, and it appears to with without ESP, then the lack of debugging
>> ]means that you turn off all security.
>> ]
>> ]ESP-authenticated-with-NULL-encryption is debuggable in the field.
>> ]Not having it, means turning off ESP; and if the problem is in the link
>> ]between the ESP layer and the upper layer, then...
>> ]
>> ]--
>> ]Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -=
>> ]IPv6 IoT consulting =-
>> ]
>> ]
>>
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
> Personal email.  hbhotz@oxy.edu
>
>
>
>
>
>
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec