On Fri, May 28, 2021 at 01:44:54PM -0400, Wietse Venema wrote:
> > 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.
> >
> > [...]
> >
> > which requires some design.
>
> 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.
You probably still have what we happened to share in email, the thread
subject is "TLS user interface" from 2014-10-19 through 2014-10-24.
> 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}.
Yes, something like that, but with care about downgrades. So it is
really:
dane =
if | MX host zone unsigned -> may
| TLSA lookup fails -> next MX or defer
| signed usable TLSA records -> dane-only
| signed all unusable TLSA records -> encrypt
| no signed TLSA records -> may
dane-only =
if | STARTTLS not offered -> next MX or defer
| handshake fails -> next MX or defer
| TLSA records don't match -> next MX or defer
encrypt =
if | STARTTLS not offered -> next MX or defer
| STARTTLS offered -> mustTLS
mustTLS =
if | handshake succeeds -> send with unauthenticated TLS
| otherwise -> next MX or defer
may =
if | STARTTLS not offered -> none
| STARTTLS offered -> tryTLS
tryTLS =
if | handshake succeeds -> unauthenticated TLS
| if message is fresh -> next MX or defer
| if message age > backoff time -> reconnect + none
none = try sending in the clear
... verify, fingerprint ...
Adding more conditional branches without introducing inadvertent
downgrades, and possibly allowing explicit downgrades, ... is
a bit of a challenge.
--
Viktor.
