Hi Peter,
I am actually fine with your new text. And just for context, this
section also talks about HSTS.
Thanks,
Yaron
On 06/22/2014 04:29 AM, Peter Saint-Andre wrote:
As part of the authors' work on addressing WG feedback, Yaron has
provisionally added the following statement to draft-ietf-uta-tls-bcp:
Combining unprotected and TLS-protected communication opens
the way to SSL Stripping and similar attacks. Clients and Servers
SHOULD prefer strict TLS configuration, as opposed to dynamic
upgrade from unencrypted to TLS-protected traffic, such as STARTTLS.
This statement strikes me as potentially problematic. Here's why:
For reasons other than security (e.g., see RFC 6335), TLS-only ports
have been deprecated and discouraged over the years in various
application protocols. For example, in Jabber/XMPP we once used port
5223 for SSL-only communications (this was in 1999-2004), and used port
5222 for unencrypted communications (similar to the HTTP convention of
the day). When XMPP was standardized at the IETF in RFC 3920, the IESG
told the XMPP WG to use STARTTLS upgrade on port 5222 (not a TLS-only
port of 5223), and we complied. The advice that Yaron has added might
lead naive implementers of XMPP to believe that they should use port
5223 even though it was never standardized and was actively discouraged
by RFC 3920 (and reinforced by RFC 6120). IMHO such behavior would be
bad, and would violate the spirit and letter of RFC 3920 / RFC 6120.
I suggest instead:
Combining unprotected and TLS-protected communication opens
the way to SSL Stripping and similar attacks. In cases where an
application protocol allows implementations or deployments a choice
between strict TLS configuration and dynamic upgrade from
unencrypted to TLS-protected traffic (such as STARTTLS), clients and
servers SHOULD prefer strict TLS configuration.
Peter
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
