7 ms·

There is a proposed solution for this scenario: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based

by psz 12y ago

There is a proposed solution for this scenario: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na... It will allow for pinning certificates (self-signed too) to records in in DNS with DNSSEC.

ejr 12y ago
That's interesting. I hope it sees more widespread adoption by browser vendors and the recent security disclosures will hopefully help to tip implementation in that direction.
mike-cardwell 12y ago
If you're using a resolver which supports DNSSEC, and you're using Firefox with the DNSSEC-Validator addon from https://www.dnssec-validator.cz/ https://www.dnssec-validator.cz/ (which supports DANE) and you visit https://grepular.com/ https://grepular.com/, you will see a nice little green icon in the address bar to show you that DNSSEC was used, and another green icon to show you that the SSL cert was validated using DANE.
y0ghur7_xxx 12y ago
DNSSEC still relays on CAs. They were just renamed to "Trust Anchors". The trust anchor for .com is Verisign.
- kilburn 12y ago
  > DNSSEC still relays on CAs. No, DNSSEC has nothing to do with CAs. Each DNS authority defines its own keys used to sign its records. > They were just renamed to "Trust Anchors". You are thinking about DANE [1], which is what the a protocol on top of DNSSEC. Using DANE you authorize X.509 certificates and/or CAs for certain domains. This allows you to restrict your domain to a specific well-known CA (such as Verisign), but it also allows you to authorize your own CA or even a specific certificate directly. It even works per-service, so you do not need to use the same CA/certificates for all your services. If you were suggesting that DANE does not solve the traditional CA issue you are wrong. [1] http://tools.ietf.org/html/rfc6698 http://tools.ietf.org/html/rfc6698 > The trust anchor for .com is Verisign. Err.. no? I don't even understand what are you trying to say here. The "com" domain does not seem to have any TLSA records...
  - 0x0 12y ago
    >> The trust anchor for .com is Verisign. >Err.. no? I don't even understand what are you trying to say here. The "com" domain does not seem to have any TLSA records... Verisign runs the "com." zone, so I guess they would have to admin any DNSSEC/DANE/TLSA stuff.
    - kilburn 12y ago
      They only have to admin the DNSSEC stuff (publish your domain name keys along with your nameservers, as you set them up through your regular domain provider). The DANE part needs no further support than you being able to use DNSSEC for your domain's DNS. Obviously there is always some entity controling each TLD, and that entity can screw up your domain if it acts improperly.
      - schoen 12y ago
        That last property is what makes that entity a "trust anchor", and what DANE critics specifically don't like or want to get rid of.
      - tptacek 12y ago
        You're not following. DNSSEC is secured by a chain of keys leading to a root; the entity that controls the root controls the chain. If you use DNSSEC to authenticate your certificate, you're giving control over your certificate to whoever runs the roots.
      - 0x0 12y ago
        So you will have to trust Verisign not publish a different, compromised, set of domain name keys along with your nameservers.
        vertex-four 12y ago
        You have to trust them not to do that anyway right now, as they're a CA. You also have to trust any of the >100 other CAs that your system trusts.

by psz 12y ago

ejr 12y ago

That's interesting. I hope it sees more widespread adoption by browser vendors and the recent security disclosures will hopefully help to tip implementation in that direction.

mike-cardwell 12y ago

If you're using a resolver which supports DNSSEC, and you're using Firefox with the DNSSEC-Validator addon from https://www.dnssec-validator.cz/ https://www.dnssec-validator.cz/ (which supports DANE) and you visit https://grepular.com/ https://grepular.com/, you will see a nice little green icon in the address bar to show you that DNSSEC was used, and another green icon to show you that the SSL cert was validated using DANE.

y0ghur7_xxx 12y ago

DNSSEC still relays on CAs. They were just renamed to "Trust Anchors". The trust anchor for .com is Verisign.

kilburn 12y ago
> DNSSEC still relays on CAs. No, DNSSEC has nothing to do with CAs. Each DNS authority defines its own keys used to sign its records. > They were just renamed to "Trust Anchors". You are thinking about DANE [1], which is what the a protocol on top of DNSSEC. Using DANE you authorize X.509 certificates and/or CAs for certain domains. This allows you to restrict your domain to a specific well-known CA (such as Verisign), but it also allows you to authorize your own CA or even a specific certificate directly. It even works per-service, so you do not need to use the same CA/certificates for all your services. If you were suggesting that DANE does not solve the traditional CA issue you are wrong. [1] http://tools.ietf.org/html/rfc6698 http://tools.ietf.org/html/rfc6698 > The trust anchor for .com is Verisign. Err.. no? I don't even understand what are you trying to say here. The "com" domain does not seem to have any TLSA records...
- 0x0 12y ago
  >> The trust anchor for .com is Verisign. >Err.. no? I don't even understand what are you trying to say here. The "com" domain does not seem to have any TLSA records... Verisign runs the "com." zone, so I guess they would have to admin any DNSSEC/DANE/TLSA stuff.
  - kilburn 12y ago
    They only have to admin the DNSSEC stuff (publish your domain name keys along with your nameservers, as you set them up through your regular domain provider). The DANE part needs no further support than you being able to use DNSSEC for your domain's DNS. Obviously there is always some entity controling each TLD, and that entity can screw up your domain if it acts improperly.
    - schoen 12y ago
      That last property is what makes that entity a "trust anchor", and what DANE critics specifically don't like or want to get rid of.
    - tptacek 12y ago
      You're not following. DNSSEC is secured by a chain of keys leading to a root; the entity that controls the root controls the chain. If you use DNSSEC to authenticate your certificate, you're giving control over your certificate to whoever runs the roots.
    - 0x0 12y ago
      So you will have to trust Verisign not publish a different, compromised, set of domain name keys along with your nameservers.
      - vertex-four 12y ago
        You have to trust them not to do that anyway right now, as they're a CA. You also have to trust any of the >100 other CAs that your system trusts.