IETF Logo Mail Archive

Re: [saag] SSH & Ntruprime

Jan-Frederik Rieckers <rieckers@dfn.de> Mon, 25 March 2024 15:16 UTC

Return-Path: <rieckers@dfn.de>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D2BC14CEFF for <saag@ietfa.amsl.com>; Mon, 25 Mar 2024 08:16:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (1024-bit key) header.d=dfn.de
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 0_1jU0rNk9kA for <saag@ietfa.amsl.com>; Mon, 25 Mar 2024 08:16:25 -0700 (PDT)
Received: from b1004.mx.srv.dfn.de (b1004.mx.srv.dfn.de [194.95.235.6]) (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 ADBFCC14F6B6 for <saag@ietf.org>; Mon, 25 Mar 2024 08:16:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dfn.de; h= content-type:content-type:in-reply-to:subject:subject :organization:from:from:references:content-language:user-agent :mime-version:date:date:message-id:received; s=s1; t=1711379780; x=1713194181; bh=fT0KW6K+F2CFRuxTlyyRGmk0mQK6XnhHatiGHllaQlI=; b= iLcNMkiwxjZdsGrbNEcZu63ObAUs6zmUkgUgDh/cPSovgFR8PzwbkMK8hJfSLi2l S//5qCAqTivFLfx1erGjmAegZDYjbw5dHOdbPjoFsp4DWFQcf2X3W+pa3JLogV7M oBSWJFBCpsN9fB9+hVqpdj6v01uvBaoDRWK/YfpmAOA=
Received: from mail.dfn.de (mail.dfn.de [IPv6:2001:638:d:c102::150]) by b1004.mx.srv.dfn.de (Postfix) with ESMTPS id D37AD2200F0 for <saag@ietf.org>; Mon, 25 Mar 2024 16:16:20 +0100 (CET)
Received: from [IPV6:2001:638:d:1010::1000] (unknown [IPv6:2001:638:d:1010::1000]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mspool2.in.dfn.de (Postfix) with ESMTPSA id 3C1173D6 for <saag@ietf.org>; Mon, 25 Mar 2024 16:16:19 +0100 (CET)
Message-ID: <b587e754-5213-46b1-aa7b-c590316946b5@dfn.de>
Date: Mon, 25 Mar 2024 16:16:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: saag@ietf.org
References: <CABcZeBPWjXvLh06-DBO3Z0sfeb2hgzqzaSZ-J2-TZ7qesrSraA@mail.gmail.com> <D0CD341B-523B-48A0-8954-EE7F89113241@aiven.io> <AF7B6F32-9EE6-4810-A99A-833DEA917FA9@sonic.net> <CABcZeBPfXQckpZageogUxTYgX2j_Nr_O3bvf-a-x0S_82BHMxg@mail.gmail.com> <079A0AA3-FA02-440F-ABA0-6AF897570E86@sonic.net> <CABcZeBOxfYR+=61DV1XN0F9nrmbzLR2zq_ZvADw4UUy1uFafzw@mail.gmail.com> <8caa2d4d-bc80-4fcf-b8bc-839052371730@lear.ch> <CABcZeBMABJ89T0qY0-9C3xxd=mFfGyCh7_9GKbEUBm6JtR+_ng@mail.gmail.com> <6c491f5c-92da-4fb3-a8b1-da1de27b36a6@lear.ch> <CABcZeBN1w0QU6ug3LcMwC+hTMA_-iOs32FkZe+gpPuFrp1y+JA@mail.gmail.com> <64e81f68-5169-4469-b5a0-2851da912091@lear.ch> <CABcZeBOLKMJb5pw59J072FsfeMFcoz1eZYxa1qpXDLW0nAU0cg@mail.gmail.com> <7b4d38b8-b4c1-412b-8287-bd44d0c512a3@lear.ch> <CABcZeBOQYp49i_JjE7vdg6AjxwyvktW7LFTJ4Mh3jt0bmxxxDQ@mail.gmail.com>
From: Jan-Frederik Rieckers <rieckers@dfn.de>
Autocrypt: addr=rieckers@dfn.de; keydata= xjMEYS90/RYJKwYBBAHaRw8BAQdAWXYFYTJZD1YR1SztUNqHenPGnf+gdQe/9LjiHlr2XATN J0phbi1GcmVkZXJpayBSaWVja2VycyA8cmllY2tlcnNAZGZuLmRlPsKWBBMWCAA+AhsDBQsJ CAcCBhUKCQgLAgQWAgMBAh4BAheAFiEE/fv7DCp4WBOrb8RyDYuiXSS+ypYFAmVbGkYFCQWP mkkACgkQDYuiXSS+ypYT0AD/TZAi4LsaVAAzkFSuejWnhQKRyJiPKcZUo7RHhGe1DAABAOBV K+OUb4o43IP2fVcVxKL9kyxArIAhehHp4cplQl8PzjgEYS90/RIKKwYBBAGXVQEFAQEHQBxo 6esD49rxn4d3su5fJJL79XjfKNy26LiFE9Gpg38+AwEIB8J+BBgWCAAmAhsMFiEE/fv7DCp4 WBOrb8RyDYuiXSS+ypYFAmVbGlAFCQWPmlMACgkQDYuiXSS+ypadsAEAqZTaohfkaVGeSk5x iiOcy47K43+ze2dUm5qja0eUUuQA/RNoF//lH8NeFNxN0Qs/Ej7MOdbr9B//R7To8AtqgiMJ
X-Enigmail-Draft-Status: N11222
Organization: DFN e.V.
In-Reply-To: <CABcZeBOQYp49i_JjE7vdg6AjxwyvktW7LFTJ4Mh3jt0bmxxxDQ@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms080205040801040002020607"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/MvbyFS9ZigrNj4Unuwe2yGC4mMA>
Subject: Re: [saag] SSH & Ntruprime
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2024 15:16:29 -0000

Hi all,

I think one question is whether we want to encourage using the 
datatracker as (sorry for the harsh language) "dumping ground" for 
specifications that just want to have a code point, but do not intend 
making this an RFC.

A typical I-D also has the legal boilerplate in it, and maybe people 
don't want that.

So it would be fine to have this available on an external server, as 
long as there is at least some confidence, that this won't change at random.

If we are really this concerned about the stability of the documents 
that are the basis of a code point registration for a "Specification 
Required" registry, maybe we should have a mirroring service within the 
IETF tools and require that every specification has to (also) be 
published there.

But using the datatracker "just because it's already there" is not 
really a good way IMHO, people not familiar with IETF procedures may 
confuse the fact that this is an (expired/inactive) I-D with the 
equivalent of "People tried to bring this to the IETF, but the IETF 
wasn't interested in this."

Cheers
Janfred

On 26.03.24 00:34, Eric Rescorla wrote:
> 
> 
> On Mon, Mar 25, 2024 at 7:25 AM Eliot Lear <lear@lear.ch 
> <mailto:lear@lear.ch>> wrote:
> 
>     Eric,
> 
>     On 25.03.2024 15:23, Eric Rescorla wrote:
>      > Why does it make sense to require some third party to host a spec
>     with
>      > unclear stability properties when we already have a way of hosting
>      > with clear stability properties?
> 
>     I'm not requiring anything, but you and I are disagreeing about the
>     stability properties of drafts.
> 
> 
> I'm not sure what you think that disagreement is about, as those 
> properties are quite clear:
> 
> 1. Any individual draft version doesn't change.
> 2. Whether subsequent versions are issued or are different is up to the 
> authors, but it's visible when it happens because the version increments.
> 
> The properties of a document hosted on someone's web site are that it 
> can be changed at any time and those changes may or may not be visible. 
> Why do you think this is more stable?
> 
> -Ekr
> 

-- 
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieckers@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__________________________________________________________________________________

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
https://www.dfn.de

Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | 
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822

v2.23.0 | Report a Bug | By Email