Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Dan Brown <[e-mail]>]

‎Section 3, of the eprint "Ron is wrong, Whit is right", subsection "Moduli with shared primes", suggests to me that it's not unlikely when seeding two secrets near in time, one has low entropy (by accident). That's not the only explanation of the observed shared primes, but is plausible and relevant to the question at hand. (I thought I mentioned this earlier.)
From: Colm MacCárthaigh
Sent: Saturday, July 29, 2017 2:04 PM
To: Dan Brown
Cc: Stephen Farrell; Eric Rescorla; Blumenthal, Uri - 0553 - MITLL; [e-mail]
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's




I don't see anything relevant to the problem at hand in that paper. Did you reference the right one? There are some mentions about not re-using random secrets, but that applies no matter how many RNGs you use.

In your previous mail, even if an implementer were to seed two RNGs from one CSPRNG, and all 3 are bad generator, this is still strictly better than one broken generator; because the amount of work an attacker must do is far greater.

On Sat, Jul 29, 2017 at 8:54 AM, Dan Brown <[e-mail]<mailto:[e-mail]>> wrote:
https://eprint.iacr.org/2012/064
mentions the problem of generating multiple secrets instead of a single secret




  Original Message
From: Stephen Farrell
Sent: Friday, July 28, 2017 11:48 AM
To: Dan Brown; Eric Rescorla; Blumenthal, Uri - 0553 - MITLL
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's


I don't think this is simply a case of multiple CSPRNGs.

My guess is many TLS implementations don't have visibility
into how the CSPRNG operates. That code does however, know
which output values will be public and which not. For me,
that implies that any good separation scheme applied within
the TLS code that differentiates between public and non
public outputs is a good plan. Yes, if an attacker can bork
your CSPRNG, they may be able to get at the TLS code too
sometimes, but I'd argue the defence in depth is worthwhile.

Cheers,
S.

On 28/07/17 14:37, Dan Brown wrote:
> I try below to better explain my points against separated public and private CSPRNG instances.
>
> Perhaps the easiest way to get "independent" seeds for the two instances of a CSPRNG, is to use a third CSPRNG instance to generate the seeds.  But then the problem arises again, if the 3 CSPRNGs are bad enough, (0=seeder, 1=public, 2=private), there is a risk that:
>
> Public_nonce=output1=>seed1=output0_for_1=>seed0=>output0_for_2=seed2=>output_2=private_key=TLS_insecurity.
>
> In short, generally speaking, three bad CSPRNGs do not combine easily into 1 good CSPRNG.
>
> (I'm not yet sure if this attack on three CSPRNGs combined applies to Dual_EC, since it may do something hash-like to the seed (I forgot details), and also output leaks the next state, not the previous state, as I recall, so that might break the chain above.)
>
> The alternative to a 3rd CSPRNG is to get the seeds from directly from a raw entropy source. In that case, keep in mind that one of the purposes of CSPRNGs is that raw entropy sources are unreliable (sometimes stall, etc. [references to be added]) and generally weak on the independence (they are non-uniform, hence have correlations).  CSPRNGs are supposed to correct these deficiencies, among other things.  So, if the 2 seeds are generated directly from a raw entropy sources (without a CSPRNG), two things may go wrong. First, deriving one seed from the other might be feasible because of non-uniformity. A bad CSPRNG might enable this this to be exploited, by finding one seed from the other.  Second, if the entropy source stalls (down a trickle of low entropy), between too close seed requests - accidentally - then even a good CSPRNG couldn't cope.
>
> Maybe, all this wouldn't be a problem on many higher end systems, with high entropy, so my concern is lower end systems, and also unnecessary complications of maintaining multiple bad CSPRNGs, potentially to no avail.
>
> Finally, on systems with a linux-style interface, /dev/urandom and /dev/random could be used as the two CSPRNGs on some systems (or seed sources), although I think one of these is now deprecated?
>
> -----Original Message-----
> From: TLS [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Stephen Farrell
> Sent: Friday, July 28, 2017 4:47 AM
> To: Eric Rescorla <[e-mail]<mailto:[e-mail]>>; Blumenthal, Uri - 0553 - MITLL <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
>
>
> Hiya,
>
> On 28/07/17 00:50, Eric Rescorla wrote:
>> I used the term "separate" here, which was intended to convey this,
>> but if people think "independent" or something is better, happy to change.
>
> I think your change is a fine improvement over -21, thanks.
> (And my suggested text was as imperfect as I usually manage:-)
>
> I'm not clear if implementers will or will not get the ramifications of "separate" (or "independent"), so I think we ought describe (or reference) at least one way in which that separation can be achieved.
>
> I also think we ought at least RECOMMEND separate CSPRNGs.
> I'd prefer a MUST myself but since there's no one good way we can describe to achieve the effect that'd work in all cases, I don't think we can say MUST.
>
> Cheers,
> S.
>
>
>>
>> -Ekr
>>
>>
>> On Thu, Jul 27, 2017 at 4:43 PM, Blumenthal, Uri - 0553 - MITLL <
>> [e-mail]<mailto:[e-mail]>> wrote:
>>
>>> Respectfully disagree. Having two cryptographically independent
>>> PRNGs, one for public data and one for key material, IMHO is a good
>>> idea. Of course, both should be properly seeded - but that's a different issue.
>>>
>>> Regards,
>>> Uri
>>>
>>> Sent from my iPhone
>>>
>>> On Jul 27, 2017, at 19:33, Dan Brown <[e-mail]<mailto:[e-mail]>> wrote:
>>>
>>>
>>> I don't think 2 CSPRNGs is a good idea.
>>>
>>> Wasn’t there a few years back some RSA keys with separate p and q,
>>> generated independently leading to an attack...
>>>
>>> Here if the seeds to initialize the RNGS are related, or one is weak,
>>> or worst if the seed is a raw source that doesn’t change in the
>>> moments between the two CSPRNG inits, that'd be bad, even if the CSPRNGs were good.
>>> *From: *Eric Rescorla
>>> *Sent: *Thursday, July 27, 2017 6:34 PM
>>> *To: *Stephen Farrell
>>> *Cc: *[e-mail]<mailto:[e-mail]>
>>> *Subject: *Re: [TLS] 32 byte randoms in TLS1.3 hello's
>>>
>>> Spec updated here;
>>> https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0ac
>>> bc42
>>> 942af9ca77
>>>
>>> -Ekr
>>>
>>>
>>> On Wed, Jul 26, 2017 at 4:27 PM, Stephen Farrell <
>>> [e-mail]<mailto:[e-mail]>> wrote:
>>>
>>>>
>>>> I've suggested some text for this in a PR [1] based on what people
>>>> have said in this thread.
>>>>
>>>> I'm sure that can be further improved.
>>>>
>>>> It might be no harm to add more pointers to that appendix from
>>>> elsewhere in the spec, and/or to add a list of the various
>>>> public/private random numbers that are needed to that appendix. (I'd
>>>> be happy to do a pass to identify those if folks basically like this
>>>> kind of addition.)
>>>>
>>>> I also need to figure out how to handle the reference properly:-)
>>>> Can do that tomorrow.
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>> [1] https://github.com/tlswg/tls13-spec/pull/1068
>>>>
>>>>
>>>> _______________________________________________
>>>> TLS mailing list
>>>> [e-mail]<mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>>
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>

_______________________________________________
TLS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls



--
Colm