Viktor Dukhovni:
> 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.
Thanks, I found some emails with that subject.
> > 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:
Yes, and that maze of implicit fallback logic will have to go if
we want to give the user more control, as in:
none = no encryption.
encrypt = encryption but no trusted server.
verify = the server certificate is PKI verified, and contains an expected name.
secure = ditto
dane = the server certificate (issuer) matches the TLSA record from secure DNS.
Instead of implicit fallback, just do what they say. There will
need to be logging to justify why some the { ... } elements could
not be realized.
Wietse
