6 ms·

1. Why? An unqualified blanket statement does not prove anything. SPF, DKIM, DMARC provide strong cryptographical ties to a specific, real, and verified accoun

1. Why? An unqualified blanket statement does not prove anything. SPF, DKIM, DMARC provide strong cryptographical ties to a specific, real, and verified account holder. DNSSEC provides domain level certification. So, with all four items, there is a very strong assurance level of the validity of the email account holder. Do you honestly disagree? 2. Can DNSSEC be re-directed to incorrect public keys? Sure. But DNS can be pointed anywhere anyway. DNSSEC does no extra damage. And exploitation of DNSSEC enabled domain records is very easily discoverable by the domain holder, since the public key will no longer match the domain's private key... which is still very much in the domain owner's control. 3. Much of cryptography dates to the 1950s. This '90s cryptography stuff is pure nonsense. 4. Only if you don't value the hard work by many smart people over a long time. 5. OK. Denial of service is a bad thing. If you have a worldwide network, you are going to have denial of service. Mitigation is possible... maybe instead of throwing out other people's work, some resources could be used to improve what's already out there... ah... but then back #4. 6. Yes it is. 7. Revealing hostnames is only a problem if a domain is seeking to hide hosts. So, this particular issue is domain level dependent -- why not let a domain owner speak for him/her self? 8. Again with the 'old' is bad 'new' is better? Got anything else? 9. Wrong. SSH public keys, Email public keys, DKIM public keys... check your email headers from Google... they all have "unprotected key" because Google doesn't use DNSSEC -- the large provider host hiding problem is most likely why. However, for a small domain, DNSSEC is terrific.

tptacek 12y ago
1. Because SMTP email transmits unencrypted messages through a series of insecure relay servers. SMTP is insecure. The protocols you mentioned are band-aids that do not result in SMTP being end-to-end secure. But that's what SMTP needs to be if all of Internet security is going to rely on it to authenticate keys. 2. The point of argument #2 is that the government's ability to poison the DNS makes it unsuitable for storing end-user keys, which, no matter what the DNSSEC deployment goal you have in mind is, is the core function of DNSSEC. 3. Elliptic curve cryptography is from the 1980s. Secure elliptic curve functions take you to the early 2000s. Authenticated encryption functions are late 90s early 2000s. The first error oracle attack was published in the early 2000s; practically all cryptography designed prior to that was designed ignorant to the concept of an error oracle. I could go on. 4. That's not an argument. 5. The problem with DNSSEC isn't that it makes DDoS attackers easier, although it does. The problem is DNSSEC spontaneously kills sites because it is calamitously easy to screw up, because it is very complicated. 6. That's not an argument either. 7. Virtually every Fortune 500 company on the Internet currently depends on some way on hidden hostnames. You more or less admit that this is a real problem when you cite NSEC5 as a step forward; it would be unnecessary if you were right that hidden hostnames were unimportant. 8. Non sequitur. 9. I'm not smart enough to understand what this argument means.
- danyork 12y ago
  > 9. I'm not smart enough to understand what this argument means. Thomas, I _think_ you are replying to this: > 9. Wrong. SSH public keys, Email public keys, DKIM public keys... check your email headers from Google... they all have "unprotected key" because Google doesn't use DNSSEC -- the large provider host hiding problem is most likely why. With which I'll agree with jocluteseh that the value DNSSEC can bring is far larger than only TLS certificates - although I agree with you that protection of TLS certs is one value it brings. There are people using DNS/DNSSEC to secure the storage of SSH public keys, of PGP public keys and other similar public keys. People are putting those keys in DNS and then using DNSSEC to ensure that someone retrieving those keys and performing DNSSEC validation can be sure they are getting the correct keys associated with that domain.
  - tptacek 12y ago
    Why on earth would anyone store SSH keys in a PKI controlled by NSA and GCHQ? How does that not make the argument against DNSSEC even stronger?
    - pyre 12y ago
      To expand on this. If you store your public SSH key in DNSSEC, I'm assuming that the use-case is either: 1. Pull the public key from DNS to add to ~/.ssh/authorized_keys 2. Implement an sshd runtime that checks the DNS record rather then (or in addition to) ~/.ssh/authorized_keys Sure, it's "just" the public key so you're not providing the private key to the world-at-large, but if the NSA controls DNSSEC, then they can change the public key to one that is paired with a private key that they control. Now they have access to all systems that the public key could access. This is basically adding DNSSEC as an attack vector to your ~/.ssh/authorized_keys file, which seems like a bad idea. Please correct me if I'm missing something about how DNSSEC and SSH keys would be used together.
      - danyork 12y ago
        The idea would be to enable you to verify the public key of a server to which you are connecting for the first time. RFC 4255 outlines this use case: http://tools.ietf.org/html/rfc4255 http://tools.ietf.org/html/rfc4255 When you first connect and get the SSH fingerprint, how many people truly validate through some other mechanism that this is the correct public key to use for some system? (I have on some systems but I know I have just accepted the public key on other systems.) The idea is to use DNSSEC and the SSHFP record to provide a mechanism to validate the SSH public key. Do note this is not a new idea. This RFC was published back in 2006.
