Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks

[Michael Richardson <[e-mail]>]

>>>>> "Paul" == Paul Hoffman <[e-mail]> writes:
    Paul> +1 to "now that you understand it, please show where you were
    Paul> confused before" so that we can close out the document and
    Paul> move it to the IETF. 

sorry, day job got in the way.

rereading section 2.1/2.2 again.

   This leakage can be prevented if the recipient performs a test on the
   peer's public value, however this test is expensive (approximately as
   expensive as what reusing DH private values saves).

does the stuff in () add anything?   And is the word "saves" correct?

   In addition, the
   NIST standard [NIST-800-56A] requires that test (see section
   5.6.2.4), hence anyone needing to conform to that standard will need
   to implement the test anyway.

("that test" refers to the test on the peer's public value?
Visiting NIST-800-56A section 5.6.2.4.. but that section refers to
private/public key pair generation, not MODP groups... but anyway.

my suggested text:

   For a node which wishes to reuse its DH private value, in order
   to avoid this leakage, the following test is to be performed on
   the public value received from the peer before combining it with
   the node's private value.

   While this test is expensive, it is no more expensive than generating
   new DH private values, except that it does not require access to a high
   quality random value.  This test is mandated by the NIST standard
   [NIST-800-56A] (see section 5.6.2.4), and is described here:

   It MUST check both that the peer's public value is in range
   (1 < r < p-1) and that r**q = 1 mod p (where q is the size of the
   subgroup, as listed in the RFC).  
      DH private values MAY then be reused.  
      This option is appropriate if conformance to [NIST-800-56A] is required.

   Alternatively, it MUST NOT reuse DH private values (that is, the DH
   private value 
      for each DH exchange MUST be generated from a fresh output of a
      cryptographically secure random number generator), and it MUST
      check that the peer's public value is in range (1 < r < p-1).
      This option is more appropriate if conformance to [NIST-800-56A]
      is not required.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [