Viktor Dukhovni:
> The barrier to progress is deciding whether a point solution such as
> a new level like "dane-or-encrypt" is good enough, or whether the right
> way forward is a more general syntax for specifying what happends when
> a dynamic level like dane finds its preconditions missing.
>
> A more complete set of options might be:
>
> * "dane", or else "encrypt"
>
> * "dane", or else "secure" (equivalently "verify" with explicit
> "match" patterns).
>
> * "dane", or else "mta-sts" (built-in "mta-sts" is not presently
> supported or even planned, but perhaps some day...)
>
> * "dane", with an "on fail" override to deliver anyway, but the
> possible MiTM is logged and is "tamper-evident". (This
> should/would be discouraged, except as a limited-duration
> work-around).
>
> * "mta-sts", or ... (again if some day implemented)
>
> which requires some design.
Indeed, if we want to support multiple acceptable TLS security
settings then it should not be just for DANE.
Victor and I started a discussion on multiple acceptable security
settings six years ago (I recall that I was looking for a way to
discover sites that supported stronger-than-opportunisic TLS, but
it could equally well be used to allow different forms of mandatory
TLS). Unfortunately any notes that I kept on paper or whiteboard
were lost in the shuffle as I changed jobs.
Postfix's opportunistic TLS is like an alias for {none, encrypt},
dane is like {none, encrypt, dane-only} while what you asked for
corresponds to something like {encrypt, dane-only} or maybe {verify,
dane-only}.
Wietse
