5 ms·

> The [BGP hijacking] solution we intend to deploy in 2019 is multi-perspective validation, in which we will check from multiple network perspectives (distinct

> The [BGP hijacking] solution we intend to deploy in 2019 is multi-perspective validation, in which we will check from multiple network perspectives (distinct Autonomous Systems). This is really exciting. The CloudFlare BGP hijack and subsequent attack of myetherwallet.com could have been much more successful if they had also been able to get a valid certificate. Having this multi perspective feature would make it even harder to get a valid cert during a BGP hack. Of course those falsely attained certs would still be logged publicly in a certificate transparency log- but better the cert never gets created to start with. > We had planned to add ECDSA root and intermediate certificates in 2018 but other priorities ultimately took precedence. I was particularly looking forward to ECDSA. Not for any real reasons other then I want to try it out. I currently have their 4096 bit RSA cert on a raspberry pi and the SSL negotiation is particularly slow according to Newrelic. Im curious to see how EDSA performs on a raspberry pi.

tialaramex 8y ago
You would get a significant speed-up just going to 2048 bits RSA. EC would be even faster but slightly more work. You don't need 4096, unless somehow your Raspberry Pi is the target for a powerful adversary and you don't rotate the keys (like a CA). The Let's Encrypt defaults auto-rotate keys on each renewal. Note however that you can go to EC today. Your device doesn't care about the CA keys, so those still being 4096 bit RSA makes no major difference to you.
- schoen 8y ago
  > You don't need 4096, unless somehow your Raspberry Pi is the target for a powerful adversary and you don't rotate the keys (like a CA). See https://github.com/certbot/certbot/issues/2080 https://github.com/certbot/certbot/issues/2080 for some long debate and my most recent thinking about this. (I predict some discussion about this at Real World Cryptography in January, if only because I'm likely to ask some real cryptographers for their opinions there.)
- duskwuff 8y ago
  > Your device doesn't care about the CA keys, so those still being 4096 bit RSA makes no major difference to you. Your device does care about the CA keys, because it has to validate the certificate chain. But the Let's Encrypt CA uses a 2048-bit RSA key, regardless of the size of the key you're using.
  - move-on-by 8y ago
    Yes, this is why I haven’t bothered with the current EDCSA support. As for the 4096 bit cert on my Raspberry Pi- this is more fun interest then actual concern someone is trying to break my static site
  - tialaramex 8y ago
    The client cares but the server needn't, and since they're saying it needs a certificate from Lets Encrypt I presumed it's a server. For a server the certificates are just a pile of bits to be transmitted. Server software could be introspective but in general it isn't, e.g. it doesn't do AIA chasing. But you're correct that I had misremembered the root as being 4096 bit and it's actually 2048.
Avamander 8y ago
One thing that massively sped up serving content on my RPi was precompressing everything static and disabling on-the-fly compression. I'd also be more exited about getting EdDSA leaf certificates than ECDSA.

tialaramex 8y ago

You would get a significant speed-up just going to 2048 bits RSA. EC would be even faster but slightly more work. You don't need 4096, unless somehow your Raspberry Pi is the target for a powerful adversary and you don't rotate the keys (like a CA). The Let's Encrypt defaults auto-rotate keys on each renewal. Note however that you can go to EC today. Your device doesn't care about the CA keys, so those still being 4096 bit RSA makes no major difference to you.

schoen 8y ago
> You don't need 4096, unless somehow your Raspberry Pi is the target for a powerful adversary and you don't rotate the keys (like a CA). See https://github.com/certbot/certbot/issues/2080 https://github.com/certbot/certbot/issues/2080 for some long debate and my most recent thinking about this. (I predict some discussion about this at Real World Cryptography in January, if only because I'm likely to ask some real cryptographers for their opinions there.)
duskwuff 8y ago
> Your device doesn't care about the CA keys, so those still being 4096 bit RSA makes no major difference to you. Your device does care about the CA keys, because it has to validate the certificate chain. But the Let's Encrypt CA uses a 2048-bit RSA key, regardless of the size of the key you're using.
- move-on-by 8y ago
  Yes, this is why I haven’t bothered with the current EDCSA support. As for the 4096 bit cert on my Raspberry Pi- this is more fun interest then actual concern someone is trying to break my static site
- tialaramex 8y ago
  The client cares but the server needn't, and since they're saying it needs a certificate from Lets Encrypt I presumed it's a server. For a server the certificates are just a pile of bits to be transmitted. Server software could be introspective but in general it isn't, e.g. it doesn't do AIA chasing. But you're correct that I had misremembered the root as being 4096 bit and it's actually 2048.

Avamander 8y ago

One thing that massively sped up serving content on my RPi was precompressing everything static and disabling on-the-fly compression. I'd also be more exited about getting EdDSA leaf certificates than ECDSA.