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

Status: RESOLVED WONTFIX

(Core :: WebRTC: Networking, defect, P3)

Description

[Eric Rescorla (:ekr)]

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.

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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.

Comment 2

[Eric Rescorla (:ekr)]

(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.

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(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?

Comment 4

[Eric Rescorla (:ekr)]

(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.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 6

[Maire Reavy [:mreavy]]

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.)

Comment 7

[Martin Thomson [:mt:]]

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.

Comment 8

[Martin Thomson [:mt:]]

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.

Comment 9

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 10

[Nils Ohlmeier [:drno]]

Feels to me like we can close this one, or do we still want to implement something here?

Comment 11

[Martin Thomson [:mt:]]

Yeah, P-256 keygen is enough faster that we don't need to worry about this.