Subject: [IPsec] AD review of draft-ietf-ipsecme-rfc4307bis

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 9 Dec 2016 13:33:31 -0500

Hello,

Thanks for your work on draft-ietf-ipsecme-rfc4307bis.  I reviewed the
draft and just have a few questions, the first is a nit.

Nit:
In the second paragraph of 1.3, you can drop the last two words of this
sentence as they are redundant:

   This document does not give any recommendations for the use of
   algorithms, it only gives implementation recommendations for
   implementations.

In section 3.2 & 3.3, why isn't there a bigger jump down to SHOULD or
SHOULD- for:

PRF_HMAC_SHA1     | MUST-    |

| AUTH_HMAC_SHA1_96      | MUST-

The justifications seems like a bigger jump would be appropriate.

Thank you!

-- 

Best regards,
Kathleen

---

From: Paul Wouters <[email-masked]>
Date: Mon, 12 Dec 2016 13:10:51 -0500 (EST)

On Fri, 9 Dec 2016, Kathleen Moriarty wrote:

> Hello,
> Thanks for your work on draft-ietf-ipsecme-rfc4307bis.  I reviewed the draft and just have a few questions, the first is a nit.
> 
> 
> Nit:
> In the second paragraph of 1.3, you can drop the last two words of this sentence as they are redundant:
>

Will do if we do a new draft version, or else will remind RFC editor of it.

> In section 3.2 & 3.3, why isn't there a bigger jump down to SHOULD or SHOULD- for:
> 
> PRF_HMAC_SHA1     | MUST-    |
> 

In 4307 itself, we only had one MUST and that was SHA1. The SHOULD+
candidate was AES_XCBC but it was been overtaken in reality by SHA2.
And AESPRF/AES_MAC is not as widely implemented (example: not
available in NSS) so even those implementors who picked the MUST
and SHOULD algorithm only have SHA1 and AESPRF/AES_MAC. If a 4307bis
implementation only implements the MUST algorithms, it would not interop
with a 4307 implementation that implemented all the MUST and SHOULDs,
if we made SHA1 a SHOULD- or less.

I think the available options we have are MUST- or SHOULD-. I think
MAY or SHOULD NOT would lead to interoperability issues. I think the
MUST- is still the best choice.

Note also that all SHA1 use here is still safe (HMAC and PRF are
different from plain SHA1)

Note though that I would like to keep the status for Type 2 and Type 3
the same, because all sane implementations will use the same INTEG and
PRF algorithms for a given IKE session, so these two are tightly
coupled.

Paul

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 16 Dec 2016 15:44:50 -0500

Hi Paul,

Thanks for your response and sorry for my delayed response.

> Will do if we do a new draft version, or else will remind RFC editor of it.

Great.

>> | AUTH_HMAC_SHA1_96      | MUST- The justifications seems like a bigger
>> jump would be appropriate.
>>
>

Yeah, I knew it was fine, but the justification provided was enough to drop
it further, so I wanted to poke at that a bit as it'll take the next update
to drop it further.  If that's what the WG agreed to, that's fine.  I'll
push this through to IETF last call unless the WG wants me to wait until
after the holidays.

Thank you,
Kathleen

-- 

Best regards,
Kathleen