Subject: [dsfjdssdfsd] Should secure RNGs be a MUST?

From: Dan Brown <[email-masked]>
Date: Tue, 11 Mar 2014 17:08:06 +0000

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Alyssa Rowan <[email-masked]>
Date: Tue, 11 Mar 2014 18:26:59 +0000

On 11/03/2014 17:08, Dan Brown wrote:

> So, I am not totally sure about the question of whether secure
> RNGs should be a MUST.  I wonder what others think.

Given this list exists, I'd say yes: going forward, they MUST be. <g>

Regarding your counterargument: I think security considerations
warrant MUST.

I think secure RNGs really need to be considered a vital component to
analyse. They have clearly been considered a vital component to
attack: and no wonder. Insecure RNGs introduce major unexpected
problems, including predictable keys and key leakage, in protocols
which rely on secure RNGs to satisfy their security requirements. But
they can be subtle, and hard to verify.

We should consider how robust protocols may be if those requirements
are not met, and generally prefer (as a "safety net") protocols which
do not fail catastrophically if the RNG is weak, if a practical
alternative exists. But it's perfectly reasonable I think to also
specify at the same time that the RNG MUST be strong and if it isn't,
you're doing it wrong.

We know really vital problems have existed in implementations. Someone
should figure out what any further problems may be; look for them;
find them; fix them; disclose them. (Not necessarily in that order.)
It seems that in many cases, this hasn't happened. (Maybe everyone
thought it was someone else's problem.) It needs to.

It doesn't matter so much whose problems they are: as you correctly
say, an insecure implementation would not be securely interoperable
even with a secure one. While a bad RNG is in the wild, it could be
everyone's problem: I think we need to do what we can to avoid that.

- -- 
/akr

---

From: Dan Brown <[email-masked]>
Date: Tue, 11 Mar 2014 19:32:39 +0000

Hi Alyssa,

Thanks for your input.

By the way, I believe current specs from ANSI X9F1 and NIST (in SP 800-56A
...) have taken the view that keys MUST be generated with a secure RNG, and
have gone further to specify various details of the RNG such as a DRBG
(PRNG) mechanism that MUST be one of three or four mechanisms, and further
the seeds for the DRBG must adhere to various requirements. 

I do not disagree with these requirements, from a security perspective, but
I guess I was asking whether they are in scope, or priorities, of IETF.
Maybe, IETF places such a high priority on connectivity that security is
just a close second.  

Some IETF docs refer to ECDSA, often via X9.62-2005, which, as already
noted, requires secure RNGs, namely one of the ANSI X9.82 RNGs, or any
future ANSI-approved RNGs.  So, in that regard, the IETF docs would already
inherit a MUST for secure RNGs, including the DRBG mechanisms and so on.
(Other crypto algorithms, including IETF re-specified algorithms, may not
have these ANSI/NIST requirements, I have not checked yet.)

If so, then maybe this list should discuss whether these ANSI/NIST
requirements are necessary and/or sufficient for IETF, at least in the case
of ECDSA. 

Best regards,

Dan  

> -----Original Message-----
> From: dsfjdssdfsd [mailto:[email-masked]] On Behalf Of
Alyssa
> Rowan
> Sent: Tuesday, March 11, 2014 2:27 PM
> To: [email-masked]
> Subject: Re: [dsfjdssdfsd] Should secure RNGs be a MUST?
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> > So, I am not totally sure about the question of whether secure RNGs
> > should be a MUST.  I wonder what others think.
> 
> Regarding your counterargument: I think security considerations warrant
MUST.
> I think secure RNGs really need to be considered a vital component to
analyse.
> They have clearly been considered a vital component to
> attack: and no wonder. Insecure RNGs introduce major unexpected problems,
> including predictable keys and key leakage, in protocols which rely on
secure
> RNGs to satisfy their security requirements. But they can be subtle, and
hard to
> verify.
> 
> We should consider how robust protocols may be if those requirements are
not
> met, and generally prefer (as a "safety net") protocols which do not fail
> catastrophically if the RNG is weak, if a practical alternative exists.
But it's
> perfectly reasonable I think to also specify at the same time that the RNG
MUST
> be strong and if it isn't, you're doing it wrong.
> 
> should figure out what any further problems may be; look for them; find
them;
> fix them; disclose them. (Not necessarily in that order.) It seems that in
many
> cases, this hasn't happened. (Maybe everyone thought it was someone else's
> problem.) It needs to.
> 
> It doesn't matter so much whose problems they are: as you correctly say,
an
> insecure implementation would not be securely interoperable even with a
secure
> one. While a bad RNG is in the wild, it could be everyone's problem: I
think we
> need to do what we can to avoid that.
> 
> - --
> /akr
> -----BEGIN PGP SIGNATURE-----
> 
> iQIcBAEBCgAGBQJTH1VzAAoJEOyEjtkWi2t6nBsP/0CqWHtgs7WBXQto5lD+pFTE
> 8Uh7Nkoc7Kiy6VBadGEb7irR4+gfLhxJboAbJO3cUfqJDuEHczkTZLhiM2PV1FFS
> zHycQv8JwGs1EM2OUEX607jQgnV+3Jy/c+LTTGZJLCSEGXnvgD+BwQ7wlOfqvQq
> 4
> kWGsAe54VhvKGCb944H+pqTSeTZbCEUpTOQBaQoNl2JUAKwXY0QVk10o5dRV1
> bJt
> xXirhmV+sNVpCkcg7ExL8GkOcxQ9RLWIVAMzaAqwqH/FHK4FmLLGNWjuwePThp
> G/
> AbngohDsei7YOecMkwkcB1+14XdgAnGxfnNMXq6eslQi9XhGrF24gEQBI8JJzJ6d
> EqwrJGCRP7PVkJdAvufwgAiiP3hUURGFHjMuNZmFb7XGLO/Yeu2xKmT6Z4CsIk6j
> W1bOP7MPJsztprFQC2qtOgzV5qbsEia0/6LiXnpQRn8Zz8LkJNjpLlgzr3xsDwLj
> pLkglDVZf3HIKzIk6DuY1dAN6zcgpCS2xMa1PDyZJAS6QNXPg1Tuq2IkMSgwPt3F
> 165pALuohuWk5AL+UQsu4KgSTmHYFUl9EX5nRNgMiaNwM0NNJF37VexFIyHzc0
> 4i
> NlTHe4pW1vo4ngeIss07fN8/cS5X4ymYpmiobbi1KBjrDkUestZpFCOR1MjdGfs9
> RyY8FgwLznkNiBYuLYLc
> =sHBQ
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> dsfjdssdfsd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dsfjdssdfsd

