Subject: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 15 Mar 2017 18:48:19 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-ipsecme-rfc7321bis-05: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm balloting "Yes", but I have a few minor comments/questions:

- Abtstract: "This document obsoletes RFC 7321 on the cryptographic
recommendations only."

I'm not sure what that means. Does the reader of this still need to read
7321? If so, is "obsoletes" the correct relation?

-3: I wonder why "... is not to be used..." is not "... MUST NOT be
used...". But the section goes on to say if you do it anyway, you MUST
NOT use certain cryptosuites. So, does "... is not to be used..." mean
"SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU WILL"
sort of requirements?

- Table in section 6:
I'm boggled by the first entry being labeled "MUST/MUST NOT". I don't see
anything in the text to explain the "MUST" part--did I miss something?

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Mar 2017 13:07:32 -0400 (EDT)

> 7321? If so, is "obsoletes" the correct relation?

Skimming over 7321 I cannot actually tell what we meant to not obsolete?
I think we can remove the "on the cryptographic recommendations only."

> "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU WILL"

It is indeed. I think a SHOULD NOT would actually be appropriate ?

> anything in the text to explain the "MUST" part--did I miss something?

First paragraph under the table:

    AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT.  The
    only reason NULL is acceptable is when authenticated encryption
    algorithms are selected from Section 5.  In all other cases, NULL
    MUST NOT be selected.

Paul

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 16 Mar 2017 17:14:33 +0000

Comments below.

> -----Original Message-----
> From: Paul Wouters [mailto:[email-masked]]
> Sent: Thursday, March 16, 2017 1:08 PM
> To: Ben Campbell <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; Waltermire, David A. (Fed)
> <[email-masked]>
> Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05:
> (with COMMENT)
> 

Anyone in the WG have an opinion about making this change to SHOULD NOT? Please comment soon if you do.

Thanks,
Dave

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 16 Mar 2017 12:55:31 -0500

Thansk for the response. This resolves all but one of my comments, where 
I still have a question:

> On Wed, 15 Mar 2017, Ben Campbell wrote:

[...]

>    algorithms are selected from Section 5.  In all other cases, NULL

So does the authenticated encryption case make AUTH_NONE a MUST? If so, 
it would help to add something along the lines of "..., in which case 
AUTH_NONE MUST be selected."  to the 2nd sentence.

---

From: "Frankel, Sheila E. (Fed)" <[email-masked]>
Date: Thu, 16 Mar 2017 20:13:46 +0000

Hi Dave,

I don't have any strong feelings about MUST NOT vs. SHOULD NOT, but I wonder if it would help to clarify the reasoning behind it.

For these algorithms, RFC6071 (IPsec/IKE Roadmap) says:
- Reuse of the IV with the same key compromises the data's security; thus, AES-GCM should not be used with manual keying.
- Reuse of the IV with the same key and nonce compromises the data's security; thus, AES-CTR should not be used with manual keying.
- Reuse of the IV with the same key compromises the data's security; thus, AES-CCM should not be used with manual keying.
- Reuse of the salt value with the same key compromises the data's security; thus, AES-GMAC should not be used with manual keying.

Instead of just saying "these algorithms require IKE", could we give a slightly more detailed explanation? something like: "These algorithms require the use of an automated key negotiation protocol (e.g. IKE) to avoid reuse of important parameters, whose reuse compromises the algorithm's security." (Not the best wording, but you get the idea!)

But if you don't add this, I wouldn't object to publication of the RFC.

Sheila Frankel

________________________________
From: IPsec <[email-masked]> on behalf of Waltermire, David A. (Fed) <[email-masked]>
Sent: Thursday, March 16, 2017 1:14:33 PM
To: [email-masked]
Cc: [email-masked]; Ben Campbell; [email-masked]; [email-masked]; The IESG
Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)

Comments below.

Thanks,
Dave

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: <[email-masked]>
Date: Thu, 16 Mar 2017 20:19:40 +0000

On Mar 16, 2017, at 4:13 PM, Frankel, Sheila E. (Fed) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dave,

For these algorithms, RFC6071 (IPsec/IKE Roadmap) says:
- Reuse of the IV with the same key compromises the data's security; thus, AES-GCM should not be used with manual keying.   ...

If "compromises" means that the security is slightly weakened, then this wording seems ok.  If it means that the cipher is readily broken if you do this bad thing, then the only valid text is "MUST NOT".

paul

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 23 Mar 2017 11:37:12 +0200

> It is indeed. I think a SHOULD NOT would actually be appropriate ?

We do not want to make the implementation of the manual keying MUST
NOT, as it is still useful in testing and similar situations, but we
do not want anybody using it in any real world use cases. As this
document is mostly about the implementation and tries to stay out from
the issues about what should be used (as explained in the 2nd
paragraph of the section 1.3).

On the other hand section 1.3 is really about the use of the manual
keying, not about the implementation of manual keying, so that
confuses things (we do have some other cases were we say things DES
MUST NOT be used).

I think the text needs to be clarified about this bit more, especially
we do not want to say that ENCR_AES_CBC MUST be used, as there are
other algorithms which can also be used (MUST be used would indicate
no other algorithm is possible).

>     algorithms are selected from Section 5.  In all other cases, NULL

It does not make it easier that there is typo in that paragraph, and
it talks about NULL, when it should be talking about AUTH_NONE... 
-- 
[email-masked]

---

From: <[email-masked]>
Date: Thu, 23 Mar 2017 13:04:47 +0000

> On Mar 23, 2017, at 5:37 AM, Tero Kivinen <[email-masked]> wrote:
> 
> Paul Wouters writes:

The problem is that currently USGv6 mandates support for manual keying based on earlier RFC text.  I wonder if the proposed text is strong enough to make them understand this is wrong.  This is why I was pushing for MUST NOT.

Exotic test scenarios aren't all that good an argument, for those you can hack the code and ignore the RFC.

	paul

---

From: "Hu, Jun (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 23 Mar 2017 16:25:53 +0000

A very real use case is OSPFv3 authentication (RFC 4552), all major router vendor supports OSPFv3 implement that, and it is deployed around world;
Plus I don't see any realistic alternative for the use case

> From: IPsec [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, March 23, 2017 6:05 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; ipsecme-
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> >>> used...". But the section goes on to say if you do it anyway, you
> >>> MUST NOT use certain cryptosuites. So, does "... is not to be
> >>> used..." mean "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE
> KNOW YOU WILL"
> >>> sort of requirements?
> >>
> The problem is that currently USGv6 mandates support for manual keying
> based on earlier RFC text.  I wonder if the proposed text is strong enough to
> make them understand this is wrong.  This is why I was pushing for MUST NOT.
>