Re: [saag] sntrup761x25519-sha512

Tero Kivinen <kivinen@iki.fi> Sat, 27 May 2023 09:40 UTC

Return-Path: <kivinen@iki.fi>
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 BD077C15171F for <saag@ietfa.amsl.com>; Sat, 27 May 2023 02:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, NICE_REPLY_A=-0.001, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi
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 z0UibRCX7ADW for <saag@ietfa.amsl.com>; Sat, 27 May 2023 02:40:09 -0700 (PDT)
Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 A20C1C151097 for <saag@ietf.org>; Sat, 27 May 2023 02:40:08 -0700 (PDT)
Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (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) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id 4QSxbQ6FLzzyd6; Sat, 27 May 2023 12:39:58 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1685180404; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pVg8nLLCyTfNW/9o305w+cLzG20zZ5CBmuxVitjMw90=; b=pj1GahWCUmTIU+PVkH2+a6Cjf9to3fZV7D7H2evmSJKd/uEWnIir1Vc85oEaXtEm//Szeg Hc30Jlvfzb4ZfDAq/CYsBrrpRww0LI0yXgQU/x4+WPdciCd6IrPAMIgTdRfR1bLVouQ7oW 8SBLtkPynCVnDGy1wbvre2Frw9wq1EI=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1685180404; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pVg8nLLCyTfNW/9o305w+cLzG20zZ5CBmuxVitjMw90=; b=R3aWaI3HmUM6z1wmQroUirACrczoxnr4n0kKAOQfFI4TDCP7Bbdwl1SIeKJizh+ITwUbtr stqn/Z2850yabOgtjUjZmj4d0SON9c8pk0jj2EXmdHJfQDnX4RDumignWrYflwUYhV3t4g 9p6/O05ii5dJekP0uAGkXd2n9px6rfM=
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi
ARC-Seal: i=1; s=meesny; d=iki.fi; t=1685180404; a=rsa-sha256; cv=none; b=VLvC5+bfyfGhUoAqe2DPovA2Tlt33TlL4O+6n00LwBNPffYcY97LWmFx8FT0IKLjWK52gK 5px8Neg9pyKEtlk5W8vCCv01t2tBop1+lJyuaoCnsoYw5gwm1qmEBq7P/x4TGVA4vesTWd KvYJ4XrnPFj9HgxDDJdZPNJG3DCPjnY=
Received: by fireball.acr.fi (Postfix, from userid 15204) id 5522125C12AE; Sat, 27 May 2023 12:39:57 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <25713.53229.248828.846116@fireball.acr.fi>
Date: Sat, 27 May 2023 12:39:57 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: Eric Rescorla <ekr@rtfm.com>, Simon Josefsson <simon=40josefsson.org@dmarc.ietf.org>, "saag@ietf.org" <saag@ietf.org>
In-Reply-To: <SY4PR01MB6251707EC5380E5D109F1F37EE479@SY4PR01MB6251.ausprd01.prod.outlook.com>
References: <875y8y4ip2.fsf@kaka.sjd.se> <84296E62-5843-4E7A-BD43-430491A5A1F3@akamai.com> <874jo8ytgw.fsf@kaka.sjd.se> <f6aa133635084609b0032ab1cfbfb7ce@amazon.com> <87sfbny046.fsf@kaka.sjd.se> <CABcZeBME4CRjd+4kqFCzYOmaOEafUiabsBoUQ0Eqm8A7OD-46A@mail.gmail.com> <87fs7nxj9f.fsf@kaka.sjd.se> <b82f1264-3935-4ca0-918a-fdb7f819c2bf@app.fastmail.com> <877csyznd1.fsf@kaka.sjd.se> <CABcZeBMobKFKjtFn3xt7DDD1rx0ZtvW2m5sq6Gz1q29ETp04rQ@mail.gmail.com> <25710.32450.966653.66336@fireball.acr.fi> <SY4PR01MB6251707EC5380E5D109F1F37EE479@SY4PR01MB6251.ausprd01.prod.outlook.com>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 4 min
X-Total-Time: 4 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/5VXcKKZWgH_m9S41ujAXP-fet_w>
Subject: Re: [saag] sntrup761x25519-sha512
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: Sat, 27 May 2023 09:40:13 -0000

Peter Gutmann writes:
> Tero Kivinen <kivinen@iki.fi> writes:
> 
> >All names having @example.com are free for that organization to allocate as
> >they like. I.e. openssh has allocated several protocol names from
> >@openssh.com domain.
> 
> Some of those are actually de facto standards, for example there are
> implementations that either ship with, or whose default configuration is,
> "*-etm@openssh.com" and none of the MTI mechanisms covered in the spec, so the
> only way you can talk to them is to dig up a vague description of what that
> involves from the bottom of a locked filing cabinet stuck in a disused
> lavatory with a sign on the door saying "Beware of the Leopard".

If they are defacto standards, then I think it would be usefull to
have more people looking at them, thus having IETF consensus would be
better than just expert review.

> The ability to stuff things you've made up yourself into @xyz mechanisms I
> think is more of a bug than a feature when you've got something that can set
> de facto standards in this way, you end up having to implement it or things
> break but there's no RFC to implement it from.

It also allows fast testing and development, as you can allocate
unique identifiers for your algorithms easily without needing to wait
for official allocation from anybody.

The issue is that people should NOT use those implementations having @
names, they should ask for the vendor who allocated them to actually
write documentation of the feature, and get proper name allocated.
-- 
kivinen@iki.fi