Hi, I think that's a great summary, Orit, thanks. I think the way to go would be to acknowledge in the BCP that a document for O-TLS is coming. While implementations should thus retain the "old" algorithms needed for O-TLS, deployments for strict TLS should not. We can have a look at how that could be best built into the BCP, if the list agrees.
Ralph On 15 October 2014 22:21, Orit Levin (LCA) <[email protected]> wrote: > 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 >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
