> On Dec 5, 2015, at 5:14 PM, Aaron Zauner <[email protected]> wrote:
>
>>> And I also think I've broken your proposal in this GitHub issue:
>>> https://github.com/mrisher/smtp-sts/issues/1
>>
>> No. Neither DEEP nor TACK can protect MTA-to-MTA SMTP. The reason
>> is MX indirection. DEEP and TACK pin server properties, not domain
>> properties. The MITM will just forge the MX RRset and bypass DEEP
>> and TACK. In any case, there are domains to which I send email
>> very infrequently, but still want the transport to be secure, none
>> of DEEP, TACK or STS address that.
>
> I'm not saying that TACK is the only and ultimate way to go. It served
> as an example in this case. The major problem I see with DNS is that a
> lot of small mail-servers do not get a lot of attention, some of their
> operators might not even have direct DNS access (think semi-hosted setup
> where you have to either go through a web interface of your provider or
> actually write an e-mail.
Well somebody publishes MX and/or A records for the domain so it can
get mail.
> Another case is where the Postmaster has no
> real influence on DNS record because of company/university/whatever
> bureaucracy). I know you heavily support DANE and I do like DANE in
> general but see major problems in DNSSEC still (not only deployment).
MTA-to-MTA SMTP (relay) establishes connections to wherever the MX records
point. The MX records are in DNS. Therefore, if active attacks are in
scope, and DNS is not protected from active attack, you cannot protect
of MTA-to-MTA SMTP from active attack. None of the proposals you suggest
both scale and work if DNS is subject to MITM.
If you have an architecture that somehow avoids critical reliance on DNS
security, and works even for infrequent or first-time communication, you
need to explain how it does in some detail. I've not seen anything that
matches that description.
Similar observations can be made for MUA to MSA in the RFC 6186 scenario
(SRV records for locating the submission, imap and/or pop servers).
As for postmasters v.s provider hosted domains, I might note that udmedia.de
have published TLSA records for the MX hosts of ~30,000 (perhaps more now)
domains, without any need for the domain owner to take explicit action for
that to happen. There also a few thousand such domains hosted by each of
nederhost.net and transip.nl. The provider case is actually the easy one,
if the provider is willing to take the appropriate steps. If not, switch
to a better provider.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta