HTTP Working Group Materials

HTTP Working Group Minutes - IETF 94

Monday, 2 November 2015 13:00-15:00

Agenda Bashing

No comments

Specification Status

mnot: doesn’t think we’ll need much in way of modifications based on review, will kick off with IESG in near term.

Active Drafts

Alternative Services

Discuss the issues list and draft status.

mike bishop: see comments in the issue #76 & PR #98

martin T: spec typical cert checks for normal case, and if the alt svc has additional reqs, need to spec them also. dont think we have real issues with alt svcs, but we have a soft fail, which ends up just degrading the ecosystem. need to get the additional checks on certs right – what is in spec now is too vague.

mikeb: when we tried to be more specific at last ietf mtg, folks didn’t like the specifics chuckle

mnot: eg have the typical defaults, spec additional stuff in context of the alt svc spec

ekr: missed

mike b: tried to say “implementations have their own reqs anyway”

mnot: perhaps say “other” rather than “implementation specific”

martin t: essence that we reserve right to impose further restrictions is fine

issue #89 - using alt svc on localhost

mnot: patrick have anything to add? had difficulty to generate the text, if there’s no issue we can close it, if not we need additional txt

martin t: thinks Patrick’s last comment is fine

mnot: closed

issue #92 alt-svc vs the ability to convey the scheme inside the protocol

martin t: the point is to avoid app being confused, eg by looking at the “stack” and if see TLS underneath, they often assume https. need app containers to shield the app from seeing that there’s TLS there when doing opp security and the connection isn’t authenticated – having text along those lines a good thing – highlight things one needs to look for. eg in sec considerations

patrick m: this is similar to virt hosting environments, emphasize that origin is not changing.

julian via jabber: right now we have a MUST NOT in the sec cons. do we agree on changing this to advisory prose?

in Sec 9.5

martin & julian disagreeing on what change can be made to S 9.5 – has to doing with diffs between HTTP 1.1 vs 2

mnot: ok, take it to the list then

issue #96 IANA procedure for alt-svc parameters

mnot: what review level is needed for this? “ietf review”, “spec req’d”, “expert review” ?

yoav n: thinks expert review is appropriate.

mnot: finding expert can be painful

martin t: spec req’d involves expert

barryL: appoint someone who participates in WG and have them query WG WRT answer, thus is sort of a shepherded WG review

yoav: anoint Julian as expert :)

mnot: thinks can get this to WGLC in a few weeks – lets get discussions happening on list. There are implementations of this, is there any discussions of test suites?

pr #101:

mike b: diss levels of normative text in diff places, tried to rectify that, eg changing ‘can’ to ‘SHOULD’

mnot: 1st is a normative change…

mike: so that one was a MAY and elsewhere a SHOULD

martin t: this one is ok – should encourage clients to use this so SHOULD is appropriate

pr #98 was discussed way up above

[ patrick m has their own test suite – but no one else speaks up ]

Opportunistic Security

mnot: waiting for alt-svc to be done – so in holding pattern – hasn’t been a chance to deploy this on server side until recently.

martin: there was disc on this during TPAC last week, there’s been work on it since then, in a few weeks may see email about how this works.

mnot: can see this going in any direction: publish as-is, don’t pub, modify it

martin: yes

Key

mnot: way to calculate a cached key – VARY header is tough to use martin will be shepherd on spec, mnot is co-author had a decent amount of implementer interest from “cache” folk have a fair number of issues- some minor, some speculative

issue #?

igrigorik submitted

martin: rather than the proposed syntax perhaps we can simplify it in some manner, eg have mult matching rules mean ‘OR’ – currently ordering and precedence is likely an issue.

mnot: take to list

issue #? case insensitive matches

mnot: summarizing: we’ll iterate on this draft one or two times and then we’ll have something ready for experimentation – really want implementation experience before shipping it

[ leif intending to implement ]

Client Certificates and HTTP/2

Presentation: client authentication - Martin Thomson

mnot: we disallowed client certs in http/2 because we disallowed reneg – this is a proposal that meshes with discussion in TLS WG

