> On 06/04/16 09:52, Daniel Margolis wrote:
> > But even if we'd prefer TACK (which
> > isn't unreasonable by itself), do we really want to deviate from the
> > well-trodden path of webPKI? I think not--browser-to-webmail HTTPS is
> > already an existing piece of attack surface for most users, so reusing it
> > here is somewhat sensible.
> Speaking as the maintainer of an MTA, no it is not. Having to add
> support for another protocol to an application which deals in SMTP,
> and knows how to use a library to get DNS, just feels wrong.
As I indicated in the Jabber chat session the other day, I'm 100% with Jeremy
on this. This expands the attack surface of the MTA considerably, and like it
or not that has to be considered as part of the security tradeoffs we're making
here.
Nor did the suggestion that prefetching, caching, and similar techniques
somehow ameliorate this impress me. While it may be possible to perform some or
even all of these http operations outside of critical SMTP client code, the MTA
has to perform them somewhere, somehow.
I briefly considered calling for a limited profile of https for this purpose,
but I don't see how that can possibly work. Just as we know that the way some
people are going to implement the client side of this is by throwing an
existing, hugely complex https library into their SMTP client, it's even more
certain that the way people are going to implement the server part of this is
by throwing up a web server using whatever existing web server technology they
have lying around, with all that implies.
> I'd
> feel an extreme lack of enthusiasm for ever getting around to
> implementing such.
FWIW, if this comes to pass given our customer base we won't really have an
option not to implement it. But I think the way I'm going to handle it is by
building on top of an existing minimal https client we already have, and adding
additional capabilties as the need arises. And if that causes ongoing
interoperability issues, that's just too bad.
Ned
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
