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.
The latest version of the draft added:
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. 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.
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).
So we could:
1. Say explicitly that opportunistic TLS is out of scope.
2. Or say explicitly that it is in scope, and with the same requirements
as "regular" TLS.
3. Or come up with a different set of requirements for opportunistic TLS.
I tend towards #2, because:
- With channel bindings, you can convert an unauthenticated TLS channel
into an authenticated one, after the fact.
- Also, because we do not want to fragment the TLS ecosystem.
- Lastly, an opportunistic deployment can eventually become
authenticated TLS, when DANE is introduced.
Other opinions?
PS: let's try to avoid the terminology discussion on what is
"opportunistic", please.
Thanks,
Yaron
On 10/03/2014 04:42 PM, Viktor Dukhovni wrote:
On Thu, Oct 02, 2014 at 05:20:56PM -0400, Sean Turner wrote:
The deployment recommendations address the operators of application
layer services that are most commonly used on the Internet, including
but not limited to:
o Operators of email servers who wish to protect the application-
layer protocols with TLS (e.g., IMAP, POP3, or SMTP between client
and server).
When you say "between client and server" do you mean "MUA to MTA"?
Because "MTA to MTA" SMTP is also between "client and server", and
so the latter phrase is potentially confusing if meant more narrowly.
The reason for the question is that TLS authentication is generally
not applicable with MTA to MTA SMTP (DANE adoption is likely around
~1000 domains at present).
o Operators of instant-messaging services who wish to protect their
application-layer protocols with TLS (e.g. XMPP or IRC between
client and server).
XMPP is also generally opportunistic TLS (modulo some few DANE
early adopters), unless again "client to server" means "user-agent
to server".
The recommendations address the utilization of all of the security services
provided by TLS, which include the following three services:
o Confidentiality: all (payload) communication is encrypted with the
goal that no party be able to decrypt it except the
intended peer.
o Data integrity: any changes made to the communication are
detectable by the peer.
o (optionally) Authentication: the peer is the intended entity to which
communication is desired. TLS support authentication of one or
both peers (i.e., server authentication or server and client
authentication).
This document does not address the rare deployment scenarios where
one of these three properties is not desired. In fact, it is so rare that
deployers
need to verify carefully consider why they need to deviate from the
recommendations provided in this document. An example of an audience
not needing confidentiality is the following: a monitored network where the
authorities in charge of that traffic domain require full access to
unencrypted
(plaintext) traffic, and where users collaborate and send their traffic in
the
clear.
However optional authentication is far from rare. Opportunistic
TLS is quite common outside of HTTP.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
