Hiya, With no hats, I'd like to argue that the WG should pursue the "webby" STS proposal, but should also ensure that we do not damage progress made by those who are deploying the DANE/DNSSEC approach to securing MTA-MTA connections.
I think we can do that by requiring that outbound MTAs
that implement the "webby" approach MUST/SHOULD first test
for, and process, TLSA records for the next MX in the path.
In other words the "webby" approach is tried 2nd.
In more detail, my reasoning is as follows:
- The DANE/DNSSEC approach works and when deployed does
move MTA-MTA use of TLS beyond opportunistic security.
And indeed some folks have deployed that and gotten the
benefits.
- Deploying DANE/DNSSEC requires DNSSEC (fairly obviously;-)
and the fact is that DNSSEC deployment is not something
that everyone who wants to move beyond opportunistic
security is currently willing to do.
- We can, and probably will, define a "webby" to achieve
the same desired effect of getting beyond opportunistic
security. Daniel and co's STS aprooach (as outlined for
the next revision in B-A) is one such, and seems like
it's one that can work.
- Any such webby approach will inherently involve us in
re-inventing a lot of what we get from DANE/DNSSEC. That's
a bit of a pain, but inevitable and not a reason to not
do STS. (The goal here is not perfection but to enable
folks to do better than opportunistic security after all.)
- My guess is that the webby approach will end up being
a bit less secure/safe compared to the DANE/DNSSEC way
of doing things, mostly due to it having to depend on
some kind of TOFU step that gets repeated whenever DNS
without DNSSEC is used (i.e. when something cached
expires).
- We therefore end up with two ways to do one thing. One
("webby") likely to be deployed by some bigger mail
processors who don't currently do DNSSEC, and another
DANE/DNSSEC that will likely be better and that's where
we'd (as in the IETF) really prefer us all to end up
when/if possible.
- I think that saying one MUST first try DANE/DNSSEC is
correct, but there may be cases where e.g. DNSSEC is
just never going to visibly work for an MTA so it may
be correct to say one SHOULD first try DANE/DNSSEC
with the exception being cases where one knows at
coding time that you'll never see an RRSIG or similar.
Anyway with two ways, I really hope the WG conclude that
we want both to be deployable without one damaging the
other. There are of course other ways to try ensure we can
sensibly live with both DANE/DNSSEC and webby STS and
yet help folks move beyond opportunistic security, but
I think the way outlined above is likely best if the folks
who develop MTAs can accept it.
Cheers,
S.
PS: Yes, this is entirely jumping the gun, and is only
something the WG would need to decide a bit down the road.
But since we had a good discussion of the topic in B-A,
I wanted to send this before I forget it all, as I'm quite
likely to do;-)
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
