On Mon, Aug 18, 2014 at 12:20:41AM -0400, Benjamin Kaduk wrote:
> "if you can
> use DANE as a trust anchor, attempt to do so, but fall back if there is no
> record"
[ Just want to add a possibly useful terminology improvement in
light of the draft. ]
Note, I'd like to promote the view that not negotiating a stronger
mechanism is not fallback. In the next (2.12) Postfix development
snapshot or so, while opportunistic DANE TLS still employs DANE
when TLSA records are present and not otherwise, one can also
specify a "fallback" TLS security level of "encrypt" or "may",
which is used when DANE TLSA records are present, but authentication
fails! This is effectively an "audit" mode of authentication
enforcement, where mail is delivered even if authentication fails
(possibly even in the clear with "may"), but warning are logged,
making MiTM at least tamper-evident for those who enable this and
don't just ignore the logs. Sending sites concerned with the
potential impact of enabling opportunistic DANE TLS on mail delivery
can initially turn it on in "audit-mode".
So I'd like to think of "fallback" as the kind of noisy "your
security is degraded, here's a dialogue to say it's OK" mess that
we're currently in when not able to create a suitably secure channel.
With opportunistic security, when the peer does not advertise
support for some mechanism, and as a result that mechanism is not
employed, there is no fuss, the peers operate closer to the baseline
security level.
[ Note, there is no specific recommendation to use DANE in the
draft. This is deliberate, I wanted to avoid giving mechanism-specific
advice. Be it at the cost of greater abstraction. ]
The text about DANE in the draft, carefully suggests that it is
but one of many possibilities.
Opportunistic security protocols should provide a means to
enforce authentication for those peers for which authentication
can be expected to succeed based on information advertised by
the peer via DANE, TOFU or other means. With DANE, the
advertisement that a peer supports authentication is
downgrade-resistant. What is "opportunistic" here is the
selective use of authentication for certain peers; much in
the same way as unauthenticated encrypted communication may
be used "opportunistically" with peers capable of more than
cleartext.
Enforcement of authentication is not incompatible with
opportunistic security. If an OS-enabled peer (A) makes
available authentication key material, e.g., via DANE, to peer
(B), then B should make use of this material to authenticate
A, if B is OS-enabled and supports DANE.
Of course at this time only DANE provides (for as yet too few
domains) an authenticated channel with authenticated denial of
existence for publishing peer authentication material. So I cannot
offer practical examples of this with a different underlying
technology.
--
Viktor.