Return-Path: 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 2852DC14F739 for ; Thu, 28 Nov 2024 19:38:45 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 WTJmCJXpQqtV for ; Thu, 28 Nov 2024 19:38:44 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43261C14F71F for ; Thu, 28 Nov 2024 19:38:44 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-385d7f19f20so332900f8f.1 for ; Thu, 28 Nov 2024 19:38:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732851523; x=1733456323; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VP8kTqFy/BW1nimsTy2s5nJl+y+EY6sYG7szqRiS3ik=; b=mJehefMomOs+SqzrcQm5lUjnnTVHcsstDZEqn9GCKlk/0x/OYJnK920NkPNiF7uLos sUt5xOojc0EJvWE6rjolJ+d2iv9og17e6K9YJ30dRZuALqeXjmXuCodQT204sh0b6AP7 Qzm4KN3xkYTUOziQ9nKF+3Qg7V0RPRBc82hzKLjMlNswoTLVEdve+jElZDFsOA/HpEpE 5tT/K0babHBa/Qlrj/DUTEDyTuTuuU/Vkem4Z02MWU1cmPRBkD1qSYutI5ioWioaK0St 0o7PrqghpJoTCGSQolnptdaAatAeGoII9DP+B2h6m9ABI/jDzyBqZLsG0ttW/eA4GYA9 yy3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732851523; x=1733456323; h=cc: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=VP8kTqFy/BW1nimsTy2s5nJl+y+EY6sYG7szqRiS3ik=; b=HrdjSLD9UEi2QbpLeeCdQ0YDp6EqRhMcZlmxQ+LYN8GcETsVgZfHlZehGqMRQ99dr/ tSTmRblL40bPvIZ1DUgASgLRDsCzrRgbGxrR2fN90W62st/VJ39B7K4BzDAD1IXh7g9B vyGbeWapKW5rSKddneKNyHMniz5ga5jSrlH+0kL7rJerJkZQdMAigZd2bQ2VAw6W0L9f liyPjerXWkV6w7ZrI04ivvAEzCsE5H5K6pL8hHovXdkHhW5PptWnoKu90mYmP7GN0sII DiRVAfiCTum3kB1QUdsKpuIdHQSzVbJwFVlnFboSWrNViP1GbALlxCdd3fTXFBDY5n5m fBcA== X-Forwarded-Encrypted: i=1; AJvYcCWRxd094DH6qDiHz+1vNl4VxCKj3zK53mujzirm6IhsyIs7weLw8LuPcCTXnsSsYZk3kWUO@ietf.org X-Gm-Message-State: AOJu0YwdbOfb++7nVF/8lgTEQciALzL8w5+6U1+XT0EwQ5WXzKd+54j0 4CJ/QOvBw4b0sEb1ry7w7gPS7QlulcHDOByp57TV4d2BhvZgFLgv4/ZwyX+1yE1PuP3wU+MCP2k k9SEhkURZBjtbQ/yDrrjIG3P/d6FsuA== X-Gm-Gg: ASbGncv59lDcREXNeHeNzUZG0kE4thN0gHs9FxddVNxP13sr+7f9g4knaAWxOsrVzs6 wGieNHX5j8JF0RglnmSeKSEfJ92jP8w== X-Google-Smtp-Source: AGHT+IGJ+EFoszYGLomcO8CCn6U1g8nrc4mB6QTmnckkkdDUke34YgsZAqQ9jzwig1gqBw2YBIbaZtNJ8uFDj1QOCGo= X-Received: by 2002:a05:6000:4818:b0:382:5af:e990 with SMTP id ffacd0b85a97d-385c6ee221amr7774550f8f.49.1732851522546; Thu, 28 Nov 2024 19:38:42 -0800 (PST) MIME-Version: 1.0 References: <87zfljybgc.fsf@kaka.sjd.se> <4855756A-0AB8-44C1-9A44-45D477E0A548@aiven.io> In-Reply-To: <4855756A-0AB8-44C1-9A44-45D477E0A548@aiven.io> From: Watson Ladd Date: Thu, 28 Nov 2024 22:38:31 -0500 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary="00000000000073355c062804ef3c" Message-ID-Hash: QA7H7AQITQBHNFO6EWAGCP7JBMZAHQ4L X-Message-ID-Hash: QA7H7AQITQBHNFO6EWAGCP7JBMZAHQ4L X-MailFrom: watsonbladd@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-saag.ietf.org-0; header-match-saag.ietf.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Simon Josefsson , Tero Kivinen , Damien Miller , "Salz, Rich" , IETF SAAG X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bsaag=5D_Re=3A_New_Version_Notification_for_draft-rsalz-crypto-r?= =?utf-8?q?egistries-00=2Etxt?= List-Id: Security Area Advisory Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000073355c062804ef3c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 28, 2024, 12:33=E2=80=AFPM Paul Wouters wrote: > > > > On Nov 28, 2024, at 04:07, Simon Josefsson 40josefsson.org@dmarc.ietf.org> wrote: > > > > > > I share that sympathy. We can help them by making the IETF a welcoming > > place to get documents reviewed, improved and published. > > > > I believe the IETF share the responsibility for things ending up in the > > way you describe. > > > > While it is easy to cast the blame on OpenSSH folks for doing the > > actions, I believe the primary place to improve the outcome is in the > > IETF. It's not OpenSSH that should change, it's the IETF. > > Again you seem to want to have the benefits of the IETF process while > skipping the IETF process that yields that value to the community. > What value to whom? "the community" is a reification. There are different people with their own views and needs, and any discussion needs to remember that. > > If the IETF had been a more attractive place to come to and get things > > done, doing so happens naturally and automatically. > > and somehow most protocols can do this fine except ssh ? > I've been in many working groups and the ssh dynamic is not unique. WHATWG, the W3C, etc are what happens when people say no and others continue to realize the value of their innovation. > > Unfortunately, I see diminishing interest in acknowleding or improving > > this state. > > as long a you believe only ietf is wrong, i can see how your statement > becomes true. > It's slower and harder to get things through than it used to be. That's a problem. I've admittedly been a very slow penholder but getting SPAKE2 and related and Roughtime through the process has taken years. > > > > Instead there appears to be strong interest in using the > > powers to 1) delay, defer and stop publications (ssh-ntruprime, peap, > > anything non-nist) > > "the powers" being the entire active ietf community, except 3 ssh people > with a very personal agenda about cryptography. > I think that's not a fair reflection of the discussion here or the formation of the ssh wg. > > The rough consensus is that there is no appetite for NTRUprime. the > reasonings of why some believe this case is special because of its > "widespread use", ignore the market position of these three people and 1 > implementation who pushed through defaults as they saw fitting their own > cryptographic and political agenda. Don't blame IETF for this. > Running code matters. You are carefully eliding your role here and I think people should be aware of it. It also raises the question of whose rough consensus when several vendors have implemented. > > > and 2) publish specifications that are incompatible > > with deployments which damages ecosystems (pgp) > > it's interesting you pick this example as i was closely involved after th= e > first re-opened openpgp working group failed due to one draft author addi= ng > stuff without working group consensus, then claiming the code point later > after they walked away from IETF during a two year additional run of the > re-re-opened working group. The IETF here had weekly calls to move forwar= d > with the openpgp document and the author in the rough was part of that > until the substituted themselves with their candidate of choice from thei= r > own implementation. two years later they complained about the results. Ho= w > is this the IETFs fault ? The IETF even skipped the code point to avoid > wide scale issues because of the one person squatting a code point for > their own homegrown stuff. > > Remember, "rough consensus", not Kings or Rockstars or single implementor= s > / implementations. > > > , and 3) favor protocols > > that lead to weaker system security due to complexity (ipsec, x509). > > i assume you mean IKE, not IPsec (if not I advise you to check the wire > formats of wireguard and ESP). I also advise you to look at how one does > negotiate parameters with WireGuard - hint it requires its own crypto > stack, usually HTTPS or SSH for a severely limited hardcoded way of doing > things. That might work for your basement but not at scale. You want to d= o > just in time operator access for VPN to a bastion host? you need to use a= n > entire different (ssh) protocol to login to the bastion with root access > allowing you to modify crypto keys inside the kernel. Then do the same > later on to remove the state. complaining about x509 and proposing a > simpler alternative that doesn't meet the minimum requirements won't help > (eg see "age" vs "openpgp" ) > Letting a few advanced use cases make the most important use case hard is a problem. It's a balancing act and log rolling consensus will tend to overcomplicate the result. There's no reason to the think the IETF has gotten it right, particularly with the way X509 actually works in practice. > > IETF is slower because we make things that apply to different deployment > scenarios. it involves listening and talking and discussion with many > different people and taking their points into consideration. That's not really how it works, even if it says that on paper. It's a much messier process. > > > saying x509 leads to weaker system security is cute, and everyone here > agrees the complexity is not ideal. Replacing it is a difficult large > project. It's only going to happen when someone implements and deploys a feasible alternative, not from chatting at the IETF. That comes later. Meanwhile, it's the basis for almost all encrypted internet connections. > it's offering real life security benefits for everyone doing web, email, > vpn. Again coming in isolation, with a single use case solution, and havi= ng > everyone write custom wrapper code (around wireguard, around ssh > certificates) is itself a huge unknown risk because all that wrapper code > has been mostly unaudited, unseen and hacked by generic non-security (oft= en > junior) software engineers. It's guaranteed to be less secure, less > maintained, and never revisited. > X509 can't express the authorization logic you would want for your example above, particularly if looking at patterns of activity. > > A large part of academic public cryptographic research and development > happens around NIST competitions. That's not something the IETF can chang= e. > It is not surprising that IETF picks among those candidates. In the > previous round, IETF ended up selecting a NIST and a non-NIST algorithm a= s > the defacto algorithms. Nothing suggests it will be different this time. The IETF made a real mess of the curve selection by doing it vs just publishing the draft describing what people were deployed and had running. This permanently lost contributors who were valuable for nothing. It was a mistake to do this. We will need ML-KEM for SSH. If you feel strongly write the draft but I think it has been done. There's no reason we can't also have NTRU prime described. Why are we intent on making the same mistakes? Some > > > Paul > > > _______________________________________________ > saag mailing list -- saag@ietf.org > To unsubscribe send an email to saag-leave@ietf.org > --00000000000073355c062804ef3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 28, 2024, 12:33=E2=80=AFP= M Paul Wouters <paul.wouters=3D40aiven.io@d= marc.ietf.org> wrote:


