Support for PSK mode?

[pthatcherg]

I've just learned about TLS 1.3 PSK mode, which sounds like it could be very useful.

Basically, instead of the app having to provide a remote certificate fingerprint and send a local certificate fingerprint to the remote side, the app could provide a pre-shared secret on both ends. That could probably simplify the use of the API in p2p cases, and it could provide an easy extra layer of authentication (such as the app having the user provide the pre-shared secret to authenticate the its endpoint to the other endpoint).

Would this be worth pursuing? Could we trust the web app with providing a secure PSK (if you just provide "1234" every time, it doesn't do much good).

[lgrahl]

[...] it could provide an easy extra layer of authentication (such as the app having the user provide the pre-shared secret to authenticate the its endpoint to the other endpoint).

This is already technically possible by supplying your own private key for the certificate (if that key has been established or derived from a pre-shared secret). It's just not available in the web APIs and has been discussed before, see w3c/webrtc-pc#1853.

Personally, I would find this useful.

[martinthomson]

I don't want this. Raw public keys might be OK, if the concern is handshake size, but we explicitly rejected SRTP-SDES. TLS 1.3 PSK might allow for forward secrecy though the use of (EC)DHE, but it still allows for impersonation.

(Just to be clear, I also oppose the ability to provide private keys.)

[aboba]

Currently the RTCQuicTransport adopts the RTCDtlsTransport authentication model. Where WebRTC-QUIC is used alongside WebRTC-PC, this would enable SDP negotiation to be handled similarly to DTLS in RFC 8122 (e.g. QUIC fingerprint exchange).

It is more difficult to see how this would work for PSK authentication, since this would require something along the lines of SRTP/SDES.

[pthatcherg]

I understand the concern over similarity to SRTP-SDES, which is why I asked the question "could we trust the web app?". I remember the arguments again SRTP-SDES being along the lines of "we can't trust the web app because it will screw up by doing X" (I recall one example being logging the SDP which contains the keys). But PSK doesn't sound as easy to screw up, so it may be worth doing even if SRTP-SDES wasn't.

As for the authentication model being like DtlsTransport: This same question of PSK would probably apply to the DtlsTransport, since if it ever gets DTLS 1.3 (that will happen someday, right?), it could also use PSK mode. And in both cases, I think the answer is just a different constructor or start method that takes a PSK.

To be clear, I don't currently have an opinion either way, but I can see arguments both for and against.

[pthatcherg]

It looks like we're not going to do this