IETF conflict review for draft-irtf-cfrg-randomness-improvements
conflict-review-irtf-cfrg-randomness-improvements-00

Section 1

   of the same length.  CSPRNGs are critical building blocks for TLS and
   related transport security protocols.  TLS in particular uses CSPRNGs
   to generate several values: session IDs, ephemeral key shares, and
   ClientHello and ServerHello random values.  [...]

Session IDs seem to be a (legacy) TLS 1.2 construct at this point,
right?  But neither RFC 5246 nor 5077 specifically says the ID has to be
or involve a CSPRNG output, which makes me wonder if I'm misinterpreting
this statement.

   3.  If the CSPRNG is broken or controlled by Adv, the output of the
       proposed construction remains indistinguishable from random
       provided the private key remains unknown to Adv.

When I first read this, I wondered about an attacker that controlled the
CSPRNG and also had access to an oracle that could perform signatures
using the private key (but not the private key itself).  It seems
(intuitively, thus not reliably) that keeping the tag1 value
confidential would stymie such an attacker, though if the tag1 is just
device-specific information and the attacker has access to the HSM then
keeping tag1 confidential may not be possible.  On the other hand, the
draft discusses a scenario with a single HSM shared across multiple
machines, so perhaps just having access to the HSM is not as strong of
an ability as intuition suggests.  On the gripping hand, if tag1 was
confidential and that was enough protection, then even an attacker that
knew the private key (but not tag1) would still not be able to break the
construction ... so I conclude that I'm still confused about this case.