On 12/03/2019 07:54, Ryan Sleevi via dev-security-policy wrote:
On Mon, Mar 11, 2019 at 5:35 PM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Since choice 1 is a logical consequence of "containing 64 bits of random
data", I was always under the impression, that choice 2 was meant by the
BRGs. If choice 1 is meant, then I think the requirement of being
'non-sequential' is just some lyrical sugar in the BRGs. Maybe there is a
third definition of "sequential" that I haven't thought of?
I had definitely seen it as lyrical sugar, trying to *really* hammer the
point of concern (of predictable serials). This is an example where
providing guidance in-doc can lead to more confusion, rather than less.
For example, a "confused" reading of the BR requirement would say "at least
64-bits of entropy" by generating a random number once [1] and including it
in all subsequent serials, monotonically increasing +1 each time :)
Sony tried this (minus the increment) when generating random nonces for
ECDSA signing, apparently generating the nonce once during key
generation, and reusing it for all subsequent signing operations [1].
That worked wonders for them *cough* :)
I think when it comes to specifications with cryptographic relevance (as
unpredictable serials are), less is more; the more inflexible and
unambiguous the spec is, the less likely it will be "creatively
interpreted" in a manner that bypasses the whole point. To someone with
crypto experience and an understanding of the intent, the current
language clearly means "take 64 bits from a CSPRNG once, put whatever
you want around them (or nothing), DER encode, and stuff it into the
serial field". But clearly some implementers interpreted this
differently, and here we are.
That said, I do think the current exercise is, shall we say, bringing
out some interesting opinions on what an appropriate response to the
problem is. Statements such as:
There are no, and has never been any, 63 bit serial numbers created by EJBCA.
... lead me to significantly reduce my trust in those making them, and
their ability to correctly interpret security-critical standards in the
future. Not everyone gets things right the first time, but owning up to
problems, understanding the technical issue at hand, and accepting
responsibility is a basic tenet of earning community trust.
[1] https://mrcn.st/t/1780_27c3_console_hacking_2010.pdf pp. 122-129
--
Hector Martin "marcan"
Public key: https://mrcn.st/pub
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
