Subject: [hybi] [Technical Errata Reported] RFC6455 (3150)

From: RFC Errata System <[email-masked]>
Date: Wed, 7 Mar 2012 11:17:13 -0800 (PST)

The following errata report has been submitted for RFC6455,
"The WebSocket Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6455&eid=3150

--------------------------------------
Type: Technical
Reported by: Robert Munyer <[email-masked]>

Section: 4.1

Original Text
-------------
AQIDBAUGBwgJCgsMDQ4PEC==

Corrected Text
--------------
AQIDBAUGBwgJCgsMDQ4PEA==

Notes
-----
The "test vector" for Sec-WebSocket-Key encoding, provided in RFC 6455 section 4.1, is wrong.  It was processed by a base 64 encoder that was "improperly implemented" as mentioned in RFC 4648 section 3.5.  Pad bits were not set to zero, which is a "MUST" requirement in RFC 4648, and was also required by many other RFCs, going back to RFC 989 in the 1980s.  In the string "AQIDBAUGBwgJCgsMDQ4PEC==", the final C should be changed to A.

In a Sec-WebSocket-Key header sent by a properly implemented client, the last letter will always be A, Q, g or w.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6455 (draft-ietf-hybi-thewebsocketprotocol-17)
--------------------------------------
Title               : The WebSocket Protocol
Publication Date    : December 2011
Author(s)           : I. Fette, A. Melnikov
Category            : PROPOSED STANDARD
Source              : BiDirectional or Server-Initiated HTTP
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 08 Mar 2012 01:24:11 +0100

* RFC Errata System wrote:
>Section: 4.1
>
>Original Text
>-------------
>AQIDBAUGBwgJCgsMDQ4PEC==
>
>Corrected Text
>--------------
>AQIDBAUGBwgJCgsMDQ4PEA==
>
>Notes
>-----
>The "test vector" for Sec-WebSocket-Key encoding, provided in RFC 6455
>section 4.1, is wrong.  It was processed by a base 64 encoder that was
>"improperly implemented" as mentioned in RFC 4648 section 3.5.

If this is true, why did we fail to catch this in time? Was it added
late, for instance? (I would like an analysis to support discussions
whether to create a review team specifically for this kind of formal
syntax error.)
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Mar 2012 17:28:05 -0700

> whether to create a review team specifically for this kind of formal

As far as I can tell from the erratum, this was a problem with
generation of an example, not a syntax error.

Peter

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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 08 Mar 2012 01:37:27 +0100

>generation of an example, not a syntax error.

Base64 is a formal language. Unlike interpreting english prose, people
are not good at spotting problems with formal languages, in the case
here they would most probably have to use software to verify the code.
That it occurs in an example does not really matter, people would like-
ly use the examples in the specification for their first tests, and if
they come up with different results there is costly confusion, to the
point that people might change their correct implementation so it re-
produces the example, which would lead to interoperability problems. I
think we should try to avoid this kind of costly bug, and understanding
how we ended up with it, if the report is correct, is the first step.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Mar 2012 17:41:46 -0600

> how we ended up with it, if the report is correct, is the first step.

Understood.

Alexey, can you verify that the example is incorrect?

Peter

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

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 22 Mar 2012 13:50:51 +0900

> >>> whether to create a review team specifically for this kind of formal

This text was introduced in 03->04 update to provide example for
Sec-WebSocket-Key and Sec-WebSocket-Nonce (no longer used), and was also
used in the example of opening handshake as a value for Sec-WebSocket-Nonce.
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-04

On 05->06 update, we dropped Sec-WebSocket-Nonce but left the text as an
example of base64 encoding procedure, and it remained in the RFC.
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06

> > produces the example, which would lead to interoperability problems. I

It makes sense.

In this particular case, I think it doesn't cause such confusion so much
since it's not used anywhere else and it's unlikely that people implement
base64 encoder by themselves and then check if their implementation is
working correctly using this test vector. It's also the reason why we
didn't notice this error in implementing/testing handshake processor code.
We never thought using this in our tests.

> Alexey, can you verify that the example is incorrect?

+1 for the reported errata.

RFC 4648
- Section 3.5 "These pad bits MUST be set to zero by conforming encoders,
which is described in the descriptions on padding below."
- Section 4 Paragraph 6 "When fewer than 24 input bits are available in an
input group, bits with value zero are added (on the right) to form an
integral number of 6-bit groups."

Values for "EC" are 0b000100 0b000010 in binary. The last unused 4 bits
0010 must be 0000.

Takeshi

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Mar 2012 12:11:58 -0600

On 3/21/12 10:50 PM, Takeshi Yoshino wrote:
> On Thu, Mar 22, 2012 at 08:41, Peter Saint-Andre
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>>> If this is true, why did we fail to catch this in time? Was
>>>> it added late, for instance? (I would like an analysis to
>>>> support discussions whether to create a review team
>>>> specifically for this kind of formal syntax error.)
> 
> 
> Sec-WebSocket-Key and Sec-WebSocket-Nonce (no longer used), and was
> also used in the example of opening handshake as a value for
> Sec-WebSocket-Nonce. 
> On 05->06 update, we dropped Sec-WebSocket-Nonce but left the text
> as an example of base64 encoding procedure, and it remained in the
> RFC. 
>> Base64 is a formal language. Unlike interpreting english prose,
>> people are not good at spotting problems with formal languages,
>> in the case here they would most probably have to use software to
>> verify the code. That it occurs in an example does not really
>> matter, people would
> like-
>> ly use the examples in the specification for their first tests,
>> and if they come up with different results there is costly
>> confusion, to the point that people might change their correct
>> implementation so it re- produces the example, which would lead
>> to interoperability problems. I
> 
> 
> It makes sense.
> 
> In this particular case, I think it doesn't cause such confusion so
> much since it's not used anywhere else and it's unlikely that
> people implement base64 encoder by themselves and then check if
> their implementation is working correctly using this test vector.
> It's also the reason why we didn't notice this error in
> implementing/testing handshake processor code. We never thought
> using this in our tests.
> 
> 
> RFC 4648 - Section 3.5 "These pad bits MUST be set to zero by
> conforming encoders, which is described in the descriptions on
> padding below." - Section 4 Paragraph 6 "When fewer than 24 input
> bits are available in an input group, bits with value zero are
> added (on the right) to form an integral number of 6-bit groups."
> 
> Values for "EC" are 0b000100 0b000010 in binary. The last unused 4
> bits 0010 must be 0000.

Takeshi, thank you for checking. I shall process this erratum as
"Verified".

Peter

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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 23 Mar 2012 10:00:43 +0100

On 22/03/2012 19:11, Peter Saint-Andre wrote:
>> <[email-masked]<mailto:[email-masked]>>  wrote:
>>
This looks correct. Thank you Takeshi.