* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Httpbis Status Pages

Hypertext Transfer Protocol (Active WG)
Art Area: Barry Leiba, Alissa Cooper, Ben Campbell | 2007-Oct-23 —  

IETF-94 httpbis minutes

Session 2015-11-02 1300-1500: Room 501 - Audio stream - httpbis chatroom


minutes-94-httpbis minute

          # HTTP Working Group Minutes - IETF 94
          ## Monday, 2 November 2015 13:00-15:00
          - [agenda bashing](#agenda-bashing)
          - [Specification Status](#specification-status)
          - [Active Drafts](#active-drafts)
            - [[Alternative
            - [[Opportunistic
          - [Client Certificates and HTTP/2](#client-certificates-and-http2)
          - [Potential Work](#potential-work)
            - [COOKIES](#cookies)
          - [AOB](#aob)
          ### Agenda Bashing
          No comments
          ### Specification Status
          - [The ALPN Header Field](http://datatracker.ietf.org/doc/rfc7639/)
          *RFC Published*
          - [Client Initiated Content
          *In RFC Editor Queue*
          - [An HTTP Status Code to Report Legal
          *Exiting WGLC*
          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
          Discuss the [issues
          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
          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](https://github.com/httpwg/http-extensions/issues/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](https://github.com/httpwg/http-extensions/issues/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](https://github.com/httpwg/http-extensions/issues/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
          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](https://tools.ietf.org/html/draft-ietf-httpbis-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
          - 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
          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
          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
          * [A JSON Encoding for HTTP Header Field
          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  -- 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
          * [Encrypted Content Encoding for
          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
          * [ORIGIN
          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
          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
          * [First-Party
          addresses CSRF
          * [Cookie Prefixes](http://tools.ietf.org/html/draft-west-cookie-prefixes)
          addresses cookie leakage
          * [Leave Secure Cookies
          addresses cookie slinging attacks
          origin-cookie --
          * [Accept Push
          ? from Canon presenting --
          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

Generated from PyHt script /wg/httpbis/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -