Meeting begins at 17:13

Token binding over HTTPS (Vinod)
Some pushback against doing a recap
Showing federation use-case
Since last time: 

    Changed header name from Sec-Token-Binding to Token-Binding

    Prove key possision by signing EKM

    updated secuirty considerations


Questions about threats:

    victim's private key should not only be kept secret, but also protected from signing arbitrary attacker-controlled data.

    EKR: why does EKM need to be secret.

    EKR: if EKM is leaked, attacker can impose their own sec header.

    MThomson: if we know about the header we can make ...

    EKR: sec header by default makes it impossible to inject. What is the argument for not using a sec header


Chairs: ready for LC?
MThomson: things come up in this area that may be interesting (duplicate signatures). 

    I wonder whether is someone considered doing a formal analysis of this protocol.

    Not sure we don't have something like this, especially in the federated case.

Andrei Popov: going to enable it in Microsoft browser. Will be interesting to see how it fares in the wild.
Chairs: list is quiet. That there are implementations is good. 
Andrei: yes. Also want early allocation - could help.

EKR: would be more antsy if this was primary authentication.
Andrei: yes, this is for secondary.
MThomson: not prepared to do this in the clear.


Andrei Popv presenting on changes in token binding and negotiation drafts (17:42)
Using TLS extractors instead of tls_unique
ekr: what appears in the digestinfo in pkcs#1.5. What algorithm identifier (OID)
EKR: one more point: kind of trivial: why does the client order by preference but the server picks whatever they want.
Andrei: server may or may not respect the client's order.

EKR: looks very solid. exporters should be enough as personalization string.

folunteering to review and post on the list: Tony, Yoav, EKR and Tony.  This is the protocol document.

Nothing on open mic.