IETF Logo Mail Archive

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

"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Tue, 09 April 2013 04:19 UTC

Return-Path: <sfluhrer@cisco.com>
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 6816321F860A for <ipsec@ietfa.amsl.com>; Mon, 8 Apr 2013 21:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 1zCHuvB4dfTj for <ipsec@ietfa.amsl.com>; Mon, 8 Apr 2013 21:19:21 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9C17721F853A for <ipsec@ietf.org>; Mon, 8 Apr 2013 21:19:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1356; q=dns/txt; s=iport; t=1365481161; x=1366690761; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=YGPzOwZ9tnl9cWqko/SzHEeDpKQwDk8jH+Iqej4LRiU=; b=Pwhd4iToiJK27GJVaiMFZJIQPJHIkX0PLxLV3bqYeENKDyvD6s8aTsnd J4ufOrwoyPu1PI4TJ03ZViHhy/WLfuZDKam+jOiidOWDa3jI3G0H85F8D 2jldU4zYlw/JE3U6r+o1JpwmiW2XWK54huDOh9XM5i/gDzADO7BwsiCYr w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisFAP2VY1GtJV2Z/2dsb2JhbABRgwbBcYEQFnSCHwEBAQMBHR1LBAIBCBEEAQELFAkHMhQJCAIEARIIiAYGrWGQLI5yJhIGglphA6gCgn4Ngig
X-IronPort-AV: E=Sophos;i="4.87,436,1363132800"; d="scan'208";a="196487979"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 09 Apr 2013 04:19:21 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r394JLDI015309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Apr 2013 04:19:21 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.60]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 23:19:20 -0500
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, IPsecme WG <ipsec@ietf.org>
Thread-Topic: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks
Thread-Index: AQHONKKDikpZdmEiWUOFvhKCnr1P7JjNh4EA//+sFAA=
Date: Tue, 09 Apr 2013 04:19:20 +0000
Message-ID: <A113ACFD9DF8B04F96395BDEACB3404209060652@xmb-rcd-x04.cisco.com>
References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> <5697.1365476466@sandelman.ca>
In-Reply-To: <5697.1365476466@sandelman.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.32.244.83]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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, 09 Apr 2013 04:19:22 -0000

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of Michael Richardson
> Sent: Monday, April 08, 2013 11:01 PM
> To: IPsecme WG
> Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks
> 
> 
> 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.

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

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

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

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

> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>

v2.23.0 | Report a Bug | By Email