> On Nov 28, 2024, at 04:07, Simon Josefsson <simon=3D40josefsson.org@dmarc.ietf.org> wrote:=
>
>
> I share that sympathy.=C2=A0 We can help them by making the IETF a wel= coming
> place to get documents reviewed, improved and published.
>
> I believe the IETF share the responsibility for things ending up in th= e
> way you describe.
>
> While it is easy to cast the blame on OpenSSH folks for doing the
> actions, I believe the primary place to improve the outcome is in the<= br> > IETF.=C2=A0 It's not OpenSSH that should change, it's the IETF= .

Again you seem to want to have the benefits of the IETF process while skipp= ing the IETF process that yields that value to the community.

What value to = whom? "the community" is a reification. There are different peopl= e with their own views and needs, and any discussion needs to remember that= .


> If the IETF had been a more attractive place to come to and get things=
> done, doing so happens naturally and automatically.

and somehow most protocols can do this fine except ssh ?

I've been in ma= ny working groups and the ssh dynamic is not unique. WHATWG, the W3C, etc a= re what happens when people say no and others continue to realize the value= of their innovation.=C2=A0


> Unfortunately, I see diminishing interest in acknowleding or improving=
> this state.

as long a you believe only ietf is wrong, i can see how your statement beco= mes true.

It's slower and harder to get things through than it used to = be. That's a problem. I've admittedly been a very slow penholder bu= t getting SPAKE2 and related and Roughtime through the process has taken ye= ars.


