Earlier quoted context omitted.
The point is that (to a first approximation) nobody uses DNSSEC, which is badly flawed, and MTA-STS doesn't rely on it.
why flawed... the tree structure and government participation?
SMTP MTA Strict Transport Security (MTA-STS)
21–30 of 42 posts
Re: SMTP MTA Strict Transport Security (MTA-STS)
#22Earlier quoted context omitted.
why flawed... the tree structure and government participation?
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
i've never understood how any pinning of certs/ca can work after the "quantum insert" relevation from snowden?
sorry if asking stupid questions...
Re: SMTP MTA Strict Transport Security (MTA-STS)
#23Earlier quoted context omitted.
But now we have dns over https too?
Wake me when we have DNS over HTTPS for anything except web browsers. Plus, someone running an MTA is very likely running a recursive DNS server on the same network , if not the same machine, that uses UDP or TCP for upstream queries. Anyone positioned to MITM SMTP is likely positioned to MITM DNS. EDIT: Ah, perhaps you meant that with DNS over HTTPS, MTAs will need an HTTP client anyhow. IMO the path of least resist…
Some sort of secure channel DNS seems likely to trickle down. Especially since an MTA is already well past getaddrinfo. And STS already requires https (which I do find kind of weird). So all the heavy lifting code of some form of secure DNS is here.
Re: SMTP MTA Strict Transport Security (MTA-STS)
#24Earlier quoted context omitted.
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
i've never understood how any pinning of certs/ca can work after the "quantum insert" relevation from snowden? sorry if asking stupid questions...
QUANTUM INSERT doesn't do anything an ordinary attacker couldn't do; the only difference is that NSA can effectively deploy the attack anywhere on the Internet, and an independent attacker has to fight their way to any particular vantage point. But that's a distinction that doesn't make much of a difference in protocol design.
Importantly: if NSA is part of your threat model, the hoped-for alternative that STS supersedes --- DNSSEC --- is no help. NSA controls the DNSSEC roots.
Re: SMTP MTA Strict Transport Security (MTA-STS)
#25Earlier quoted context omitted.
i've never understood how any pinning of certs/ca can work after the "quantum insert" relevation from snowden? sorry if asking stupid questions...
QUANTUM INSERT doesn't do anything an ordinary attacker couldn't do; the only difference is that NSA can effectively deploy the attack anywhere on the Internet, and an independent attacker has to fight their way to any particular vantage point. But that's a distinction that doesn't make much of a difference in protocol design. Importantly: if NSA is part of your threat model, the hoped-for alternative that STS supers…
I guess DNS is doomed... =)
and we will have to start writing public keys on a distributed wall of TLDs
Re: SMTP MTA Strict Transport Security (MTA-STS)
#26Earlier quoted context omitted.
i've never understood how any pinning of certs/ca can work after the "quantum insert" relevation from snowden? sorry if asking stupid questions...
QUANTUM INSERT doesn't do anything an ordinary attacker couldn't do; the only difference is that NSA can effectively deploy the attack anywhere on the Internet, and an independent attacker has to fight their way to any particular vantage point. But that's a distinction that doesn't make much of a difference in protocol design. Importantly: if NSA is part of your threat model, the hoped-for alternative that STS supers…
> NSA controls the DNSSEC roots.
Is this any more true than saying "NSA controls the web CA roots" i.e. the NSA could infiltrate one of the hundreds of certificate authorities that browsers trust and issue a malicious certificate?
If so, and if NSA is part of your threat model, then I would say that STS doesn't help very much either.
What's more interesting is the issue of transparency. Are STS clients going to be requiring that the certificates for the HTTPS resources they access are present in a certificate transparency log? CAs are allowed to issue certificates that aren't logged, for privacy reasons I suppose, but there would be no such excuse for a "DNS transparency" log of DNSSEC keys for top level domains. Logging all of these keys would be orders of magnitude simpler than logging all CA issued certificates on the web.
Re: SMTP MTA Strict Transport Security (MTA-STS)
#27Earlier quoted context omitted.
i've never understood how any pinning of certs/ca can work after the "quantum insert" relevation from snowden? sorry if asking stupid questions...
QUANTUM INSERT doesn't do anything an ordinary attacker couldn't do; the only difference is that NSA can effectively deploy the attack anywhere on the Internet, and an independent attacker has to fight their way to any particular vantage point. But that's a distinction that doesn't make much of a difference in protocol design. Importantly: if NSA is part of your threat model, the hoped-for alternative that STS supers…
> NSA controls the DNSSEC roots.
No they don’t. You know better than to spread FUD, regardless of what you think about DNSSEC.
I agree with your other points, however.
Re: SMTP MTA Strict Transport Security (MTA-STS)
#28Earlier quoted context omitted.
why flawed... the tree structure and government participation?
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
Maybe time to update your rant about DNSSEC.
For example, when you're explaining about how DNSSEC isn't relevant to the Domain Validation problem, you could mention that er, it's checked by the CA which issued your certificate, and closes literally the only otherwise insecure link in the chain for that CA.
Sound implementations of 3.2.2.4.7 (including those by your own chosen CA) are protected by DNSSEC. No DNSSEC? No protection.
Further down you're going to want to cover how the thing you were so sure it was essential to protect (secret hostnames) is actually gone now in the very architecture you told everybody they should prefer over DNSSEC (the Web PKI). If you're polite you'd explain how this happened, all the trust breaches and security problems in your better option that meant we had no other choice.
Or you know, just keep linking to the 2015 version and acting as though nothing changed. Put it on your Friendster maybe?
Re: SMTP MTA Strict Transport Security (MTA-STS)
#29Earlier quoted context omitted.
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
Maybe time to update your rant about DNSSEC. For example, when you're explaining about how DNSSEC isn't relevant to the Domain Validation problem, you could mention that er, it's checked by the CA which issued your certificate, and closes literally the only otherwise insecure link in the chain for that CA. Sound implementations of 3.2.2.4.7 (including those by your own chosen CA) are protected by DNSSEC. No DNSSEC? N…
There's a FAQ on this post, which I wrote in 2015, that answers your objection.
Re: SMTP MTA Strict Transport Security (MTA-STS)
#30Earlier quoted context omitted.
Except in the absence of DNSSEC it does not ensure transport security. An attacker positioned to perform a MITM of an SMTP session is also positioned to MITM DNS requests. It's also worth mentioning that even if you skipped TXT querying and went straight to querying mta-sts.example.com, the attacker can just drop the A or AAAA record for mta-sts.example.com. The only way to prevent this is to use DNSSEC, which can si…
The difference between your threat model and mine is that yours is based on concern for random people running small mail servers. I understand and respect that threat model, though I do not appreciate or really care about it. On the other hand: I believe email is a technological dead end, and that we are not evolving towards an Internet with a more distributed email system, but with less distribution. I think that, f…
The difference between your threat model and mine is that yours is based on concern for random people running small mail servers. I understand and respect that threat model, though I do not appreciate or really care about it.
Why should anyone be discriminated against based on the size of their mail server?