On Mar 3, 2024, at 7:57 AM, Jan-Frederik Rieckers <rieck...@uni-bremen.de> wrote: > The idea here is that future versions may signal some information outside the > TLS tunnel. Our first idea, where this kind of still stems from was that the > server signals the RPID outside the TLS tunnel, so the client can verify that > the server's certificate is in fact valid for that.
I would strongly prefer that there be no signalling outside of the TLS tunnel. The "outer TLV" issue with TEAP is frustrating for an implementor. Adding similar, but different, things for other EAP methods makes implementations more difficult. ALPN would be much simpler, I think. The downside there is that every time you rev the protocol, you have to register a new ALPN name. That's annoying. I don't know if it would be acceptable to register an ALPN _prefix_, and then just self-allocate versions. An alternative would be to do the version negotiation inside of the TLS tunnel. That's also imperfect, but at least gives EAP-FIDO complete control over all aspects of the protocol. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
