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

[Watson Ladd <[e-mail]>]

On Thu, Nov 28, 2024, 12:33 PM Paul Wouters <paul.wouters=
[e-mail]> wrote:

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

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 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" )
>

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

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


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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>