Re: [saag] SSH & Ntruprime

Deb Cooley <debcooley1@gmail.com> Tue, 16 April 2024 19:36 UTC

Return-Path: <debcooley1@gmail.com>
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 9B0F1C14CE54 for <saag@ietfa.amsl.com>; Tue, 16 Apr 2024 12:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.845
X-Spam-Level:
X-Spam-Status: No, score=-1.845 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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_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=gmail.com
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 wu3x3i0CIvxG for <saag@ietfa.amsl.com>; Tue, 16 Apr 2024 12:35:58 -0700 (PDT)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 CD9B4C14F5EE for <saag@ietf.org>; Tue, 16 Apr 2024 12:35:58 -0700 (PDT)
Received: by mail-il1-x12b.google.com with SMTP id e9e14a558f8ab-36afb4b4a3eso19181825ab.3 for <saag@ietf.org>; Tue, 16 Apr 2024 12:35:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713296157; x=1713900957; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=RTNIk8JZIs5ory1uVq0x2aHw/FeXhF/Eeqa+IBj2hZY=; b=IGT6aYbqOIcH8s0LKuG6bVhWAj3VlcTjDkhrCSe+8SIDTIYrjjAJswuo9TLriYM0s9 YHzjrWLgnLjkZddlJGlWBCFaBrTRp7u4fF1xTN/T5UpokeWzbvBzwNZ9GqTc/fDfJcHN DpqCCoN4Cp4BxxCMoXPWErMSreMhglMdlSwlsbhzb4FaePaUrewUkdEYcalsc+nuMCNO KrQIt0P3X7kiayFr+8iJHQrlQHKb+9dNYYSgIOU+9xHjRd4L9Q8TbtefqbcfWK2ZgcQJ G3Kp1Kmv7KK9J1j61eX8LgPD5RdIjeYIzF/3HKFrEO/mftPueBkp1HeoRIuaY/dQgRTq BrRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713296157; x=1713900957; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RTNIk8JZIs5ory1uVq0x2aHw/FeXhF/Eeqa+IBj2hZY=; b=bj6fNVeot8foah4GR/dMdR9eLpPuJVMU0HxizFhNDGo5qiuL/1CS9+bxkLYaOUF0Jo qFUvLCR4P2DiqB7R4C1LmQ+TNUlI6dqMjTdrDDrz7dPrwmznFmiseajhNvmveM1KJAT1 FsULeHXKrOlBtWDwtyDapl9KP/OM07qJJ9WeoIfA+K7bwjovCo6ja0IY5Xm5re0olyLL hX4gc9C6AZrNkOzMZMolKbgNeBR7zi0cgqexlR5X4DekIWRqIg6e/VB53NQnXEcn1Pyq HP/P56E5ocGGc8R08tBPYIDatnnN4jMDd0FkpVDflvwIavxOAXGw/U0X8A3OhDflAsJd Clgg==
X-Gm-Message-State: AOJu0YyjPXAINQXwf+wlavkKuHl8w0k/WR3OgW3caKjHtuR1ip7REsdR 8iGF4tCugvk/nUciiiG9+WRFfxKJTGnBzIgdTk9GlVT1ti7QpIeesfa/7tgEURI1I9eKC0dXZjF Rf/xZ09sFvkerxeyhGHqGExxT7GxX
X-Google-Smtp-Source: AGHT+IFiEO6iYuKVohgpOS/R+5RvHI10b1TmhweXh/wqf7l9W9JOcbxm5M7vYkEVEVgACfRGj/9L/+KHyngt/SiDsXE=
X-Received: by 2002:a05:6e02:188f:b0:36a:fd39:1a75 with SMTP id o15-20020a056e02188f00b0036afd391a75mr17883661ilu.21.1713296157523; Tue, 16 Apr 2024 12:35:57 -0700 (PDT)
MIME-Version: 1.0
References: <CAGL5yWZRMJAWifEz9qxSRpkhv44B+_6PzoX9c5GGVpjJ2OWuHQ@mail.gmail.com> <20240416182212.179605.qmail@cr.yp.to>
In-Reply-To: <20240416182212.179605.qmail@cr.yp.to>
From: Deb Cooley <debcooley1@gmail.com>
Date: Tue, 16 Apr 2024 15:35:31 -0400
Message-ID: <CAGgd1OegoRS7rWMoZsBWHnfHp1cbvRpsOGyvYLw+ALXv0m29+w@mail.gmail.com>
To: saag@ietf.org
Content-Type: multipart/alternative; boundary="000000000000dd525606163bd8e0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/yUBO4m7ErSQpLESZuXDR9_RIVaI>
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: Tue, 16 Apr 2024 19:36:02 -0000

To bring this back to the SSH AD sponsor discussion.  There are two
issues:

1.  lack of change control - can the IETF make changes to the current
draft?  Or is it set in stone already.
2.  A less than ideal combiner for the hybrid.  Is this combiner 'safe in
the SSH context'?  Or are changes required (see #1 above).

We (Security ADs) are happy to entertain the formation of a SSH Working
Group, if the community is interested in contributing.  The previous
working group was closed in 2007 after the publication of RFC4819.  Since
that time, updates to this protocol have been haphazard at best.

