Subject: [Uta] "always use TLS"

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 21 Jun 2014 19:29:09 -0600

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

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 22 Jun 2014 12:01:14 +0300

Hi Peter,

I am actually fine with your new text. And just for context, this 
section also talks about HSTS.

Thanks,
	Yaron

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 22 Jun 2014 16:02:28 -0700

> port of 5223), and we complied. 

This may be the current practice, but is it something that we want to keep
or encourage? "Just starting TLS" is clearly simpler and more robust than
first going through a "STARTTLS" negotiation. I think it would make perfect
sense to allocate TLS only ports for services that we want to transition to
a "default TLS" posture. RFC 6335 explains why IANA should preserve the
port-numbers resource, and we could do that by phasing out usage of the
clear-text only port, and then removing its registration.

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Jun 2014 00:09:25 +0100

> clear-text only port, and then removing its registration.

That seems like a good strategic approach to me, where we can
get it agreed. I suspect its not for this WG though, but yeah,
maybe sometime in the not-too-distant we can deprecate some
clear-text ports. (I wonder which would be the first where that
is practical?)

S.

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 22 Jun 2014 16:22:28 -0700

> clear-text ports. (I wonder which would be the first where that

POP3 and IMAP come to mind. Maybe XMPP as well.

-- Christian Huitema

---

From: Watson Ladd <[email-masked]>
Date: Sun, 22 Jun 2014 16:25:51 -0700

> clear-text ports. (I wonder which would be the first where that

Maybe the echo service? The problem is that this requires global
coordinated action.

We can get to TLS everywhere even with STARTTLS and without stripping
attacks by remembering TLS support of peers and applying ratchets.
Once enough peers use TLS, we can force its use by making STARTTLS
mandatory, and aborting if the client does it support it.

By contrast freeing a port means figuring out if it is used by anyone
at all. I think we might be able to take DEC related protocols back,
but watch as someone says "well, I got this sewage treatment plant
that runs on a VAX, and when it breaks we'll replace it, but until
then..." This is not an imaginary problem: I seem to remember
discussion of a Cisco protocol that stepped on what was once supposed
to be a port for secure mail submission, and IANA, in its infinite
wisdom, changed the usage of the port.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 22 Jun 2014 19:16:55 -0600

> clear-text ports. (I wonder which would be the first where that

In XMPP, we have a way of signaling whether TLS negotiation is required, 
and as of May 19th of this year the entire network has moved in that 
direction:

https://github.com/stpeter/manifesto/blob/master/manifesto.txt

So I don't see that a TLS-only port (or two ports, since we have 
separate ports for client-to-server and server-to-server connections) 
does us any good, at least in the XMPP community. It sounds nice in 
theory (we're more secure!), but in practice it makes no difference.

And I, for one, don't want to fight the RFC 6335 battles again.

Peter

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Jun 2014 07:43:21 +0100

> clear-text only port, and then removing its registration.

That last bit is a misreading of RFC 6335. The document clearly says that there is no expected shortage of port numbers at the current run rate, and nowhere says that preservation should be considered above operational realities.

If every single IETF application that has its own (non-TLS) port was given a second port, the effect on the pool of port numbers would be almost unnoticeable. Please don't prematurely optimize in a way that hurts operations.

--Paul Hoffman