Subject: Re: [hybi] Why not just use ssh?

From: Eric Rescorla <[email-masked]>
Date: Wed, 1 Sep 2010 08:20:11 -0700

On Tue, Aug 31, 2010 at 10:49 PM, Willy Tarreau <[email-masked]> wrote:

> On Tue, Aug 31, 2010 at 08:40:45PM -0400, John Tamplin wrote:
> > On Tue, Aug 31, 2010 at 8:26 PM, Adam Barth <[email-masked]> wrote:
> > > Why?  There are a number of compelling technical reasons to prefer the
> > > TLS-based handshake.  The counter arguments appear to be entirely
> > > non-technical.
> >
> > I don't know -- does changing the typical total frame header size
> > after RoHC from 7 bytes to 22 count as a technical argument?  With a
> > large number of frames likely being a few dozen bytes after
> > compression, that seems significant.  The requirement for any
> > implementation to include TLS libraries also seems to be a technical
> > argument.
>
> I'd like to add that the WG's goal is to achieve interoperability, and
> that's not only based on technical arguments. With TLS, an administrator
> can't analyze traffic. That's very important in schools for example, and
> some large enterprises, where the policy is simple : either you can
> analyze and filter, or you block.

I confess myself fairly unmoved by this particular argument:

1. As has been noted several times, TLS has a null encryption mode. It's
    true that it's not widely used, but since any implementation which was
going
    to support NPN would likely need an upgrade in any case, it would be
easy
    to add at that time. The natural move would be to say that:

    ws: -> TLS with NULL cipher
    wss: -> TLS with normal cipher.

2. There are a number of mechanisms enabling enterprises to monitor
TLS-encrypted
    traffic, including on-client spyware and intercepting proxies.

I'm generally not in favor of designing an inferior protocol solely to
enable
monitoring.

-Ekr

While I'm very favorable to a TLS
> version, I'd really like to have an HTTP one too. For this reason, I
> think we should ensure the handshake is simple enough to limit misuses,
> and looks a lot like HTTP so that it does not create a new attack
> vector. After all, the WS clients will be the browsers. They already
> have access to the net (direct or via proxies), and what we should be
> concerned about is that we can't do with WS what we can't already do
> with HTTP.
>
> So in my opinion, trying to stop protocol attacks before the handshake
> is complete is a waste of time since the HTTP vector is still available,
> however we have to ensure we won't complete the handshake on a non-WS
> server. For that use, I think that the nonce, whatever its form (possibly
> a WS ping+pong) is very important.
>
> Willy
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: John Tamplin <[email-masked]>
Date: Wed, 1 Sep 2010 11:43:26 -0400

On Wed, Sep 1, 2010 at 11:20 AM, Eric Rescorla <[email-masked]> wrote:
>  ... The natural move would be to say that:
>

As I understand it, even with the NULL cipher you still get TLS record
overhead which includes a hash of the record contents.  For small
frames, that will be noticeable overhead.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 1 Sep 2010 08:48:04 -0700

Agreed. I'm merely addressing the question of monitoring.

The overhead question is a direct technical tradeoff between the security
benefits
of TLS and the additional overhead. (minimum 15 bytes with TLS NULL). [0]

-Ekr

[0] We did at one point design a header compression method but it has never
been standardized. The integrity check cannot really be compressed, though
one could imagine specifying an even shorter MAC with correspondingly
less security.

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 1 Sep 2010 20:17:34 +0000

> > I might have missed that part of the discussion, but, if the server is replying to
> an Upgrade (perhaps over HTTPS) with a 101, and with a random nonce sent by
> the client, how is this vulnerable to a cross-protocol attack?
> 
> Cross-protocol attacks are quite subtle and generally take years to uncover.
> Your statement is roughly equivalent to "protocol XYZ uses encryption, it might
> be secure against man-in-the-middle attacks, right?"

Not sure how you made that jump. Along the lines of the above, your statement then could be claimed to be "roughly equivalent" to:

"protocol XYZ uses TLS-NPN, obviously it will be impervious to as yet unknown and undiscovered attacks"

Neither statement makes much sense, but luckily nobody's said either of the above. We design protocols based on plausible threat models. If we don't know all the attacks, then increased complexity is not necessarily the answer. Often times it has the opposite effect.

---

From: Adam Barth <[email-masked]>
Date: Wed, 1 Sep 2010 13:48:58 -0700

> Neither statement makes much sense, but luckily nobody's said either of the above. We design protocols based on plausible threat models. If we don't know all the attacks, then increased complexity…

I claim that the TLS+NPN protocol that I sent to the list earlier
resists cross-protocol attacks, which are a clear and plausible threat
model.  The security argument is fairly straightforward.

As for complexity, the TLS-only model is less complex than the
existing handshake, as evidenced by the fact that I would describe it
completely simply by deleting text from the current draft.

Adam

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Sep 2010 23:19:59 +0200

Hello Adam,

> completely simply by deleting text from the current draft.

If we want to be fair, we should say that the TLS-only model requires
a lot more additional capabilities on intermediates and servers, and
certificate management on the server. We're not comparing apples to
apples. Also, the current text is heavy because it tries to redefine
something as complex as HTTP without telling it is HTTP. So basically
you have 2616 in the draft. Having a paragraph stating that it relies
on "Upgrade: WebSocket" in requests and responses with a 101 in the
response (as 2817 explains it) would be a lot smaller and straightforward.

Also, I don't see why TLS could not be used on top of HTTP as is proposed
by 2817. This has the advantage of HTTP being easy to handle with existing
infrastructure and offers the better protection of TLS.

Just a few thoughts.

Willy

---

From: Adam Barth <[email-masked]>
Date: Wed, 1 Sep 2010 14:28:29 -0700

> infrastructure and offers the better protection of TLS.

RFC 2817 is a joke and, as I understand things, about to be moved to
historic.  Adding an HTTP framing arounds TLS is a bad idea for two
reasons:

1) It adds an extra round-trip.
2) It defeats the TLS-based handshake's resistance to cross-protocol attacks.

Adam

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 1 Sep 2010 14:40:23 -0700

On Wed, Sep 1, 2010 at 2:28 PM, Adam Barth <[email-masked]> wrote:

> historic.

I don't know about historic or not, but the Upgrade part of HTTP is
basically irrelevant
to the Web. Everyone uses 2818. The CONNECT part is still relevant.

-Ekr

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Sep 2010 23:41:53 +0200

> 1) It adds an extra round-trip.

not necessarily when the client knows it can pipeline connection requests

> 2) It defeats the TLS-based handshake's resistance to cross-protocol attacks.

not necessarily if the HTTP part is very limited and the only part the
attacker has control of is the body, which itself is a TLS handshake.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Sep 2010 23:47:17 +0200

> to the Web. Everyone uses 2818. The CONNECT part is still relevant.

Well, FWIW, in january I suggested to use CONNECT instead of Upgrade
(because CONNECT is more common) but there were objections due to the
fact that CONNECT is only used with proxies right now, and it would
*possibly* be dangerous to send that to servers that can sometimes act
as proxies. In fact in my opinion, CONNECT is exactly equivalent to
an Upgrade, in that it establishes a bidirectionnal connection between
the client and the other side, and nothing prevents the "other side"
from being the server itself. Still that would not change anything
WRT the cross-protocol attacks. It could even be worse, because while
upgrade-aware servers are the only one which can respond 101, any
stupid server which does not check the method might respond 200 to
a CONNECT.

Willy

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 1 Sep 2010 23:56:27 +0000

> I claim that the TLS+NPN protocol that I sent to the list earlier resists cross-
> protocol attacks, which are a clear and plausible threat model.  The security
> argument is fairly straightforward.

My question was whether there was anything to substantiate such a claim. The proposal you sent did not have an analysis, from what I recall. However, I'm actually much more interested in your analysis of the HTTP Upgrade handshake (not the TLS-NPN version).  In particular, I'd be interested in your analysis of much simpler variants of the handshake (than the one in version -76) that would provide similar protection against cross-protocol attacks.

It would be good to hear your answer to Greg's last question here:
http://www.ietf.org/mail-archive/web/hybi/current/msg01269.html

I know this is not your main focus, but I'm hoping you recognize that the "HTTP Upgrade variant" is much closer to the WG position than a "TLS-NPN only" position, and that this will convince you to contribute there as well. [Of course, having an HTTP upgrade variant does not preclude a TLS-NPN variant from being pursued as well. ]

> As for complexity, the TLS-only model is less complex than the existing
> handshake, as evidenced by the fact that I would describe it completely simply
> by deleting text from the current draft.

Deletion of text upstairs only? Presumably, you're assuming some other text (and complexity) gets added elsewhere (TLS-NPN spec), implying changes to massively deployed software, acceptance in the TLS WG based on perceived tradeoff, etc.