jocluteseh 12y ago
1.a.1 I think this is your main fault. You are assuming that end-to-end encrypted message content is equatable to 'insecure' SMTP. The clear text or encrypted content of an email message has nothing to do with validating that an email account belongs to a domain and is valid. SPF validates that the email account holder is valid. DKIM signs the message and provides a body hash which is validated against the public key in DNS. DMARC allows the domain owner to say that the message should trashed or passed. And DNSSEC allows the DNS root to say that the sending domain is the sending domain. So -- I repeat -- with SPF, DKIM, DMARC, and DNSSEC email validated CA certificates are quite secure. And, yet, you are unwilling to admit this... I suggest you read the DKIM RFCs, particularly RFC5585 "2.3. Establishing Message Validity Though man-in-the-middle attacks are historically rare in email, it is nevertheless theoretically possible for a message to be modified during transit. An interesting side effect of the cryptographic method used by DKIM is that it is possible to be certain that a signed message (or, if l= is used, the signed portion of a message) has not been modified between the time of signing and the time of verifying. If it has been changed in any way, then the message will not be verified successfully with DKIM."
- pyre 12y ago
  While I don't purport myself to be a crypto expert, you can't cite an RFC of a protocol as "proof" that something is secure. For example, if people come up with attacks against DKIM after the RFC is created, they don't issue an errata on the RFC listing all possible attacks.
- deleted 12y ago
  [deleted]
- rakoo 12y ago
  > DKIM signs the message and provides a body hash which is validated against the public key in DNS And how do you make sure the public key is correct then ? Well, just use DNSSEC !

tptacek 12y ago

1. Because SMTP email transmits unencrypted messages through a series of insecure relay servers. SMTP is insecure. The protocols you mentioned are band-aids that do not result in SMTP being end-to-end secure. But that's what SMTP needs to be if all of Internet security is going to rely on it to authenticate keys. 2. The point of argument #2 is that the government's ability to poison the DNS makes it unsuitable for storing end-user keys, which, no matter what the DNSSEC deployment goal you have in mind is, is the core function of DNSSEC. 3. Elliptic curve cryptography is from the 1980s. Secure elliptic curve functions take you to the early 2000s. Authenticated encryption functions are late 90s early 2000s. The first error oracle attack was published in the early 2000s; practically all cryptography designed prior to that was designed ignorant to the concept of an error oracle. I could go on. 4. That's not an argument. 5. The problem with DNSSEC isn't that it makes DDoS attackers easier, although it does. The problem is DNSSEC spontaneously kills sites because it is calamitously easy to screw up, because it is very complicated. 6. That's not an argument either. 7. Virtually every Fortune 500 company on the Internet currently depends on some way on hidden hostnames. You more or less admit that this is a real problem when you cite NSEC5 as a step forward; it would be unnecessary if you were right that hidden hostnames were unimportant. 8. Non sequitur. 9. I'm not smart enough to understand what this argument means.

