Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)

Paul Wouters <paul@nohats.ca> Wed, 15 March 2017 11:43 UTC

Return-Path: <paul@nohats.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 29F35129BF6; Wed, 15 Mar 2017 04:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 UvJMGJ7BqiyN; Wed, 15 Mar 2017 04:43:28 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1CB6129BF5; Wed, 15 Mar 2017 04:43:27 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vjqVj1YRszD26; Wed, 15 Mar 2017 12:43:25 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1489578205; bh=EzMPtgtiT6lxzkTSOFp+rOzSwoqG2uRVggNYWIIQMQs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Lo7J2dN/8zAiiaF9hiFKTjs84HvPTJD2bsd77xm0EbSp+MzWjZFPLqFIelYgwb+LM NaTBFF1r9+bxTw+o3/0MplJREvnQYeNMTR/jLL2ogsSc5zJuqa2O54Wog9FwIAoSua d7KkPL1v3obAJLd+wuBjxHFSxlQazPQfBdMNiZbM=
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 1dKqr_bgcPD6; Wed, 15 Mar 2017 12:43:21 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 15 Mar 2017 12:43:20 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id E8E5C2DEFC7; Wed, 15 Mar 2017 07:43:18 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E8E5C2DEFC7
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D079140D80EE; Wed, 15 Mar 2017 07:43:18 -0400 (EDT)
Date: Wed, 15 Mar 2017 07:43:18 -0400
From: Paul Wouters <paul@nohats.ca>
To: Daniel Migault <daniel.migault@ericsson.com>
cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, draft-ietf-ipsecme-rfc7321bis@ietf.org, "ipsec@ietf.org" <ipsec@ietf.org>, ipsecme-chairs@ietf.org, The IESG <iesg@ietf.org>, "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>
In-Reply-To: <CADZyTk=hvaU9Z9w6m7LYaR75CW3sKBW6ryXa+s3_53FFHohSgA@mail.gmail.com>
Message-ID: <alpine.LRH.2.20.999.1703150740300.9627@bofh.nohats.ca>
References: <148954159755.24347.12366542904819082480.idtracker@ietfa.amsl.com> <CADZyTk=hvaU9Z9w6m7LYaR75CW3sKBW6ryXa+s3_53FFHohSgA@mail.gmail.com>
User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/rf1376xBp-G1qZO5FN6rmJfPCUc>
Subject: Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 15 Mar 2017 11:43:30 -0000

On Wed, 15 Mar 2017, Daniel Migault wrote:

> Regarding the first item manual key is prevented by AES-GCM RFC4306. We do not not such "MUST
> NOT" level for AES-CCM and Chacha20_poly1305. Maybe we could relax that a little bit and be more
> accurate saying:
> 
> OLD:
> " If manual keying is used anyway, ENCR_AES_CBC MUST be used,
> and ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305
> MUST NOT be used as these algorithms require IKE.  "
> 
> NEW:
> " If manual keying is used anyway, ENCR_AES_GCM MUST NOT be used and ENCR_AES_CBC SHOULD be
> used."
>  
> NEWbis:
> " If manual keying is used anyway, ENCR_AES_CBC SHOULD be used."

I don't think that we should relax it. Those ciphers MUST NOT be used
with manual keying due to cryptographic reasons. On top of that, people
SHOULD NOT use manual keying because it prevents Perfect Forward Secrecy
(PFS).

We can clarify that, but I don't think we should change the MUST NOT.

Paul

> 
> AES-GCM (RFC4306 section 2):
> """
>
>    Because reusing an nonce/key combination destroys the security
>    guarantees of AES-GCM mode, it can be difficult to use this mode
>    securely when using statically configured keys.  For safety's sake,
>    implementations MUST use an automated key management system, such as
>    the Internet Key Exchange (IKE) [RFC2409], to ensure that this
>    requirement is met.
> """ 
> 
> AES-CCM (RFC4309)
> """
>    To be safe, implementations MUST use fresh keys with
>    AES CCM.  The Internet Key Exchange (IKE) [IKE] protocol or IKEv2
>    [IKEv2] can be used to establish fresh keys.
> """
> 
> Chacha20_poly1305 (RFC7539)
> 
> """
> To generate such a key pair (r,s), we will use the ChaCha20 block
>    function described in Section 2.3.  This assumes that we have a
>    256-bit session key for the Message Authentication Code (MAC)
>    function, such as SK_ai and SK_ar in Internet Key Exchange Protocol
>    version 2 (IKEv2) ([RFC7296]), the integrity key in the Encapsulating
>    Security Payload (ESP) and Authentication Header (AH), or the
>    client_write_MAC_key and server_write_MAC_key in TLS.  Any document
>    that specifies the use of Poly1305 as a MAC algorithm for some
>    protocol must specify that 256 bits are allocated for the integrity
>    key.
> """
> 
> On Tue, Mar 14, 2017 at 9:33 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>       Stephen Farrell 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 agree with Christian's secdir review [1] that this
>       doesn't seem justified (at least on it's face): " If
>       manual keying is used anyway, ENCR_AES_CBC MUST be used,
>       and ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305
>       MUST NOT be used as these algorithms require IKE.  " Can
>       you explain the reasoning that lead the WG to say that?
>
>       - ENCR_NULL IMO ought be MUST NOT - did the WG discuss
>       that explicitly?  If so, can you provide a pointer to the
>       archive?  If not, does it still have to be a MUST?  I do
>       wonder who wants to use AH via NAT but cannot, which seems
>       to be the justification.
>
>       [1] https://www.ietf.org/mail-archive/web/secdir/current/msg07262.html
> 
>
>       _______________________________________________
>       IPsec mailing list
>       IPsec@ietf.org
>       https://www.ietf.org/mailman/listinfo/ipsec
> 
> 
> 
>