4 ms·

Why? They solve different problems. DNSSEC/DANE moves the TLS CA into the hands of the DNS hierarchy from various corporations. STS just says to use TLS (with t

Why? They solve different problems. DNSSEC/DANE moves the TLS CA into the hands of the DNS hierarchy from various corporations. STS just says to use TLS (with this cert, but you can only know the cert is OK to begin with because of a CA, or DANE).

yuhong 11y ago
DNSSEC however has its own problems. I have been thinking of a DNSSEC2 proposal for a while now that for example would use online signing only.
- mned 11y ago
  Having no support for offline signing in and of itself isn't a selling point. What else does your approach have to offer?
  - yuhong 11y ago
    It is a selling point in that it simplifies the protocol, making it easier to implement. Obviously it would not be the only difference.
    - mned 11y ago
      > It is a selling point in that it simplifies the protocol, making it easier to implement. In the current protocol the only difference between offline and online signing is in how authoritative servers are implemented. There the differences aren't all that significant (relative to building an authoritative server as a whole) -- the same data needs signing, etc -- so please explain how your protocol makes implementation simpler. > Obviously it would not be the only difference. Can you please expand on that? You've said you've been thinking of a DNSSEC2 proposal for a while so you must have more to say.
      - yuhong 11y ago
        I forgot to mention that one of the known problems of DNSSEC is the DNS zone information disclosure problem. Online signing would allow the problem to be eliminated and reduce complexity by the protocol no longer having to be designed for enumerating DNS records. Of course, DNSSEC2 would probably only allow ECC signing too (I suggest both NIST curves and Curve25519 as options).
        mned 11y ago
        Online signing and white lies are already in DNSSEC. What you've described so far doesn't seem to be different to the status quo. Even deprecation of older cryptographic signatures is being worked through at the moment.
        yuhong 11y ago
        I know about this. That is why I mentioned the complexity that comes from the original protocol design being designed for offline signing.
        mned 11y ago
        You have said you have been thinking of a DNSSEC2 proposal for a while, that your protocol differs in multiple ways and that it is easier to implement. Given this you should be able to concretely articulate how your protocol differs and where its advantages are gained. Thus far you have not shown the ability to do this.
        yuhong 11y ago
        It is just a bunch of ideas at this point and not even a complete list of them.
- sdkmvx 11y ago
  The DNS root servers need offline signing. Many servers are in untrusted areas (think intervention from local government).
  - yuhong 11y ago
    I think DNSSEC already deals with this by offline signing another key that actually signs the DNS root zone.
tptacek 11y ago
Because the only remaining reason to deploy DNSSEC is to exploit DANE to allow SMTP MTAs to force TLS. All the other uses of DNSSEC are already DOA. It's a little tricky to explain why this is the case without getting into a lot of gritty detail. A shorthand answer is that browser vendors have, pretty much as a group, decided not to adopt DANE (the DNSSEC-based alternative to the X.509 CA system), and DANE is the only reason anyone cares about DNS security on an Internet where everything is going to be encrypted (usually with TLS) by default.
- colanderman 11y ago
  Is SSHFP not a legitimate use case for DNSSEC? (Genuinely curious.)
  - stephenr 11y ago
    It absolutely is a legitimate use case, and would IMO improve security for the type of developers who do use SSH, but don't know what a fingerprint is. It would also make it easier to create secure connections for non-developers, e.g. a SFTP/SCP based file sync app.
  - tptacek 11y ago
    No, SSHFP is pretty silly as a motivating use case for DNSSEC. There's nothing it does that you can't do (better!) with some other system. It makes sense if you already have a secure DNS. But that begs the question of why you would need a secure DNS. You don't need a secure DNS for the web. You don't, with STS deployed, need a secure DNS for email. Is publishing SSH key fingerprints so important that we should do a forklift upgrade of the DNS? No, of course not.
    - AndyMcConachie 11y ago
      STS information is stored in DNS records. Why would you not want to secure those? Also, I think you're underestimating the growth of DNSSEC deployments. I've been watching DNSSEC growth for about 2 years and it is steadily moving up and to the right.

yuhong 11y ago

DNSSEC however has its own problems. I have been thinking of a DNSSEC2 proposal for a while now that for example would use online signing only.

mned 11y ago
Having no support for offline signing in and of itself isn't a selling point. What else does your approach have to offer?
- yuhong 11y ago
  It is a selling point in that it simplifies the protocol, making it easier to implement. Obviously it would not be the only difference.
  - mned 11y ago
    > It is a selling point in that it simplifies the protocol, making it easier to implement. In the current protocol the only difference between offline and online signing is in how authoritative servers are implemented. There the differences aren't all that significant (relative to building an authoritative server as a whole) -- the same data needs signing, etc -- so please explain how your protocol makes implementation simpler. > Obviously it would not be the only difference. Can you please expand on that? You've said you've been thinking of a DNSSEC2 proposal for a while so you must have more to say.
    - yuhong 11y ago
      I forgot to mention that one of the known problems of DNSSEC is the DNS zone information disclosure problem. Online signing would allow the problem to be eliminated and reduce complexity by the protocol no longer having to be designed for enumerating DNS records. Of course, DNSSEC2 would probably only allow ECC signing too (I suggest both NIST curves and Curve25519 as options).
      - mned 11y ago
        Online signing and white lies are already in DNSSEC. What you've described so far doesn't seem to be different to the status quo. Even deprecation of older cryptographic signatures is being worked through at the moment.
        yuhong 11y ago
        I know about this. That is why I mentioned the complexity that comes from the original protocol design being designed for offline signing.
        mned 11y ago
        You have said you have been thinking of a DNSSEC2 proposal for a while, that your protocol differs in multiple ways and that it is easier to implement. Given this you should be able to concretely articulate how your protocol differs and where its advantages are gained. Thus far you have not shown the ability to do this.
        yuhong 11y ago
        It is just a bunch of ideas at this point and not even a complete list of them.
sdkmvx 11y ago
The DNS root servers need offline signing. Many servers are in untrusted areas (think intervention from local government).
- yuhong 11y ago
  I think DNSSEC already deals with this by offline signing another key that actually signs the DNS root zone.

tptacek 11y ago

Because the only remaining reason to deploy DNSSEC is to exploit DANE to allow SMTP MTAs to force TLS. All the other uses of DNSSEC are already DOA. It's a little tricky to explain why this is the case without getting into a lot of gritty detail. A shorthand answer is that browser vendors have, pretty much as a group, decided not to adopt DANE (the DNSSEC-based alternative to the X.509 CA system), and DANE is the only reason anyone cares about DNS security on an Internet where everything is going to be encrypted (usually with TLS) by default.

colanderman 11y ago
Is SSHFP not a legitimate use case for DNSSEC? (Genuinely curious.)
- stephenr 11y ago
  It absolutely is a legitimate use case, and would IMO improve security for the type of developers who do use SSH, but don't know what a fingerprint is. It would also make it easier to create secure connections for non-developers, e.g. a SFTP/SCP based file sync app.
- tptacek 11y ago
  No, SSHFP is pretty silly as a motivating use case for DNSSEC. There's nothing it does that you can't do (better!) with some other system. It makes sense if you already have a secure DNS. But that begs the question of why you would need a secure DNS. You don't need a secure DNS for the web. You don't, with STS deployed, need a secure DNS for email. Is publishing SSH key fingerprints so important that we should do a forklift upgrade of the DNS? No, of course not.
  - AndyMcConachie 11y ago
    STS information is stored in DNS records. Why would you not want to secure those? Also, I think you're underestimating the growth of DNSSEC deployments. I've been watching DNSSEC growth for about 2 years and it is steadily moving up and to the right.