Make certificates optional in the DtlsTransport constructor #867
Conversation
|
what is the behaviour when null is passed? I assume "generate a new one"? |
|
@fippo Yes. Now that ECDSA is the default ciphersuite, generation should not block the main thread even on modest processors. |
There was a problem hiding this comment.
I am a bit confused by ciphersuites, which for me is something like TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 in dtls (from jsep, 5.5)
Maybe this is key generation algorithm as used in https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-generatecertificate ?
Either way, this makes sense.
|
Mh, I don't think I like this change. Blocking the main thread (even slightly) is never a good idea and generating a certificate is just one line. |
index.html
Outdated
| <li><p>If <var>certificates</var> is non-null and is non-empty, | ||
| initialize the <a>[[\Certificates]]</a> internal slot to <var>certificates</var>.</p></li> | ||
| <li><p>If <var>certificates</var> is <code>null</code> or is empty, | ||
| generate a certificate using the default ciphersuite and store this in the |
There was a problem hiding this comment.
keygenalgorithm. I assume this is already fixed like in w3c/p2p-webtransport@1ace017 but not pushed :-)
|
@lgrahl I share your concern about blocking the main thread; I suspect on most desktops this will be < 40ms with P-256 default ECDSA but on slower less powerful mobile this could be 100ms+. We could never generate 2048bit RSA with blocking on a slow device (bad idea) so it's only ECDSA by default at best. |
|
Looking at the ECDSA generation times, it would seem that generating a more secure ECDSA certificate (equivalent to RSA 2048) could take longer than 100 ms on a low-end processor. So putting this proposal on hold for now. |
Fix for Issue #866