On Thu, Sep 10, 2015 at 06:31:49PM +0200, Michael Ströder wrote:
> > If you want to propose an update that requires SMTP clients to
> > employ DANE TLSA verification of MX hosts in signed zones even when
> > the MX RRset was not "secure", read the previous discussion of this
> > question in the list archives (yes, it has come up before) and make
> > a clear-cut proposal with as solid a rationale as you can.
> >
> > I am not sure this can get enough support to reach "rough consensus",
> > but I'm open to the possibility.
>
> Without a signed MX there's no cryptographically secured binding between the
> recipient domain (right address part) and the public key used for TLS authc.
>
> So I'm strictly against this possibility and the developers of a MTA I spoke
> with today are also strongly against this.
>
> @Patrik: Deploying DNSSEC/DANE at large scale is not an easy job. If you drop
> the requirement for signed MX RRs DANE would not be worth the effort to be
> implemented.
Note, the hypothetical proposal would not weaken DANE in any way,
nor would it "drop" the requirement to pay attention to the security
status of the MX RRset, in particular "bogus" replies or other DNS
errors in MX resolution would still result in deferral of mail.
All that would hypothetically happen, is that even when the MX
RRset is "insecure" (verifiably from an unsigned zone) but the
target MX host is in a signed zone and has "secure" TLSA records,
DANE authentication might be "SHOULD" or "MUST", rather than the
current "MAY".
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-2.2.1
Since the protocol in this memo is an "opportunistic security"
protocol ([RFC7435]) the SMTP client MAY elect to use DANE TLS (as
described in Section 2.2.2 below) even with MX hosts obtained via an
"insecure" MX RRSet. For example, when a hosting provider has a
signed DNS zone and publishes TLSA records for its SMTP servers,
hosted domains that are not signed may still benefit from the
provider's TLSA records. Deliveries via the provider's SMTP servers
will not be subject to active attacks when sending SMTP clients elect
to make use of the provider's TLSA records (active attacks that
tamper with the "insecure" MX RRSet are of course still possible in
this case).
I think the current "MAY" is sufficient for now, but if that proves
to be a valuable feature of the protocol, an a short update BCP
RFC upgrading the "MAY" to a "SHOULD" or "MUST" might be possible
in the future.
So long as such sessions are not reported as secure, and are not
accepted when DANE authentication is mandatory (e.g. Postfix
"dane-only" TLS security level), the proposal does not in any
way reduce the security of DANE as specified.
The main risk is with reliability. Perhaps only those customers
of a service provider that operate DNSSEC signed domains are willing
to accept service availability risk in case of DANE authentication
failure, and the customers with unsigned zones want service
availability above all else. If the proposal is formalized, then
all customer domains suffer if the TLSA records are ever wrong,
even those whose domains are unsigned.
Of course service outages happen for operational reasons beyond
incorrect TLSA record updates (or failure to update). And the
sending domains that elect the "MAY" policy will defer email even
for the unsigned domains.
So the proposal is not obviously damaging, just possibly premature.
We'll know more once there is more deployment and people either
learn (or don't learn) to operate their TLSA records correctly.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
