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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Fri, 16 December 2016 20:45 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828CB129B87 for <ipsec@ietfa.amsl.com>; Fri, 16 Dec 2016 12:45:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xTnuywZWhGS for <ipsec@ietfa.amsl.com>; Fri, 16 Dec 2016 12:45:08 -0800 (PST)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C751B1296CB for <ipsec@ietf.org>; Fri, 16 Dec 2016 12:45:01 -0800 (PST)
Received: by mail-ua0-x22a.google.com with SMTP id 3so34043542uaz.3 for <ipsec@ietf.org>; Fri, 16 Dec 2016 12:45:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MNNBJIPA7tTMV9akrYuAtlhZCEKqB9jMfDF8BlrzJjI=; b=E+nkzmuGENvaA2ACFHAu8PGC5PaFikPG/A+S+c2LglV67dCCKbtKzARTxqkW+A3aTm 6d4UsapxQauoJC9kq9lnBbH5fXyOuNgFKN8Or7/Bd7qj2JW+H5aXMH0q/wNlVnaXAQXd 75QLhtjjMg1tOLw9iXD3XFqPKCKbORBR08LlAYpZ76PTWdYV/v1U8HpYh7DBsTWJIBaH WvQu+0LG1hQWtwsJe532FnngtdONV+6YfIJnCBEI5Q0dECiic4GKUSkJdQKptg5a81ak 67cspwUYKp1iIMo9cTrgQAWij61kS1CSLVahV4/O6KZxfOj6hvN0PmfG0uSjc48MlceM q6Zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MNNBJIPA7tTMV9akrYuAtlhZCEKqB9jMfDF8BlrzJjI=; b=FJRdsFHoxjNmN9NbRzbP6L0P5H1SOv+hP1EN6zoxRMjPf6Q7LXGy/egVWMC2MtR/3b F6cJZCP+uADEPlTGlEftMkeIgyK8mSmKpMS45zQt0toum6cFu8tkDd5PydMCgfhLvOLt Mi5sOUKYKXmAHeIKXL0fBNym3jiKY8yGsmR1BtbX4XB8htIAupKcawbVIapEh8l/Xf9C jz2Lc57BiOsI9DRWBwrDjPLnCrctNwQoP+W9GXadbPAZppgjb2V9gXY4Mi5nCinj8SuE TqI8QJOGG7Tp2d6hVomp+Fxbr2Jepa789jTHNgMCCr+lIqWPFZPWpL6MkUDCjGzyOjDb 4J1Q==
X-Gm-Message-State: AKaTC00zKKJHdaPnwwyS34e4oMrr4uryw8A++Hm+ebY/0v/4rrH8/dNG9RvfOJ2j9zPTJK1vpZMZH2zrLW/ToA==
X-Received: by 10.176.82.214 with SMTP id w22mr4317494uaw.167.1481921090599; Fri, 16 Dec 2016 12:44:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.82.232 with HTTP; Fri, 16 Dec 2016 12:44:50 -0800 (PST)
In-Reply-To: <alpine.LRH.2.20.1612121254150.14930@bofh.nohats.ca>
References: <CAHbuEH4pqTK-kc65FVh98X-t+YsVe+9=J7_PjB8hESsY+5=-PQ@mail.gmail.com> <alpine.LRH.2.20.1612121254150.14930@bofh.nohats.ca>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Fri, 16 Dec 2016 15:44:50 -0500
Message-ID: <CAHbuEH4MgqDpWR_yc21Z8-HNU1Pvy8Hyz0NvW9qntwtxFuZmmw@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Content-Type: multipart/alternative; boundary="94eb2c18fad030c2320543cca4e5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Y5dmsn2QjVHBKUb1wnCl7VLjA_E>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-rfc4307bis
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Dec 2016 20:45:11 -0000

Hi Paul,

Thanks for your response and sorry for my delayed response.

On Mon, Dec 12, 2016 at 1:10 PM, Paul Wouters <paul@nohats.ca> 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