IETF Logo Mail Archive

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

Paul Wouters <paul@nohats.ca> Thu, 16 March 2017 17:07 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 837071296BE; Thu, 16 Mar 2017 10:07:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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] 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 VCsOW849WFf2; Thu, 16 Mar 2017 10:07:37 -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 BC81D127011; Thu, 16 Mar 2017 10:07:37 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vkZfH2psTzD2K; Thu, 16 Mar 2017 18:07:35 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1489684055; bh=BNBpG2ubBfYzz8dhv1LhKeKTAGDA4dvhdmTEX22g1hM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Wz2sNr6pv05XFF2z/jREYVY1Kou+zsXVYqByM1ZOPUIT/cHnx1RP97prEYbpqqxDw b3PyQT1auU92lZ16GtNPmOSWnhEsCKjrj94rTWRXpGnJhD/94UPrcYELtAzWxdTgRW +FQSkK5H6Qbk9ZVAq7SCGRZCg2XavCa/kGjnNzZk=
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 X76uCQJ1u8Zt; Thu, 16 Mar 2017 18:07:34 +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; Thu, 16 Mar 2017 18:07:33 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id BAA5239D3A6; Thu, 16 Mar 2017 13:07:32 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca BAA5239D3A6
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A7D5C40ACF3C; Thu, 16 Mar 2017 13:07:32 -0400 (EDT)
Date: Thu, 16 Mar 2017 13:07:32 -0400
From: Paul Wouters <paul@nohats.ca>
To: Ben Campbell <ben@nostrum.com>
cc: The IESG <iesg@ietf.org>, draft-ietf-ipsecme-rfc7321bis@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, david.waltermire@nist.gov
In-Reply-To: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com>
Message-ID: <alpine.LRH.2.20.999.1703161300150.32675@bofh.nohats.ca>
References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com>
User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/cuYs67tbWNj49RSMvcqUaTsFUzc>
Subject: Re: [IPsec] Ben Campbell'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: Thu, 16 Mar 2017 17:07:39 -0000

On Wed, 15 Mar 2017, Ben Campbell wrote:

> - Abtstract: "This document obsoletes RFC 7321 on the cryptographic
> recommendations only."
>
> I'm not sure what that means. Does the reader of this still need to read
> 7321? If so, is "obsoletes" the correct relation?

Skimming over 7321 I cannot actually tell what we meant to not obsolete?
I think we can remove the "on the cryptographic recommendations only."

> -3: I wonder why "... is not to be used..." is not "... MUST NOT be
> used...". But the section goes on to say if you do it anyway, you MUST
> NOT use certain cryptosuites. So, does "... is not to be used..." mean
> "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU WILL"
> sort of requirements?

It is indeed. I think a SHOULD NOT would actually be appropriate ?

> - Table in section 6:
> I'm boggled by the first entry being labeled "MUST/MUST NOT". I don't see
> anything in the text to explain the "MUST" part--did I miss something?


First paragraph under the table:

    AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT.  The
    only reason NULL is acceptable is when authenticated encryption
    algorithms are selected from Section 5.  In all other cases, NULL
    MUST NOT be selected.

Paul

v2.23.0 | Report a Bug | By Email