Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt

From: Paul Wouters <[email-masked]>
Date: Tue, 1 Apr 2014 16:46:15 -0400 (EDT)

On Mon, 31 Mar 2014, [email-masked] wrote:

> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt

> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-esp-ah-reqts-03

So one of the changes is:

- SHOULD+ AES-GCM [RFC4106]
+ SHOULD+ AES-GCM with a 16 octet ICV [RFC4106]

While I'm happy with that change (I argued for it to not using the
truncated ICV versions), the document now makes no statement about those
other ICV variants. RFC 4106 states:

 	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.

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".

language nits:

As a non-native english speaker, "efficacy" was not clear to me, and
almost read as "efficiency". So I would change "undermines the efficacy
of encryption". Maybe something like just "undermines the trustworthiness
the encryption" (although that sounds a bit Colbert like :)

s/perfers/prefers

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 Apr 2014 14:23:52 -0700

> 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.

> 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.

> the encryption" (although that sounds a bit Colbert like :)

I'll make these changes in -04. It turns out I need to do a rev anyway because I forgot to list the new DES "MUST NOT" in the changes summary.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 1 Apr 2014 17:42:16 -0400 (EDT)

> 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

> 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