Subject: [Unbearable] Draft minutes - errors are my own

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Nov 2016 18:02:37 +0900

IETF97 tokbind

Andrei - core drafts

Martin Thomson - RI is needed - Karthik Bhargavan pointed out an
  attack:
  https://mailarchive.ietf.org/arch/msg/tls/TfiUa3M390augtvUoxH2D7L5LGM

Nick Harper - RI is easy to implement

Martin - base64url is defined in RFC7515

Renegotiation

Martin - if you do this, then unless you have some constraints,
  there are always error cases.  It's unlikely, but we need to
  deal with those cases somehow.

Nick - suggest using a profile - you can only use renego under
  certain conditions if you also use tokbind.  For instance, h1
  is the only place we can use this and you have to freeze the
  connection there.

Martin - we should not use the original EKM

Nick - tbproto should prohibit renegotiation unless the profile
  describes how it works.  h1 mapping describes how we interleave
  renegotiation with the rest of the protocol.

JeffH/DirkB - sounds good

JeffH - propose that we WGLC now and treat these last few issues
  as LC comments

Chairs - WGLC starts after this session

Brian Campbell - on 0-RTT review there was a comment - are we OK
with a fixed length EKM

Andrei - wants a TLS unique

Brian - what if we need a new algorithm that uses a longer key,
  is that OK to use with 32 bytes?

Martin - not a cryptographer, but my understanding is that 32 is
  enough (similar enough to other cases), 32 bytes needs to be an
  absolute minimum.  Might want to allow a bit of flexibility.

Subodh Iyengar - do we have a strategy to manage key type rollover?

Andrei - once in a few years, asking for users to re-type their password (or
  otherwise reauthenticate), is hard

Martin - concerned about complexity

Andrei - proponents could write an internet draft and we could evaluate it

Dirk - sort of agree about complexity, we might want to think about migration

Brian - forcing a login happens naturally anyway

Nick - if the preference for key type doesn't change consistently across a fleet
  of servers, that reauthentication might be forced multiple times

JeffH - what about github issues

Chairs - if it isn't on the list, it doesn't exist, please bring github issues
  to the list

Brian - even on the list, issues get ignored

Brian - OAuth clients don't have explicit signaling about being able to reveal
  the referred token binding.  If the client is pre-configured to use referred
  information, then it shouldn't need explicit signaling; there is already an
  understanding that the client wants to do this.

Andrei - discussed in OAuth, we (inc. Dirk) agreed that this is a change we
  wanted

Brian - will generate a PR

Nick - explicit signal OR pre-arrangement is OK

John Bradley - Fetch JS doesn't really have an explicit signal either, so we
  have to avoid making the language too restrictive

Vinod Anupam - The current plan is that the javascript will make the decision

Martin - You have three parties involved

John - the origin that owns the referred token, the target of the request, and
  the origin of the javascript

Dirk - the JS cannot talk about token bindings for other origins, if it requests
  a referred binding, it is its own origin

John - that kills a bunch of use cases; which might be OK for security reasons

Dirk - the boolean in fetch doesn't allow you to identify another origin for
  referral

Andrei - to do anything else would allow sites to scrape the browser for tokens;
  we need this restriction from a security perspective

Ben Kaduk - we have to have a signal from the owner of the token to allow this

JeffH - the PR is still open, participate

Martin - Another CORS header is probably unwise, particularly since that would
  allow any resource on any of the eTLD+1 origins to "release" the token
  identity

0-RTT

Martin - 0-RTT exporters has different properties to other exporters

Martin - What about replays of stuff that got rejected?

Nick - Header fields will have to be overridden on retry.  That doesn't happen
  in current implementations (not that there are many).

Martin - We don't need the anti-replay indicator extension, or if we do, then we
  would benefit from having this generically.

Andrei - Basing exporter keys on 0-RTT makes the token binding keys replayable.
  There are mitigations, and it might be useful for the client to know.

Martin - If we have that capability, we should build it generically.

Nick - we might only have replay protection for token binding stuff, but maybe
  the granularity isn't needed

Kyle Nektritz - Replay only exists for the specific 0-RTT data that included the
  token binding.

Ben - a combination of ticket age with other 0-RTT mitigations makes those other
  mitigations much easier to deploy

Martin - Can we agree not to use 0-RTT exporters for long?

Nick - Has an alternative that latches

Martin - Does that require trial-verification?  What about defining new types
  for early exporter stuff?

Subodh - how do you decide to latch?  What about an HTTP/2 message for it?

Dirk - Meta: we should take on this work, and there are concerns we can resolve
  if we do adopt.

Chairs - hum to adopt

DECISION - adopt as a WG draft

JeffH - can we proceed with existing docs before finishing this?  Do we say
  anything about zero-RTT?

Nick - Maybe we don't need to worry if we don't reference TLS 1.3.  We can
  pretend that TLS 1.3 doesn't exist.

Leif - Maybe we won't have 1.3 mentioned.

JeffH - the spec doesn't explicitly say 1.2 right now.

Martin - early exporters are very different to exporters, maybe we can say that
  in the document, maybe more so if we end up referring to TLS 1.3, but we don't
  have to because exporter != early exporter

Chairs - please create a PR for us (no stuckee identified)

TLS Termination

Andrei - if the terminator is parsing and verifying, then it should
pass the identifiers

Brian - what about referred?

Andrei - an array

Martin - Prefer passing the EKM

Brian - hard to deal with killing the connection

Martin - that's a bad requirement ;)
Action: create PR for dropping the connection you can use these architectures

Subodh - what about pure TLS terminators that proxy at the TCP layer?

Brian - I don't know...

Subodh - hard to account for pure TLS terminators

Subodh - if we have a PR to drop the connection drop requirement, we should talk
  about status codes

