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

Michael Richardson <> Tue, 09 April 2013 13:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 092E921F9003 for <>; Tue, 9 Apr 2013 06:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D52zxgYqUurZ for <>; Tue, 9 Apr 2013 06:27:01 -0700 (PDT)
Received: from (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by (Postfix) with ESMTP id B625721F8FD6 for <>; Tue, 9 Apr 2013 06:27:01 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id D91352016F; Tue, 9 Apr 2013 09:36:36 -0400 (EDT)
Received: by (Postfix, from userid 179) id 40B65A9946; Tue, 9 Apr 2013 09:26:42 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id 2A3F3B9396; Tue, 9 Apr 2013 09:26:42 -0400 (EDT)
From: Michael Richardson <>
To: "Scott Fluhrer (sfluhrer)" <>
In-Reply-To: <>
References: <> <> <>
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, 09 Apr 2013 09:26:42 -0400
Message-ID: <>
Cc: IPsecme WG <>
Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Apr 2013 13:27:05 -0000

>>>>> "sfluhrer" == sfluhrer  <Scott> writes:
    >> I read draft-ietf-ipsecme-dh-checks-01.
    >> I am not competent to understand if this addresses a real problem.
    >> I understood that (1 < r < p-1) is a test that many implementors did not
    >> do.    I think that most implementations generated r from a PRNG.

    sfluhrer> This last statement makes me suspect that you
    sfluhrer> misunderstood what we were doing. 

    sfluhrer> The tests we suggest in this draft are not run on either
    sfluhrer> the secret exponent nor the public value we generate.
    sfluhrer> Instead, it's run on the value r we receive from the
    sfluhrer> peer's KE payload.  How the peer selects that value isn't
    sfluhrer> our problem (we certainly hope the peer selects it in a
    sfluhrer> way such that a third party can't guess its secret
    sfluhrer> exponent; we can't actually test for that); our problem is
    sfluhrer> deciding whether to accept it or not. 

Yes, I think that I understood that these tests are for what we receive,
and then I must have read something that talked about generation... sec...

Aha.... so:

   o  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

   o  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

So, in section 2.2 we talk both about what we should do with something
received, and also place a mandate about generating.

Perhaps these things belong in seperate sections.
It seems that from the receiver of g^x's point of view, point two
repeats point one, since the receiver is not in a position to know if
the DH private value was reused.

    >> I have not implemented ECDSA, but the instructions seemed well
    >> formatted, but I don't at this point know what they mean.

    sfluhrer> Actually, we're talking about ECDH here, and not ECDSA.

my typo at 11:30pm.

]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]        |   ruby on rails    [