4 ms·

What's that even mean?

by jimktrains2 11y ago

gruez 11y ago
something like EV certificates for smtp servers?
- ryan-c 11y ago
  Certificates for SMTP servers are meaningless without DNSSEC because crossdomain email servers are a thing.
  - geofft 11y ago
    Crossdomain web hosts are also a thing, and HTTPS works fine. (Sometimes with particularly hilarious definitions of "fine", like CloudFlare's former practice of putting dozens of customers' websites in the same certificate, via subject alternative names.) If you're worried about the fact that your mail host and web host can now impersonate each other, we can just define a new X.509 extension for "I can only be used for email". You might even be able to get away adding a new option to the existing Extended Key Usage field, but it's possible that enough clients don't enforce it rigorously enough. Ideally, you'd also want an SMTP equivalent of strict transport security.
    - jimktrains2 11y ago
      SMTP can use TLS, though, right? It doesn't _have_ to use STARTTLS? You _could_ use SNI. My concern is that it doesn't get you anywhere. phishing sites can and do get TLS/SSL certificates. The process isn't particularly difficult or labour intensive if you own the domain. As far as spam goes, so what? This only proves I'm talking to the server I intended to, not that it's a reputable and upstanding member of the server society.
      - thetmkay 11y ago
        What about EV itself? Currently there's no EV equivalent for individuals, but it would be a step forward.
        jimktrains2 11y ago
        If I can't reasonably get it, then how is it a step forward?
        thetmkay 11y ago
        It would at least help companies/freelancers to host their own mailserver. The same infrastructure may lead to EV for individuals (or equivalent) once we can figure that out. Waiting for everything to be equally ready leads to inaction.
    - ryan-c 11y ago
      If someone spoofs a CNAME to evil.com in response to DNS query for google.com, your browser will not accept a certificate from evil.com as valid for google.com, whereas if you send mail to gmail.com and someone spoofs an MX record for mx.evil.com, a vaild mx.evil.com certificate will be accepted.
      - geofft 11y ago
        Right, so "don't do that." There isn't a clear standard for what subject to accept, out of the two options. The obvious correct one is to check for google.com, even if you're talking to a server named mx.google.com -- just as you don't trust CNAMEs and you check the original name, don't trust MXes either. It's just that most people don't have those certs configured in their mail servers, so doing that check today would lead to widespread failures and it's a bad default. Postfix, for instance, lets you configure what it checks via the "smtp_tls_verify_cert_match" option. If you set it to "nexthop", it'll require google.com. The default, "hostname", will check against mx.evil.com. http://www.postfix.org/postconf.5.html#smtp_tls_verify_cert_match http://www.postfix.org/postconf.5.html#smtp_tls_verify_cert_...
- jimktrains2 11y ago
  That proves I own the domain to some extent. Don't DKIM records do the same? For the purposes of anti-spam, a cert doesn't do anything except prove that you showed some CA that you own the domain (which can be done and is done in other ways currently).
  - grey-area 11y ago
    At present SMTP is so broken that arbitrary servers are allowed to send mail for any domain, with fake headers, there is no proper verification of sending server or sending identity, the mail is accepted (along with legitimate mail), and put in spam folders (sometimes, as is real mail sometimes). SPF/DKIM are an attempt to solve that of course, but they are not enforced rigorously or universally, and tactics like IP reputation and email content sniffing still seem to be widely used too (the problem reported in the article). Compared to the web, email seems pretty behind on verifying server identity.
    - jimktrains2 11y ago
      Yes, that's my point. It doesn't really solve any issues that SPF/DKIM don't already solve -- pointing to certs isn't a new solution, it's a rehash of the same solution. And yes, the concept of relays should disappear along with much of the other cruft SMTP brings. (And while we're at it, can we fix/replace IMAP, or at least make the spec say that message ids are eternal and can't be invalidated?)
      - grey-area 11y ago
        IMO Message ids should be defined as a sha512 of headers and content to ensure they are unique. A new protocol is required.
        jimktrains2 11y ago
        Currently headers get modified in-flight, so a content-based ID wouldn't work. As for a new protocol, there are some out there, but all fail in some way or another. I figured I'd throw my ideas out there and see how much they fail https://github.com/jimktrains/email_ng https://github.com/jimktrains/email_ng
grey-area 11y ago
Certs or some other method to identify servers, so that gmail etc don't attempt to use IP for server identity, which is obviously flawed. The SMTP protocol is pretty flawed itself though, so probably that needs to change to see any real progress here.

