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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 16 April 2013 17:02 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEACB21F9716 for <ipsec@ietfa.amsl.com>; Tue, 16 Apr 2013 10:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRVItcxazgs4 for <ipsec@ietfa.amsl.com>; Tue, 16 Apr 2013 10:02:00 -0700 (PDT)
Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id E925721F9715 for <ipsec@ietf.org>; Tue, 16 Apr 2013 10:01:59 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3EBCF20168 for <ipsec@ietf.org>; Tue, 16 Apr 2013 13:11:55 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 4B99E639D9; Tue, 16 Apr 2013 13:01:31 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 38839638E4 for <ipsec@ietf.org>; Tue, 16 Apr 2013 13:01:31 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: IPsecme WG <ipsec@ietf.org>
In-Reply-To: <6CD9AE1A-1D27-42A6-8F59-EC7A6A4CECA3@vpnc.org>
References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> <5697.1365476466@sandelman.ca> <A113ACFD9DF8B04F96395BDEACB3404209060652@xmb-rcd-x04.cisco.com> <17925.1365514002@sandelman.ca> <810C31990B57ED40B2062BA10D43FBF513E325@XMB111CNC.rim.net> <29765.1365518014@sandelman.ca> <810C31990B57ED40B2062BA10D43FBF513E46D@XMB111CNC.rim.net> <A113ACFD9DF8B04F96395BDEACB3404209060DC2@xmb-rcd-x04.cisco.com> <6CD9AE1A-1D27-42A6-8F59-EC7A6A4CECA3@vpnc.org>
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 16 Apr 2013 13:01:31 -0400
Message-ID: <21830.1366131691@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 17:02:01 -0000

>>>>> "Paul" == Paul Hoffman <paul.hoffman@vpnc.org> 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  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [