On Wed, Oct 15, 2014 at 08:21:07PM +0000, Orit Levin (LCA) wrote:
> 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.
I am inclined to leave the "how" the authors if they agree with
the comment. The comments that are not specific to opportunistic
TLS are repeated below.
> > * 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 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.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?
The quoted paragraph seems to overlap with the opportunistic space.
The requirment to use TLS "by default" needs a somewhat narrower
scope, something like:
User-agent configurations for statically configured connections
to services that support both TLS and cleartext SHOULD use TLS
"by default".
> > * 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.
> >
> > 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.
> >
> > * 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:
> >
> > 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.
I think the above clarification is needed especially for mandatory TLS.
> > * Section 7.5 (Revocation):
> >
> > See upstream comment re "forward looking" statements.
Not strictly about opportunistic. Really about whether discussion of
future revocation alternatives is in scope for a BCP. And if so, which
ones (for example, BCP alternatives to revocation when using DANE?).
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
