Victor, Thanks for your thorough review and feedback. This has been a fascinating and an educational read for me and has tones of useful information for those who deploy or consider deploying TLS "opportunistically" in its broadest sense. It seems that I have been under the false assumption that only a couple of recommendations in the draft constrain "O" deployments. So it is very helpful to learn about this now - before the last call.
If the list agrees with Victor's technical assessment of "O" TLS, then I join those who think that it doesn't make much sense to include any of the specific "O" TLS recommendations in the baseline BCP. This deliverable is not intended for audience that use or plan using TCP "opportunistically"... This audience will need to know much more than the "strict TLS" in order to make smart deployment decisions. As we know, all these are in the scope of UTA and deserve separate IDs for "O" TLS and/or per application. (The TLS **implementation** recommendations must not be segmented between the two modes, though.) Authors, please, use your judgment whether to ask the list the same scope question again or go ahead and suggest your preferred way forward. Victor, some of your text is not directly related to the opportunistic recommendations. So, if you feel that it will be useful to include these parts or modifications into the BCP, please, submit them in a format suggesting how exactly incorporate them into the -05 version. Thanks, Orit. > -----Original Message----- > From: Uta [mailto:[email protected]] On Behalf Of Viktor Dukhovni > Sent: Tuesday, October 14, 2014 10:33 PM > To: [email protected] > Subject: [Uta] [uta] TLS BCP -05 detailed comments. draft-ietf-uta-tls-bcp- > 05.txt > > * 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 _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
