On Wed, Mar 12, 2014 at 02:59:34PM -0700, Joe Touch wrote:
[ It seems the discussion has moved on beyond the specifics of the title of
the SMTP with DANE draft: "SMTP security via opportunistic DANE TLS". So
if anyone has a considered proposal for a better name, please start a new
thread on the DANE list only, or just send me your suggestions off-list. ]
> No disagreement; there seems to be a need then for two terms:
>
> 1. unauthenticated key exchange/use
>
> 2. security that uses authentication when available,
> but allows unauthenticated methods as a backup
Moving beyond the SMTP with DANE use-case, the space for SMTP alone
is definitely larger than just two cases. For example, with email,
we have:
0. Opportunistic TLS.
http://www.postfix.org/TLS_README.html#client_tls_may
What's opportunistic here is not the key management (long-term
keys are not used or ignored), but the *use* of TLS. If
the server EHLO response includes STARTTLS, TLS is attempted,
otherwise not.
1. Mandatory unauthenticated TLS (similar to 1. above).
http://www.postfix.org/TLS_README.html#client_tls_encrypt
Use of TLS is not opportunistic, the transmission channel
is always encrypted. However as with "0." there is no
authentication.
2. Opportunistic use of authenticated TLS (e.g. via DANE) with
fallback to "0." when the destination authentication policy
is not available.
http://www.postfix.org/TLS_README.html#client_tls_dane
(with the "dane" security level)
Here when "usable" secure TLSA records are published,
the server is always authenticated. But otherwise, we
do our best to at least not send in the clear.
3. Mandatory authentication:
http://www.postfix.org/TLS_README.html#client_tls_fprint
http://www.postfix.org/TLS_README.html#client_tls_secure
http://www.postfix.org/TLS_README.html#client_tls_dane
(with the "dane-only" security level)
Similar to HTTPS, but no user to click OK, so deployment is limited
to small set of administrator designated destinations.
4. Audit-only authentication (on the drawing board for Postfix):
An attempt is made to authenticate the peer with the
administrator selected policy (2 when destination policy is
known or one of static policies in 3). Authentication
results are logged, but mail delivery proceeds even when
authentication fails. The failure mode can be configured
to either "0." or "1."
There are of course additional models (TOFU, Tack, ...)
So perhaps a small list of terms (nouns or noun-phrases) will not
cover all the models in a generic way. We can however provide some
guidance on the appropriate use of some popular "adjectives", to
encourage people to use them in a more appropriate, consistent
fashion.
My contention is, for example, that the use of "opportunistic" in
"opportunistic TLS" to describe TLS in case "0" is a proper use of
that adjective. Similarly "opportunistic DANE TLS" for case "2"
is also reasonable. By way of contrast one might speak of "mandatory
TLS", "mandatory DANE TLS", ...
Finally, the terminology is the least of our worries, lets get more
of the security protocols deployed!
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
