On Nov 7, 2019, at 12:30 PM, Owen Friel (ofriel) <ofr...@cisco.com> wrote: > [ofriel] TLS1.3 explicitly does not allow both PSK and certs simultaneously. > draft-ietf-tls-tls13-cert-with-extern-psk does, but that’s Experimental. I > don't think TLS with extern PSK is really intended for Web/Browser HTTPS > connections. Its more for devices/things which are preprovisioned with the > extern PSK.
Then the EAP-TLS document should disallow it, too. If TLS 1.3 doesn't support it, I don't see how something built on top of TLS 1.3 can support it. > In TLS1.3, by design the protocol does not differentiate between resumption > and external PSKs, and says nothing about PSK ID format, as commented here > https://mailarchive.ietf.org/arch/msg/tls/Q5K8HSPPgLRojQwXbV4ZTIxBIH0 , > https://mailarchive.ietf.org/arch/msg/tls/X_z8pc3oS2Au7KajjMhlWhP1UPc Which is fine. I'm happy to have PSKs be anything. The caveat is that we then MUST forbid the PSKs from being copied to the EAP Identity field. So the EAP-TLS document has to make a recommendation. > And its application specific how the two are differentiated, the spec says > nothing about it: > https://mailarchive.ietf.org/arch/msg/tls/btLnZERYv8GJJ2PFUksjNsDyv8o > > I still don't get why EAP-TLS1.3 should place restrictions on use of TLS1.3. > Surely it should be an EAP server implementation decision on whether to > support that feature or not, but we should not preclude a specific EAP server > implementation from supporting extern PSK by disallowing it in the spec. If a > particular EAP server does not want to support extern PSK - that’s fine. Then we need to give guidance on what implementors and administrators should do. Even if it means adding text saying "you can do certs OR PSK, but NOT BOTH". Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
