Re: [Gen-art] Gen-ART review of draft-ietf-httpbis-tunnel-protocol-04

[Martin Thomson <[e-mail]>]

I apologize for missing this, it was badly filed.  Thanks for the
comments.  Fresh eyes are always helpful here, and you identified lots
of little pieces of potentially confusing text.

The changes will be in -05, but you can preview them on github:
https://httpwg.github.io/http-extensions/tunnel-protocol.html

On 22 May 2015 at 01:26, Christer Holmberg
<[e-mail]> wrote:
> ALPN = "ALPN":" protocol-id *(COMMA protocol-id)

Julian has corrected this also.  The production that is used is
described in RFC 7230, as referenced immediately before the rule.

> Are proxies prevented from implementing any tunneled protocol? If not,
> should the text say “Proxies might not implement the tunneled protocol”?

They aren't really proxies when they implement the tunneled protocol,
are they?  That's them taking off their proxy hat and putting on a
<some other protocol> server hat (or maybe their MitM hat).


> Do you need both sentences, or could they be combined into a single
> sentence?

Good point.  It was a little redundant:
https://github.com/httpwg/http-extensions/commit/fb18ad4

> “For a tunnel that is then secured using TLS [RFC5246], the header field

> I think it would be useful to add a reference to RFC 7301 after TLS
> handshake:
>               “…be carried within the TLS handshake [RFC7301].”

https://github.com/httpwg/http-extensions/commit/970b37f36

> What if TLS is NOT used?

No problem.  Application protocols can still have an identifier.  Note
that we say "Other substrates could negotiate the application protocol
differently." and also, later, have a whole section on the subject:
https://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-04#section-2.3

> Who makes the choice of application protocol then?

That is not known.  The ALPN identifiers - if the proxy understands
them - will probably have to include a definition that covers how the
protocol is negotiated.  All the current ones do.

> What if the recipient does not support, or does not want to use, the
> protocol(s) indicated by the client?

That's a little piece of necessary uncertainty.  Just as the proxy
cannot rely on this header field being present, it cannot rely on the
two peers actually negotiating the indicated protocol.  It can check,
but TLS is (or will be) designed to make that hard.

> The text says that the ALPN header field will contain the protocol that will
> be used within the tunnel.
>
> I think “will” is wrong wording, as the recipient has the final saying on
> what will be used. Later in the document the text says “intended to be
> used”, and I think that would fit here too.

You are right:
https://github.com/httpwg/http-extensions/commit/1bbe0aa4504

> “For a CONNECT tunnel that conveys a TLS session that in turn
>               encapsulates another protocol,…”
>
> The text is confusing. Shouldn’t it simply say “A tunnel that is secured
> using TLS”, or something?

Yeah, it's a little overwrought.  How about:
For a CONNECT tunnel that conveys a protocol secured with TLS
https://github.com/httpwg/http-extensions/commit/3e470d644

> “When used in the ALPN header field, the ALPN identifier and registry
>               are used…”
>
> What is meant by “registry” here?

Yeah, that's a little confusing.
How about: "When used in the ALPN header field, an ALPN identifier is used ..."
https://github.com/httpwg/http-extensions/commit/cdf620a