[IPsec] My shepherd review of draft-ietf-ipsecme-ikev1-algo-to-historic

Tero Kivinen <kivinen@iki.fi> Tue, 07 June 2022 13:38 UTC

Return-Path: <kivinen@iki.fi>
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 53F90C157B49; Tue, 7 Jun 2022 06:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayVLcJwq26Ig; Tue, 7 Jun 2022 06:38:46 -0700 (PDT)
Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29C1C157903; Tue, 7 Jun 2022 06:38:41 -0700 (PDT)
Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id DA5741B00266; Tue, 7 Jun 2022 16:38:38 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1654609118; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=/5cNDqVoiCXdONc5CbRZITfkysY4fN+JWmjtFhGMbMo=; b=Zrn/FR1U7vQdYGUiGjjilVqMzCusNeNZocbbrVWchomsj3gxpjH+J1f0sT8zD941mZOrnK ciPD3odgp5pltHI/xKn0KzL5b1ICiIdFOB1+YCDla/f5jjITW44Y6ADED76b0dsASyw0jQ BrtDdi5mF+SEmSqaUubF0sdviu8VYaNOtCunVt6EiPojGiSG1xxDOYlhQuF9PiTAlrjkER ttVvhHbK/jkxuIeb9bfuVQBIgde6auqSvJgdwxQWS8yHldJDZz/vPFzJpW+RrcsUXIISD0 h/kE0xoM68IpYn/X4HqWycyGB/cZkIKUqq1cIIqOqs5TZc52Y9/wg30HTqIkXg==
Received: by fireball.acr.fi (Postfix, from userid 15204) id 76DE925C12ED; Tue, 7 Jun 2022 16:38:38 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <25247.21726.403824.139055@fireball.acr.fi>
Date: Tue, 07 Jun 2022 16:38:38 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: draft-ietf-ipsecme-ikev1-algo-to-historic@ietf.org
CC: ipsec@ietf.org
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 20 min
X-Total-Time: 20 min
ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1654609118; a=rsa-sha256; cv=none; b=nzvyaVR3YEwnSz7SJxz5Yv9Sj7ALEkSgNKc/cLKKKT91oVuMMd9MuzefGRpwYTuRnokHZr tyBP4RDKyv9L4XQh61ECbwkEvVRlIdKBofpu5Q2TL2Kv1kb7X3UtnjtH8s4Fk9xpfArVVd 80IdqjMzHTibE0uMLZxV+kWO9EtNpvbAWhjrKlgPvRsjNJ2M/z3Trn0COi96a+Rr6VbBlO gvoKIBKTWxJkrhjPTdGylppbfE4TNhz+uJpjCFRM0dA5zMAjz9BsYQP6bvNdhDowU7gLgo +FGcnpDNpdm7ngbEAYFLLAB++GuGvCDZ3OeLQhqR8i0R8Oxeuwim0IEzFjCX6Q==
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1654609118; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=/5cNDqVoiCXdONc5CbRZITfkysY4fN+JWmjtFhGMbMo=; b=Fwrv69Fz99BWSLFxsGqrWf/rGY0t/YbUMKiXDA7pbhkbIKewy+zoJgwtDN5DXR/rrjCOph MeLpnO1XWn+/7/FRhku987IG+kzDeZWlbXJo8YrsdIUPDebQdJFcf4IG0GVhJKHocV7omm zU1iEvGLjfB8J7pWotFGWpaRzrEpW99TAa+NGVgxKnhyJvN8Rl87ZpEOxX0WLr7WM1lzJO dYaExDYe7J3VZe2Z1iPam6DtrxkoEcEaE3LpAxKiqOthUsnf7FtQQSWZ7enlcOEjEuUcdg TzQvnVtOP2slTZgl6KaDDNM0cJIR3vLfBwoKJwJSMVSh86DIPer8ybHoNqan8A==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/eua5PlKQtlWA6Ni7PJRHukPbmsg>
Subject: [IPsec] My shepherd review of draft-ietf-ipsecme-ikev1-algo-to-historic
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 07 Jun 2022 13:38:50 -0000

In the introduction there is text:

   Algorithm implementation requirements and usage guidelines for IKEv2
   [RFC8247] and ESP/AH [RFC8223] gives guidance to implementors but
   limits that guidance to avoid broken or weak algorithms.


but the RFC8223 is completely unrelated to the matter in hand:

   [RFC8223]  Esale, S., Torvi, R., Jalil, L., Chunduri, U., and K.
              Raza, "Application-Aware Targeted LDP", RFC 8223,
              DOI 10.17487/RFC8223, August 2017,
              <https://www.rfc-editor.org/info/rfc8223>.

I assume it should be RFC8221 (i.e. replace the text in section 1 and
the reference).

--

This document says it updates 7296, 8221, and 8247. I am not
completely sure what it is supposed to update in RFC 7296? I can
somewhat understand that it supposedly updates 8221 and 8247 as it
changes the status of some cryptographic algorithms from MAY to
DEPRECATED, but I do not think there is anything in RFC7296 that is
really updated (not RFC8221, or 8247 do not update 7296).

I.e., what changes do RFC 7296 implementations need to do based on
this document (knowing that RFC7296 didn't specify the mandatory to
implement algorithms in it)?

Adding new status column to IANA is not updating the protocol.

So I would remove the 7296 from the Updates list.

--

In the section 1 there is text saying:

	IKEv1 has been moved to Historic status.

I think it is supposed to say "This document moves IKEv1 to Historic
status".

--

What about other related RFCs, like RFC2407 The Internet IP Security
Domain of Interpretation for ISAKMP, and RFC2408 Internet Security
Association and Key Management Protocol (ISAKMP)?

Both of them are also obsoleted by the IKEv2, and are standard track
documents. I think we should move all of them to HISTORIC, i.e. change
section 3 to say "RFC 2407, RFC 2408, and RFC 2409 to Historic".

You do list all of them in the section 1:

   IKEv1 [RFC2409] and its related documents for ISAKMP [RFC2408] and
   IPsec DOI [RFC2407] were obsoleted by IKEv2 [RFC4306] in December
   2005.

--

I think the Normative and Informal References split is not correct.

For example I do not think any of the RFC2407-2409, or RFC4306 are
normative.

I think the normative references section should just list RFC2119,
RFC8174, RFC8221 (replace 8223 wih this), and RFC8247.

The IKEv1, and IKEv2 releated RFCs are not needed to be normative
references, as you do not need to read and understand to know they are
deprecated :-)

I.e., move RFC2407, 2408, 2409, 4306, 6407, 7296, 8784 to informative
references section. RFC7296 might also be in normative if it is kept
in the updates list...
-- 
kivinen@iki.fi