On Sun, Oct 05, 2014 at 10:26:15PM +0300, Yaron Sheffer wrote:
> Viktor is raising an important issue that I'd like to open on the list: the
> BCP draft implicitly applies to opportunistic uses of TLS (meaning, the
> client connects to the server without validating the server certificate). In
> general, such uses are definitely in scope of the working group.
In particular, for the applications that employ opportunistic TLS,
often the client can't meaningfully authenticate the server, even
if it wanted to. In many cases server certificates are self-signed,
clients don't have a "standard" list of CAs to trust, or the
reference identifier for the server is obtained insecurely via SRV
or MX lookups.
It is not that clients are merely "lazy", rather server authentication
is not an option. This is of course the turf the opportunistic
security draft, and we should not debate its content here. It
suffices to recognize that the opportunistic use case is typically
(and well into the future) unauthenticated.
> This document assumes that data integrity protection is always one of the
> goals of a deployment. In cases when integrity is not required, it does not
> make sense to employ TLS in the first place.
Well here I must strongly disagree, because TLS for confidentiality
against passive attacks is one of the primary reasons for opportunistic
security.
Sure, I implemented DANE for SMTP because I recognize that protection
against active attacks is better. And much of the controversy
around the opportunistic security draft is around my proposal to
opportunistically enable authentication.
Still for the next decade or so, most uses of opportunistic TLS
will protect only against passive attacks, and will not provide
integriry protection in the face of active attacks.
> There are attacks against
> confidentiality-only protection that utilize the lack of integrity to also
> break confidentiality (see e.g. [DegabrieleP07] in the context of IPsec).
> Thus, even when using opportunistic encryption, it is essential to provide
> cryptographic data integrity protection.
These are out of scope. The threat model for unauthenticated
opportunistic TLS is a passive adversary.
> However, most of the "interesting" attacks against SSLv3-TLSv1.1 are active
> MITM attacks. For such an attacker, it is trivial to hijack an opportunistic
> connection by presenting a forged certificate. IOW, you might as well stay
> with TLS 1.0 (though RC4 is still not a good idea).
Indeed for opportunistic TLS many of the best practices of the
draft which are protecting against active attacks are not applicable.
> So we could:
>
> 1. Say explicitly that opportunistic TLS is out of scope.
Or explicitly say which best practices are in scope for unauthenticated
opportunistic use cases.
> 2. Or say explicitly that it is in scope, and with the same requirements as
> "regular" TLS.
This is a non-starter. You cannot impose an authentication
requirement on opportunistic TLS, that makes it unusable.
> 3. Or come up with a different set of requirements for opportunistic TLS.
My response to 1. is effectively 3.
> I tend towards #2, because:
>
> - With channel bindings, you can convert an unauthenticated TLS channel into
> an authenticated one, after the fact.
This misses the point. The clients that are doing unauthenticate
TLS, are not necessarily doing anonymous ciphersuites and the like,
nor do they have alternative ways to authenticate servers. Rather,
they simply cannot authenticate the server by any means. They are
vulnerable to active attacks, and in fact many of them send in the
clear to some or all servers.
> - Also, because we do not want to fragment the TLS ecosystem.
It is already "fragemented". There is no "TLS ecosystem". The
MTA to MTA TLS landscape is nothing like the one for HTTPS.
> - Lastly, an opportunistic deployment can eventually become authenticated
> TLS, when DANE is introduced.
This is at least a decade away. My list of DANE enabled domains
for SMTP consists of ~230 domains, almost all of them in Germany.
There may in fact be 500. None of the major players are about
to deploy DNSSEC any time soon.
> Other opinions?
There is little choice here, opinions won't change the facts on
the ground. The use cases are not compatible, and either the
document excludes opportunistic TLS or a different set of best
practices is described for this case.
> PS: let's try to avoid the terminology discussion on what is
> "opportunistic", please.
+1
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