If the community isn't interested in that, then the authors can follow
RFC9519* and request an expert review to obtain a code point.

*there is a small issue w/ the mailing list, it is being worked.

Deb Cooley
Sec AD

On Tue, Apr 16, 2024 at 2:22 PM D. J. Bernstein <djb@cr.yp.to> wrote:

> Paul Wouters writes:
> > You keep quoting IPR policy without putting it in the proper context.
> > It deals with protocols developed within the IETF, eg during the
> > working group process. The process for deciding on cryptography is a
> > separate process
>
> No. BCP 79's scope includes security, and specifically cryptography.
>
> For example, BCP 79 reports that an "IETF consensus has developed that
> no mandatory-to-implement security technology can be specified in an
> IETF specification unless it has no known IPR claims against it or a
> royalty-free license is available to implementers". The notion that
> cryptography is somehow an implicit exception to this is directly
> contradicted by the mailing-list discussions producing this BCP 79 text,
> notably
>
>
> https://mailarchive.ietf.org/arch/msg/ipr-wg/VoP9ZpFliPEmZp6Y9_qOYShyq54/
>
> from Scott Bradner (that's https://en.wikipedia.org/wiki/Scott_Bradner
> for IETF newbies who don't know the name) saying
>
>    for security-related technology, a discussion at an IETF plenary
>    meeting endorced the idea that all mandarory-to-implement security
>    technologies (such as encryption technologies) should be RF or
>    IPR-free
>
> and saying that this "should be documented"---which, of course, is what
> happened in draft-ietf-ipr-technology-rights-02 shortly afterwards,
> leading, after many more document revisions, to BCP 79.
>
> Note the words "such as encryption technologies" above. I wouldn't say
> that crypto patents were the _only_ driver of the BCP 79 text, but I
> have no idea how anyone could imagine that they're out of scope, or how
> anyone could argue that excluding them would be a good idea.
>
> > IETF does not consider itself to be a full blown academic community
> > capable of evaluating all cryptography.
>
> This seems to be referring to the idea that IETF needs help from
> academia in evaluating _whether cryptography is secure_. How is this
> supposed to turn cryptography into an exception to the BCP 79 policies
> preferring unpatented technologies?
>
> > I am not willing to AD sponsor a document
>
> You've been going far beyond declining sponsorship under the IESG AD
> sponsorship procedures: you've been broadcasting claims that discourage
> IETF attention to an unpatented alternative to Kyber.
>
> Regarding the particular draft in question, I would hope that another AD
> sees the problems with this declination and decides to sponsor the
> draft. Regarding IETF's post-quantum handling more broadly, the errors
> that have appeared here should be corrected for the record.
>
> > > Also, have you considered the possibility that the conclusions in those
> > > conversations come from underlying errors that would be corrected if
> the
> > > arguments were raised in public? Look at the above "scrutiny" claim:
> > > it's the sort of error that can easily be repeated because it _sounds_
> > > reasonable, but transparency allows the claim to be rapidly debunked.
> > No, I have confidence in the claims.
>
> To clarify, are you continuing to maintain the "scrutiny" claim that you
> stated, despite the detailed contrary evidence that I provided? Or are
> you referring to some other claim?
>
> > > > Some people prefer to not engage with you due to previous negative
> > > > experiences with your method of discussion.
> > > Now _that's_ an ad-hominem attack. Please (1) apologize and (2) keep
> > > yourself under control in the future. Thanks in advance.
>   [ ... ]
> > I was in a difficult position. I could either withhold the information
> > and be accused non-transparency
>
> Let's review the continuing lack of transparency here.
>
> The IETF 119 SAAG presentation made claims about what the Crypto Review
> Panel said, and indicated that AD sponsorship had been dropped on that
> basis. There was no reference to any other input.
>
> Your subsequent email dated 9 Apr 2024 20:26:41 -0400 referred to "the
> transparency of all IETF processes" and---in response to my observing
> that what readers learn from the AD summary is factually incorrect---
> claimed, without details, that you had "heard a similar position about
> NTRUprime from outside the IETF in the academic world of cryptography".
> Later you clarified that this was referring to secret conversations.
>
> The situation right now is that there's no paper trail justifying the AD
> decision at issue. Anyone checking the Crypto Review Panel text can see
> that what the AD has attributed to that text doesn't match what the text
> actually says. The simplest explanation available is that the AD summary
> actually came from those secret conversations in the first place---and
> the rest of us can't see what happened in those conversations.
>
> Issuing personal attacks as an alleged rationale for non-transparency
> doesn't create transparency; it violates BCP 54 and hampers moving the
> discussion forward. The only way to rectify the transparency failure
> here is to publish all of the inputs that were used---for example, the
> aforementioned secret conversations, if they in fact happened---along
> with saying what extra inputs were introduced by the AD.
>
> > I stand by my view that your statement calling the Crypto Panel Review
> > "political" was unsubstantiated.
>
> I laid out the case for this, quoting the specific text at issue and
> making specific observations on the content. That's substantiation. You
> didn't even quote, let alone reply to, the details; instead you falsely
> labeled the summary as an ad-hominem attack. Please withdraw that false
> accusation to set the record straight. Thanks in advance.
>
> ---D. J. Bernstein
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>