* Section 2.1 first bullet below first paragraph:
With unauthenticated opportunistic TLS this is not attainable.
Confidentiality: all (payload) communication is encrypted
with the goal that no party should be able to decrypt it
except the intended receiver.
Confidentially protection is attained only against passive
monitoring. Indeed with a "baseline" security of cleartext,
opportunistic applications may send cleartext when encryption
does not appear to be supported by the peer. So the above applies
only for peers for which encryption happens to be possible.
* Section 2.1, 3rd bullet below first paragraph:
Quote:
Authentication: this means that an end-point of the TLS
communication is authenticated as the intended entity to
communicate with. TLS allows to authenticate one or both end-
points in the communication. Some TLS usage scenarios do not
require authentication, and are further discussed in Section 2.2.
Not sure whether my comment on the above is in scope for the BCP,
but the subtler aspects of mutual authentication in TLS are not
widely understood, and perhaps ought to be more widely disseminated.
One might think that mutual authentication in TLS is essentially
agnostic about who authenticates whom and that active attack
prevention can be attained via authentication of either the server
or the client. This naive view is not correct.
When a server provides a public service open to all (accepting
email for a domain, a free search service, ...) authentication
of the server by the client is required and sufficient to provide
the channel security necessary to assure the client that its
access to the public service is not subject to active attacks.
Any authentication of the client by the server in this context
is no substitute for authentication of the server by the client.
In fact clients of public services may prefer to remain anonymous.
Thus, while in some cases (local policy, DANE, ...) a sending
MTA may elect to authenticate the next-hop MX host, the authentication
of sending MTAs by MX hosts plays no role in protecting the
transmission channel and has rather limited potential utility.
On the other hand, when a server supports the establishment of
a bi-directional messaging channel (say XMPP) or provides access
to confidential data available exclusively to a client or set of
clients, then authentication of the client is needed to assure
the server that it is initiating new messages or making data
available to the right client. In such cases it is not enough
for the client to authenticate the server, the server needs to
also authenticate the client (whether through TLS client certs,
or some application-layer mechanism ideally channel-bound to the
TLS connection).
Is discussion of this topic in scope?
* Section 2.1, 3rd paragraph below initial bullet points:
As before, this seems unclear:
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.
Is this talking about integrity in the AEAD sense (protection
against modification by a party other than one with whom the
handshake took place), or in the sense of handshake authentication
to ensure that the key exchange took place with the right party?
* Section 2.2, paragraph 1, please update DANE SMTP draft reference.
draft-ietf-dane-smtp-with-dane
* Section 2.2, paragraph 2, please reference
draft-dukhovni-opportunistic-security
* Section 4.1.1, SSL 2.0 "MUST NOT":
This is fine even for opportunistic TLS. Clients and servers
that support only SSL 2.0 are exceedingly rare now. In Postfix
SSL 2.0 is disabled in the opportunistic client (no SMTP servers
are v2 only), but for now still enabled in the opportunistic SMTP
server (i.e. port 25, but not 587 where TLS is mandatory). We
surely would not break any extant SMTP clients by disabling SSL
2.0 also in servers, though given that the server happily accepts
cleartext, the case for doing so is not compelling.
If some auditor pressures users to disable said server support,
nothing bad happens, no interesting traffic goes in the clear
instead.
* Section 4.1.1, SSL 3.0 "MUST NOT", TLS 1.0 SHOULD NOT.
This on the other hand is too strong for opportunistic TLS. Even
SSL 3.0 is better than cleartext. We can say that opportunistic
TLS clients that would otherwise resort to cleartext transmission
MUST support at least TLS 1.1, so that older/weaker protocol
versions are negotiated only with servers that don't support TLS
1.1. However they MAY offer to negotiate TLS 1.0 and perhaps
SSL 3.0.
It should also be noted the the TLS protocol does not give clients
the option to advertise arbitrary combinations of protocol versions.
The set of supported protocol versions must be a contiguous range,
with the client sending just the minimum and maximum supported versions.
Thus a client cannot, for example, disable just TLS 1.0, while
leaving SSL 3.0 and TLS 1.1 enabled. Users need to be careful
to make sure that the disabled protocols start with SSL 2.0 and
continue to some highest disabled protocol version, with all
remaining protocols enabled.
OpenSSL, for example, will support the first not-disabled protocol,
up to, but not including, the first disabled protocol after that.
Thus disabling SSL 2.0 and TLS 1.0, leaves SSL 3.0 enabled which
means that TLS 1.1 and TLS 1.2 are also disabled, and the client
ends up supporting *only* SSL 3.0. Avoid "holes" in the set
of disabled protocol versions!
* Section 4.1.1, MUST offer to negotiate TLS 1.2:
I appreciate the need to move forward to 1.2 and some day to 1.3.
I am concerned about the manifold issues with TLS 1.2 interoperability.
Users will continue to disable 1.2 in various cases for some
time. Can there be any wiggle-room here to disable TLS 1.2 for
selected peers where 1.2 is determined to run into problems?
* Section 4.1.3, protocol fallback.
While I'm not aware of any opportunistic TLS implementations that
do protocol fallback (rather than just fallback to cleartext when
handshakes fail), perhaps some exist. For consistency, banning
SSL 3.0 seems too strong if the alternative is cleartext. Ideally,
they should try fallback with a range of 3.0--3.2 (TLS 1.1) if
1.2 fails. I am not aware of significant interop issues with 1.1.
They will then use 3.0 only when nothing else is an option.
* Section 4.2 "Strict TLS":
Quote:
In many application protocols, clients can be configured to
use TLS even if the server has not advertised that TLS is
mandatory or even supported (e.g., this is often the
case in messaging protocols such as IMAP and XMPP).
Application clients SHOULD use TLS by default, and disable
this default only through explicit configuration by the user.
Some user-agent applications contact a small fixed set of peers
(often just one submission, IMAP or XMPP server). For these,
defaulting to TLS and requiring user action to use cleartext
is reasonable.
Other applications (MTAs, XMPP infrastructure servers, ...)
potentially contact similar servers in any domain on the
Internet. They cannot default to TLS on, until TLS adoption
by peers is universal. They MUST operate opportunistically,
and determine peer by peer which peers support TLS and which
do not. The above advice is based on familiarity with just
the first class of applications.
Is the "SHOULD" meant to provide sufficient wiggle-room to
allow SMTP and XMPP relays to be out of scope? Or should the
advice be a bit more specific?
* Section 4.4 Resumption:
Quote:
If TLS session resumption is used, care ought to be taken
to do so safely. In particular, when using session tickets
[RFC5077], the resumption information MUST be authenticated
and encrypted to prevent modification or eavesdropping by
an attacker. Further recommendations apply to session
tickets:
Not sure what "authenticated" is intended to mean here. RFC
5077 recommends an encrypt + MAC ticket encoding. Why does this
BCP need to comment on ticket encoding security? This is rarely
an application issue, I would expect ticket encoding/decoding
support to be provided by TLS toolkits, not application code.
The chief interaction between applications and session tickets
is key management, when the same session needs to work with a
cluster of hosts. So I thin the BCP should restrict its attention
to the key management issues, which are not IIRC addressed in
5077.
For example, Postfix has code to provide OpenSSL with the relevant
session ticket encryption/decryption keys (which Postfix rotates
by default hourly), but the underlying encoding details are
handled by the OpenSSL library.
* Section 4.6 SNI.
Consensus: Clients that do know a primary DNS reference identifier
for a server, and will use it to authenticate that server, MUST
send SNI. This includes, for example, "opportunistic DANE TLS"
clients that are expected to use the TLSA base domain in this
capacity. [ If "opportunistic DANE TLS" is too bleeding edge a
notion for this draft, the example can be safely skipped. ]
However: As I posted previously. Not all clients know what to send in
SNI and SNI could lead to server connection drops if servers
react poorly to names for which don't have explicitly configured
certificates. With unauthenticated TLS, the client ignores the
server certificate anyway, so there is nothing to be gained by
sending SNI (in fact this avoids a data leakage in the clear).
So I would so far as to say that SNI is NOT RECOMMENDED for
unauthenticated TLS.
On the server side, there is simply no requirement to support
SNI when the server is not doing any "virtual hosting". So server
side SNI support is optional.
Servers supporting opportunistic clients SHOULD tolerate SNI
requests that don't corresponding to any particular server
certificate, and just respond with some appropriate choice of
"default" or "closest match" certificate.
* Section, 5.1, MUST NOT RC4.
Compromise: OK as MUST NOT for mandatory TLS.
No surprise to anyone, I think this is too strong for opportunistic
TLS where cleartext might otherwise result if RC4 is excluded.
RC4 has been the most performant (absent hardware AES support
which is relatively new still) cipher for many applications until
very recently. Also with some of the CBC attacks even more users
moved to RC4.
Thus RC4 is widely used, preferred, and is the sole working
cipher suite on a non-negligible if small fraction of servers.
Thus for opportunistic TLS it is (for now) premature IMHO to ban
RC4. I'd like to see it substantially fade from use (like export
ciphers) before it is made MUST NOT.
* Section 5.1 (<128 bit text):
See comment upstream.
* Section 5.5 (DH cipher suites) ranking:
Quote:
* Elliptic Curve DHE with negotiated parameters
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, with 2048-bit Diffie-Hellman
parameters
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, with 1024-bit parameters.
It should be made more clear that the choice between the last
two is entirely based on server support for either or both. No
information is (as noted) available from the client. Thus servers
than can send DH 2048-bit parameters SHOULD do so, unless it is
known that this will cause interoperability issues with a
non-negligible fraction of clients.
* Section 7.1:
Update obsolete references as previously noted. Note that when
TLS is unauthenticated, the entire question is out of scope.
Further rules for establishing reference identities may appear
in application-protocol-specific documents that refine 6125.
This implies that authentication cannot take place when no secure
reference identity is known, but does not say it outright.
Applications where this is an issue must either employ unauthenticated
TLS or must employ some identifier other than the peer hostname
(e.g. the MX or SRV input domain used to locate the target host)
or any explicitly configured identifier that is part of the
mandatory TLS configuration for the destination. The right choice
to be specified in relevant application-specific standards.
* Section 7.5 (Revocation):
See upstream comment re "forward looking" statements.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
