Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with DISCUSS)

Warren Kumari <warren@kumari.net> Tue, 13 December 2022 17:52 UTC

Return-Path: <warren@kumari.net>
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 03896C14F730 for <ipsec@ietfa.amsl.com>; Tue, 13 Dec 2022 09:52:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net
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 lWAIwGNwWE-N for <ipsec@ietfa.amsl.com>; Tue, 13 Dec 2022 09:52:00 -0800 (PST)
Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 C52F9C1524A5 for <ipsec@ietf.org>; Tue, 13 Dec 2022 09:51:59 -0800 (PST)
Received: by mail-qv1-xf34.google.com with SMTP id s14so10895601qvo.11 for <ipsec@ietf.org>; Tue, 13 Dec 2022 09:51:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=cc:to:subject:message-id:date:references:in-reply-to:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JjM5dKwVr1w/DjCtbhlG0criXAv88h4EgZdCfab4ylQ=; b=glSm3hoL7+OjBgSWBxteOgmSps8b1aWT1Bn34kFA+f8qVYKehgy1cx6Es3b7M4nOv7 b2qxvvz4es7/nDhHt65h06GVxoERk0BEkYapsv4jtIERd21Wk3JwbB2OpXZICmXuKwgv wpbyUx5v7onzUm4brYD27kqP1c0K/MWbqUf+v5ZVMTxOknirF37LpenbBSCHctAhNFe9 pTW6WCLBr/GOZxX2yKLnpcf1ll1ZEsPSoN0MvEjJs0Tdycf+cu0PeD58hvVwCG+yubl/ KgCWLRpMgtJ0iD5CH+qN9bjGpSoEOilV+nfD7FOMPjC45ufIqCEzj/JnxvvLQKkFoKF2 xPuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:references:in-reply-to:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JjM5dKwVr1w/DjCtbhlG0criXAv88h4EgZdCfab4ylQ=; b=UZ/QyADK3475K2ncc+CIUzE6FOxL0DHp6RUw42WzEcc4MHh7P2xQ1hXZKbkZ9EHWXq MI2BhTPHx7dxsbKC7yAS5RKIT4M4g26RflmVAwatmesmuYzVH9HbbrmR09kV5KsXS9rO gei+nF7gWwkqoYPrLRwXZJRbIUceNbV6b7rksg5sze6UoN1yDLeEDO59e+GlpFszQfq8 4B5voEkT2m251SPU0dEsAR/FUA6ahOvgVHsXVI5oztA3Ihu+yp8ZNmmOFU//GHofDox7 NUlU4etBIq9cHYQZIqVJ12hmrs0QP+x9PMuhHZxgOtc3KvObVYXNAbA9MN8CWF3zRpJH 3Bpw==
X-Gm-Message-State: ANoB5pleYj+Ogu6HcEGAFtxNaBIXs24p9HMk7tZY317+q9UqkM+gwD4v 1MkihuXk7QX3r5FeZkHpd1YLMfalo54kw9NO8oqLOg==
X-Google-Smtp-Source: AA0mqf75Gq+4+JLQjXX5l3fuhkhmgARslr/HjzD4/1rvJ2SD6+ieQBYnf0oqY9s3rHdSl6Ucpf86kDmvKJwEjFNDk5M=
X-Received: by 2002:ad4:4e4a:0:b0:4e8:6c15:4445 with SMTP id eb10-20020ad44e4a000000b004e86c154445mr211409qvb.103.1670953917995; Tue, 13 Dec 2022 09:51:57 -0800 (PST)
Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Tue, 13 Dec 2022 12:51:57 -0500
Mime-Version: 1.0
From: Warren Kumari <warren@kumari.net>
X-Mailer: Superhuman Desktop (2022-12-12T23:05:54Z)
X-Superhuman-ID: lbmit2je.133131e5-0e2a-4af9-84d3-fd898f60dd62
X-Superhuman-Draft-ID: draft00afad01db3b0c0b
In-Reply-To: <ca431827-6090-dba7-6280-20bed8ebf37d@nohats.ca>
References: <167094324735.45634.6215476133161483286@ietfa.amsl.com> <ca431827-6090-dba7-6280-20bed8ebf37d@nohats.ca>
Date: Tue, 13 Dec 2022 12:51:57 -0500
Message-ID: <CAHw9_i+5aaasAdWU-pu-geGX6StrR6vzHTHmzcVGCo8FYruaxQ@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
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
Content-Type: multipart/alternative; boundary="000000000000b7fd4105efb946be"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/3j2ozhEg91Mw_l6f4lpi2m2yK08>
Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with DISCUSS)
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, 13 Dec 2022 17:52:04 -0000

