Hi, This is a long list of changes, and pretty much exactly why I favour having OE/OS out of scope.
Ralph On 15 October 2014 07:33, Viktor Dukhovni <[email protected]> wrote: > * 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
