Minutes for HTTPBIS at IETF-95
minutes-95-httpbis-1

# Minutes from HTTPBIS Session 1, IETF 95

## Agenda Summary and Administrivia (chair)
### Thanks to Barry for his service as AD
### Welcome to Alexey as new AD

## Specification Status (chair)

## Active Drafts

### Opportunistic Security (chair)
(in WGLC)

#### Separate Lifetime from Commitment

Martin: I have trouble wrapping my head around this one.  We should just do
this, though with slightly restructured JSON, something along the lines of what
Kari suggested.

Mark: Caching gets a little interesting here too.  You effectively need a
lifetime for the alternative service without having server authentication.

Martin: Mike's suggestion was to say "The following alternatives have the
following lifetime, which require/don't require security".

Mark: Let's take this offline.  It sounds like this is not adding too much
complexity.  I'm sensitive to that because we only have one implementer, so we
want to keep complexity down.

#### Requirement to Filter Alt-Svc Header Needs To Be Explicit Normative Text

Mark: Seems to be uncontroversial

#### Commit without Same Host Opt In

Basically the same resolution as the first issue.  I think we can then take
this to Last Call.

#### Other Issues

Julian: There is one open question that's not in the github tracker, which is
the restriction that the opportunistic rquest needs to be over HTTP2, as
discussed on the list.  The spec better explains what the problem is than it
did before, but it's still confusing to read. (description of the problem)

Mark: What would you like to see?

Julian: The server should reject opportunistic requests in the case where it's
not clear that the code making decisions on the content has the correct
information.

Martin: The MUST requirement is of no use to us.  I think with Julian's
hand-waving, we're going too far.  I think it's clear where the danger lies.  I
think if we can do that, we've achieved our goal here; then being proscriptive
about what clients and servers must do here doesn't add any value.  We should
articulate the problem and leave it at that.

Julien: The problem is that for the server code it's untestable whether the
application running inside the server is broken, so it has to be a conscious
decision by the server operator enabling or disabling this behavior.

Michael Bishop: This is a problem for servers.  We know this exists.  If a
request comes in, we look at the arriving port and what hosts/resources are
configured for that.  It may not be a solvable problem in the protocol spec; if
we want to do anything in the document, we need to say the client must use a
request form that includes the scheme.  I don't know how many client libraries
expose the option to do this, however.

Eric: On the client side, I agree with Michael.  On the server side, the option
might remove the need for the MUST.  Most of the server implementations appear
to do the wrong thing, so it's not clear how HTTP2 is any better here.

Mark: It sounds like we have emerging consensus.  It strikes me that putting
the scheme information in a pseud-header field in HTTP2, hiding it from HTTP,
maybe wasn't serving our audience very well; it requires them still to figure
out the scheme in a non-standard way.

### Character Encoding and Language for Parameters (chair)

Mark: No open issues.

Julien: I haven't done anything with this since it became a WG item except
testing the I-D submission system with some non-ASCII in it.  It still needs
some work; I'll get to it maybe next month.

Mark: It's mostly editorial work.  We can come back to the WG when there are
specific questions.  Hopefully it'll just go along quietly in the background. 
Do you think we could WGLC during Berlin?

Julien: Before.

#### Client Hints (chair)

Mark reviewed the issues list from the tracker.

Ted: Could "Save Data" be split off into a separate header field?  (a new
issue)   The willingness to do this particular thing is not limited to
particular methods of delivering that savings.  There are a couple listed, and
some might be significantly different from others.

Ted will raise this as an issue in the tracker and on the list for discussion.

#### Define More Precisely Which CH Headers are Sent by Default

Mark: Pretty straightforward.

#### Define "Accept-CH" More Precisely

Mark: Need to explain more clearly the scope of this option.  Ilya says this
can be resolved by plumbing in the HTML and FETCH specifications.  We shouldn't
have to think about this much more.  I know it seems weird to have some of this
in one spec and some in another but it seems to be how these things are going.

#### Should CH Headers be Treated as Simple Headers?

Julien sent a pull request.  Ilya will reiew the proposed changes.

### HTTP Encryption Content Encoding

Mark: We need advice from CFRG about the crypto choices made in this document. 
Martin, please get other helpful reviewers to take a look at this aspect of it.

Martin: That's the only issue as far as I know.

Everyone was looking at Alexey.

Mark: We were also talking about doing signatures; should we hold this up for
that?

Martin: They're orthogonal, so no.

EKR: Imposing encryption and signature is not a straightforward proposition. 
Which composition do you envision for these?

Mark: These are building block specs, so...

EKR: I don't think you can advance those independently.  You can do them
together, or drop one of them.

Mark: What impact would this have over in WEBPUSH?

Martin: It would be the long pole holding us up.

Mark: How long, estimate?

Martin: Let's talk about it offline.

Mark: We have serious concerns with this spec, and that's as far as we can go
at the moment.

#### Key Spec

Mark: We've been working on this for a while, and the remaining issues are
relatively minor.  We've done a lot of work to make this easy for an
intermediary to implement, but we don't have news that there are
implementations.   We should make sure we're on the right path before
advancing.  Right now you have to do a double lookup.  The preliminary feedback
from implementers is that they would love not to have to do that.  Are there
any implementers in the room with feedback?  Without that feedback we have to
sit on this spec.

Julien: What's the issue exactly?

Mark: Most intermediaries cheat and don't implement the whole current spec
because of the horrible performance impact.  As a result of the choices we've
made here, we have to embody the performance optimizations they've made.

Julien: So Key will be too complex?

Mark: Complex is okay; doing lots of syscalls or unbounded computation is not.

Julien: I'm trying to understand why you'd do more work besides parsing for Key.

Mark: A proper implentation of the existing spec would not have a problem, but
I don't think there are any.

Mark: Let's take the discussion offline.

### Potential Work

#### Thoughts on HTTP Header Field Parsing

Julien: "Again?"

(slides, mostly the same as what was presented in Quebec City and Toronto)

Mark: I think there's pretty broad agreement that there's a problem needing to
be solved, which is that Julien is a single point of failure in terms of HTTP
header review.  I also hear people uncomfortable with JSON, but I think we
should start with it just to get something done.  JSON pointer might be a
problem for performance reasons.

Erik: In the HTTP2 context, you'd have a direct mapping from JSON to CBOR.

Mark: That's what we were referring to before; it's a big long term win.

Jeroen: If you have an engine that wants to make decisions based on headers,
you'd have to look at data types of certain values.  "Date" is really annoying.
 Having a way to do binary comparisons is great.  Not all implementations use
JSON.

Mark: We have to pick something.  Or make something, which is scarier.

Mark: Call for Adoption of this is basically done.  If people have further
thoughts, please make them on the list or talk to me.  Julien is available to
edit.

### Origin Frame

Mark: Call for Adotion is open.

(slides)

Patrick: I'm in favor of expansion of this document in general, and we
certainly should adopt it.

Nick: I think this is an interesting thing we should advance.  We should do
<something> separate from the Origin Frame work, however.

## Adjournment

Please review the Part 2 schedule and drafts before the second half of the
meeting later in the week.

# Minutes from Session 2, IETF 95

## Administrivia (chair)

## RFC6265bis

Martin: What proof to you have that you'll bust everyone else like at Google?

Mike West: Blizzard looked like the next most vulnerable, but they were willing
to change behavior.  We need to tread carefully, but I think something can be
done here.

Richard: The leave-cookies-alone I'm in favor of.

Mark: Talked to a few people about cookie prefixes, and the only one that has
done anything used a lot of __*.

Mark: Richard and Mark are ok with same-site cookies,

Richard: The default in CORS is closed (same-origin), and we do something safer
-- you have to opt-in.

Mike West:  It is radical, but we can discuss it.

Martin: Changing the lifetime on cookies without the secure flag could cause
severe breakage.  If we treat cookies over insecure connections as ephemeral,
we might not break much and still cleanup cookies.

Richard: It can be worked around by setting it on HTTPS and reading it over
HTTP.

Mark:  I've heard of this approach in a number of contexts.

Martin: In this safe environment, a MiTM might still have a difficult time.

Mike West: It is interesting, but I'm concerned about the approach because how
'session' is defined is fluid.  A hybrid approach might be workable.  Another
might be to use a form of combined cookie.

Mark: Convincing everyone to change how they use cookies to get what we want to
combat pervasive monitoring is probably too high a bar.

Eric: One thing that sites have used to prevent tracking is to store a
persistent cookie.

Martin: There are events the browser can detect to try and use to address this
problem.

Eric:  I wonder if the CSP cookie scope is worth tracking in relation to this
cookie lifetime work.

Mike West: People are supportive of the draft, but I'm not sure if many have
thought about implementing it.

The working group is not objecting to its ability to make progress on solving
the cookie issues.  There will be calls for adoption of cookie prefixes and
same-site cookies, and look forward to drafts on cookie lifetimes.

## Potential Work II

### TCP Tuning for HTTP

Aaron Falk: Send a note to TCM and Transport about this work.  Getting more
cross-area review would really benefit this work.  I would be happy to help
review it if adopted here.

Patrick: I'm in favor of this work, but it needs to talk more about the impacts
of various network pieces more than how to configure your servers.

Spencer Dawkins:  A lot of the related documents are Experimental, and it would
be great if they can advance.  We've done cross-area sharing before with
success.

Barry:  There's some discussion happening if this work belongs here or in
Transport.  Wherever it is done needs significant help from the other area.

Bryan:  I'm in favor of this work, and have a related document I can share.

Barry: Don't worry about the category of other documents.  The AD can deal with
that.

Chair will discuss with Transport area people to find the right way to get TCP
Tuning done.

### Client Certificates

Mike Bishop:  We shipped something proprietary to meet needs, but would be
really happy to change to a standard.

Kazuho:  This is the simplest way to solve the problem, and we should do it.

Mark: We could adopt, knowing it won't get feedback in a long time.

Mike Bishop: I think it's worth adopting to help drive development.

Martin: I also think it's worth adopting even if it's abandoned later.

There are no objections to a call for adoption on client certificates.

### Secondary Server Certificates (Mike Bishop)

Martin:  Another advantage is that the alternative is a cert with lots of SANs
which are much much bigger; being able to server a smaller cert makes things
faster.

Patrick: Are these deltas to the client cert extension or its own thing?

Mike Bishop:  This was originally written as an extension to the client certs
draft, but we can move things around so it stands alone.  Also, this and
client-cert could be the same draft.

Patrick:  I think it's worth doing both.

Nick: I strongly support.

Martin: the only problem is the potential to capture, but it's a small worry.

Mike: The current requirement involves matching on DNS, and this removes that. 
We could still rely on DNSSEC, or push down a proof.

Richard: How do I figure out how to send the cert request for a new connection?

Mark:  This was talked about on Monday.

Richard:  I think the negotiation conerns need more discussion.

Mike: The draft does not currently talk about session resumption but you
probably could do it without pushing the certs again.

Mark: At the time, the thinking was SPDY was enough and more complexity was not
needed, but that might be different now.

Eric: Another idea is to have a separate record in DNS to look up for
validation against.

Mike: The server can opt-out using a server frame.

Martin:  We should all for adoption to adopt both client- and secondary-server
after Mike and I merge the documents.

Mark: The proposed work is a combination of the two with advice from the
Security area.

The working group supports a call for adoption of the client- and
secondary-server certs documents.

### Cache Digests

Martin:  I believe browsers already flush caches when you flush a site.

Martin: We need more discussion as a frame, since there might be collisions
with multiple caches.  You are assuming there is only one cache, and that's not
likely the case (think intermediaries).

Mark: The cache is hop-by-hop.

Bryan: I like it as a frame, and allow the server to request it to get a sense
of what the client has cached.

Mark: It can help if you need to drop

Martin:  I'm happier with these answers, but a note should be added that it
could be done with a header to expidite experiementation.

Mark: It's moving

Leif: What if the server doesn't do push?

Mark: There would be an indicator.

Martin:  We have afix in TLS 1.3 that allows the server to speak first. 
Firefox would then see about sending the cache digest only if we have a
reliable indication that the server supports it.

Eric: What about the server being able to indicate its limits?

Martin: There is benefit for a client to be able to ask, such as false
positivies being 1/6 then maybe I can take the hit for a larger table to get
false positives 1/1000.

Mark:  A balance would need to be struck.

A short call for adoption will be issued, with a third party to help judge
consensus.

### Decomposing/Disentangling HTTP

Tim: Work happening in DNSOP for running DNS over HTTP (over TCP or UDP).

Mark: A lot of different working groups use HTTP as a transport.

Eric: This is very interesting work we should continue to provide better
semantics.  The DNS work is really DNS over the HTTP framing to get the same
transport semantics in HTTP.

Ian Swett: There is certainly an effort to clean QUIC up before standardizing.

Martin: We need to think very carefully how we use HTTP.  We should continue
the conversation, but I don't think we need another RFC for this.

Mark: I think we should let it sit around and think more on it.

### Merkle Integrity Content Encoding

Richard: Has there been any implementation or experiementation?

Martin:  We needed a better solution to the current SRI, and I have a prototype.

Richard:  Firefox is interested in this work, mostly internal now but some with
wider scope.

Eric: I like it and have lots of use cases for it.

Natasha: I think this is interesting from a W3C perspective.

Mark:  Please look at the draft -- there's been lots of interest over years.

### Secure Content Delegation using HTTP

Ian: There is a prototype -- would it move into the browser?

Martin: Using ServiceWorkers for this interferes with other uses of
ServiceWorkers, so we would look at moving into the browser eventually.

Ian: The implication is that the integrity is maintained with the delegation.

Nick: Does this work if it's not TLS the whole way?

Martin:  The primary request is end-to-end, but the secondary don't need to be.

Eric: This could help with HTTPS adoption for large CDN usecases.

Martin: This might be a better solution to LURK.

Thomas: This can be resource intensive for the CDN.

Martin:  You're operating as a proxy, so you've signed up for that.  The client
could just talk directly to the origin.

Martin: The client discovers this delegation through MAGIC!

Mike Bishop: I have seen a lot of interest for this in SMBs more so than the
browsers.

Martin: I'll need to talk to higher ups about sharing the implementation.

## Adjornment

---

* [Content Security Policy: Cookie
Controls](https://w3c.github.io/webappsec-csp/cookies/)