Chairs - adopt?

DECISION - consensus to work on the problem

Tony Nadalin - if we adopt this, nothing will be slowed

Chairs - yes, as long as we change the connection-closing language

Martin - wanted to propose RFC 7239 as a candidate

Brian - looking for guidance on TCP layer termination

Subodh - maybe you can talk about that as being a problem; most of these are
  moved into an out-of-band channel

---

From: =JeffH <[email-masked]>
Date: Tue, 29 Nov 2016 14:18:02 -0800

fyi/fwiw, I went thru Martin's most excellent minutes and noticed a few 
things from my notes to add/clarify..

> IETF97 tokbind
   [ minutes by Martin Thomson ]
> Andrei - core drafts
<https://www.ietf.org/proceedings/97/slides/slides-97-tokbind-tb-changes-since-ietf96-00.pdf>

>   <https://mailarchive.ietf.org/arch/msg/tls/TfiUa3M390augtvUoxH2D7L5LGM>
>
see slides 9 and 10
> Andrei - once in a few years, asking for users to re-type their
>   password (or  otherwise reauthenticate), is hard
>
> Nick - if the preference for key type doesn't change consistently
>   across a fleet of servers, that reauthentication might be forced
>   multiple times
>
> JeffH - what about github issues ?
>
> Chairs - if it isn't on the list, it doesn't exist, please bring
>   github issues to the list
>
> Brian - OAuth clients don't have explicit signaling about being able
>   to reveal the referred token binding.  If the client is
>   pre-configured to use referred information, then it shouldn't need
>   explicit signaling; there is already an understanding that the
>   client wants to do this.
>
> Andrei - discussed in OAuth, we (inc. Dirk) agreed that this is a
>   change we wanted
>
> John Bradley - Fetch JS doesn't really have an explicit signal
>   either, so we have to avoid making the language too restrictive
>
> John - the origin that owns the referred token, the target of the
>   request, and the origin of the javascript
>
> Dirk - the JS cannot talk about token bindings for other origins, if
>   it requests a referred binding, it is its own origin
>
> Dirk - the boolean in fetch doesn't allow you to identify another
 >   origin for referral
>
> Andrei - to do anything else would allow sites to scrape the browser
>   for tokens; we need this restriction from a security perspective
>
> JeffH - the fetch() PR is still open, participate

the fetch() PR is still open, can still participate
   Update Fetch to support Token Binding. #325
   https://github.com/whatwg/fetch/pull/325

> Martin - Another CORS header is probably unwise, particularly since
>   that would allow any resource on any of the eTLD+1 origins to
>   "release" the token identity
>
>
> 0-RTT

slides: <https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding>

> Nick - Header fields will have to be overridden on retry. That
>   doesn'thappen in current implementations (not that there are
 >   many).
>
> Martin - We don't need the anti-replay indicator extension, or if we
>   do, then we would benefit from having this generically.
>
> Andrei - Basing exporter keys on 0-RTT makes the token binding keys
>   replayable. There are mitigations, and it might be useful for the
 >   client to know.
>
> Nick - we might only have replay protection for token binding stuff,
>   but maybe the granularity isn't needed
>
> Kyle Nektritz - Replay only exists for the specific 0-RTT data that
>   included the token binding.
>
> Ben - a combination of ticket age with other 0-RTT mitigations makes
>   those other mitigations much easier to deploy
>
> Martin - Does that require trial-verification? What about defining
>   new types for early exporter stuff?

  MT: we need to complete discussion of 'early exporter'
     (so dont want to use that in TB at this time)
   suggests including "early" or "late" signal in keyparams types

> Subodh - how do you decide to latch? What about an HTTP/2 message

subodh: in h2 probably need a latch frame that says we're now non-0-RTT

> Dirk - Meta: we should take on this work, and there are concerns we
>   can resolve if we do adopt.
>
> Chairs - hum to adopt
>

  i.e.: <https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding>

> JeffH - can we proceed with existing docs before finishing this? Do
>   we say anything about zero-RTT?
>
> Nick - Maybe we don't need to worry if we don't reference TLS 1.3.
>   We can pretend that TLS 1.3 doesn't exist.
>

but in any case, this I-D is tls13 specific so does not affect present 
spec set

> Martin - early exporters are very different to exporters, maybe we
>   can say that in the document, maybe more so if we end up referring
>   to TLS 1.3, but we don't have to because exporter != early exporter
>

<https://tools.ietf.org/agenda/97/slides/slides-97-tokbind-reverse-proxies-00.pdf>

> Martin - Prefer passing the EKM

Martin - Prefer passing the EKM - it puts the onus on the web app
i.e. option #2 in slides.

> Brian - hard to deal with killing the connection

Brian - there's more info that needs to goto web app, so more difficult 
to do option 2 correctly -- also tbproto sez u drop connection in 
certain cases but web app doesn't own tls connection in this scenario

> Martin - that's a bad requirement ;)

Martin - if the TB is bad, want to drop the present spec requirement to 
drop the connection

> Subodh - if we have a PR to drop the connection drop requirement, we
>   should talk about status codes

  subdoh added: we need to document which http status code is used to 
convey to the app   -- see RFC 7239 -- that is about doing these sort of 
things, but folks have privacy issues with the latter spec, so need to 
keep that in mind

> DECISION - consensus to work on the problem

     i.e. for someone(s) to write an I-D for this

> Subodh - maybe you can talk about that as being a problem; most of
>   these are moved into an out-of-band channel

Dirk -- open source impl of token binding
  github.com/google/token_bind

  can put nginx proxy in front of your http server and it can add tb to 
cookie

  nginx proxy: /nginx_token_bind

  chrome 56 has latest version of TB in it

---
end