Minutes IETF100: tokbind
minutes-100-tokbind-00

The meeting started at 13:31.  Note Well was shown.

John Bradley reporting on meeting with AD about HTTPS draft.
Mike Jones: He's requesting clarifications of non-normative parts?
JB: Yes.
JB: We're in good shape. Hopefully we can get it through IESG by the end of the
year.

Leif: More Q about core documents?

Nick talking about TB negotiation in TLS 1.3
(draft-nharper-tokbind-tls13)
Leif: Where do we take this?
NH: My suggestion is that the WG adopt this either as-is or merge with the
(already accepted) 0RTT draft MJ: Is it ever meaningful to implement one
without the other? NH: yes, you can dislike 0RTT. Andrei Popov: TB with 1rtt
makes sense. TB with 0rtt has weaker security properties. Not sure it makes
sense. I'd like to keep the drafts separate. Humming:

    Like the idea of adopting this (strong hum)

    Oppose (crickets)

    Don't know (crickets)

Will confirm on the list that we want to adopt this.

Brian Campbell on HTTPS TB with Reverse Proxies
(draft-campbell-tokbind-ttrp-01 - started 13:42)
TTRP = TLS Terminating Reverse Proxy
Stefan Santesson: One way of making this fail-safe is to HMAC the data between
the RP and the backend server with a shared secret. Have you considered this?
BC: There's a wide variety of ways, but it's a broader problem, so there should
not be a one-off solutiong for this draft. Stefan: Seems to me this is the
wrong conclusion. You are specifying this header, and you have an opportunity
to make this safe - to prove that it originates from the reverse proxy. BC: I'm
looking to avoid setting shared secrets between RP and backend server. Don't
want more key management issues. Leif: Some people suggested making a generic
mechanism. The consensus last time was that we should not make a one-off
solution for this here. Somebody should make a generic mechanism (but nobody
has done so yet)

BC: -01 only supports provided and referred binding types. What about others?
MJ: The TB doc and TB-HTTPS doc can communicate for 256 IDs. All but 0 and 1
are thrown away in this draft. BC: You're right. We'll toss any new. MJ: That
is not a good protocol design BC: It's a good design MJ: If you have something
with known audiences, you're going to need different bindings for different
audiences. BC: I'd like to know if this is an extension that we want to have
MJ: it's throwing away information. You should not assume they won't be used.
BC: I think it's simplifying NH: There are also extensions (over and above the
245 unused code points). I think it's acceptable to have a protocol that covers
only existing use cases... MJ: ...today NH: Yes, today. MJ: I want it to be
defined how this additional information is passed. Leif: There is a difference
between makind a 1:1 representation and making a representation for the
majority case with a place for extensibility. MJ: If the goal of your draft is
to enable communication, you need to define how you represent additional
binding types. JB: Since we don't know what they are, are there specific rules
for how the TTRP needs to extract the data or are they all the same with
different numbers? MJ: Yes Vinod: ... MJ: I'm fine with whatever syntax you
want. We shouldn't be throwing away information. That's my request Leif: Can
you sit together and come up with some lines defining this? BC: I'd like to
understand the use case. MJ: Like the Microsoft graph where things come in at
different TLS connections. JB: Good to document this use case. Who signs what
and what does it mean. MJ: I may be able to do this with Tony.  I can work on a
syntax proposal with Brian this week. *** MJ and Brian will offer a concrete
proposal on the list.

Piotr Sikora: Regarding token binding types: if we want to add new types
interoperability is not defined MJ: not the job of this document. Piotr: But
interoperability is not (yet) defined. Vinod: Our implementation is roughly the
same as this except for the header names.  Will move to the standard headers
Andrei Popov: Entirely possible that future docs will define new bindings, but
they will also define TTRP processing. Then we have issue with discovery. BC:
Depends on processing rules.  If new bindings follow same processing rules, no
problem. Otherwise...  We will work on it. BC: Hoping for broader
implementation interest as things progress. Leif: Rough timelines? WGLC by
London? BC: Perhaps around London.

====
Leif: same question for 1.3?
NH: Should be ready in London for regulsr 1.3.  0rtt might take longer.
====

(some shuffling of presentation computers around 14:20)

Attested TLS Token Binding
(draft-mandyam-tokbind-attest - 14:21)
JB explains: attestations at the token binding layer.
JB: has anyone looked at this?
(2 hands come up - Tony and Brian)
JB: The notion may be useful for web authorization.
AP: Great interest in some teams at Microsoft. The strength of the key depends
on the strength of the key storage JB: General idea has some support, but need
to wait to know if *this* is the one. JB: Will not call for adoption now.  Will
do so if there's general positive feedback.

*** Asking for Open Mic issues.

Jeff Hodges: Anything said about the HTTPS draft?
JB: We've discussed with AD and he wanted to know what constraints. We'll add
some text for what kind of federated protocols we intend. JH: He will push it?
JB: Yes, because of our agreement. JH: I think he should have sent it to the
list. Leif: He was not sue if his comments were legit. JH: Any changes need to
be on the list. Also John, Andrey and my comments. Leif: Sure. Nothing to hide.
JH: That's fine. If there are any notes on the discussion, please send to the
list.

*** And we're done at 14:28