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

[Kathleen Moriarty <[e-mail]>]

Hello,

I never got an answer as to whether or not I should wait on the last call,
so I pushed it through.  No comments came in during the holiday period.
Should last call be extended?  Or does the WG feel the reason was because
the document is ready?  If the latter then I'll get it ready for an IESG
telechat.  I'd prefer to put it on 2/2/2017 as there are already a fair
number of documents on the telechat in 2 weeks.

Thanks,
Kathleen

On Fri, Dec 16, 2016 at 3:44 PM, Kathleen Moriarty <
[e-mail]> wrote:

> Hi Paul,
>
> Thanks for your response and sorry for my delayed response.
>
> On Mon, Dec 12, 2016 at 1:10 PM, Paul Wouters <[e-mail]> wrote:
>
>> 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:
>>>
>>>    This document does not give any recommendations for the use of
>>>    algorithms, it only gives implementation recommendations for
>>>    implementations.
>>>
>>
>> Will do if we do a new draft version, or else will remind RFC editor of
>> it.
>
>
> Great.
>
>>
>>
>> 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.
>>>
>>
>> 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.
>
>
> 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
>
>>
>>
>> Paul
>>
>
>
>
> --
>
> Best regards,
> Kathleen
>



-- 

Best regards,
Kathleen