-----Original Message----- From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
I don't think this is simply a case of multiple CSPRNGs. DB> Not quite sure what you mean by "simply a case of multiple CSPRNGs", but I am starting to get an idea below. 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. DB> Ok, suppose the TLS implementation wishes to just read /dev/urandom, which is presumably a good CSPRNG. Unlike the NIST RBGs, there's no interface to create independent and separate instantiations of /dev/urandom (as far as I know, although newer versions may provide this feature). So, what would count as your "separation scheme"? Are you saying the TLS code should post-process the output of a single CSPRNG? If so, then that's probably a good idea, if done right. At least it doesn't have the downside risk of the TLS coder generating its own seeds, writing its own CSPRNG (instead of using /dev/urandom), etc. (I thought that I was being very specific that launching 2 CSPRNGs was not a good idea, yet it seems I was read as preferring as doing nothing and keeping the status quo, which is not what I intended.) So, I think some kind of clarification of the currently proposed text (for -21 ?) may be worthwhile, because I read it creating two separate CSPRNGs. (Of course, defenc e in depth is good, and often worth the implementation cost, but if it introduces new security problems, then it is not too good. More philosophically, in an ideal world, any additions to the TLS spec should be vetted with pedigree. Trying to create independently seeded CSPRNGs goes against the current best practices as I understand them. By contrast, TLS already has all kinds of key derivation, separation for different purposes (unless that was dropped in 1.3???), which TLS might as well continue to use. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
