Subject: [hybi] Handshake complexity

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 5 Aug 2011 07:06:10 +0800

The purpose of the handshake in thewebsocketprotocol is to upgrade the protocol with the maximum likelihood that the server and any intermediaries both understood the request and support the protocol.

Aside from the handshake, thewebsocketprotocol could be implemented using very little software, apart from two pieces in the handshake: Base64 and SHA-1.

The only real requirement here is that the server does something predictable to the response.  The complexity of the handshake is unwarranted.  This is especially true when the server is already providing a number of other indications that it understood the request.

I therefore propose that a simpler approach be taken.

A "sec-websocket-key" header contains a random 10 digit integer.  (ABNF = 1*10DIGIT).  A server that understand the upgrade returns a "sec-websocket-accept" header with the same value, plus 77 (ABNF = "1" 1*10DIGIT).

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 4 Aug 2011 22:54:15 -0700

We've already discussed this topic to death (please search the archive). In
general people were concerned about simple computational methods (such as
adding together two random numbers), and we reached consensus on using
SHA-1. With all due respect you're not bringing any considerations to the
table that are new (we have already discussed the complexity of SHA-1 and
whether or not it creates an unacceptable barrier to implementation; the
consensus was that it did not.) As such, I don't think we should re-open
decisions that literally stalled this group for months, especially not when
we are in last call and there is nothing new that is being raised.

-Ian

On Thu, Aug 4, 2011 at 4:06 PM, Thomson, Martin <
[email-masked]> wrote:

> The purpose of the handshake in thewebsocketprotocol is to upgrade the
> protocol with the maximum likelihood that the server and any intermediaries
> both understood the request and support the protocol.
>
> Aside from the handshake, thewebsocketprotocol could be implemented using
> very little software, apart from two pieces in the handshake: Base64 and
> SHA-1.
>
> The only real requirement here is that the server does something
> predictable to the response.  The complexity of the handshake is
> unwarranted.  This is especially true when the server is already providing a
> number of other indications that it understood the request.
>
> A "sec-websocket-key" header contains a random 10 digit integer.  (ABNF =
> 1*10DIGIT).  A server that understand the upgrade returns a
> "sec-websocket-accept" header with the same value, plus 77 (ABNF = "1"
> 1*10DIGIT).
>
>
>
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 5 Aug 2011 08:02:26 +0200

> we are in last call and there is nothing new that is being raised.

I would honnestly say that the minor new element that came since this
endless discussion is that at that time it was speculated that using
a SHA-1 library in implementations should not be difficult since SHA-1
is freely available. Now we have some WS implementations and we should
check if they encountered unexpected difficulties in using SHA-1. I don't
think so and Martin's mail makes me think it's more a matter of discomfort
caused by needless software dependencies. But if some implementers were
bringing real implementation issues due to the use of SHA-1, we should
try to find how to address them. My personal feeling has always been that
this was a bit over-engineered but well, we managed to reach a consensus.

Regards,
Willy

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 4 Aug 2011 23:04:31 -0700

> this was a bit over-engineered but well, we managed to reach a consensus.

We managed it in Chrome FWIW :)

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 5 Aug 2011 08:10:12 +0200

> We managed it in Chrome FWIW :)

I'm not worried about the use of SHA-1 in browsers nor servers where crypto
is already available. I'm thinking more about the small devices Hixie was
targetting where SHA-1 would come with a big cost or with real implementation
issues (eg: 16-bit devices for which there is no SHA-1 implementation). But
I really don't believe that the same devices will use this protocol either.

Regards,
Willy

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 5 Aug 2011 14:03:23 +0300

(as individual)

we agreed on the SHA-1 time ago after a long... discussion
and honestly I don't see any  new element worth enough to reopen it.

We have already several implementations, browsers, servers, libraries etc
and nobody of the people implementing the protocol has found particular 
difficulties
on this particular aspect, as far as I know.

cheers
/Sal

On 8/5/11 9:10 AM, Willy Tarreau wrote:
>> On Thu, Aug 4, 2011 at 11:02 PM, Willy Tarreau<[email-masked]>  wrote:
>>

---

From: Greg Longtin <[email-masked]>
Date: Fri, 5 Aug 2011 11:36:51 -0500

Speaking of Android...

Greg Longtin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ian Fette (????????)
Sent: Friday, August 05, 2011 01:05 A
To: Willy Tarreau
Cc: [email-masked]
Subject: Re: [hybi] Handshake complexity

---

From: Brian <[email-masked]>
Date: Fri, 5 Aug 2011 13:14:30 -0700

I didn't have any issue implementing this even in ActionScript 3 -- there
were multiple SHA-1 libraries in AS3 readily available.  SHA-1 is not an
onerous requirement.  It's readily available in pretty much every language,
and the code that implements it is not particularly long.  Even in a C
implementation for an embedded device, the code to implement the rest of the
WebSocket protocol would absolutely dwarf the tiny bit of code to deal with
SHA-1.

Brian

On Fri, Aug 5, 2011 at 4:03 AM, Salvatore Loreto <
[email-masked]> wrote:

>>>>> We've already discussed this topic to death (please search the
>>>>> archive).
>>>>>
>>>> In
>>>>
>>>>> decisions that literally stalled this group for months, especially not
>>>>>
>>>> when
>>>>
>> ______________________________**_________________
>> hybi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/hybi<https://www.ietf.org/mailman/listinfo/hybi>
>>
>
>
> ______________________________**_________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/hybi<https://www.ietf.org/mailman/listinfo/hybi>
>