44 ms·

On the first point: quite a few DNSSEC records use ECC keys, and have for a while. If your hypothesis holds, why not switch the root 2048 bit RSA keys, and thos

by akerl_ 8y ago

On the first point: quite a few DNSSEC records use ECC keys, and have for a while. If your hypothesis holds, why not switch the root 2048 bit RSA keys, and those TLD-level 1024 bit keys, for ECC keys? On the second: MD5 is one example, but the browser blacklists SHA1 as well. It also blacklists CAs that behaved poorly in the past, and refuses to use vulnerable ciphers.

teddyh 8y ago
> why not switch the root 2048 bit RSA keys, and those TLD-level 1024 bit keys, for ECC keys? Because this is the first time they ever switched the root key, and they want to observe the effects a bit more first? My prediction assumes that it works and sufficient time will pass. Also, ECC keys are not yet as widely supported by resolvers as RSA keys are. This, too, will require experimentations and time for conversion to be viable.
- tptacek 8y ago
  You're conceding a huge problem with DNSSEC. Yes, support for ECC isn't great. Either RIPE or APNIC was tracking it and last I saw something like 1/3 of the deployed base can't handle it, meaning effectively that everyone is stuck with the lowest common denominator of RSA and ECDSA. Meanwhile: the p-curve ECDSA that we're talking about seeing deployed is already very outmoded. And, unlike RSA PKCS1v15 signatures, where the concerns are theoretical and not practical, P-curve ECDSA is practically problematic. It could take a decade to get to the 2018 standard for curve security (presumably, a Schnorr-like construction on a curve like 25519). Meanwhile: nobody relies on DNSSEC today. I'm not kidding when I say the root keys could land on Pastebin tonight and almost nobody would have to work late or even get paged. Doesn't it seem just sort of plainly obvious that we should drop a flag on the broken protocol we're looking at now and re-do it properly with modern cryptography?
  - deleted 8y ago
    [deleted]
  - teddyh 8y ago
    > Doesn't it seem just sort of plainly obvious that we should drop a flag on the broken protocol we're looking at now and re-do it properly with modern cryptography? What makes you think that people will support this hypothetical new protocol faster than adding support for good crypto types in DNSSEC? I mean, is that really what you are suggesting as the proper course of action? Throw away DNSSEC and have nothing replacing it until a new protocol is standardized and implemented as widely?
    - tptacek 8y ago
      Because alternative approaches have been deployed far faster than DNSSEC. The obvious example to point to would be DoH. Yes: we should throw away DNSSEC and have nothing replace it until something better is available. Nobody relies on DNSSEC today! I feel like that point just isn't sinking in with you. Take some time and consider its impact. 25+ years after the work started: nobody relies on DNSSEC at all. DNSSEC simply does not matter right now. That's not hyperbole; it's a statement of fact.

by akerl_ 8y ago

teddyh 8y ago

> why not switch the root 2048 bit RSA keys, and those TLD-level 1024 bit keys, for ECC keys? Because this is the first time they ever switched the root key, and they want to observe the effects a bit more first? My prediction assumes that it works and sufficient time will pass. Also, ECC keys are not yet as widely supported by resolvers as RSA keys are. This, too, will require experimentations and time for conversion to be viable.

tptacek 8y ago
You're conceding a huge problem with DNSSEC. Yes, support for ECC isn't great. Either RIPE or APNIC was tracking it and last I saw something like 1/3 of the deployed base can't handle it, meaning effectively that everyone is stuck with the lowest common denominator of RSA and ECDSA. Meanwhile: the p-curve ECDSA that we're talking about seeing deployed is already very outmoded. And, unlike RSA PKCS1v15 signatures, where the concerns are theoretical and not practical, P-curve ECDSA is practically problematic. It could take a decade to get to the 2018 standard for curve security (presumably, a Schnorr-like construction on a curve like 25519). Meanwhile: nobody relies on DNSSEC today. I'm not kidding when I say the root keys could land on Pastebin tonight and almost nobody would have to work late or even get paged. Doesn't it seem just sort of plainly obvious that we should drop a flag on the broken protocol we're looking at now and re-do it properly with modern cryptography?
- deleted 8y ago
  [deleted]
- teddyh 8y ago
  > Doesn't it seem just sort of plainly obvious that we should drop a flag on the broken protocol we're looking at now and re-do it properly with modern cryptography? What makes you think that people will support this hypothetical new protocol faster than adding support for good crypto types in DNSSEC? I mean, is that really what you are suggesting as the proper course of action? Throw away DNSSEC and have nothing replacing it until a new protocol is standardized and implemented as widely?
  - tptacek 8y ago
    Because alternative approaches have been deployed far faster than DNSSEC. The obvious example to point to would be DoH. Yes: we should throw away DNSSEC and have nothing replace it until something better is available. Nobody relies on DNSSEC today! I feel like that point just isn't sinking in with you. Take some time and consider its impact. 25+ years after the work started: nobody relies on DNSSEC at all. DNSSEC simply does not matter right now. That's not hyperbole; it's a statement of fact.