---

From: Alyssa Rowan <[email-masked]>
Date: Tue, 11 Mar 2014 19:40:09 +0000

On 11/03/2014 19:32, Dan Brown wrote:

> […]I was asking whether they are in scope, or priorities, of 
> IETF.[…]

I'm certainly no process expert, but probably? Advice on secure RNG
practices in RFC 4086 seems to have been considered in-scope for IETF
before.

This list exists to discuss randomness, where it impacts IETF
protocols. It's definitely not something we should ignore: and given
what we've seen, and how fundamental good randomness is to good
security, I would firmly argue not something we should defer to other,
less transparent, bodies in future.

- -- 
/akr

---

From: [email-masked]
Date: Tue, 11 Mar 2014 17:22:13 -0400

> ...snip...

I know that this is not the right term as it has a pre-existing
definition, but might you be arguing that a trustworthy RNG is a,
if not the, "trust anchor" for security as we now understand it?
That is to say "the authoritative entity for which trust is assumed
and not derived"?  [quotation from various Wiki def'ns]

--dan

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Mar 2014 22:48:08 +0000

Well, you're brave if you're arguing to make NIST RNG specs
a MUST given recent news;-)

But seriously, I don't think its at all clear how 2119 terms
map to an implementation consideration such as the goodness
of an RNG, especially when its so hard to measure.

If there were some accepted descriptions for different kinds
of randomness requirements that might be placed on protocol
data units that could be useful, esp if we also had examples
of how to meet those requirements.

But I'm not sure if the above would be very useful really.

We may be better off just updating 4086.

However, that's what this list is for, so people can discuss
this kind of thing.

S.

---

From: Sandy Harris <[email-masked]>
Date: Tue, 11 Mar 2014 19:46:08 -0400

> Regarding your counterargument: I think security considerations

Absolutely, at least in any protocols whose security properties matter,
and often elsewhere as well.

> analyse. ...
> do not fail catastrophically if the RNG is weak, ...

I cannot think offhand of a protocol that uses random numbers and
does not fail with bad ones. Sometimes, as in choosing TCP sequence
numbers, it may not matter a lot, but I am not even certain of that.

There are many examples of important security protocols that fail
disastrously -- as in do not achieve any of their design goals -- if a
weak RNG is used. Here are some:

The Diffie-Hellman key negotiation protocol -- used by at least IPsec,
SSL/TLS and SSH, and for all I know others -- can be straightforwardly
broken if either party uses a weak RNG. The break gives the enemy
the shared key, which lets him break both the encryption and the
packet-level authentication.

PGP generates a random key and uses it to encrypt the message
with an efficient block cipher. Then it uses public key methods to
safely deliver that key to recipients. A sufficiently bad RNG could
therefore break PGP.

RNGs are also required for most types of key generation for any
public key algorithm. The recent findings of massive duplication
of TLS keys (a fatal flaw) on the net was attributed mainly to
linux-based routers that failed to initialise their RNGs correctly.

The DSA algorithm may be a standard, but it is horrendously
flawed. A single use with a bad RNG or multiple uses if each
leaks a bit of random material, completely break it, letting an
attacker get the private key.
https://en.wikipedia.org/wiki/Digital_Signature_Algorithm#Sensitivity

Some people, including me, suspect that such a flawed method
could only have been standardised as a deliberate attempt to
facilitate monitoring.