What's that even mean?

gruez 11y ago

something like EV certificates for smtp servers?

ryan-c 11y ago
Certificates for SMTP servers are meaningless without DNSSEC because crossdomain email servers are a thing.
- geofft 11y ago
  Crossdomain web hosts are also a thing, and HTTPS works fine. (Sometimes with particularly hilarious definitions of "fine", like CloudFlare's former practice of putting dozens of customers' websites in the same certificate, via subject alternative names.) If you're worried about the fact that your mail host and web host can now impersonate each other, we can just define a new X.509 extension for "I can only be used for email". You might even be able to get away adding a new option to the existing Extended Key Usage field, but it's possible that enough clients don't enforce it rigorously enough. Ideally, you'd also want an SMTP equivalent of strict transport security.
  - jimktrains2 11y ago
    SMTP can use TLS, though, right? It doesn't _have_ to use STARTTLS? You _could_ use SNI. My concern is that it doesn't get you anywhere. phishing sites can and do get TLS/SSL certificates. The process isn't particularly difficult or labour intensive if you own the domain. As far as spam goes, so what? This only proves I'm talking to the server I intended to, not that it's a reputable and upstanding member of the server society.
    - thetmkay 11y ago
      What about EV itself? Currently there's no EV equivalent for individuals, but it would be a step forward.
      - jimktrains2 11y ago
        If I can't reasonably get it, then how is it a step forward?
        thetmkay 11y ago
        It would at least help companies/freelancers to host their own mailserver. The same infrastructure may lead to EV for individuals (or equivalent) once we can figure that out. Waiting for everything to be equally ready leads to inaction.
  - ryan-c 11y ago
    If someone spoofs a CNAME to evil.com in response to DNS query for google.com, your browser will not accept a certificate from evil.com as valid for google.com, whereas if you send mail to gmail.com and someone spoofs an MX record for mx.evil.com, a vaild mx.evil.com certificate will be accepted.
    - geofft 11y ago
      Right, so "don't do that." There isn't a clear standard for what subject to accept, out of the two options. The obvious correct one is to check for google.com, even if you're talking to a server named mx.google.com -- just as you don't trust CNAMEs and you check the original name, don't trust MXes either. It's just that most people don't have those certs configured in their mail servers, so doing that check today would lead to widespread failures and it's a bad default. Postfix, for instance, lets you configure what it checks via the "smtp_tls_verify_cert_match" option. If you set it to "nexthop", it'll require google.com. The default, "hostname", will check against mx.evil.com. http://www.postfix.org/postconf.5.html#smtp_tls_verify_cert_match http://www.postfix.org/postconf.5.html#smtp_tls_verify_cert_...
jimktrains2 11y ago
That proves I own the domain to some extent. Don't DKIM records do the same? For the purposes of anti-spam, a cert doesn't do anything except prove that you showed some CA that you own the domain (which can be done and is done in other ways currently).
- grey-area 11y ago
  At present SMTP is so broken that arbitrary servers are allowed to send mail for any domain, with fake headers, there is no proper verification of sending server or sending identity, the mail is accepted (along with legitimate mail), and put in spam folders (sometimes, as is real mail sometimes). SPF/DKIM are an attempt to solve that of course, but they are not enforced rigorously or universally, and tactics like IP reputation and email content sniffing still seem to be widely used too (the problem reported in the article). Compared to the web, email seems pretty behind on verifying server identity.
  - jimktrains2 11y ago
    Yes, that's my point. It doesn't really solve any issues that SPF/DKIM don't already solve -- pointing to certs isn't a new solution, it's a rehash of the same solution. And yes, the concept of relays should disappear along with much of the other cruft SMTP brings. (And while we're at it, can we fix/replace IMAP, or at least make the spec say that message ids are eternal and can't be invalidated?)
    - grey-area 11y ago
      IMO Message ids should be defined as a sha512 of headers and content to ensure they are unique. A new protocol is required.
      - jimktrains2 11y ago
        Currently headers get modified in-flight, so a content-based ID wouldn't work. As for a new protocol, there are some out there, but all fail in some way or another. I figured I'd throw my ideas out there and see how much they fail https://github.com/jimktrains/email_ng https://github.com/jimktrains/email_ng

grey-area 11y ago

Certs or some other method to identify servers, so that gmail etc don't attempt to use IP for server identity, which is obviously flawed. The SMTP protocol is pretty flawed itself though, so probably that needs to change to see any real progress here.