The ALPN HTTP Header Field
draft-ietf-httpbis-tunnel-protocol-05

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

[Ballot comment]
ABNF is (has?) been fixed as a part of the Gen-ART review comments from Christer. Make sure these edits are folded in before the draft is approved.

[Ballot comment]
I'm a no-objection, because I'm assuming that this specification doesn't also map to CoAP and DTLS. If that's a bad assumption, please tell me, and I'll look at it through those lenses.

In this text,

  The HTTP CONNECT method (Section 4.3.6 of [RFC7231]) requests that
  the recipient establish a tunnel to the identified origin server and
  thereafter forward packets, in both directions, until the tunnel is
  closed.  Such tunnels are commonly used to create end-to-end virtual
  connections, through one or more proxies.
                        ^^^^^^^^^^^
                       
it may be obvious to everyone else how to do this through multiple proxies, and I bet I could guess how given two or three guesses, but I didn't see any description in the document of how to do that.

Is any description needed?

[Ballot comment]
I support Stephen's discuss and comments.

It looks like the discussion on Stephen's comments addressed the concern I had as a discuss, so I removed that and will follow along with his discuss and comments to address authentication.

[Ballot discuss]
The SecDir review called out an important point on authentication & authorization for

http://www.ietf.org/mail-archive/web/secdir/current/msg05748.html

The SecDir review has the the fuller set of questions.  Here is the summary:
    "The draft never says what the proxy should do if the client makes one claim
    in the ALPN header, but then does something different (including using different
    ALPNs in encapsulated TLS negotiations). Seems like it should.

    Also, the draft seems to suggest that it is okay to use the ALPN for policy/
    authorization decisions. This is unreliable from a security perspective. At minimum,
    I think the draft should explicitly call this out." 

It seems to me that authentication relies on TLS.  Maybe stating this explicitly would address the concern?  Is there a reason this should be in the ALPN header(I'm not sure of that, just asking)?

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

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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-httpbis-tunnel-protocol-04.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

As this document requests a registration in an Expert Review registry, Expert review
is required.

IANA understands that, upon approval of this document, there is a single action which must be completed.

In the Permanent Message Header Field Names subregistry of the Message Headers registry located at:

http://www.iana.org/assignments/message-headers/

one, new message header field name is to be registered as follows:

Header Field Name: ALPN
Protocol: http
Status: Standard
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request.  Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The ALPN HTTP Header Field) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document:
- 'The ALPN HTTP Header Field'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-06-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification allows HTTP CONNECT requests to indicate what
  protocol will be used within the tunnel once established, using the
  ALPN header field.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-tunnel-protocol/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-tunnel-protocol/ballot/


No IPR declarations have been submitted directly on this I-D.

# Shepherd Writeup for draft-ietf-httpbis-tunnel-protocol

## 1. Summary

Mark Nottingham is the document shepherd; Barry Leiba is the responsible Area Director.

This specification allows HTTP CONNECT requests to indicate what protocol will be used within the tunnel once established, using the ALPN header field.

Its intended status is Proposed Standard.

## 2. Review and Consensus

This document was brought to the Working Group as a result of work in WebRTC and related groups,
to satisfy a requirement there.

It was discussed in WG meetings as well as on-list, with a broad selection of participants.

Some participants were concerned that the mechanism is not verifiable; i.e., an intermediary does not have any assurance that the protocol in use inside an encrypted tunnel is actually advertised. However, we found that this is acceptable, because of the nature of the mechanism; it is not designed to provide such assurances, but instead allow coordination between cooperating (or semi-cooperating) actors.

Other participants were concerned because of confusion about whether this mechanism can be used when TLS is not in use, and the ambiguity that the use of ALPN entails when it is not. We resolved this by explicitly linking it to ALPN, so that the protocol identifier can nominate whether encryption is in use.

To our knowledge, this specification has not been implemented yet. This is not surprising, given the nature of the extension.


## 3. Intellectual Property

Each author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed.

No IPR declarations have been made.


## 4. Other Points

Idnits reports a few problems, but they are spurious.

IANA Considerations does not precisely identify the registry being entered into; the next draft will correct this.