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

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 08 Jun 2015 06:01:35 -0700

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.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 9 Jun 2015 11:15:53 +1000

Hi Stephen,

> On 8 Jun 2015, at 11:01 pm, Stephen Farrell <[email-masked]> wrote:

Seems reasonable to me.

Or the UA could omit the header, or the UA could send the header with no value. 

> just because there's a different order or spelling or just a

Seems reasonable to me. 

> you should call that out in the security considerations section

Again, seems reasonable.

I wonder if it would be helpful to explicitly motivate it — i.e., say this header is there to make the information available at the HTTP layer during CONNECT, so that the server can refuse the connection gracefully if they like (e.g., with a 403); without it, the server would have to sniff ALPN in the tunnel and then close the connection rudely.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 09 Jun 2015 11:17:26 +0100

Hi Mark,

That's all good from my POV and I like your suggestion at the end.

Cheers,
S.

>> 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.
>> 
>> 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.
> 
> Seems reasonable to me.
> 
> 
>> - 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.
> 
> Again, seems reasonable.
> 
> I wonder if it would be helpful to explicitly motivate it — i.e., say
> this header is there to make the information available at the HTTP
> layer during CONNECT, so that the server can refuse the connection
> gracefully if they like (e.g., with a 403); without it, the server
> would have to sniff ALPN in the tunnel and then close the connection
> rudely.
> 
> Cheers,
> 
> 
> -- Mark Nottingham   https://www.mnot.net/
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Jun 2015 14:09:25 -0700

Finally getting^Wmaking some time for this.

>> That last sentence seems to imply that you ought replicate such

Likewise.  https://github.com/httpwg/http-extensions/commit/6c7b987

> Or the UA could omit the header, or the UA could send the header with no value.

I think those are better options.  Do you think we need to say that
with the other agreed changes already in place?

>> just because there's a different order or spelling or just a

I'll roll that into the point below.

> I wonder if it would be helpful to explicitly motivate it — i.e., say this header is there to make the information available at the HTTP layer during CONNECT, so that the server can refuse the conn…

I think that we're going to need some review on this change.

https://github.com/httpwg/http-extensions/commit/a62c60a

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 10 Jun 2015 12:16:52 +1200

> https://github.com/httpwg/http-extensions/commit/a62c60a

Recall the long discussion for March WGLC on this documents -02.

That discussions made it clear that:
a) this header value was *not* intended to describe the full protocol
stack - only an undefined number (1..N) protocol(s) at the top of it.
b) TLS was mandatory - except when it wasn't used. (WTF!)
c) some values describe whole stacks, some only the leaf protocol.

Consider the (multiple) cases of ALPN "http/1.1" - TLS or not?. Which we
went over exhaustively earlier.

When a proxy MUST inspect the packets in order to understand what the
header contains it becomes a waste of bytes. We just go with sniffing.
Its way simpler.

I stepped out of the discussions on this document when that point became
clear. If the header *did* describe the whole protocol stack, it would
be wonderful and I'm back in again trying to add support to Squid.
Otherwise its just a waste of time for me.

Amos

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 10 Jun 2015 00:27:31 +0000

------ Original Message ------
From: "Amos Jeffries" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 10/06/2015 12:16:52 p.m.
Subject: Re: Stephen Farrell's Discuss on 
draft-ietf-httpbis-tunnel-protocol-04: (with DISCUSS and COMMENT)

>header contains it becomes a waste of bytes. We just go with sniffing.

that's the conclusion I reached also.  Will need to sniff, and ignore / 
strip the ALPN header, certainly won't be making policy decisions on it.

Given that the header is intended for intermediaries it's hard to miss 
the irony in this.

Adrien

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Jun 2015 15:21:14 +1000

[ paring down CC: list ]

> On 10 Jun 2015, at 7:09 am, Martin Thomson <[email-masked]> wrote:
> 

Looks OK to me - others?

---

From: Barry Leiba <[email-masked]>
Date: Thu, 11 Jun 2015 16:57:11 +0100

OK... the telechat is over, and Martin has some updates queued.
Martin, please post the updates, let's wait for Stephen to get back
home and review them (that might take until the end of the month), and
in the meantime let's make sure the httpbis working group is OK with
the changes.

Barry, ART Director

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 Jun 2015 09:48:58 -0700

On 11 June 2015 at 08:57, Barry Leiba <[email-masked]> wrote:
> Martin, please post the updates,

Roger that, posted.

> Barry, ART Director

And you will never get sick of signing emails that way, will you?

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 11 Jun 2015 20:38:59 +0000

Martin (Thomson),

On Jun 11, 2015 11:49, "Martin Thomson" <[email-masked] <mailto:[email-masked]>> wrote:
>
> On 11 June 2015 at 08:57, Barry Leiba <[email-masked] <mailto:[email-masked]>> wrote:

Did you not wonder why the acronym didn't change when TSV dropped out of the proposal?

Now, you know why!

:D