mnot: doesn’t think we’ll need much in way of modifications based on review, will kick off with IESG in near term.
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
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
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?
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 ]
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
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
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 ]
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
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
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
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
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
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
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 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?
mikeb: wrt PR #101 on alt-sve – julian commented on it just now
mnot: answering julian: thinks we can resolve this in the issue