Stephen Farrell's No Objection on draft-ietf-httpbis-tunnel-protocol-05: (with COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-httpbis-tunnel-protocol-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-tunnel-protocol/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for handling my discuss. 

--- OLD COMMENTS below, I didnt' check 'em.

- I can see situations where I might want to not tell the proxy
what protocol I'll be using inside TLS and when TLS1.3 hides
ALPM from the proxy (I hope:-) then could there be value
registering a "I'm not telling" ALPN value so that a UA
wouldn't have to lie to the proxy?

- I think you ought say what you expect a proxy to do if the
ALPN header field and the ALPN TLS extension value do not match
and I think that ought say that a CONNECT recipient in such
cases SHOULD NOT drop the connection solely on that basis.  If
they have some policy about it fine, but they shouldn't barf
just because there's a different order or spelling or just a
different value.

- Replicating values at multiple protocol layers produces a
common failure mode where code only uses one copy to do access
control or authorization or where two nodes in sequence use
different copies, with unexpected behaviour resulting. I think
you should call that out in the security considerations section
as it keeps happening.