On Tue, Oct 14, 2014 at 12:47:33AM +0300, Yaron Sheffer wrote:
> What's new?
>
> - Lots of edits and some section rearrangement (thanks Sean!)
> - A short but important section on unauthenticated TLS.
Please replace the long obsolete reference to:
https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01
and even more obsolete:
https://tools.ietf.org/html/draft-ietf-dane-smtp-01
with
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-12
which supersedes both.
I don't know whether it makes sense to mention that authentication
via DANE TLSA might some day obviate the need for CRLs. I am
guessing that this being a BCP, and DANE not yet being a significant
current practice, such a comment might be premature. However, the
text does contain some "forward looking statements" about future
"must staple" signals, ... and thus perhaps other "forward looking
statements" might not be out of place.
Comments on particular text:
----------------------------
1.
The text about <128-bit ciphersuites is a bit imprecise:
Implementations SHOULD NOT negotiate cipher suites that use
algorithms offering less than 128 bits of security.
Rationale: Cipher suites that offer between 112-bits and 128-bits
of security are not considered weak at this time, however it is
expected that their useful lifespan is short enough to justify
supporting stronger cipher suites at this time. 128-bit ciphers
are expected to remain secure for at least several years, and
256-bit ciphers "until the next fundamental technology
breakthrough". Note that some legacy cipher suites (e.g. 168-bit
3DES) have an effective key length which is smaller than their
nominal key length (112 bits in the case of 3DES). Such cipher
suites should be evaluated according to their effective key
length.
The Rationale says "between" without clarifying which end-points
are included. Presumably the grey-zone is [112, 128). I've seen
no credible suggestions that anyone is remotely close to brute-forcing
a 128-bit key through exhaustive search. So perhaps "at least
several years", is rather too gloomy.
Finally, with opportunistic TLS, even 112-bit 3DES is stronger than
cleartext, and the "SHOULD NOT" does not apply. After all, in
these cases not finding a mutually agreeable cipher suite typically
leads to cleartext transmission, and cleartext is by far the weakest
option. I've not been able to convince Wietse that we should
disable any algorithms with opportunistic TLS (even 40bit export-grade
RC4). And he's not wrong, even though I've not seen any evidence
of its use in years, so I would be willing to risk cleartext with
any miraculous export-only peers.
And in particular the "MUST NOT" for RC4 is also inapplicable with
opportunistic TLS.
2.
SNI requirement is I think too strong:
TLS implementations MUST support the Server Name Indication (SNI)
extension for those higher level protocols which would benefit from
it, including HTTPS. However, unlike implementation, the use of SNI
in particular circumstances is a matter of local policy.
TLS clients SHOULD certainly signal SNI where applicable. However,
MUST is too strong IMHO. If the client is using opportunistic TLS
(without authentication), the server certificate is irrelevant,
and sending SNI might trigger handshake failures if the server has
no matching certificate (SMTP MTAs don't even know which reference
identifier applies to the peer).
For server applications which for various reasons don't support
multiple server identities, there is no reason to require SNI.
Such servers can simply ignore all SNI extensions in the client
HELLO. I have no intention of adding server-side SNI support in
Postfix. The Postfix SMTP client uses SNI only with DANE
authentication, because with DANE it is finally possibly to reliably
infer a server reference identifier (the TLSA base domain).
3.
SSL Protocol version recommendations.
Once again with unauthenticated opportunistic TLS even SSL 3.0 or
TLS 1.0 is (much) better than cleartext. So the MUST NOT SSL 3.0
and SHOULD NOT TLS 1.0 are too strong.
4.
Integrity protection text:
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).
It is not clear whether this is talking about integrity via
authenticated key exchange? Or integrity protection of the data
stream via HMAC, AEAD, ...? If the former, then there is once again
a conflict with keeping opportunistic TLS in scope.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
