Viktor Dukhovni wrote: > On Thu, Sep 10, 2015 at 08:39:38PM +0200, Michael Ströder wrote: > >> Maybe there should be some additional text for 'dane-only' in [1]? >> I'm not sure about the correct wording though. > > I think it is fine as-is. The "dane-only" security level requires > that a peer be DANE authenticated, which means "secure" MX RRset, > "secure" address RRset for the MX host and "secure" matching TLSA > records. All the links in the chain have to be valid. > >>> I gather you're looking for something like: >>> >>> example.com secure match=nexthop:dot-nexthop:hostname dnssec=yes >>> >>> where "dnssec=yes" would be a new policy option, that requires a >>> "secure" MX RRset, or "secure" absence of an MX host. >> >> Yes. :-) > > Just to be clear, is that what you had in mind when you started > this thread?
Yes. And I also thought to myself that such a policy option would be useful for all TLS security levels. > Or did I suggest a feature that you decided you want? No, you guessed my wish. > One might also imagine an alternative interface: > > example.com secure match=nexthop:dot-nexthop:dnssec-hostname > > Where "dnssec-hostname" matches the hostname only if securely > obtained. This would not require secure MX RRsets, but would make > use of them to "improve" PKIX name matching when present. Maybe I do not fully understand what you're saying. But personally I consider the TLS hostname matching to be sufficiently secured (because I likely also limit the CA cert used for validation). Mainly it's the MX lookup what I'm concerned about. Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
