Re: [IPsec] [Technical Errata Reported] RFC7634 (5441)

"Valery Smyslov" <smyslov.ietf@gmail.com> Fri, 27 July 2018 14:59 UTC

Return-Path: <smyslov.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 623CB130EF9 for <ipsec@ietfa.amsl.com>; Fri, 27 Jul 2018 07:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no 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 0rSyTxN7dQkb for <ipsec@ietfa.amsl.com>; Fri, 27 Jul 2018 07:59:31 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 67EE9130E25 for <ipsec@ietf.org>; Fri, 27 Jul 2018 07:59:31 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id a134-v6so3725884lfe.6 for <ipsec@ietf.org>; Fri, 27 Jul 2018 07:59:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=pxYJuAtXcb1dFNl5CSyTMa2uIqm1/foEJEemLV80ltI=; b=TNodAUd/euzsFsYKhDlG3uE5+WO0dBNQggxWkgnMtDznkGcBGDdq5Ivst+oAlf7u+J g+/g9QGL51F03ZzwntlPL2YViKkvlWaCyRaxad3WcQg0WXBUf+qtA5AwV0PaDVqdxSrv Rq5X4mQGBKPZ0qKkA5p7vzRLIaRw59YRIRiakOWCOf7K0qJFzYaq0hfYdDY3pN7B1/lt 6AZpALR/72VDHHIab6UCPKh8pGFVWYvA9xGK/pFcuUDeMSJ+rSflNHZwy7e1DCT1Ml1a bIMod7XeDa9lYTmXux5/oLTJPcMD6DMiUDSZX6VXVTO/SbckxCwFn8YvwbTdqfbIEE13 BK2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=pxYJuAtXcb1dFNl5CSyTMa2uIqm1/foEJEemLV80ltI=; b=PE2soMyQZTVlIEmWYyuna0dshRkSWOZhANai0SfwLXfNqJlVbOXMdgzZbgNH0JxYm3 f7wNVgkelCk/9tfhx7oF9qs2xl3NpCTGUwR5ToB0fUCcqEG+PoCbcS+tmnmEjhFGJUzj RL8y17uab7i3MMqb0yjkAwSvs+xSTacgIpN6KPfkZsacWsWkHF75Druvmqk6eXr1Mp4l dR4Ye2RSeM2pqbU08U/9nNliVOHCOWG2zbSLD2jjCT2Cz2DVhLek4wRIW62+rv5vl+Nb N/GyxAOc/LgPH2Sr7+1h9HOg5PLnVzRnk029+djMOWBI50Hwekc2cGNnXVsOr95eMq4a B1ig==
X-Gm-Message-State: AOUpUlHNp0vVJmDPaVVj/sjd4dwfs/QxE+lWND64YR8ohWFxjumunIEC gER0tXQFintAuvNMr8ldMsA=
X-Google-Smtp-Source: AAOMgpfnWY3FFcsvWf4dM/v3fPqHk94EA4+hrr4n3ua723py539njXZkiQocg1j/C3kSdJAvZEhVxg==
X-Received: by 2002:a19:1863:: with SMTP id o96-v6mr4511926lfi.134.1532703569660; Fri, 27 Jul 2018 07:59:29 -0700 (PDT)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id k10-v6sm714936ljh.5.2018.07.27.07.59.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 27 Jul 2018 07:59:28 -0700 (PDT)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Benjamin Kaduk' <kaduk@mit.edu>, 'Yoav Nir' <ynir.ietf@gmail.com>
Cc: ekr@rtfm.com, andrew.cagney@gmail.com, kivinen@iki.fi, ipsec@ietf.org, david.waltermire@nist.gov, 'RFC Errata System' <rfc-editor@rfc-editor.org>
References: <20180726182923.D548CB8125E@rfc-editor.org> <20FE97E3-768B-426D-9DF1-A228E8DEB143@gmail.com> <20180727141658.GC12983@mit.edu>
In-Reply-To: <20180727141658.GC12983@mit.edu>
Date: Fri, 27 Jul 2018 17:59:22 +0300
Message-ID: <01e201d425ba$677b0fd0$36712f70$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGYblzrU7jz7pTlhpgmWna88nmmAQHZoxp7AjcKXvik+g+EsA==
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/HXVrn_kOInUh1wWfzSV9i7Ta5aM>
Subject: Re: [IPsec] [Technical Errata Reported] RFC7634 (5441)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.27
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, 27 Jul 2018 14:59:34 -0000

Hi,

while this clarification wouldn't hurt if it were present in the RFC 7634,
I think that generally speaking it is redundant. RFC 7634 doesn't exist
in vacuum, it is expected that its readers are familiar with RFC 7296,
which has a clear rule that algorithms with fixed key size MUST NOT
include Key Length attribute. I see no reason to repeat this rule in every RFC
specifying new algorithm. It definitely wouldn't hurt if it were repeated,
but if it isn't then that is that. Go and read RFC 7296.

Regards,
Valery.


> > This errata proposes to add the following sentence to section 4 of RFC 7634
> <https://tools.ietf.org/html/rfc7634#section-4>:
> >
> > As with other transforms that use a fixed-length key, the Key Length attribute MUST NOT be specified.
> >
> > This sentence is correct. If this came up as a suggestion during WG processing or during LC, I think we would
> add it.
> >
> > Looking back in RFC 7296, we have in section 3.3.5 <https://tools.ietf.org/html/rfc7296#section-3.3.5>:
> >
> >    o  The Key Length attribute MUST NOT be used with transforms that use
> >       a fixed-length key.  For example, this includes ENCR_DES,
> >       ENCR_IDEA, and all the Type 2 (Pseudorandom Function) and Type 3
> >       (Integrity Algorithm) transforms specified in this document.  It
> >       is recommended that future Type 2 or 3 transforms do not use this
> >       attribute.
> >
> > And RFC 7634 says:
> >
> >    o  The encryption key is 256 bits.
> >
> > Given that, I don’t think there is any chance for a conscientious implementer to make the mistake of
> including the Key Length attribute.
> >
> > I don’t believe adding clarifying text is a proper use of the errata system. At best it should be marked as
> editorial and held for document update, if not rejected outright.
> 
> I generally agree with this sentiment.  I would probably be willing to mark
> as editorial/hold for document update in this case, though.  How would that
> work for people?
> 
> -Ben