Re: [saag] SSH & Ntruprime

Christian Huitema <huitema@huitema.net> Wed, 27 March 2024 03:33 UTC

Return-Path: <huitema@huitema.net>
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 18C17C14CF1C for <saag@ietfa.amsl.com>; Tue, 26 Mar 2024 20:33:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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
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 5YHnJnC1VhLZ for <saag@ietfa.amsl.com>; Tue, 26 Mar 2024 20:33:33 -0700 (PDT)
Received: from se01.mfg.siteprotect.com (se01.mfg.siteprotect.com [64.26.60.164]) (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 5D3B6C14F701 for <saag@ietf.org>; Tue, 26 Mar 2024 20:33:33 -0700 (PDT)
Received: from smtpauth01.mfg.siteprotect.com ([64.26.60.150]) by se01.mfg.siteprotect.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1rpK2c-004Mco-Rw; Tue, 26 Mar 2024 23:33:32 -0400
Received: from [10.32.61.31] (unknown [192.0.32.236]) (Authenticated sender: huitema@huitema.net) by smtpauth01.mfg.siteprotect.com (Postfix) with ESMTPSA id 4V4C1h4VMcz1627G9; Tue, 26 Mar 2024 23:33:28 -0400 (EDT)
Message-ID: <03efb140-267f-4ec3-9324-5a1190ff8db7@huitema.net>
Date: Tue, 26 Mar 2024 20:33:28 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Michael Richardson <mcr+ietf@sandelman.ca>, saag <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> <87sf0dupjn.fsf@kaka.sjd.se> <CAN8C-_JTwA1fP=d0c_AXOdYsAX6fDfnFb0U05aO8y8tg8R3bVw@mail.gmail.com> <484345.1711508956@dyas>
Content-Language: en-US
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; keydata= xjMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1RmvN J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsKWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAzjgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB8J+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
In-Reply-To: <484345.1711508956@dyas>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Authentication-Results: mfg.siteprotect.com; auth=pass smtp.auth=huitema@huitema.net
X-Originating-IP: 64.26.60.150
X-SpamExperts-Domain: mfg.outbound
X-SpamExperts-Username: 64.26.60.150/31
Authentication-Results: mfg.siteprotect.com; auth=pass smtp.auth=64.26.60.150/31@mfg.outbound
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.25)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/HDCIICaFPabAmTOTTzU6aPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wLIbRZIHN70LHPIlJms4D5QaTBWRaqpzIdzwBjFPVO+20a VdXcs4QACya27lNXiQjnx8yeplRO3sLIqUlSH7OGqxeylLDN0BLUrPsmlp6fYoMlhcTgOXSCz8qb ysTVYVn6w92A9ufZeIxcANJL/o3B64bdOj4sZJTV3cCesl5JZGfAc0ykrwr36g7qVffW0UrSHSaK l6ICge62pPwC4mZpC36xw4KfUVdI3efK/Bi13Bjgvu7pAn+NdcA8i2i+TTif2qHpgkuCgiCmigYc 0JaNzJ3vJBBYvcIXZcvdbj7fjbZn+1a2iCCdPFy3WGiBkBZc+BBb+UeYFBhPAZQ65C2d4vB6Mmh6 nzlzGKK4CNTdFqDi8JFm404TMJu86vxuL7TdY4ZzPzG72tly1fyyBM2ihxr/CirnbEtCEQE6MoLy fQLIxx77PRxFP9mwEQV4kMTfX8TdqEXkwxwMjsp2mNApPCqZc39PjocnaDJuSwgBjdxJmMd6htGD AZ47En37od1FQVRTn8m0sooRS7h6xdEgKTjECb0PwpN4olPuA0AI936c0SM84BxzaZIqKXfxGELS AIttXPEgCLSmIU9J1aqq/yJ79jYxxklvhfrt8SqXf0W7s0R5EImR82HkXgfT4GZgmI3h+t3qGRYD 7x9bR/nuzqUqLa6c4RN3CaQKGkBju5J0xV4Vg9g3GWQa88qJMTyv1KPcaedUtYK7db97bYwOlt58 5ejW+xAUR5rZ83KuM6I0my2I/q8+LvwxuYUF7VIlrnEujmSG0GhzpL2apVTB4N+aLuPoORGKM1UJ qzeGg24VX8EMkwp1uLZPwqgLglhRXxKF5tPxTxfD0dMN+t5ZnZSkMhtHPWPd9LV3WUy7C1hd7+Z3 ohEuqbhw2IGiK9CL9mGn/WqpBlSCoZxT+LEya7X/CX9/5OOSfZtD8DykTk6bUDBJr0uSuYe0kRlI eSf1v8Y0StKQxc8ZKSMnjO5WAOTmdYiIhy2F1Nqi2QhqtJaYq78TG9r/hs7i2ldyYM7NgP007RqT LBS/vATKx0/sjznvAJBzabCuUDC3WKw4eA==
X-Report-Abuse-To: spam@se02.mfg.siteprotect.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/SsXe5lHKYZsqRK978ozeeFSyGDA>
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: Wed, 27 Mar 2024 03:33:37 -0000


On 3/26/2024 8:09 PM, Michael Richardson wrote:
> 
> Orie Steele <orie@transmute.industries> wrote:
>      > 1. Publish SSH related specifications as RFCs
>      > 2. Support the review process from RFC9519 (We're working to resolve the
>      > issue with the list, thanks for reporting it)
> 
>      > I don't think using IDs to document SSH algorithms and then never
>      > publishing those drafts helps either community.
> 
> It's a lot of effort and money to publish a document for an algorithm that
> some say isn't as secure as claimed, and perhaps shouldn't be widely implemented.
> 
> a) anyone can register foobar@example.com in the SecSH ecosystem, and openssh
>     has done exactly that, and really, it's done.
> 
> b) if someone wants "foobar", I'm fine with *any stable web page* (including
>     ietf.org/archive/foobar).  That's what **Specifications Required** means, and
>     please let's not raise the bar here.
>     If necessary, we can loop it through archive.org, which is what the RPC
>     is doing for other references in RFCs.

+1

The "specification required" policy has the big advantage of not using 
code-point registration as a gatekeeping tool. There are some rare 
conditions were gating is necessary, for example when the code space is 
really small. But otherwise, code-point gatekeeping becomes a tools that 
insiders can use to pick favorites, and the net result is to force 
communities to develop workarounds outside the IETF and IANA.

The current rule is fine.

-- Christian Huitema