Stephen Farrell's Discuss on draft-ietf-httpbis-tunnel-protocol-04: (with DISCUSS and COMMENT)

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

Stephen Farrell has entered the following ballot position for
draft-ietf-httpbis-tunnel-protocol-04: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


I think this should be an easy discuss but is needed.  RFC 7301
says:

Care must be taken when such identifiers may leak personally
identifiable information, or when such leakage may lead to
profiling or to leaking of sensitive information.  If any of
these apply to this new protocol identifier, the identifier
SHOULD NOT be used in TLS configurations where it would be
visible in the clear, and documents specifying such protocol
identifiers SHOULD recommend against such unsafe use.

That last sentence seems to imply that you ought replicate such
guidance here.


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


- 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.