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

[Paul Wouters <[e-mail]>]

On Nov 28, 2024, at 22:38, Watson Ladd <[e-mail]> wrote:
>> 
>> 
>> > 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 above did not relate at all to the formation of the sshm WG at all. Please note I was the AD that started the process of widening some SSH proposals into creating a new SSH maintenance working group.

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

the term "overcomplicate" is biased towards your own use cases. For others, this would be called "Minimum Viable Product". Yes, something out of the IETF will also be more complex than something developed by a single developer with a single use case in mind. again, wireguard comes to mind when their key exchange didn't support various "overcomplicated" features such as dynamic IP allocation and nameserver IP options for vpn clients". Is IKE "overcomplicated" supporting those? If you need a hardcoded IP tunnel between two endpoints that have an SSH trust relationship to reconfigure each others kernel, yes. for the majority of other use cases, no.

> There's no reason to the think the IETF has gotten it right, particularly with the way X509 actually works in practice.

Sure, without taking into account historic context, every system designed 30 years ago "got it wrong".

I mean, the SSH protocol doesn't even ensure both peers experienced the same handshake content using a cryptographic signature. Clearly that's wrong too if we look back without any further context of how that came to be.

Seems weird to only blame IETF for this.

Note that when we first started talking post quantum, Stephen Farrell proposed "since we need to redo so much, let's replace x509 while we are at it".  Where was the support for that work from the people dissing x509 now? Why didn't you volunteer to help this effort ? The answers to that will put the context in your "didn't get it right". Money, time, balancing risk, incremental progress over starting from scratch, etc.

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

People complained about the IESG being slow and last IETF numbers were presented that showed it wasn't the IESG but far more authors in AUTH48 delaying themselves. Perhaps we need to do some delving into slowness factors in the WG stage of the process. I bet a lot of slowness is from unresolved disagreements. Again, the IETF will always be slower than one person in a basement making a decision for their own software.

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

yes, someone needs to put up a few dozen million dollars. The real problem of replacing x509 is that it works reasonably well despite its issues.

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

what logic do I state above that x509 cannot do? I am confused because i just described protocols that use x509 at internet scale.


>> 
> 
> 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 did that in the 90s and later people complained we had 200 different ciphersuites. and we cut them down massively in the last five years. you want to repeat that for post quantum ?

> We will need ML-KEM for SSH. If you feel strongly write the draft but I think it has been done.

we need ml-kem and we need a common hybrid of ml-kem and like ecdsa or something. this work is happening across working groups (cfrg, tls, ike, ssh, lamps)

> There's no reason we can't also have NTRU prime described. Why are we intent on making the same mistakes?

We are trying to not repeat the 90s.

two reasons have been quoted for using ntruprime.

1) "don't ever use a NIST approved algorithm"

 Said by the cryptographer who entered the NIST competition with NTRUprime, but they refused to answer my question of whether that would mean ntruprime should not have been used if it had won the NIST competiton, and therefor why not apply the same sanity rule for losing candidates?)

2) patents on kyber

it seems most people believe the USG has or will have this arranged with the patent holders.

And before a cryptographer calls me an NSA shill again, I believe we should also have a non-NIST alternative for ml-kem. It seems FrodoKEM is gaining that momentum (iso, etsi, europe, ...)

Paul