Pre-generate and/or cache/store RSA key gen for DTLS-SRTP

NEW
Assigned to

Status

()

Core
WebRTC: Networking
P3
normal
Rank:
28
6 years ago
8 months ago

People

(Reporter: ekr, Assigned: jib)

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
Currently we are generating 1024-bit keys. It would be nice if they were stronger, but it's too expensive to generate 2048-bit keys on the fly. We need to add some caching and/or pre-generation at which point we should dial the number up to 2048.
This is one reason BrowserID is using DSA. Perhaps we should switch to DSA.

Regardless, we shouldn't be doing these time-consuming operations on the socket transport thread and we absolutely must not be doing them on the main thread.

We should avoid generating any keypairs the page has accessed or created some kind of WebRTC-related DOM object. I bet we can do that without adding any latency because the key generation can be made to happen concurrently with the first part of the DTLS handshake. (BTW, do we have the DTLS cookie mechanism enabled? Should we?)

We need to be careful about re-using the same keypair across multiple connections, to avoid making it trivial to link identities across connections.
(Reporter)

Comment 2

6 years ago
(In reply to Brian Smith (:bsmith) from comment #1)
> This is one reason BrowserID is using DSA. Perhaps we should switch to DSA.

That would be a pretty break break from current TLS practice.


> Regardless, we shouldn't be doing these time-consuming operations on the
> socket transport thread and we absolutely must not be doing them on the main
> thread.

Yes, it's on my TODO list. 


> We should avoid generating any keypairs the page has accessed or created
> some kind of WebRTC-related DOM object. 

Sorry, I don't understand this. Can you rephrase?

>I bet we can do that without adding
> any latency because the key generation can be made to happen concurrently
> with the first part of the DTLS handshake. (BTW, do we have the DTLS cookie
> mechanism enabled? Should we?)

Regrettably, it cannot be done concurrently because you must send the
fingerprint first.

We don't have *any* session caching enabled.


> We need to be careful about re-using the same keypair across multiple
> connections, to avoid making it trivial to link identities across
> connections.

The idea is that the keys will be domain scoped.

Yes. See http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-03 Section 5.5.
Send comments if you think that's not sufficient.
(In reply to Eric Rescorla from comment #2)
> (In reply to Brian Smith (:bsmith) from comment #1)
> > This is one reason BrowserID is using DSA. Perhaps we should switch to DSA.
> 
> That would be a pretty break break from current TLS practice.

Sure, but WebRTC, TLS over UDP, etc. are already a break from current practice. And, also, I know (via non-public information) that DSA certificates are likely to be becoming more popular soon for regular TLS anyway.

> > We should avoid generating any keypairs the page has accessed or created
> > some kind of WebRTC-related DOM object. 
> 
> Sorry, I don't understand this. Can you rephrase?

Accidentally a word: We should avoid generating any keypairs UNTIL the page has accessed or created some kind of WebRTC-related DOM object. That is, don't start pre-generating them before we've even seen something related to DTLS.

> >I bet we can do that without adding
> > any latency because the key generation can be made to happen concurrently
> > with the first part of the DTLS handshake.
> 
> Regrettably, it cannot be done concurrently because you must send the
> fingerprint first.

>> (BTW, do we have the DTLS cookie mechanism enabled? Should we?)

> We don't have *any* session caching enabled.

I meant, do we use the DTLS stateless cookie exchange DoS prevention mechanism?
(Reporter)

Comment 4

6 years ago
(In reply to Brian Smith (:bsmith) from comment #3
> > > We should avoid generating any keypairs the page has accessed or created
> > > some kind of WebRTC-related DOM object. 
> > 
> > Sorry, I don't understand this. Can you rephrase?
> 
> Accidentally a word: We should avoid generating any keypairs UNTIL the page
> has accessed or created some kind of WebRTC-related DOM object. That is,
> don't start pre-generating them before we've even seen something related to
> DTLS.

That's currently the way we behave, but if we are to pre-generate, we'd
probably like to have a cache of a few unbound keys and then just
pull one off the stack at the time when we currently generate it, namely
PC instantiation.



> > We don't have *any* session caching enabled.
> 
> I meant, do we use the DTLS stateless cookie exchange DoS prevention
> mechanism?

No, it's not necessary b/c ICE has its own consent mechanism.

Updated

6 years ago
Whiteboard: [WebRTC] [blocking-webrtc-]

Updated

6 years ago
Whiteboard: [WebRTC] [blocking-webrtc-] → [WebRTC] [blocking-webrtc+]
Unmarking as blocking - we'd like this but it's not required to pref on IMHO

-> Jan-Ivar for now tentatively, though this is not currently a priority to work.
Assignee: nobody → jib
Priority: -- → P3
Whiteboard: [WebRTC] [blocking-webrtc+] → [WebRTC] [blocking-webrtc-]

Updated

3 years ago
backlog: --- → webRTC+
Rank: 35
Whiteboard: [WebRTC] [blocking-webrtc-]
Martin -- How much would this reduce call set up time on low end mobile devices for 1024-bit and 2048-bit keys?  (I'm looking to re-assess the priority of this bug.)
backlog: webRTC+ → ---
Rank: 35
Flags: needinfo?(martin.thomson)
Priority: P3 → --
It's going to depend a fair amount on what sort of device we're talking about.  At 1024-bit, I'd expect something in the order of 100s of milliseconds. bench.cr.yp.to has a 2012 high end ARM chip taking 0.33s at 1024, and 1.55 at 2048; the same chip does ECSDA in <2ms.

We're talking seriously now about moving to ECDSA in the IETF, as well as a certificate management API, which will include programmatic control over caching.

The certificate management pieces (i.e., caching) is now in the spec proper, so now would be a good time to start implementing.

The plan is to do the following, all together:
 1. implement the certificate management API
 2. default to ECDSA with P-256
 3. increase the minimum with RSA to 2048 bits

The caching part of the certificate management API might be implemented at a later point, but I'm told that it's not especially hard.
Flags: needinfo?(martin.thomson)
backlog: --- → webRTC+
Rank: 28
Priority: -- → P2
Superceded now by bug 1172785.  For which I now have an implementation.  I don't know how you want to manage these Maire, but I've put the implementation there.  BTW, if you could prod :peterv about fixing bug 863952, that would be superb.  It's the only thing that is really holding this back.
Depends on: 1172785
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.