On 10/12/23 4:52 AM, Falko Strenzke wrote:
Hi Robert, thanks for your feedback. See my answers below.
Robert Relyea schrieb am Montag, 25. September 2023 um 19:23:04 UTC+2:
On 8/21/23 11:52 PM, Falko Strenzke wrote:
Hi John,
that is great to hear. Our two interests are PQC algorithms for
TLS in Firefox and S/MIME in Thunderbird. As I understand it you
are working on the former. Hash-based signatures are also
interesting for us, mainly stateless ones. Are you going to
support SPHINCS+ certificates for TLS, too?
I don't know of anyone that's talking about hash-based signatures
in any of the on-line protocols (TLS, SSH, IKE). The stateful ones
have deployment issues and signature limitations, the stateless
ones are have too big of keys.
The use case for hash-based appears to be mostly code-signing.
It's also one of the few signing operations that have long lived
signatures that could create real problems for a signature made
today and a quantum computer 10 years in the future.
I agree that hash-based schemes will most likely not appear in EE
certificates. But in the certificate chain they might very well
appear, I think. There are currently concepts being discussed for
stateful hash-based root CAs.
I did misspeak. for hash-based schemes, the key size isn't the issue,
it's the signature size. So having hash-based signatures in your chain
is going to blow up the size of the certs signed with those signatures.
If you keep the signature count low, you can get away with smaller
signtures in state-full hashes, but then you run into nasty deployment
issues as you can't really back up stateful keys in any meaningful way
(you'll have to do something key key partitioning or similiar, which in
turns expands the needed signature count).
That being said, I expect to support stateless verification. Again, if
the oids are properly defined we would be able to handle certs that use
them. We would not support stateless signature (at least not natively)
in NSS because there isn't a way to safely deploy stateless signature in
software.
You best indicator on what will be supportable is what the actual
standards bodies define.
The point here is that waiting for final standards delays large scale
proof-of-concept testing for PQC migration – maybe by years. What I
think would be useful is having at least ML-DSA (Dilithium) as a
signature algorithm for authenticating the handshake in TLS. Could you
imagine integrating that in NSS?
Eventually yes, but TLS authentication is not the first priority. We
only need to have that in and generally supported before Cryptographic
Relevent Quantum computers are generally available. Recording a TLS
session and in the future cracking the signature doesn't generate a
compromise.
There are good reasons to wait for the standards before deployment
(rather than experimentation). Mostly because all the PQ algorithms are
quite new and we now have a pretty good track record for what happens if
you move *TOO* quickly. We also want to have the final versions that
everyone agrees on deployed and solid to maximize deployment of those
(if there are a lot of competing standards and everyone still negotiates
ECC or RSA we all loose).
In the mean-time experiments are good to help understand the deployment
issues.
Other things we can do is try to prepare for the new algorithms. I
currently have a patch for the general signature processing that would
make adding the new PQ signatures pretty transparent, for instance.
Do you think an existing (individual) RFC draft for PQC signature
identifiers in TLS would help here?
It would. We're actually pretty close on the standards. NIST should be
final first quarter of 2024. The draft is already good enough for other
standards to reference it. There's a strong desire to get these things
defined and finalized. I expect most of the important standards will be
in place by the end of 2024.
The two areas of most work (In the entire cyrpto industry, not
just firefox or NSS) is getting standardize hybrid into our
streaming protocols which are subject to 'record now/decrypt
later' attacks and firmware/code signing. These are the two main
areas where the useful life of the encrypted/signed objects may
outstrip the potential advent of a crypto relevant quantum
computer. I expect that will be where most of the work occurs in
2024. Remember: the only standardized PQ algorithms right now is
LMS/HSS and XMSS,XMSS/MT. That will change by early 2024 (NIST now
has drafts for Kyber, Dilithium, and SPHINCS).
I understand being cautious to release experimental / not yet
standardised features. Is there a concept in the NSS / Firefox code
base and a development workflow for such features to be integrated
into the code but not being accessible in the release version? That
might facilitate contributions of experimental features that are not
too invasive with respect to the source code structure such as merely
adding new algorithms.
There are experimental API standards in NSS, where the API is access
through a function that is marked as experimental and NSS API
guarrentees do not apply. There are patches to add Kyber_25519 hybrid to
NSS, but I don't see that they've landed yet. Those are explicitly
experimental. Given that the final specs are now close, I'm not sure how
much we would just put off for the final specs though.
bob
--
You received this message because you are subscribed to the Google Groups
"dev-tech-crypto@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dev-tech-crypto+unsubscr...@mozilla.org.
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/851358ae-aaf3-43a2-bf59-b50ac0a7c081%40redhat.com.
