Re: [IPsec] Update to RFC4307 too?

Paul Wouters <paul@cypherpunks.ca> Fri, 11 October 2013 18:49 UTC

Return-Path: <paul@cypherpunks.ca>
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 7BB5F11E8199 for <ipsec@ietfa.amsl.com>; Fri, 11 Oct 2013 11:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level:
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4Fm2acI+MLD for <ipsec@ietfa.amsl.com>; Fri, 11 Oct 2013 11:49:01 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id B0D9111E8188 for <ipsec@ietf.org>; Fri, 11 Oct 2013 11:49:01 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cxJ9555vcz4Fd; Fri, 11 Oct 2013 14:48:57 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id is6lWH1gYNr3; Fri, 11 Oct 2013 14:48:56 -0400 (EDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Fri, 11 Oct 2013 14:48:56 -0400 (EDT)
Received: by bofh.nohats.ca (Postfix, from userid 500) id 7E408800A9; Fri, 11 Oct 2013 14:48:57 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7135D80096; Fri, 11 Oct 2013 14:48:57 -0400 (EDT)
Date: Fri, 11 Oct 2013 14:48:57 -0400
From: Paul Wouters <paul@cypherpunks.ca>
X-X-Sender: paul@bofh.nohats.ca
To: Tero Kivinen <kivinen@iki.fi>
In-Reply-To: <21077.33006.734392.994194@fireball.kivinen.iki.fi>
Message-ID: <alpine.LFD.2.10.1310111443530.13161@bofh.nohats.ca>
References: <21077.33006.734392.994194@fireball.kivinen.iki.fi>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>
Subject: Re: [IPsec] Update to RFC4307 too?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 11 Oct 2013 18:49:22 -0000

On Wed, 9 Oct 2013, Tero Kivinen wrote:

> I think the changes we would like to do there are:
>
> Downgrade Diffie-Hellman group 2 (1024-bits) from MUST- to SHOULD.

Actually, 4307 states:

3.1.2.  Diffie-Hellman Groups

    There are several Modular Exponential (MODP) groups that are defined
    for use in IKEv2.  They are defined in both the [IKEv2] base document
    and in the MODP extensions document.  They are identified by group
    number.  Any groups not listed here are considered as "MAY be
    implemented".

       Group Number        Bit Length            Status     Defined
       2                   1024 MODP Group       MUST-      [RFC2409]
       14                  2048 MODP Group       SHOULD+    [RFC3526]

which seems to imply 768 MODP group is "MAY". Which is confirmed in RFC
4109. So I think we should also update 768 MODP group to MUST NOT.

> Downgrade ENCR_3DES from MUST- to MAY

I'm not sure how I feel about that. There are still not many
alternatives to AES, and I think having 3DES in there is good. Yes it is
slow, but I don't think it has been concluded to be weak or insecure.

> Then we might want to think whether we want to add new algorithms,
> i.e. "AES_GCM with a 8/12/16 octect ICV", PRF_HMAC_SHA2_256/384/512,
> or AUTH_HMAC_SHA2_256_128/384_192/512_256. In all of those I think we
> might want to pick one length and make that SHOULD...

Sounds good.

Paul