Re: [IPsec] Robert Wilton's No Objection on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 12 December 2022 14:12 UTC

Return-Path: <mcr+ietf@sandelman.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 24C0BC14F736; Mon, 12 Dec 2022 06:12:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.396
X-Spam-Level:
X-Spam-Status: No, score=-4.396 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
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 q9nStJTV6Ekv; Mon, 12 Dec 2022 06:12:39 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (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 D58D2C14F6E7; Mon, 12 Dec 2022 06:12:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4ABDF38990; Mon, 12 Dec 2022 09:39:23 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jzvbv8qbc_wv; Mon, 12 Dec 2022 09:39:22 -0500 (EST)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id A80003898B; Mon, 12 Dec 2022 09:39:22 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1670855962; bh=Rtl5VEevxqGMJrroAXmZR65D7vbnHf4EUMdFWFpyEa8=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=HSIFiVfI5RNBe2yqEiQegh/M0QGnw1ZPZSMshjOEcEcn79NmN8dqt3tSEHVfYER7B 4F71wqSpJiKPr9dWrBO3HasUav4i1f58WFIl/fXyUc8RdqE5pzKVHc6wMK17F4ftSo AFCRi7sGLGxeyJF2FRh+ZHPwFHyUfC9RL3gTlJ6+BPICVzM2DRrdJIQFzh81KTkmnu y0ozovsj5iNDzNX4Vi830zh4V3bIH3Li5hPxS+FiwGmMjXkf0mpJtSexpaGeBb/r1u kz2A2NqNgTKD9mCZKa4ifZtNhhDeotw8WTd4RNLN8qRNnUqTLMpFcGSw+nFS5NKb7Z EJ/EMrK79zJcg==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DA0DB2E5; Mon, 12 Dec 2022 09:12:31 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Robert Wilton <rwilton@cisco.com>
cc: The IESG <iesg@ietf.org>, draft-ietf-ipsecme-ikev1-algo-to-historic@ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org, kivinen@iki.fi
In-Reply-To: <167084069079.46817.6055063604904352116@ietfa.amsl.com>
References: <167084069079.46817.6055063604904352116@ietfa.amsl.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 12 Dec 2022 09:12:31 -0500
Message-ID: <3297.1670854351@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/eMq2Edpd5WD6kWvm9qaIWv4QD0c>
Subject: Re: [IPsec] Robert Wilton's No Objection on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with COMMENT)
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: Mon, 12 Dec 2022 14:12:43 -0000

Robert Wilton via Datatracker <noreply@ietf.org> wrote:
    > I do wonder exactly how well understood "deprecated" is in the wider community.

In the end, nobody really knows.
The customers that read RFCs already knew IKEv1 was dead and replaced.
The end customers that don't know, are still using their 2003 era equipment
(maybe with 3DES).   Often they have newer equipment (or firmware), but they
lack the expertise to have enough confidence to adjust their configuration to
do IKEv2.

This document means that some more security auditors will now flag them for
non-compliance, and that might free up resources to upgrade.

    > (i) the definition of deprecated in YANG (RFC 7950) is:
    > o  "deprecated" indicates an obsolete definition, but it permits
    > new/continued implementation in order to foster interoperability
    > with older/existing implementations.

IKEv1 had this definition as soon as IKEv2 was published.
Will this document move us beyond this definition yet?  No.  Devices will
still ship with IKEv1 available (but maybe not default) because they still
need to interop.   But, at least we will get some more pressure to remove
support from vendors.  They can point at this document in their EOL announcements.

    > (ii) the definition in Java is:
    > A program element annotated @Deprecated is one that programmers are
    > discouraged from using, typically because it is dangerous, or because a
    > better alternative exists. Compilers warn when a deprecated program element
    > is used or overridden in non-deprecated code.

    > I think that the definition that security uses is presumably much closer to
    > (ii), or not even stronger in sentiment to move away from it?

Yes, (ii) is way more about what we mean, but not having available protocol
police,  I don't think it really matters that much.

    > I tried to search and find a definition in IANA of exactly what deprecated
    > means, but with no luck.

    > Perhaps there is already a security definition of deprecated that could be
    > referenced, or if not, it might be helpful to:
    > - in Section 5, unambiguously specify what is meant by deprecated.
    > - in Section 7, bind the definition of the Status column back to Section 5.

I'm not sure that a more precise definition will really help.
Section 3 is also pretty clear: upgrade to IKEv2.


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide