Suggest getrandom interface which is available on newer OSes. #1373
Conversation
| as /dev/urandom, which should be used absent other (e.g., performance) concerns. | ||
| as /dev/urandom, which should be used absent other (e.g., performance) concerns. On | ||
| newer Operating Systems, the getrandom interface SHOULD be used as | ||
| it can be used in sandboxing environments. |
There was a problem hiding this comment.
Not an objection per se, but I dunno if we want to get into a whole digression in the spec about different APIs to access the PRNG. E.g. getrandom is Linux-specific, then there's getentropy, and then there's the mess about which versions of Linux have which early boot behavior.
Makes me wonder if we should say anything at all here.
There was a problem hiding this comment.
yes, while the intention is good, I think it's too Linux specific
There was a problem hiding this comment.
I do want to keep the guidance on "use the OS CSPRNG rather than rolling your own" (ISTR that I added it in the first place but apparently don't have a checkout on this device to look), and giving one example seems probably reasonable but maybe not necessary. Going into the details of multiple different interfaces feels a bit overspecific for the protocol spec, though maybe in an "implementation notes" section it is still ok?
There was a problem hiding this comment.
Oh yeah, +1 to keeping the mention of the OS. Sorry, "say anything at all" wasn't right. I was thinking just not saying anything about the specific API, but wrote something broader.
There was a problem hiding this comment.
I don't think the TLS spec should opine about something as implementation-specific as which Linux-specific APIs are or aren't friendly for sandboxing. Definitely not at the level of a SHOULD.
I mean, depending on the sandboxing strategy and the TLS stack's structure, /dev/urandom might even be better than getrandom for a sandbox. Imagine a syscall-filtering sandbox that hasn't been updated for getrandom, paired with a capabilities-heavy TLS stack that actually happily takes an externally-supplied /dev/urandom file descriptor.
(Though, yes, getrandom is probably generally more sandboxing-friendly than /dev/urandom in most cases. Certainly we prefer it for Chrome's sandbox. I wouldn't expect most TLS libraries to happily take an externally-supplied fd in lieu of /dev/urandom. But it's a plausible enough design to disqualify this guidance IMO. And then you've got Windows, where the APIs and sandboxing considerations are completely different.)
There was a problem hiding this comment.
Also, practically speaking, the TLS library is probably calling into its cryptography library's general-purpose PRNG interface, so it's not like it's going to do anything special anyway.
| In most cases, the operating system provides an appropriate facility such | ||
| as /dev/urandom, which should be used absent other (e.g., performance) concerns. | ||
| as /dev/urandom, which should be used absent other (e.g., performance) concerns. On | ||
| newer Operating Systems, the getrandom interface SHOULD be used as | ||
| it can be used in sandboxing environments. |
There was a problem hiding this comment.
I can't suggest this, but here's what I'd say:
A performant and appropriately-secure CSPRNG is provided
by most operating systems or can be sourced from a cryptographic library.
| @@ -5223,7 +5226,7 @@ TLS uses random values (1) in public protocol fields such as the | |||
| public Random values in the ClientHello and ServerHello and (2) to | |||
| generate keying material. With a properly functioning CSPRNG, this | |||
| does not present a security problem, as it is not feasible to determine | |||
| the CSPRNG state from its output. However, with a broken CSPRNG, it | |||
| the CSPRNG state from its output. However, with a broken or compromised CSPRNG, it | |||
There was a problem hiding this comment.
Isn't it true that compromised \subsetof broken ?
There was a problem hiding this comment.
Broken seems to be sufficient. This sentence is a counterpoint to properly functioning CSPRNG in the previous sentence.
There was a problem hiding this comment.
Understood. Will remove this.
No description provided.