Subject: Fwd: New Version Notification for draft-pardue-httpbis-dont-be-clear-00.txt

From: Lucas Pardue <[email-masked]>
Date: Tue, 16 Mar 2021 00:47:18 +0000

Hello HTTP WG,

Anthony and I found a little Alt-Svc "what if" case where some naive
parsing code might stumble when trying to process keyword "clear" or an
ALPN protocol ID of "clear". The ALPN space is large enough that the
chances are small, but we wrote a little I-D (forwarded) that would reserve
the sequence so that nobody might do this unwittingly.

Thoughts?

Maybe the odds of actual problems are so small that doing nothing is ok. Or
maybe this is a potential improvement to bank for some type of RFC 7838bis.
Either way, the problem seems well-formed enough to document in order to
gather feedback or criticism :)

Cheers
Lucas

---------- Forwarded message ---------
From: <[email-masked]>
Date: Tue, Mar 16, 2021 at 12:33 AM
Subject: New Version Notification for
draft-pardue-httpbis-dont-be-clear-00.txt
To: Anthony Ramine <[email-masked]>, Lucas Pardue <[email-masked]

A new version of I-D, draft-pardue-httpbis-dont-be-clear-00.txt
has been successfully submitted by Lucas Pardue and posted to the
IETF repository.

Name:           draft-pardue-httpbis-dont-be-clear
Revision:       00
Title:          Reserving the clear ALPN Protocol ID
Document date:  2021-03-16
Group:          Individual Submission
Pages:          4
URL:
https://www.ietf.org/archive/id/draft-pardue-httpbis-dont-be-clear-00.txt
Status:
https://datatracker.ietf.org/doc/draft-pardue-httpbis-dont-be-clear/
Html:
https://www.ietf.org/archive/id/draft-pardue-httpbis-dont-be-clear-00.html
Htmlized:
https://tools.ietf.org/html/draft-pardue-httpbis-dont-be-clear-00

Abstract:
   HTTP Alternative Services (Alt-Svc) are identified by a tuple of
   Application-Protocol Layer Negotiation (ALPN) protocol identifier, a
   host and a port.  The wire format for Alt-Svc is defined in ABNF and
   encodes this tuple or the keyword "clear", which has a special
   meaning.  This memo reserves the ALPN protocol identifier "clear" to
   reduce the chances of accidental aliasing with the "clear" keyword.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Julian Reschke <[email-masked]>
Date: Tue, 16 Mar 2021 08:38:41 +0100

> ALPN protocol ID of "clear". The ALPN space is large enough that the

Not "naive", but really broken, right?

> chances are small, but we wrote a little I-D (forwarded) that would
> reserve the sequence so that nobody might do this unwittingly.
>
> Thoughts?
>
> Maybe the odds of actual problems are so small that doing nothing is ok.
> Or maybe this is a potential improvement to bank for some type of RFC
> 7838bis. Either way, the problem seems well-formed enough to document in
> order to gather feedback or criticism :)
> ...

If we did a 7838bis, we *could* add a warning that using a broken parser
is bad. The problem is that people who actually read the spec whould
probably know this already.

Best regards, Julian

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 16 Mar 2021 11:55:39 -0400

I think this is probably worthwhile if there's some nontrivially deployed
parser with this bug.  Otherwise, it doesn't seem necessary.

---

From: Erik Nygren <[email-masked]>
Date: Tue, 16 Mar 2021 12:04:23 -0400

I also added it to my (growing) list of topics for 7838bis.
There's starting to be enough for 7838bis that we may want
to fold it in there rather than have a stand-alone draft.
I'm interested in helping pull together 7838bis in the next
few months if others are interested, but have a number
of other things I need to work through first.

Best, Erik

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 16 Mar 2021 16:15:27 +0000

Hey Erik,

> of other things I need to work through first.

We'd be happy to collaborate and identify fixes that address problems that
a broad set of people agree exist and need solving.

Cheers,
Lucas