Intro/Agenda -- no changes to agenda Andre Popov presented slides relating to the document draft-popov-token-binding Some discussion about the negotiation that and where it occurs. Should it be in an APLN TLS extension, a different TLS extension or at the application layer. AP said that moving to the application layer is a problem as that introduces extra round trips to do the negotiation. Current thought is that a new TLS extension would be used. In response to a question key lifetimes, Andre responded that the user can always delete them, the crypto device would be able to delete them based on parameters about the key algorithms. It would also be good to provide a suggestion that easily accessible UI be provided to make logining and (and thus deleting the key) be easier than cookie deletion is today. Dirk Balfanz then presented slides relating to draft-balfanz-https-token-binding There was a large amount of discussion dealing with the issues of what information is being sent to the IdP and why it was being sent. Privacy considerations means that minimal information needs to be sent, but it was not clear to some people by both public keys were being used in the message to the IdP. There was a large discussion on the issue of using the TLS unique value as opposed to some type of challenge from the server. While a challenge would involve the addition of a round trip, depending on the TLS unique value introduces a large number of problems for TLS proxies on both the client side and the server side. The client side introduces a new TLS channel and thus a new TLS unique value, the server side introduces problems with how to get the TLS unique value or the verification of the signature from the gateway to the HTTP server. Open Discussions Lief asked the group to express an opinion on adoption of the documents in the working group. The hum in the room showed strong consensus to adopt the document. Lief suggested that the current github tracker being used for the documents continued to be used, but requested that the documents themselves be published so that multiple people can contribute. A discussion about milestones was then held. The current milestone seems somewhat optimistic, however there was not a strong push to have them changed until the next IETF when it can be seen how the group is functioning Finally, a presentation FIDO was made by Jeff Hodges and Dirk Balfanz. ******************** END minutes ************************* presentation #1 Martin Thompson (MT) - Dont use ALPN Does not make sense using TLS is smaller Hannes (HT) - Is TLS the correct place to do this? why not use OAUTH - resouce server needs the information not the client AP - not client auth - dont' want to use more round trips doing negoation HT - parameters to communicate client to server tell auth server who issues token - client avoid using alg that resurce server does not know auth server knows what the resource server can do AP - binding use with both the auth server and the resource server DKG - client signaling what binding can be used - HT has more complex ideas signing this piece in TLS extension make sense HT - need to tell, hash function & protocol - maybe some other (CoaP) not endless number of things - but not just one MT - No one consuming this at the TLS layer - all activity in the HTTP/protocol layer moving to other protocols later not now AP - This is not in TLS - uses TLS unique - could be used with other protocols MT - signal at HTTP layer - cleaner - can't use signature extension because not sufficient AP - don't want to do extra roundtrip in appliction layer to negotiate John - don't need the multi-party negotiation - Hannes is over thinking Bill Mills - How does this work with speedy with multiple sites behind the TLS firewall AP - token binding is per TLD in that case YN - can have different cookies for different site? AP - yes HT - more infrastructure that people will want to tie into later even if don't realize it now AP - key lifetime - user can always delete them crypto layer can decide to purge key based on age of key leave to the crypto layer to make decision about lifetimes YN - erasing cookies is not a frequent user operation Intend this to be more accessable to users? I.e. log out button? AP - no language in draft on UI requirements Would not object to recommendation to do this. draft-balfanz-https-token-binding MT - provide redirect - allows to sling any information over the redirect RP stuffs additional data into the URL why prove someting to the IdP here ?B - IdP gets proof that both private keys controlled by the client MT - man in the middle kind of hosed anyway. Prefer not to have the information shared unless needed ?B - make sure token is about this client - trying to exclude some MITM attacks MT - RS and IdP have a relationship - can pass some information setup for OAUTH tokens to be run around ?B - otherwise it could be somebody elses key pair MT - as long as RP is not exposed to MITM attack - info is useless to the attacker ?? - concerned about another client stealing the authorization ?? - which TLS_unique is bing used on HTTP-Redirects slide#2 ?B - this is the Cient-IdP link TLS-Unique MT - On fetch question - trying to deprecate XmlHttpRequest, trying not to add new things to it. Lief - Need to get W3C review on this document. can you get some review MT - yes - go to webapp sec group to get review with email. Wendy - happy to help to get the communications happen ?? - political question - 99% of world is still using XHR - do you want it to be highly used ?B - not a problem with getting new browsers since need to have updates to roll this out anyway. BM - is the HTTP server assumed to have access to the tls-unique value? Does the HTTP app layer recheck this signature? ?B - @ google would have the terminator do the POP verification - alternative would be to send tls-unique downstream to the backend DKG - is this dependent on the TLS session hash fix? ?B - yes YN - fails for TLS proxies since TLS unique value has changed ?B - won't get this to work since binding would be to proxy - problem is client moves around from behind proxy to not and back. BM - No binding between TLS and HTTP in the proxy case Brian ? - Intercepting proxies that currently intercept client certs are going to have the same problems with this type of system as it will have problems with different tls_uniques - problems with bounding around on different load balance proxies ?B - really trying not to introduce more round trips MT - only way to solve is to do a challange - only wao to address with MITM of some type. don't know if you want to solve the CDN case or not ?B - don't want the extra round trip, from our data does not seem to be a massive problem with logging people out from changing being behind proxy JB - Differing expectations on what appliations can get to what keys in this case. Need some security considerations about this. ?B - plans to get some recommendations on these issues as a group. Key protection: should not be extractable - Discloser of IdP info to the RP or user data w/the IdP - this is why was done with the ower level - Open Discussion - Lief Issue tracking - use the GitHub tracker - put sources on the github as well for pull requests working group adoption AP - please adopt Hum shows strong adoption in the room Charter milestones - Lief - suggest leaving along until we find how work progresses Steve Ferral - always somewhat fictional please make it fast Lief - given discussion - probalby not before fall AP - should have current issues addressed by next meeting with document update also have the TLS extension draft by the next meeting MT - don't have a dependency on TLS - do the extension here SF - dissucsion on the dependency for the WebAppSec W3C group Wendy - suggest independent documents - fetch not W3C SF - use descriptive not normative text on the API changes Open Mic time Jeff Hodges on FIDO