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 _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable