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

# HTTP WG IETF 93 Meeting Minutes

__Scribed by Wendy Seltzer__

### Specification Status

mnot: Tunnel-protocol in RFC editor queue. Client-initiated content encoding
submitted to IESG.

Julian Reschke: Authentication-info header field obsoletes RFC 2617 in
combination with Basic and Digest specs; depends on PRECIS framework.

mnot: What do we need to do to obsolete 2617?

Barry: It's already taken care of. The documents flag it, when they're
published.

## [Alternative
Services](https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc)

mnot: Julian and I worked through issues list yesterday. Work from the bottom
up.

### Alt-Svc alternative cache invalidation #16

Julian: while the use case you mentioned would be handled, not convinced all
would be. If we need to group alt-svc so they can be independently refreshed,
we might need to think of labels

mnot: e.g. explicit label field in the header for a group. But complex to
implement in clients.

Martin Thomson: Rather than identifying the mechanism, identify the source.

Mike Bishop: That doesn't entirely make sense to me. Any alt-svc can handle
itself. Where it came from is the origin or someone authorized to speak for the
origin. Need to think more about what we should do for validation.

mnot: We know we need something, not sure what its shape should be. In the
past, we've tended to over-design. Keep it simple.

Patrick McManus: Operationally, seems a bit confusing to have two elements from
the same origin, different sources

Martin: Propose a single global scope for a given origin. Whatever you learn
next replaces what you have. Keeps things simple, but means you might not get
the pinning with respect to H2. You can maintain with a bit more care.

mnot: if want to use alt-svc for oppsec, then switch to load-balancing...

Martin: that's why we have @@

Erik Nygren: If you had one global setting, and priorities, then set high
priority for oppsec, lower priority, short-lived for load-balancing. Push a
whole set.

Mike: max-age currently applies to the entire entry. If it applied per
parameter,

Bence Beky: might be a need to send a header or frame to clear alt-svcs. While
implementing hacks proposed on ML, I found them more complicated

Julian: According to ABNF, max-age is specific to parameters.

mnot: seems simplest to have one global scope. An empty frame resets.

Julian: Need to change the syntax to allow an empty alt-svc header. currently
does not.

mnot: Does anyone who thinks we need more capable labeling system want to talk
about use cases? Does anyone object to simple global scope?

[no objections]

Patrick: Not clear that oppsec needs an alternative.

Erik: Need clear guidance on what ordering to use (priority, shortest lifetime?)

mnot: when we've discussed in past, inclination to leave it to the client.

Erik: here, we probably want to make explicit

Martin: if no other preference, lexical ordering

### ALPN identifiers in Alt-Svc #43

mnot: marked as editor-ready. Do we need to discuss?

### need to define extensibility for alt-svc parameters #69

mnot: conventional would be to make must-ignore

Julian: still need to define how to add new ones

Erik: define the granularity of what to ignore.

mnot: proposal to make extensibility work at the attribute level. How do we do
mandatory? we don't. Do we need an IANA registry for such extensions? One
direction could be to establish directory on first need for it.

Barry: if you think there are likely to be extensions, go ahead and create it
now. If not likely, then defer.

Julian: put it in now.

Mike: Issue 71, one proposal was to kick that out to extension, so we'd need a
registry then.

mnot: ok, establish registry

### 71. Persistence of alternates across network changes alt-svc design

mnot: it would be nice to have an option to say whether alt-svc should be
flushed. Do we need to define that extension now, or defer?

Erik: worthwhile to put it in from the beginning.

mnot: any objections?

[no objections]

mnot: add a parameter to do this now.

### 73 Alt-Svc: Elevation of privilege alt-svc design

mnot: we currently allow someone to advertise alternative on same origin
without strongly authenticating. Designed for oppsec so you don't need a valid
cert. Is this reasonable? one suggestion, disallow advertising port higher than
privileged ports if origin is on privileged port.

Martin: Another potential attack if you have untrusted actor on your host. if
you have cluster, id one node on the cluster, someone can target all the
traffic to one node as DDOS I don't like the segregation on 1024, but might be
ok alternative, if you see alt-svc frame, you might ignore header, on the
ground that server is capable of sending frame. header less trusted.

mnot: should we treat localhost specially? ongoing discussion in webappsec
about mixed content in local host.

Martin: I might open that issue.

Patrick: I don't have a lot of faith in the 1024, but don't strongly object.
Another issue I've heard, when changing hosts, verifying certs, right mechanism
is CORS, and this violates CORS.

mnot: I'd like to hear more, because that's a very different layer

Patrick: DNS rebinding attacks can do the same.

mnot: not CORS, but something the server can do to indicate it's used as
alternative

Mike: see oppsec discussion

mnot: we're really just talking about http urls.

Mike: for http, I really don't want to let you move me to a different port
without HTTPS, but might be ok

mnot: you can always ignore the advertisement

Martin: What level of advice do we think is appropriate? Do we outline the
potential use?

Erik: What about being fairly vague in alt-svc, more specific in oppsec?

mnot: still put info about privileged ports here?

Erik: certainly in oppsec.

Martin: We might describe the risks.

mnot: describe the risks and recommend a privilege barrier

### 74 Alt-Svc: Alternates of alternates

mnot: is everyone comfortable with what's in the issue as "second reading"? 
Yes.

### 75 Alt-Svc header with 421 status alt-svc design

Mike: asking you to reverse the text in 421

Patrick: it should be flipped to must not

mnot: must be ignored.

An alt-svc header in a 421 must be ignored.

### Alt-Svc and Cert Pinning #76

mnot [reads]
spec currently reads must be valid, but not necessarily identical credentials.

Mike: starting from HTTP means there are attacks that will work against you.

mnot: oppsec is not proof against active attackers in any way. if we start
trying to plug holes, we'll never stop.

Mike: but here, you're making the attack worse, because you could redirect wth
host, have a long-lived alt-svc

Martin: we also have guidance about clearing state between networks,
particularly for unsecured origins. If you're mitm'd once due to cert
compromise, high chance in the browser that that can be persisted already. if
you can get something in browser cache, storage, service workers...

mnot: oppsec provides no security indicators to user.

Martin: we can talk about concerns, don't need to change the design

Mike: can live with it

Erik: oppsec can't send to a different hostname

mnot: so even for https origin, we're rooting our trust in the certificate. a
bad cert could persist. Need to add security considerations and possible
mitigations.

### 83 Alt-Svc Header - hop by hop

mnot: any proxy in the way is going to strip it.

Martin: Thumbs down. Patrick: nod.

Martin: I like that you can push this all the way through a proxy. Not
consistency for consistency's sake.

mnot: close with no action.

### 87 alt-svc response header field in HTTP/2 frame

Martin: only reason to treat differently if ability to write to header field is
less privileged than ability to write to frame.

mnot: there may be circumstances where it's interesting to put it into header.

mnot: no special handling

### 89 Using alt-svc on localhost

mnot: do we know enough now?

Martin: treat public address-space -> private or into localhost as privilege
escalation. Recommend ignoring the alternative that appears

mnot: rough-in some text, discuss with browser security folks.

mnot: through with alt-svc issues. lots of work for the editors

## [Opportunistic
Security](https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption)

mnot: checkpoint. We've only had one browser implementation. TAG F2F and
WebAppSec discussions of things that look like oppsec. Have another good look
once alt-svc settles down. not inclined to publish right away.

Martin: some uncertainty in community what the right strategy is here. Upgrade
Insecure from WebAppSec, akin to HSTS. original vision for oppsec was to try to
move cleartext http closer to https other changes could let us avoid that.
Doesn't address the landing page issue, where you start from HTTP

mnot: other issues, hard to get certs for some people; hard to transition from
http to https on some websites. W3C efforts to make that easier

Erik: IPv4 space issues and SNI. We're not yet at the SNI adoption point where
everyone can use v4 HTTPS without IP address. tradeoff

Patrick: lots of parallel paths. I think we all want to wind up at full HTTPS.
other issues: 3d party content; hosting providers' models; corp behind the
firewall. I believe there's medium-term value here. Don't want to put oppsec on
back burner forever.

##
[451](https://tools.ietf.org/html/draft-ietf-httpbis-legally-restricted-status)

### 80 distinguishing intermediaries from origins.

mnot: some people have said that's interesting. poll on mailing list said yes,
it's useful to make machine-readable. If we're going to differentiate, how?
header? status code?

mnot: my inclination would be to use a different status code. not a lot of
feedback about whether it's done right. Headers, more likely to make errors.
lots easier to change one digit in-flight in a status code than to change a
header.

Martin: it won't be anywhere near as cool

mnot: if the web is going to HTTPS, then one would think intermediaries have
less opportunity to add legal restriction codes

Wendy Seltzer: As a researcher, I think it will be interesting to get
differentiated information; don't have a strong feeling which mode.

mnot: ok, taking back to list.

## Potential Work

### Search method

Julian: common webdev question: why can't I use a payload with GET?
[reading slides]
(https://httpwg.github.io/wg-materials/ietf93/ietf-93-httpbis-search.pdf)

Phil Hunt. I was one of those trying to use GET. I had a draft that was uglier
than necessary because it couldn't use SEARCH, dealing with stored results.
https://tools.ietf.org/html/draft-hunt-scim-search-00

mnot: safe POST, or use to store search?

Phil: POST to store the search query, SEARCH to execute. Query itself becomes a
restful object. stateful results are useful.

Martin: Stored queries. I'm not worried about that. We frequently log GET
requests and do all sorts of "non safe" things on the server. Channeling Roy,
the client is not responsible for its side effects on the server.

mnot: why not just use POST?

Julian: leave the stored query stuff out of the spec. SEARCH is GET with a body
[meme alert]

mnot: think I'm ok with that.

Phil: if you look at SCIM, @@

PUT v SEARCH?

mnot: I'd be concerned that if this gets implemented in browser, we lose a lot
of cache efficiency on the web.

Julian: if we do this, explain why it's almost always better to use GET
SEARCH RFC is experimental, I'm the author, so we should be able to relax
payload to make it more generic.

mnot: my inclination is to call for adoption. any more discussion?
Call for adoption on the list.

### New content-codings.

New content-codings -
[Presentation](https://docs.google.com/presentation/d/1rncpm-SRSzVv86lHQipGHi0TXwjoDycXkLGhkwUwB4c/edit#slide=id.p)

Martin: give people a sense how all these things fit together.
[reviewing slides]

### Remaining items on the
[watchlist](https://github.com/httpwg/wiki/wiki/WatchList)

mnot: Julian wants to wait for new RFC format for non-ascii for @@
Encrypted content encoding, client hints
inclined to call for adoption on client hints.

Martin: some extensive security review, getting it into WG would help on
feedback.

mnot: I'd explicitly reach out to Security Area.

weak interest in Patch status

there's a repo with an issues list for HTTP/1.1

Strong feelings on any of these docs?