slide: history

mic yoav: does this really matter? one can do foo

martin: trying to avoid situations where that is possible – can lock the entire browser due to concurrency issue (eg firefox) – u receive req for cert, which client to I ask to provide the cert?

slide: ignoring prob doesn’t make it go away

?: did you ask TLS wg to fix this?

martin: yes, and will explain what we’re doing

yoav: there will be disc about this in TLS session

ekr: TLS 1.3 will support a diff sec mech, in gen it is hard to reason about semantics of reneg, thus decisions taken in TLS WG

slide: solution overview

there is a WAITING_FOR_AUTH frame added to h2, and an identifier that maps this to the TLS context

yoav: some detail wrt correlation

martin: this ident makes it more clear what the binding is between the layers and sidesteps concurrency blockage

slide: part 1.1: WAITING_FOR_AUTH frame

slide: part 1.2: TLS 1.2 magic

ident is sent in ClientHello extension by client server can then decide which of the outstanding authz’s it wishes to take on

slide: part 1.3: TLS 1.3 magic

not entirely decided here how it works

slide: part 2 - setting reneg

martin: my opinion: don’t use this feature this can cause some surprises in your stacks, ie practical concerns wrt state of a session

mnot: don’t use “now” or “ever” ??

martin: you use this for backwards compatibility, but this is not the future

mike b: why dont we just define a ALPN (?) for this (for the future) and this prop is just back compat

martin: agree

yoav: am not sure why this is more deployable than other way

martin: this doesn’t touch the app at all – in the other approach, the server needs to send a 401, and that’s a change to the app api you’re presenting

yoav: disagree

martin: the 401 goes to client, and then ought to send an alert at tls layer but can’t in tls1.3. the point of this is to fix backward compatibility requirements w/o changing apps

yoav: this still looks to me the same api

ekr: this is a much easier drop-in than the alternatives

?: observes that not having this solved is slowing h2 deployment – but saying dont use this isn’t helpful – is there a doc we want to write that says “please use this but it is dangerous”

martin: we do have a handle on the sorts of problems this might cause, so we will quantify those problems and leave it as that

mike b: we’re crossing layers, so understand why it makes folks nervous, as to why we don’t have an api using 401 is that we’re killing the old stream, that reqs client stack to do things that aren’t easy or presently supported, and also the server has to think it is on same transaction when it isn’t, so this draft is easier to do

martin: the disc on list seemed to arrive at that

slide: adopt me

martin: do we want to work on this prob? there is a draft, sub’d just before the deadline – mike & I. as mike said, this’d be easier to adopt

mike b: had earlier draft, didn’t adopt it, Microsoft pub’d as proprietary, made TLS folk sad, this draft is an improvement, so am fine with deprecating the prior approach

martin: goog may take diff view on this,

mikeb: they removed reneg while app data is flowing – … – do still have open question on tls implementers

martin: we may need to tweak the tls v1.2 aspect of this from this

mnot: need more disc on tls 1.2 & 1.3 particulars to ensure we going in right direction

ekr: at TLS interim, we decided to adopt changes that support this – what is not done is a tech proposal for the crypto that makes this work – but there is consensus on the semantics

martin: the 1.2 question has to do with reneg handling in 1.2 stacks

mnot: that makes me relatively comfortable wrt making call for adopt in next week or two

Potential Work

mnot: this is for NEW HEADERS. If your data is interms of JS objects, can map to this since uses json. In h2 had disc wrt header-aware compression - thus some interest in this. Every time some one comes up with new http header field Julian needs to review, and he is thus the bottleneck. Would much rather have documentation and techniques for this such that less review is needed thus this spec – an attempt to do that. The audience for this is other spec writers. Feedback is that looks interesting but isn’t a std – chick & egg prob maybe we httpbis should adopt and make some progress.

julian: there is connection to the key spec. there is one field that relies on foo – if can fix that in the key spec, then http-jfv might be able to be used. maybe that would make it popular for other header fields?

