On 11 April 2018 at 16:40, Ned Freed <[email protected]> wrote: > > > However, it surprises me that the MTA-STS draft does not appear to note > > this prior art at all, and this makes me wonder whether it was even on > the > > radar. > > The relevance of POSH was discussed as recently as March on the UTA list. > I believe it has come up in previously discussions as well. >
Good to know it's come up at least. > > > Importantly, POSH was never deployed very heavily - I can find only one > > deployment (and "most users opt to just give us the cert"). This was in > > part because of Google's withdrawal from standards-based IM, which > > liberated the community from having to support a use-case only Google > > really felt important, and also the rise of free CAs, which avoided the > > cost issue associated with traditional PKIX. > > The situation here is very different. First, Google is one of the players > behind this proposal and their withdrawl from standards-based email > seems... > unlikely. As far as SMTP is concerned, at least, I'd agree. > Second, the primary problem MTA-STS solves - added security against > active attacks on existing email infrastructure - is quite different than > the > XMPP situation. > > I'm not entirely sure that statement is accurate. The exact same list of requirements is what drove POSH in my memory - an inability to authenticate the certificates used in many cases and a (perceived) unwillingness to share private keys, alongside a difficulty in certificate management when hosting many domains. Yes, XMPP has the advantage of less cruft and a simpler deployment model, but I think that's largely irrelevant. > > 2) HTTPS Call-out > > > Given the policy is essentially trust-on-first-use, it's not clear to me > > why much of the STS policy cannot be transferred within SMTP itself, > > perhaps in response to the EHLO issued after STARTTLS completes. This is > > good enough for HTTPS's STS variant, and feels intuitively simpler for > MTAs > > to implement. > > I'm afraid you have this exactly backwards. Even if the SMTP server > approach > provided comparable security - and it doesn't - deploying a new SMTP > extension > is quite difficult; we have an abundance of fully worked examples > demonstrating > this point. Whereas throwing up an A record, certificate, and server that > serves out a single document is trivially easy. These days I don't rank as > an > experienced IT person, and I was able to do it for a test domain in about > 20 > minutes. > > I entirely agree that hosting a single document under HTTPS is trivial. > This is not to say that there aren't issues implementing MTA-STS. There are > significant issues, but they are all on the client side. Adding an HTTP > client > to your SMTP client significantly increases attack surface, so much so > that I'm > not willing to do it, and other folks have said they aren't willing to > either. > > The approach I'm using is to build an MTA-STS query server with integrated > caching support. I have one mostly coded, and while I haven't worked > through > all the caching and timeout issues yet, I have not found any significant > implementation obstacles. > > This workload is what I consider to be the antithesis of "intuitively simpler". > > 3) DNSSEC or not? > > > The MTA-STS problem is reasonably well-defined in the document - SMTP > > servers often do host numerous domains, and unfortunately operating one's > > own server has become a rarity, so domains are concentrated on a few > > servers. STARTTLS is, as the abstract notes, theoretically susceptible > to a > > downgrade attack - but this does require either active MITM or some > fairly > > tight hoops to jump through to actually exploit. > > > The draft then goes on to compare the solution to DANE, and notes that > > DNSSEC is not required with MTA-STS - "at a cost of risking malicious > > downgrade attacks". These would be performed by DNS spoofing, which has a > > known history of occurring. In any case, what is distinctly unclear to me > > is whether MTA-STS without DNSSEC is materially different from RFC 7672 > > without DNSSEC; if unsecured DNS is "good enough" for MTA-STS, my > immediate > > question is whether it might therefore be good enough for at least some > > cases of DANE. > > I haven't implemented the SMTP client integration part of this yet so I > may be > speaking out of turn, but I've mapped it out and it appears to be > reasonably > straightforward. > > I've also looked at implementing DANE, and IMO it's a major PITA to > implement, > so much so that it would take substantial customer interest to make me do > it - > interest that has not materialized. > > For what it's worth, I implemented DANE in XMPP, including securely deriving reference identifiers - making it slightly more complex than RFC 7672 in the end due to XMPP authenticating both ends of an S2S stream - in a couple of days. I didn't find it even a minor PITA to implement. > And that's without even considering the difficulty of getting people to > deploy > funky DNS records. Like it or not, these days throwing up a single-purpose > HTTPS server is dead easy. And keep in mind that someone using a hosted > email > solution need only deploy a single CNAME record pointing at the hosted > solution's MTA-STS server. That's about as simple as it gets. > > > I'd note that in RFC 7672, the presence of a (DNSSEC-secure) TLSA record > is > > sufficient to mandate TLS - hence my question is whether an insecure TLSA > > record stipulating a particular trust anchor and/or valid certificate > > (PKIX-TA and PKIX-EE) might be sufficient to meet the same security > > requirements here. > > Frankly, I don't care if it does or not. DANE is currently a nonstarter in > my > book, whereas while I dislike various aspects of this proposal, the > reality is > it's far easier to implement. > > Well, we agree it's simpler on the receiving side at least, but that's only because SMTP doesn't try authenticating the sending MTA. > > 4) Wildcard on Wildcard Action. > > > It is deeply unfortunate that MTA-STS mandates a name match based on > > dNSName SANs only. I would have thought that emulating an SRV, and > matching > > a corresponding sRVName, would be more useful - and overall, the idea > that > > a new matching algorithm has been included so as to match an "mx pattern" > > to a dNSName wildcard just feels like an exploit waiting to happen. It > > would feel considerably safer to do one of: > > Please explain how it would be more useful. > > > a) Make matches operate the same way as DANE, by being based on hashes of > > SubjectPublicKeyInfo and/or the complete certificate. (Similar to POSH's > > approach of a certificate hash). > > That drags in some (but not all) of the implementation isssues with DANE. I > probably would not have bothered to implement MTA-STS had this been part > of it. > > I suspect it's a lot easier than it sounds, actually. Otherwise I doubt I could do it. > > b) Make matches operate the same way as RFC 6125 (unreferenced, I note).. > > Not sure what you mean about references: Section 3.2, fourth bullet point, > section 3.3, second paragraph. section 4.1, first paragraph. > > My error. I somehow missed that one. > > c) Both/either of the above. > > > I assume the logic behind allowing a wildcard-to-wildcard match is to > allow > > a Google user to simply specify ".googlemail.com" and ".l.google.com" as > > their MX identity patterns; however it feels as though Google could > simply > > use a known name within the certificate for all their receiving MTAs, > > irrespective of the DNS records involved. This, of course, presupposes > that > > the administrator of the mail domain somehow does not know the precise > > names of the MTAs used in their own DNS records. > > > I further assume the logic in mandating matches against dNSName SANs is > > because these are readily available; however sRVName SANs, by restricting > > their use to a particular service, have the advantage that customers > giving > > these to their service provider might be deemed more acceptable. > > A comparable effect can be achieved by using a subdomain root reserved for > email server use. > > So it's a choice between an easily implemented naming convention and a > bunch > of PKIX esoterica. This does not strike me as a difficult choice. > > Well, being *able* to use sRVName would be nice at least. The specification as written prevents it, which seems unfortunate. Being able to use dNSName is a given, of course. For one thing, it already has support directly in OpenSSL's API - unless you're matching one wildcard against another of course, when you have to do it yourself. > > 5) Terminology and Nomenclature. > > > It is well-known that naming things remains the hardest problem in > > technology. > > > However, this draft appears to have taken bold strides in demonstrating > > that coming up with new names for things needn't be so challenging. > > > Take §7.1, for example, which dictates that the SNI extension MUST > contain > > the "MX hostname" - this latter term does not appear anywhere else in the > > document. I'm going to guess that it means the RHS of the MX record, as > > defined in RFC 7672 (and informative reference), which is the same as RFC > > 7672. "MX host", which appears once in RFC 5321, also appears elsewhere > in > > this draft, including in §1.1, where it is in this definition: > > I missed the "MX hostname" thing and agree it should be fixed. I also agree > that "MX host" is misleading and should be replaced, but I could not come > up with a useful replacement and so didn't suggest making that change in > my review. > > > o MTA-STS Policy: A commitment by the Policy Domain to support PKIX > > [RFC5280] authenticated TLS for the specified MX hosts. > > > Impressively, by my reading, the commitment is for the Policy Domain to > > support PKIX for all SMTP; and not just for specified hosts. > > Of course that's the commitment. How could it be otherwise? > Then that needs rephrasing, because I didn't see any "Of course" about it. A commitment by the Policy Domain to support PKIX [RFC 5280] authenticated TLS, using reference identifiers as listed. (I'm trying to guess what was meant by "for the specified MX hosts".) > > > Using more common - and more uniform - terminology would be of huge > > benefit: "Sending MTA", "Receiving MTA", and so on are well-known terms.. > > Except those terms don't match up with anything that needs naming here > AFAICT. > > "Sending MTA" is used a fair amount (15 times). But they're sending to a "receiving MX" (4.1), or a "SMTP server" (curiously, some "SMTP servers" are sending email, though). > > If > > a new term is needed, please do define it. If you mean to use terms from > > other RFCs, these need to be Normative References and noted in the > > Terminology section. > > > 6) Reference Identifiers and derivation. > > > RFC 6125 provides a slew of terminology and best practise - from the same > > UTA working group, as I recall. RFC 7672 also provides terminology and > much > > behaviour. > > > It feels as though this draft should at least attempt to use the same > > terminology, and ideally the same behaviour, as RFC 7672 (and RFC 6125).. > > > This is particularly noticeable in the difference between the reference > > identifiers used within RFC 7672 (and used within the SNI discussed > there) > > compared with this draft, see for example this draft's §7.1, compared > with > > RFC 7672 §8.1 > > I haven't gone through the sections on SNI yet so I'm not going to > comment on this. > The main difference (from memory now) is that RFC 7672 uses a "TLSA base name", which is either the "MX hostname" before or after following CNAMEs. Dave.
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
