[saag] Re: New Version Notification for draft-rsalz-crypto-registries-00.txt

[Paul Wouters <[e-mail]>]

> On Nov 28, 2024, at 04:07, Simon Josefsson <simon=[e-mail]> 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.

> 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 ?

> 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.


> 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.

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.

> 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 adding 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 forward with the openpgp document and the author in the rough was part of that until the substituted themselves with their candidate of choice from their own 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 implementors /  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 do just in time operator access for VPN to a bastion host? you need to use an 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" )

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. 

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. 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 having 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 (often junior) software engineers. It's guaranteed to be less secure, less maintained, and never revisited.

A large part of academic public cryptographic research and development happens around NIST competitions. That's not something the IETF can change. 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 as the defacto algorithms. Nothing suggests it will be different this time. 

Paul