On Fri, Mar 25, 2016 at 12:35:02PM -0700, Jim Fenton wrote:
> > If the entire goal is to ensure the integrity of the RFC 6125
> > "reference identifier" used to authenticate the nexthop SMTP
> > server, then it is perhaps a good idea to say so explicitly.
>
> The primary purpose was indeed to ensure the integrity of the reference
> identifier; this is discussed in the Security Considerations (section
> 6.2, paragraph 3).
If so, with DNSSEC validation required, CNAMEs need only be secured
to the extent that they affect "reference identifier" selection.
* CNAME/DNAMEs between the MX qname and the owner domain of
the ultimate MX RRset definitely need to be validated.
* For domains with no MX RRset, the absence of the MX RRset
would potentially need to be DNSSEC validated.
* Otherwise, CNAMEs only need to be validated to the extent
that (e.g. following RFC 7672) the ultimate "reference
identifier" is determined in whole or in part based on
the result of the CNAME lookup.
> > <quote>
> > The CHAIN and DANE parameters are additive; if both are specified,
> > either method of certificate validation is acceptable. If neither
> > CHAIN nor DANE is specified, the certificate presented by the SMTP
> > server is not required to be verified.
> > </quote>
> >
> > This is reasonably clear, either suffices when both are specified.
> > I am concerned that giving the user the choice to specify either
> > alone, rather than just a single "AUTHENTICATED" (or similar)
> > keyword, may be too much rope.
>
> By not using the CHAIN and DANE options, certificate verification is not
> required, so if too many messages are being bounced with those options,
> they'll not see use. But without those options, we're limiting the
> effectiveness of REQUIRETLS to passive attacks only; MITM attacks will
> still be possible.
NOTE: I am not suggesting that REQUIRETLS should not be able to
require authenticated TLS. Rather, I am (strongly) suggesting that
such a requirement needs be mechanism-neutral, and should not be
so specific as to be able to specify the use of DANE, WebPKI or
some future alternative.
> I have received suggestions that there also be options to require
> specific TLS version, cipher suites, PFS, etc. as well, and my gut feel
> is that's getting too specific.
Don't let this be over-engineered. That's a guaranteed way to fail
to produce a workable protocol. Of course it is clear that even
a simple REQUIRETLS can gain sufficient traction, but to the extent
that you want this to have a fighting chance you should resist all
calls for overly-specific policy.
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
