Implement P2P Crypto Handshake for RTCQuicTransport |
|
Issue descriptionAs defined in the specification (https://w3c.github.io/webrtc-quic), we plan to implement a peer to peer crypto handshake. Unlike the standard client-server case, this means verifying both peer's self signed certificates by checking the cert fingerprint against the remote fingerprint that was signaled through a secure channel (see rfc 5763 section 5 - https://tools.ietf.org/html/rfc5763#section-5).
,
Aug 15
This is currently blocked on the QUIC library supporting the TLS 1.3 handshake. What we will likely need is something similar to: - server always asks the client for a CertificateRequest - API surface for us to give the client's self signed certificate & signature of the handshake context (similar to ProofSource for the client?) - API surface for us to verify the client's certificate (similar to ProofVerifier, but for the server?)
,
Aug 15
Note that this has been implemented by the DtlsTransport in WebRTC (https://cs.chromium.org/chromium/src/third_party/webrtc/p2p/base/dtlstransport.h). There is a race that can occur between the signaling of the remote fingerprint and the initial CHLO. For the DtlsTransport the verification of the fingerprint is skipped in this case, and the fingerprint is not verified until after the handshake completes and the remote fingerprint is set. In the case of how the QUIC TLS 1.3 handshake is implemented this means either: - the handshake waits for the remote fingerprints to be set -verifying the fingerprint happens after the handshake completes and media doesn't flow until this occurs (like in the DtlsTransport) |
|
►
Sign in to add a comment |
|
Comment 1 by shampson@chromium.org
, Aug 15