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 <[email protected]> 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:[email protected]] On Behalf Of Michael
]Richardson
]Sent: Tuesday, July 08, 2014 11:00 AM
]To: Stephen Farrell
]Cc: [email protected]; [email protected]
]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis
]
]
]Stephen Farrell <[email protected]> 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 <[email protected]>, Sandelman Software Works -=
]IPv6 IoT consulting =-
]
]
_______________________________________________
saag mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/saag
Personal email. [email protected]
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
