5 ms·

Yes, there isn't adequate browser (or other client) support to use Curve25519 signatures in a public CA's certificate. I'm actually kind of confused about exac

by schoen 6y ago

Yes, there isn't adequate browser (or other client) support to use Curve25519 signatures in a public CA's certificate. I'm actually kind of confused about exactly what would be required and exactly what the state of it is, so maybe someone can chime in -- I just know it's not ready. Another thing I don't understand is what the threat model looks like for applying hypothetically backdoored curves. That is, can you interactively or offline attack ECDHE, ECDSA, or both? Can you derive the private key from the public key, by inspection and calculation, by observing random signatures, by obtaining chosen signatures, or something else?

coder543 6y ago
> Yes, there isn't adequate browser (or other client) support to use Curve25519 signatures in a public CA's certificate. I'm not so sure about that. https://en.wikipedia.org/wiki/Curve25519#History https://en.wikipedia.org/wiki/Curve25519#History "Also in 2018, RFC 8446 was published as the new Transport Layer Security v1.3 standard. It requires mandatory support for X25519, Ed25519, X448, and Ed448 algorithms.[24]" I haven't confirmed this myself, but it seems like anything that supports TLS 1.3 (a lot of things, relatively speaking) supports both curve25519 and curve448. > Another thing I don't understand is what the threat model looks like for applying hypothetically backdoored curves. Maybe this article can provide some insight into what people are concerned about: https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG Obviously, no one has proof that the NIST curves are backdoored, so who knows what kind of backdoor they would have? No one really wants to find out the hard way, though.
- nicoburns 6y ago
  > but it seems like anything that supports TLS 1.3 (a lot of things, relatively speaking) A lot of things, but probably not enough things for a certificate authority that has to support pretty much everything in widespread use to use.
  - coder543 6y ago
    Could a certificate authority not have several root certificates? I really don't see any reason they would have to have only one root certificate. They could let people choose what kind of certificate they want issued to them, and the default could be whichever is most widely supported or whatever.
    - CydeWeys 6y ago
      Supporting a variety of options instead of just doing one thing has its own costs in terms of added complexity and maintenance. Maybe they thought about it and decided it wasn't worth it, at least not for now. There's nothing prohibiting them from offering more curves in the future.
    - aaronmdjones 6y ago
      People can already choose what kind of certificate they want issued to them, because the CA does not generate your private keys. Them giving you a certificate with an RSA public key in it is impossible if you submit a Certificate Signing Request with an ECDSA public key in it (or vice versa). Then it's only down to what intermediate certificate you want to serve. That's the constraining factor; since you don't get to choose which private key the CA signs your certificate with, you have to use the intermediate certificate whose public key corresponds to the private key that made that signature. The sensible thing for a CA to do is to sign with (and supply) an ECDSA intermediate if they get handed an ECDSA CSR, and an RSA intermediate if they get handed an RSA CSR. I imagine this is what Let's Encrypt does already.
      - tialaramex 6y ago
        It can't be what they do already because Let's Encrypt does not currently operate an ECDSA intermediate. This document describes a hierarchy they've just recently issued, and which is not yet in production use. If you present a CSR for an ECDSA public key today, Let's Encrypt will issue a certificate signed by their RSA intermediate Let's Encrypt Authority X3, for your ECDSA key. They haven't actually specified whether you'll get certificates in the new ECDSA hierarchy from the same API endpoint or need to use a different endpoint.
- toast0 6y ago
  > "Also in 2018, RFC 8446 was published as the new Transport Layer Security v1.3 standard. It requires mandatory support for X25519, Ed25519, X448, and Ed448 algorithms.[24]" This is oversold, if not simply factually incorrect. RFC 8446 says > A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A TLS-compliant application MUST support key exchange with secp256r1(NIST P-256) and SHOULD support key exchange with X25519 x448 is not mandatory. x25519 is not mandatory, it's only a SHOULD. In addition, key exchange is for diffie-hellman ephemeral keys; that's separate from the keys used in the certificate. I don't think there's widespread support for X25519 (or X448) in X.509 certificates.
  - throw0101a 6y ago
    > I don't think there's widespread support for X25519 (or X448) in X.509 certificates. The 2018 RFC if anyone is wondering: * https://tools.ietf.org/html/rfc8410 https://tools.ietf.org/html/rfc8410
    - tialaramex 6y ago
      Note that this document is (of course) not an implementation, or even an explanation of how to implement support for this, but only a description of how to spell X25519 in ASN.1 in order to write it into a PKIX X.509 certificate. So this document is a precursor to widespread support for X25519 in certificates only in the same way that coming up with a name for your kid is a precursor to giving birth. It's not strictly necessary, and it's certainly not the most important thing you needed to do, but I guess it can be part of the process.
      - GoblinSlayer 6y ago
        Huh? It doesn't write all the code for you, but it is an explanation, even provides an example of full certificate.
        tialaramex 6y ago