mnot: agree - - inclined to issue call for adopt – want to talk with folk in webappsec to see if this is palatable & useful – comments?

jeffH: seems reasonable

julian: yep

mnot: this is martin’s spec – web push depends on this?

martin: yes, this is basis of msg encryption in webpush. need to work out where this lives

mnot: were waiting for use cases & implrs to emerge – has occurred – so issue call for adopt – is sec-oriented, want to be careful

mnot: h2 allows you to coalesce origins on a given connection – of interest to CDNs – clients interested & willing to implement?

patrick m: yes, we are interested in this

martin: the std way we decide something can be coalesced, we get same ip address & port, this introduces potential for one to learn what other names are available on an origin w/o going thru dns disco – is that the intent?

mnot: in h2, both dns and the cert have to match, we’re not changing that, there are cases where both dns and cert match and it is a mistake – a question is whether we want to add semantics to this

mikeb: if a client wanted to do the opt, can query the dns, to a certain extent the client decides that and it doesn’t need to be spec’d

martin: we have to ‘consider it’ in any case – don’t think this is a bad idea patrickm: let’s adopt

ekr: what about the privacy issue? it provides a more agressive way to exfiltrate what extensions are supported – hmmm… concerned about DNS naming – ie dns name blocking –

mnot: in proposed spec, origin sends frame to client – these are origins I am willing to serve – can be a long list

ekr: ultimately thinks it’s fine

mnot: may send call for adoption on this, will see if Erik N is willing to edit

ekr: is this a doc that doesn’t req https? it would be attractive to go to goog and they send you frame with all this info – is fine over https – but if plain http isn’t ok

mnot: intent is to not do over http

COOKIES

martin: preso on this:

slide 2: cookies are stale. enumerate problems with cookies

slide 3: lets get fresh. [ summarizes the four draft-west-* IDs – three of which are listed below]

slide 4: the choice is yours. do we do a subset of these four IDs or all of ‘em ?

mnot: prob a bad idea is to make blanket statement “we going to improve cookies” given history

proposing: have initial phase of getting some implementation experience with these proposals, and only open up cookie spec and apply the ones that we’ve decided that “works”

martin: do want to implement some of thise on short timescale – eg cookie slinging is of concern now as opposed to origin cookie which is a “nice to have”

mnot: we have text already, maybe also regard cookie spec as a carefully managed “living standard” that gets constantly updated

ekr: nice to disting between “nice to haves” and “necessary” ones. eg secure cookies thing is being implemented – fait accompli ? others prob need some coordination – what is the relationship of them to existing mechs. eg first party only is just a declaration, and then how does that relate to origin cookie. thus need to have client and server work together to get value out of them, and if there are implementation differences between clients and servers then may not get value.

mnot: thinks mike finds origin cookie as ‘defence in depth’ that server can’t depend upon. just wanted to kick off discussion. need to discuss approach steps too

addresses CSRF

addresses cookie leakage

addresses cookie slinging attacks

origin-cookie – https://github.com/mikewest/internetdrafts/blob/master/origin-cookies/draft-west-origin-cookies-01.txt

slide 4: load balancer

slide 5: fast first display

slide 7: push policy - defines server behavior regarding push – can be negotiated

slide 9: possible policies

mnot: this is from DASH as primary use-case, for common web use case wonders if it will be useful whether servers will use it – if just for dash, then it can have such headers in its specs

?: want to at least have feedback from this community and maybe go a bit further than dash needs, generalizing and doing IETF

martin: this is similar to signaling about the client cache – could be useful – wonders whether we see clients actually implementing policies around this and what sorts of policies

mnot: tend to agree, if we have mech for server to learn client state it is interesting, but if we standardise something, need to do it right, and not be vague

martin: the other preso from this last weekend was good – can experiment with cookies and service workers – this is interesting, can experiment with this using those techniques, eg is a simple system of tags sufficient or something more complex necessary for desired use cases?

AOB

mikeb: wrt PR #101 on alt-sve – julian commented on it just now

mnot: answering julian: thinks we can resolve this in the issue

Source on GitHub