Hi Binu, First off: sorry for the very late reply, I've been moving to another continent temporarily.
> On 06 Apr 2016, at 08:42, Binu Ramakrishnan <[email protected]> wrote: > > Aaron, I think the important point here is when you say TOFU (Trust On First > Use) - that means no trust anchor is involved at least during the initial > step. In the case of STS, the policy is served over webpki. In fact sender > can possibly skip DNS indicator flag and directly fetch policies from > recipient's well known HTTPS endpoint. Note that DNS STS record is a > convenience, not a must to have component. I think your misconception is that I'm an opponent to WebPKI. I'm not - I'm merely trying to deal with realities.. Currently the majority of MXs (i.e. 90+%) on the internet do not have properly signed certificates, and even the signed ones often contain wrong CNs or SANs. I've even seen invalid characters in different places in certs during scans [0] - no idea how they got signed by a CA in the first place. A lot of them are a few years old and expired long ago. This is the reason why MTAs do not properly validate certificates in the first place. The move you're suggesting just puts verification in a different (out-of-band, HTTPS) place. As noted earlier to Viktor: I'd like to see WebPKI + TACK. Meaning: we could probably achieve fast roll-out on MTAs that do not have properly signed certs and move to properly signed certificates in the long run. TACK would effectively mitigate MITM attacks due to pinning. Once a MTA switches to a valid cert (or something like Let's Encrypt to automate) you get pinning plus a trust-chain/anchor. I'm not suggesting we move away from the CA system - it's currently the only thing that works at scale. I'm still quite pessimistic about DNSSEC, though I hear about big rollouts to happen during this year - let's see. Then there's another problem, it's probably what Dan meant with 'bootstrapping': If I'm not mistaken, a sending MTA on the first connection to a new MTA will need to resolve DNS - MX records, without DNSSEC any attacker can manipulate these queries. One idea is to pre-populate with pins as STARTTLS-Everywhere tried in the past and some of you have suggested for STS. TACK Pinning would also work very effectively in this case, with the nice property that TACK allows for very efficient key-rollover - no out-of-band communication needed at all. Of course this doesn't solve the matter of policy distribution, while I'd like to see something in-band (i.e. an SMTP extension as mentioned earlier) the STS suggested way is via out-of-band HTTPS verification where i.e. policies get compared and verified. I'm not a fan of this solution as you can probably guess - if it ends up this way, I'll probably need to implement support for that in STARTTLS-Everywhere/LE anyhow. > > One of the main issues currently is that most MTA-MTA traffic is over > > connections established without a CA signed certificate. You're now > > requiring them to use one anyhow, just in a different place. > Using untrusted cert is not a feature, but an important security issue that > needs to be fixed either through DANE or PKIX. ..as mentioned in the sentence you quote; I strongly feel this is one of the major issues in MTA security today, not a feature. It's probably a good idea to split this into several threads as Dan suggested: policies and their distribution, feedback mechanisms and authentication (pinning, PKIX et cetera). Thanks, Aaron [0] http://arxiv.org/abs/1510.08646
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
