Re: [IPsec] On marking algorithms obsolete in IANA registries
Paul Wouters <paul@nohats.ca> Tue, 18 December 2018 15:19 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 13D3E130E6E for <ipsec@ietfa.amsl.com>; Tue, 18 Dec 2018 07:19:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 yid4Hwl9fEGy for <ipsec@ietfa.amsl.com>; Tue, 18 Dec 2018 07:19:56 -0800 (PST)
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 0D23312896A for <ipsec@ietf.org>; Tue, 18 Dec 2018 07:19:54 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43K1sW57Dmz6j for <ipsec@ietf.org>; Tue, 18 Dec 2018 16:19:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1545146383; bh=Ddmdikj4iG2vc/A6YlrcjONYAO9bMha4o30sny1NLuE=; h=Date:From:To:Subject:In-Reply-To:References; b=I+qC+jpzMG0aPgi/gwFrOJIBkaxX3fx4OeDFYJUa9vgJwZoP19djRUo3DgGlsOxM5 MUWJ1Y8X+rp51QZWp/ZtRweqj4ki+ES3BhPpwcrzlGd/NLscsPjPRRGy1oCpxM5uSq jSEg7Qlfh01cSQ9IXKSMZFL334UaAMd4R/2uEkVI=
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 L3RlOZhQ8x03 for <ipsec@ietf.org>; Tue, 18 Dec 2018 16:19:22 +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 for <ipsec@ietf.org>; Tue, 18 Dec 2018 16:19:20 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id B3F1A4A2511; Tue, 18 Dec 2018 10:19:19 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B3F1A4A2511
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id ACB05418A294 for <ipsec@ietf.org>; Tue, 18 Dec 2018 10:19:19 -0500 (EST)
Date: Tue, 18 Dec 2018 10:19:19 -0500
From: Paul Wouters <paul@nohats.ca>
To: "ipsec@ietf.org WG" <ipsec@ietf.org>
In-Reply-To: <EEEF2F73-0DB3-48C6-A638-E7C444B6BC32@dell.com>
Message-ID: <alpine.LRH.2.21.1812181016540.27761@bofh.nohats.ca>
References: <alpine.LRH.2.21.1812172308290.2530@bofh.nohats.ca> <0BD40F44-9677-44CB-9C9B-A755671B5C70@gmail.com> <alpine.LRH.2.21.1812172335480.2530@bofh.nohats.ca> <005801d4969c$63215360$2963fa20$@gmail.com> <EEEF2F73-0DB3-48C6-A638-E7C444B6BC32@dell.com>
User-Agent: Alpine 2.21 (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/2IPNnqslr6jhmi7xHPYXkMh8KoA>
Subject: Re: [IPsec] On marking algorithms obsolete in IANA registries
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
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, 18 Dec 2018 15:19:59 -0000
On Tue, 18 Dec 2018, Paul.Koning@dell.com wrote: >> Well, I think it's a bit too complex for random implementer. >> I'd prefer to classify all algorithms as follows: >> >> 1. Secure, required for interoperability >> 2. Secure, not required for interoperability >> 3. Insecure (obsoleted) > Possibly some algorithms are candidates for "obsolete" status not because they are known to be insecure but because they never got traction or security analysis. I'm not sure if CAST is an example. > > On terminology: "secure" is too strong a statement for the non-expert audience. "Believed to be secure" would be more prudent, but I don't really like those words either. Can we come up with some words that don't suggest a guarantee we can't make? When I described the various SHOULD, MAY, MUST and their variants, I was not suggesting of putting that into the IANA registry. The IANA registry should only get "deprecated" or "obsolete". In my view (and I think the RFCs view) deprecrated means "issues found, stop using it" and "obsolete" means "meh, not harmful but no one else is using it anymore". Paul
- [IPsec] On marking algorithms obsolete in IANA re… Paul Wouters
- Re: [IPsec] On marking algorithms obsolete in IAN… Yoav Nir
- Re: [IPsec] On marking algorithms obsolete in IAN… Paul Wouters
- Re: [IPsec] On marking algorithms obsolete in IAN… Valery Smyslov
- Re: [IPsec] On marking algorithms obsolete in IAN… Paul.Koning
- Re: [IPsec] On marking algorithms obsolete in IAN… Valery Smyslov
- Re: [IPsec] On marking algorithms obsolete in IAN… Paul Wouters
- Re: [IPsec] On marking algorithms obsolete in IAN… Paul Wouters
- Re: [IPsec] On marking algorithms obsolete in IAN… Michael Richardson
- Re: [IPsec] On marking algorithms obsolete in IAN… Yoav Nir
- Re: [IPsec] On marking algorithms obsolete in IAN… Paul Wouters
- [IPsec] On marking algorithms obsolete in IANA re… Tero Kivinen
- Re: [IPsec] On marking algorithms obsolete in IAN… Paul Wouters