> Instead there appears to be strong interest in using the
> powers to 1) delay, defer and stop publications (ssh-ntruprime, peap,<= br> > anything non-nist)

"the powers" being the entire active ietf community, except 3 ssh= people with a very personal agenda about cryptography.

I think that's n= ot a fair reflection of the discussion here or the formation of the ssh wg.=

The rough consensus is that there is no appetite for NTRUprime. the reasoni= ngs of why some believe this case is special because of its "widesprea= d use", ignore the market position of these three people and 1 impleme= ntation who pushed through defaults as they saw fitting their own cryptogra= phic and political agenda. Don't blame IETF for this.
<= /div>

Running code matte= rs. You are carefully eliding your role here and I think people should be a= ware of it. It also raises the question of whose rough consensus when sever= al vendors have implemented.

> and 2) publish specifications that are incompatible
> with deployments which damages ecosystems (pgp)

it's interesting you pick this example as i was closely involved after = the first re-opened openpgp working group failed due to one draft author ad= ding stuff without working group consensus, then claiming the code point la= ter after they walked away from IETF during a two year additional run of th= e re-re-opened working group. The IETF here had weekly calls to move forwar= d with the openpgp document and the author in the rough was part of that un= til the substituted themselves with their candidate of choice from their ow= n implementation. two years later they complained about the results. How is= this the IETFs fault ? The IETF even skipped the code point to avoid wide = scale issues because of the one person squatting a code point for their own= homegrown stuff.

