Subject: [hybi] Simple payload masking

From: Paul Colomiets <[email-masked]>
Date: Tue, 21 Dec 2010 07:13:34 +0200

21.12.2010, 06:57, "Eric Rescorla" <[email-masked]>;:

>>  But there is a TLS for security. The only thing this protocol should do is
>>  don't look like HTTP. So I really think that AES encryption would be a
>>  problem for protocol adoption. Not only because CPU needed, but also
>>  because of need of using some big library (e.g. openssl) for it.
>  The amount of CPU needed is marginal. You don't need anything anywhere near
>  as heavyweight code size wise as OpenSSL to just get AES, and of course
>  the primary target environment (browsers), already has an AES impl.
>
>  -Ekr

I don't care about CPU. Yes browsers have AES implemented. But there are
small servers and tiny API clients (consider twitter streaming API could use
websockets). It's just much harder to implement and harder to get right.

It also means that if e.g. python want to include websockets implementation
standard library (it has http currently), it needs either to reimplement AES
or include also some cryptographic library.

Is that a trivial task to implement AES?
--
Paul

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Dec 2010 21:16:17 -0800

It's a trivial task to download it. There are a very large number of
available open source
AES stacks.

-Ekr

2010/12/20 Paul Colomiets <[email-masked]>

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: "Alexander Philippou" <[email-masked]>
Date: Tue, 21 Dec 2010 11:58:20 +0200

> It's a trivial task to download it. There are a very large number of available open source AES stacks.
> 
> -Ekr

If AES or any other crypto-related functionality is included in the non-secure version of WS, then out-of-browser closed-source apps that use a WS implementation provided by an independent library (not provided by the OS) will need an export license. OS and browser vendors already include crypto so it's not an issue to them, but for others the pain of export restrictions might be an inhibitor to adoption. It would be good to keep the non-secure WS free of crypto functionality or alternatively to make it optional/negotiable.

Alexander

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Dec 2010 08:02:30 -0800

On Tue, Dec 21, 2010 at 1:58 AM, Alexander Philippou <[email-masked]>wrote:

> available open source AES stacks.
> >
> > -Ekr
>
> If AES or any other crypto-related functionality is included in the
> non-secure version of WS, then out-of-browser closed-source apps that use a
> WS implementation provided by an independent library (not provided by the
> OS) will need an export license.

I don't believe this is true if used in the way I describe, but more
importantly any realistic
stack is going to have TLS, which means it's going to have the relevant
algorithms.

-Ekr

> OS and browser vendors already include crypto so it's not an issue to them,
> but for others the pain of export restrictions might be an inhibitor to
> adoption. It would be good to keep the non-secure WS free of crypto
> functionality or alternatively to make it optional/negotiable.
>
>