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

The following approval message was sent
From: The IESG
To: irtf-chair@irtf.org,
    Internet Research Steering Group ,
    draft-irtf-cfrg-randomness-improvements@ietf.org,
    Colin Perkins ,
    Alexey Melnikov ,
    cfrg-chairs@ietf.org
Cc: iana@iana.org,
    IETF-Announce ,
    The IESG
Subject: Results of IETF-conflict review for draft-irtf-cfrg-randomness-improvements-13

The IESG has completed a review of draft-irtf-cfrg-randomness-improvements-13
consistent with RFC5742.

The IESG has no problem with the publication of 'Randomness Improvements for
Security Protocols'  as an
Informational RFC.

The IESG has concluded that this work is related to IETF work done in the TLS
WG, but this relationship does not prevent publishing.

The IESG would also like the IRTF to review the comments in the datatracker
related to this document and determine whether or not they merit
incorporation into the document. Comments may exist in both the ballot and
the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-irtf-cfrg-randomness-improvements/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-randomness-improvements/

The process for such documents is described in RFC 5743

Thank you,

The IESG Secretary

[Ballot comment]
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.