barkingcat 6y ago
the very nature of a backdoor prevents you from knowing the answer to your threat model questions. If no-one knows what kind of backdoor it is, how does anyone know how the attack works? The only sane approach is to assume all of the above.
- schoen 6y ago
  I disagree: DJB and others have researched how backdoors in elliptic-curve cryptography (and other algorithms) could work. In Dual_EC_DRBG we even know exactly how they would work. While I don't believe there's any publication that explains the exact mathematics of a backdoor that could have been used in the NIST curves, I think the likely algorithmic consequences for EC security assumptions probably are understood -- just not by me. :-)

by schoen 6y ago

coder543 6y ago

> Yes, there isn't adequate browser (or other client) support to use Curve25519 signatures in a public CA's certificate. I'm not so sure about that. https://en.wikipedia.org/wiki/Curve25519#History https://en.wikipedia.org/wiki/Curve25519#History "Also in 2018, RFC 8446 was published as the new Transport Layer Security v1.3 standard. It requires mandatory support for X25519, Ed25519, X448, and Ed448 algorithms.[24]" I haven't confirmed this myself, but it seems like anything that supports TLS 1.3 (a lot of things, relatively speaking) supports both curve25519 and curve448. > Another thing I don't understand is what the threat model looks like for applying hypothetically backdoored curves. Maybe this article can provide some insight into what people are concerned about: https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG Obviously, no one has proof that the NIST curves are backdoored, so who knows what kind of backdoor they would have? No one really wants to find out the hard way, though.

nicoburns 6y ago
> but it seems like anything that supports TLS 1.3 (a lot of things, relatively speaking) A lot of things, but probably not enough things for a certificate authority that has to support pretty much everything in widespread use to use.
- coder543 6y ago
  Could a certificate authority not have several root certificates? I really don't see any reason they would have to have only one root certificate. They could let people choose what kind of certificate they want issued to them, and the default could be whichever is most widely supported or whatever.
  - CydeWeys 6y ago
    Supporting a variety of options instead of just doing one thing has its own costs in terms of added complexity and maintenance. Maybe they thought about it and decided it wasn't worth it, at least not for now. There's nothing prohibiting them from offering more curves in the future.
  - aaronmdjones 6y ago
    People can already choose what kind of certificate they want issued to them, because the CA does not generate your private keys. Them giving you a certificate with an RSA public key in it is impossible if you submit a Certificate Signing Request with an ECDSA public key in it (or vice versa). Then it's only down to what intermediate certificate you want to serve. That's the constraining factor; since you don't get to choose which private key the CA signs your certificate with, you have to use the intermediate certificate whose public key corresponds to the private key that made that signature. The sensible thing for a CA to do is to sign with (and supply) an ECDSA intermediate if they get handed an ECDSA CSR, and an RSA intermediate if they get handed an RSA CSR. I imagine this is what Let's Encrypt does already.
    - tialaramex 6y ago
      It can't be what they do already because Let's Encrypt does not currently operate an ECDSA intermediate. This document describes a hierarchy they've just recently issued, and which is not yet in production use. If you present a CSR for an ECDSA public key today, Let's Encrypt will issue a certificate signed by their RSA intermediate Let's Encrypt Authority X3, for your ECDSA key. They haven't actually specified whether you'll get certificates in the new ECDSA hierarchy from the same API endpoint or need to use a different endpoint.
toast0 6y ago
> "Also in 2018, RFC 8446 was published as the new Transport Layer Security v1.3 standard. It requires mandatory support for X25519, Ed25519, X448, and Ed448 algorithms.[24]" This is oversold, if not simply factually incorrect. RFC 8446 says > A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A TLS-compliant application MUST support key exchange with secp256r1(NIST P-256) and SHOULD support key exchange with X25519 x448 is not mandatory. x25519 is not mandatory, it's only a SHOULD. In addition, key exchange is for diffie-hellman ephemeral keys; that's separate from the keys used in the certificate. I don't think there's widespread support for X25519 (or X448) in X.509 certificates.
- throw0101a 6y ago
  > I don't think there's widespread support for X25519 (or X448) in X.509 certificates. The 2018 RFC if anyone is wondering: * https://tools.ietf.org/html/rfc8410 https://tools.ietf.org/html/rfc8410
  - tialaramex 6y ago
    Note that this document is (of course) not an implementation, or even an explanation of how to implement support for this, but only a description of how to spell X25519 in ASN.1 in order to write it into a PKIX X.509 certificate. So this document is a precursor to widespread support for X25519 in certificates only in the same way that coming up with a name for your kid is a precursor to giving birth. It's not strictly necessary, and it's certainly not the most important thing you needed to do, but I guess it can be part of the process.
    - GoblinSlayer 6y ago
      Huh? It doesn't write all the code for you, but it is an explanation, even provides an example of full certificate.
      - tialaramex 6y ago

barkingcat 6y ago

the very nature of a backdoor prevents you from knowing the answer to your threat model questions. If no-one knows what kind of backdoor it is, how does anyone know how the attack works? The only sane approach is to assume all of the above.

schoen 6y ago
I disagree: DJB and others have researched how backdoors in elliptic-curve cryptography (and other algorithms) could work. In Dual_EC_DRBG we even know exactly how they would work. While I don't believe there's any publication that explains the exact mathematics of a backdoor that could have been used in the NIST curves, I think the likely algorithmic consequences for EC security assumptions probably are understood -- just not by me. :-)