On Tue, Dec 13, 2022 at 10:36 AM, Paul Wouters <paul@nohats.ca> wrote:

> On Tue, 13 Dec 2022, Warren Kumari via Datatracker wrote:
>
> [speaking with author hat on]
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>
>
> Be ye not afraid -- see
> https://www.ietf.org/about/groups/iesg/statements/
> handling-ballot-positions/ on handling ballots, especially DISCUSS
> ballots...
>
>
>
> Can the IETF actually deprecate / make a protocol historic? (as stated in
> "Internet Key Exchange version 1 (IKEv1) has been deprecated" and "IKEv1
> has been moved to Historic status.")
>
>
> I agree that **making the documents that describe these** be historic is
> the right thing to do, and also that the IETF can strongly recommend that
> people don't use/deploy/whatever IKEv1, but I don't really know if we (or
> anyone) have the power to deprecate a protocol. We are not the protocol
> police, and we cannot instruct people to e.g deploy protocol foo, so I
> don't know if we can deprecate a protocol either -- but I suspect that this
> might be because I don't actually know what "IKEv1 has been deprecated"
> actually *means*.
>
> Again, I'm not trying to block what this document is attempting to *do*,
> but rather make it clear what it is actually doing.
>
> What it means is that the IETF has stopped maintaining it. It will not
> allow any new registrations into the related IANA registries and no new
> work will be started on this protocol version.
>


Perhaps you could add something to the document saying that (or, even
better, drop in a reference to an RFC that says that)? From Rob's ballot:
"I do wonder exactly how well understood "deprecated" is in the wider
community." - it's not just "in the wider community", because it wasn't
clear to me *exactly* what it meant.


> It does not make any recommendations to users or administrators on whether
> they should stop running it and migrate, although it is a pretty strong
> hint that this protocol is dying and it would be wise to move away from it.
>
> It also means that other documents that want to depend on IKE, have to
> ensure it works (and references) IKEv2, not IKEv1.
>
> The IETF does not tell you which protocols to use or not use. However,
> other organizations that do, often base their requirements on IETF
> recommendations. This is where the IETF and others (eg NIST, PCI-DSS) play
> a careful balancing act. The IETF tries to nudge people in the right
> direction. But it is indeed not the protocol police.
>

Yes, we have the BCP series, which "endorses" technical information and
"define and ratify the community's best current thinking on a statement of
principle or on what is believed to be the best way to perform some
operations." That isn't the IETF telling someone what to do, but it is
basically standing up, pointing, and saying "This thing over here! We think
that this is a good thing to do!".

Note that the document itself does not deprecate anything.
>

Well, now I'm confused:
"This document deprecates those unmentioned algorithms that are no longer
advised but for which there are no known attacks resulting in their earlier
deprecation."
and
"5.  Deprecating obsolete algorithms

This document deprecates the following algorithms: [...]"

It cannot. Only the IESG can change a document static to historic.
>


I'm unclear if you are arguing that a document doesn't do anything until
the IESG formally approves it", which feels like a very semantic point. We
very commonly say that draft-ietf-foo-bar does X (e.g change registry
policy), even if technically we mean "draft-ietf-foo-bar does X, but only
after it has completed IETF LC and then IESG Eval and had all of the
DISCUSSES addressed and then approved"

Perhaps when you said "the document itself does not deprecate anything" you
were meaning "does not make other documents historic, that is handled by
the status-change document -
https://datatracker.ietf.org/doc/status-change-ikev1-to-historic/  " ?

See your other work item on the telechat where this is requested.
>

Yes. That is partly what drove me to this discussion — in that case, the
document had originally said: "The document marks as historic…" and Pete
Resnick (correctly) pointed out that document don't mark things as
historic, and suggested the new text "The document deprecates the use of
[..]"

W

>
> Only after that request passes the IESG, can this document move further
> and say that
> "it has happened".
>
>
> Paul
>