Remember, "rough consensus", not Kings or Rockstars or single imp= lementors /=C2=A0 implementations.

> , and 3) favor protocols
> that lead to weaker system security due to complexity (ipsec, x509).
i assume you mean IKE, not IPsec (if not I advise you to check the wire for= mats of wireguard and ESP). I also advise you to look at how one does negot= iate parameters with WireGuard - hint it requires its own crypto stack, usu= ally HTTPS or SSH for a severely limited hardcoded way of doing things. Tha= t might work for your basement but not at scale. You want to do just in tim= e operator access for VPN to a bastion host? you need to use an entire diff= erent (ssh) protocol to login to the bastion with root access allowing you = to modify crypto keys inside the kernel. Then do the same later on to remov= e the state. complaining about x509 and proposing a simpler alternative tha= t doesn't meet the minimum requirements won't help (eg see "ag= e" vs "openpgp" )

Letting a few advanced use cases make the m= ost important use case hard is a problem. It's a balancing act and log = rolling consensus will tend to overcomplicate the result. There's no re= ason to the think the IETF has gotten it right, particularly with the way X= 509 actually works in practice.

IETF is slower because we make things that apply to different deployment sc= enarios. it involves listening and talking and discussion with many differe= nt people and taking their points into consideration.

That's not really how = it works, even if it says that on paper. It's a much messier process.


saying x509 leads to weaker system security is cute, and everyone here agre= es the complexity is not ideal. Replacing it is a difficult large project. =

It's only goi= ng to happen when someone implements and deploys a feasible alternative, no= t from chatting at the IETF. That comes later.
<= br>
Meanwhile, it's the basis for almost all e= ncrypted internet connections. it's offering real life security benefit= s for everyone doing web, email, vpn. Again coming in isolation, with a sin= gle use case solution, and having everyone write custom wrapper code (aroun= d wireguard, around ssh certificates) is itself a huge unknown risk because= all that wrapper code has been mostly unaudited, unseen and hacked by gene= ric non-security (often junior) software engineers. It's guaranteed to = be less secure, less maintained, and never revisited.

X509 can't express= the authorization logic you would want for your example above, particularl= y if looking at patterns of activity.

A large part of academic public cryptographic research and development happ= ens around NIST competitions. That's not something the IETF can change.= It is not surprising that IETF picks among those candidates. In the previo= us round, IETF ended up selecting a NIST and a non-NIST algorithm as the de= facto algorithms. Nothing suggests it will be different this time.

The IETF made= a real mess of the curve selection by doing it vs just publishing the draf= t describing what people were deployed and had running. This permanently lo= st contributors who were valuable for nothing. It was a mistake to do this.=

We will need ML-KEM for= SSH. If you feel strongly write the draft but I think it has been done. Th= ere's no reason we can't also have NTRU prime described. Why are we= intent on making the same mistakes?

<= div dir=3D"auto">Some=C2=A0


Paul


_______________________________________________
saag mailing list -- saag@ietf.org
To unsubscribe send an email to saag-lea= ve@ietf.org
--00000000000073355c062804ef3c--