3 ms·

Also, the web ‘public suffix list’ should be a DNS property instead. Unfortunately the public suffix list has serious security implications, so it isn't safe t

Also, the web ‘public suffix list’ should be a DNS property instead. Unfortunately the public suffix list has serious security implications, so it isn't safe to distribute it via unauthenticated DNS. It also has very serious availability implications, so if you sign it with the WebPKI-maximum validity of 90 days and somehow and those signatures expire, you either get major vulnerabilities if you fail open or else an entire TLD (like ".com") breaks if you fail closed. You get to play this game every 90 days. Sounds like fun. https://www.digicert.com/blog/chromes-proposed-90-day-certificate-validity-period https://www.digicert.com/blog/chromes-proposed-90-day-certif... This is the fundamental problem with trying to have DNSSEC replace DNS (instead of augmenting it): signature revocation is Byzantine-Generals-complete, which means that you either sign something forever (like ssh keys) or for a fixed time period and treat nonrenewal as revocation. Nonrenewal-as-revocation sorta works for signing single domains; if one website's cert expires it isn't the end of the world. When you start trying to sign larger and larger fractions of the Domain Name space, moving up to ccTLDs and then the root, the stakes are just way too high. This is why DNSSEC will never displace unauthenticated DNS. The choices are to stick with unauthenticated DNS, or maintain both systems in parallel forever. There is no third option where unsigned DNS records just go away.

cryptonector 3y ago
> This is the fundamental problem with trying to have DNSSEC replace DNS (instead of augmenting it): DNSSEC does not replace DNS. DNSSEC augments DNS. > [stuff about revocation] Much of what you wrote there is erroneous: > [..] you either sign something forever (like ssh keys) or for a fixed time period and treat nonrenewal as revocation. In DNSSEC you revoke by publishing new public keys in a DS record at the delegation and deleting the old public keys, also at the delegation. No need to worry about expiration -- the DS record has none. There is no expiration in the DS record but that's not "you sign something forever" because the DS record is signed by an RRSIG record that has an expiration. Zone operators have to re-sign RRSIG records, but that's not really a problem. So revocation in DNSSEC is easy, and you can do it as often as the TTL on the DS RR allows. Revocation in PKI is much harder, unless one just goes for short-lived certificates. By automating certificate renewal operations, Let's Encrypt is doing the world a favor, as it will allow servers to have very short-lived certificates, thus eliding the need for revocation (and keeping CRLs small if recovation is still needed). > [...] if one website's cert expires it isn't the end of the world. When you start trying to sign larger and larger fractions of the Domain Name space, moving up to ccTLDs and then the root, the stakes are just way too high. Now this is true but it shouldn't be any more likely than other whole-domain outage failure modes of DNS. If you publish the wrong DS records at the delegation, your domain will be out -- don't do that! That's like publishing the wrong NS records at the delegation. The delegator can also break the delegation on their own, but they can do that w/o DNSSEC too, so you're no more and no less at their mercy w/ or w/o DNSSEC. And if you fail to re-sign your zones, you'll have some outages. In practice the right way to do the last is to sign dynamically in your DNS servers using ECC and with some caching, naturally. > This is why DNSSEC will never displace unauthenticated DNS. > > The choices are [...] The predicate is erroneous, so the conclusion doesn't follow from it. It might follow from other issues, but not the ones you stated.
- crotchfire 3y ago
  > No need to worry about expiration -- the DS record has none. > the DS record is signed by an RRSIG record that has an expiration You've just contradicted yourself. > No need to worry about expiration If that were true, which it isn't, a MITM could keep feeding old signatures to the victim. You seem to have little idea what you're talking about.
  - cryptonector 3y ago
    > > No need to worry about expiration -- the DS record has none. > > the DS record is signed by an RRSIG record that has an expiration > You've just contradicted yourself. No contradiction there. I said that the DS RR doesn't have an expiration, and that's correct. The RRSIG RR has an expiration, but because the custom is that the zone operator resigns the contents periodically, it's a non-issue. The child delegation's operator doesn't have to take special action to have their DS "renewed", they only have to take special action to rotate the child zone's public keys. You don't have to worry about expiration because the parent should keep re-signing their zone. The expiration allows you to "revoke" by telling the parent the new keys and then delete the DS RRs for the old keys at a convenient time.

cryptonector 3y ago

> This is the fundamental problem with trying to have DNSSEC replace DNS (instead of augmenting it): DNSSEC does not replace DNS. DNSSEC augments DNS. > [stuff about revocation] Much of what you wrote there is erroneous: > [..] you either sign something forever (like ssh keys) or for a fixed time period and treat nonrenewal as revocation. In DNSSEC you revoke by publishing new public keys in a DS record at the delegation and deleting the old public keys, also at the delegation. No need to worry about expiration -- the DS record has none. There is no expiration in the DS record but that's not "you sign something forever" because the DS record is signed by an RRSIG record that has an expiration. Zone operators have to re-sign RRSIG records, but that's not really a problem. So revocation in DNSSEC is easy, and you can do it as often as the TTL on the DS RR allows. Revocation in PKI is much harder, unless one just goes for short-lived certificates. By automating certificate renewal operations, Let's Encrypt is doing the world a favor, as it will allow servers to have very short-lived certificates, thus eliding the need for revocation (and keeping CRLs small if recovation is still needed). > [...] if one website's cert expires it isn't the end of the world. When you start trying to sign larger and larger fractions of the Domain Name space, moving up to ccTLDs and then the root, the stakes are just way too high. Now this is true but it shouldn't be any more likely than other whole-domain outage failure modes of DNS. If you publish the wrong DS records at the delegation, your domain will be out -- don't do that! That's like publishing the wrong NS records at the delegation. The delegator can also break the delegation on their own, but they can do that w/o DNSSEC too, so you're no more and no less at their mercy w/ or w/o DNSSEC. And if you fail to re-sign your zones, you'll have some outages. In practice the right way to do the last is to sign dynamically in your DNS servers using ECC and with some caching, naturally. > This is why DNSSEC will never displace unauthenticated DNS. > > The choices are [...] The predicate is erroneous, so the conclusion doesn't follow from it. It might follow from other issues, but not the ones you stated.

crotchfire 3y ago
> No need to worry about expiration -- the DS record has none. > the DS record is signed by an RRSIG record that has an expiration You've just contradicted yourself. > No need to worry about expiration If that were true, which it isn't, a MITM could keep feeding old signatures to the victim. You seem to have little idea what you're talking about.
- cryptonector 3y ago
  > > No need to worry about expiration -- the DS record has none. > > the DS record is signed by an RRSIG record that has an expiration > You've just contradicted yourself. No contradiction there. I said that the DS RR doesn't have an expiration, and that's correct. The RRSIG RR has an expiration, but because the custom is that the zone operator resigns the contents periodically, it's a non-issue. The child delegation's operator doesn't have to take special action to have their DS "renewed", they only have to take special action to rotate the child zone's public keys. You don't have to worry about expiration because the parent should keep re-signing their zone. The expiration allows you to "revoke" by telling the parent the new keys and then delete the DS RRs for the old keys at a convenient time.