On Tue, 1 Apr 2014, Paul Hoffman wrote:
The ICV consists solely of the AES-GCM Authentication Tag.
Implementations MUST support a full-length 16-octet ICV, and MAY
support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths.
Me personally, and one of the authors of 4106 (John Viega) would like to
see those other ICV's moved to SHOULD NOT. Since these are MAY in 4106,
and not mentioned in this draft, they would remain MAY.
That was the intention: MAY. "SHOULD NOT" somewhat indicates a belief that the
crypto has degraded, and that is not the case here.
Ok, too bad :P
I also wonder about:
"It is NOT RECOMMENDED to use ESP with NULL authentication
in conjunction with AH"
Why do we now say "NOT RECOMMENDED" instead of continuing to talk in
RFC4835 terms? eg:
ESP with NULL authentication MUST NOT be used in conjunction
with AH.
If we go through the effort of stating such deployments are insecure,
which we do in the next line, we might as well clearly tell implementors
not to do this. "not recommended" does not say "don't do this".
RFC 4835 does not say that ESP with NULL MUST NOT be used with AH. It waffles.
Isn't the point of this document to fix that waffling?
The next sentence is:
"some configurations of this combination of services have been shown to be
insecure [PD10]"
Isn't "is insecure" a good enough reason to MUST NOT?
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