danyork 12y ago
> 9. I'm not smart enough to understand what this argument means. Thomas, I _think_ you are replying to this: > 9. Wrong. SSH public keys, Email public keys, DKIM public keys... check your email headers from Google... they all have "unprotected key" because Google doesn't use DNSSEC -- the large provider host hiding problem is most likely why. With which I'll agree with jocluteseh that the value DNSSEC can bring is far larger than only TLS certificates - although I agree with you that protection of TLS certs is one value it brings. There are people using DNS/DNSSEC to secure the storage of SSH public keys, of PGP public keys and other similar public keys. People are putting those keys in DNS and then using DNSSEC to ensure that someone retrieving those keys and performing DNSSEC validation can be sure they are getting the correct keys associated with that domain.
- tptacek 12y ago
  Why on earth would anyone store SSH keys in a PKI controlled by NSA and GCHQ? How does that not make the argument against DNSSEC even stronger?
  - pyre 12y ago
    To expand on this. If you store your public SSH key in DNSSEC, I'm assuming that the use-case is either: 1. Pull the public key from DNS to add to ~/.ssh/authorized_keys 2. Implement an sshd runtime that checks the DNS record rather then (or in addition to) ~/.ssh/authorized_keys Sure, it's "just" the public key so you're not providing the private key to the world-at-large, but if the NSA controls DNSSEC, then they can change the public key to one that is paired with a private key that they control. Now they have access to all systems that the public key could access. This is basically adding DNSSEC as an attack vector to your ~/.ssh/authorized_keys file, which seems like a bad idea. Please correct me if I'm missing something about how DNSSEC and SSH keys would be used together.
    - danyork 12y ago
      The idea would be to enable you to verify the public key of a server to which you are connecting for the first time. RFC 4255 outlines this use case: http://tools.ietf.org/html/rfc4255 http://tools.ietf.org/html/rfc4255 When you first connect and get the SSH fingerprint, how many people truly validate through some other mechanism that this is the correct public key to use for some system? (I have on some systems but I know I have just accepted the public key on other systems.) The idea is to use DNSSEC and the SSHFP record to provide a mechanism to validate the SSH public key. Do note this is not a new idea. This RFC was published back in 2006.

jocluteseh 12y ago

1.a.1 I think this is your main fault. You are assuming that end-to-end encrypted message content is equatable to 'insecure' SMTP. The clear text or encrypted content of an email message has nothing to do with validating that an email account belongs to a domain and is valid. SPF validates that the email account holder is valid. DKIM signs the message and provides a body hash which is validated against the public key in DNS. DMARC allows the domain owner to say that the message should trashed or passed. And DNSSEC allows the DNS root to say that the sending domain is the sending domain. So -- I repeat -- with SPF, DKIM, DMARC, and DNSSEC email validated CA certificates are quite secure. And, yet, you are unwilling to admit this... I suggest you read the DKIM RFCs, particularly RFC5585 "2.3. Establishing Message Validity Though man-in-the-middle attacks are historically rare in email, it is nevertheless theoretically possible for a message to be modified during transit. An interesting side effect of the cryptographic method used by DKIM is that it is possible to be certain that a signed message (or, if l= is used, the signed portion of a message) has not been modified between the time of signing and the time of verifying. If it has been changed in any way, then the message will not be verified successfully with DKIM."

pyre 12y ago
While I don't purport myself to be a crypto expert, you can't cite an RFC of a protocol as "proof" that something is secure. For example, if people come up with attacks against DKIM after the RFC is created, they don't issue an errata on the RFC listing all possible attacks.
deleted 12y ago
[deleted]
rakoo 12y ago
> DKIM signs the message and provides a body hash which is validated against the public key in DNS And how do you make sure the public key is correct then ? Well, just use DNSSEC !