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

[Colm MacCárthaigh <[e-mail]>]

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]> 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]
> 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]] On Behalf Of Stephen Farrell
> > Sent: Friday, July 28, 2017 4:47 AM
> > To: Eric Rescorla <[e-mail]>; Blumenthal, Uri - 0553 - MITLL <
> [e-mail]>
> > Cc: [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]> 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]> 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]
> >>> *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]> 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]
> >>>> https://www.ietf.org/mailman/listinfo/tls
> >>>>
> >>>>
> >>> _______________________________________________
> >>> TLS mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/tls
> >>>
> >>>
> >>> _______________________________________________
> >>> TLS mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/tls
> >>>
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> TLS mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tls
> >>
> >
> >
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
Colm