Viktor Dukhovni wrote: > 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.
Hmm...I can understand why you wrote it like this. But some people are more eager and want to push things into mandatory way. I wished DANE starts with "MUST" from the very beginning. It's a new standard and a big invest anyway. > 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. Postfix's "dane-only" requires successfully validated signed MX RRs? > 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. Yes, service providers have opt-in mechs for such a distinction. And of course they must have *different* right-hand parts in their MX RRs for both cases. > 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. People should be prepared that some MTAs will require signed MX RRs. Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
