[Hipsec] HIP and Curve25519 - RFC 7748

Robert Moskowitz <rgm@htt-consult.com> Mon, 25 January 2016 20:05 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371981A00CA for <hipsec@ietfa.amsl.com>; Mon, 25 Jan 2016 12:05:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.502
X-Spam-Level:
X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AP1ry1E8kQyF for <hipsec@ietfa.amsl.com>; Mon, 25 Jan 2016 12:05:31 -0800 (PST)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92D51A00A4 for <hipsec@ietf.org>; Mon, 25 Jan 2016 12:05:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D80856218A for <hipsec@ietf.org>; Mon, 25 Jan 2016 15:05:28 -0500 (EST)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oSBeArsepHyK for <hipsec@ietf.org>; Mon, 25 Jan 2016 15:05:22 -0500 (EST)
Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id A026B62183 for <hipsec@ietf.org>; Mon, 25 Jan 2016 15:05:21 -0500 (EST)
To: hipsec@ietf.org
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <56A67FFE.30502@htt-consult.com>
Date: Mon, 25 Jan 2016 15:05:18 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/7vwnRo0UdIDFnR6G5MqcNlPO61w>
Subject: [Hipsec] HIP and Curve25519 - RFC 7748
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2016 20:05:33 -0000

We have an RFC now for Curve25519 and it behooves us to start looking at 
it and what it means to HIP.  I definitely need to look at it for DEX as 
I don't have to wait for Ed25519 which is moving along as well.

I believe an important part that impacts HIP in RFC 7748 is:

    Designers using these curves should be aware that for each public
    key, there are several publicly computable public keys that are
    equivalent to it, i.e., they produce the same shared secrets. Thus
    using a public key as an identifier and knowledge of a shared secret
    as proof of ownership (without including the public keys in the key
    derivation) might lead to subtle vulnerabilities.


Ouch!  That is us, I believe.

So this points to KEYMAT changes.  If you look elsewhere in 7748 you see 
in 6.1:

    Both now share K = X25519(a, X25519(b, 9)) = X25519(b, X25519(a, 9))
    as a shared secret.  Both MAY check, without leaking extra
    information about the value of K, whether K is the all-zero value and
    abort if so (see below).  Alice and Bob can then use a key-derivation
    function that includes K, K_A, and K_B to derive a symmetric key.

So this is a bit different requirement for KEYMAT.  Again, it definitely 
impacts DEX, but also BEX.  I believe.

One item not mentioned that is very important in DEX is ephemeral vs 
static key usage.  What concerns are there with static key usage?

Any comments on working to include this curve work?  Also be on the 
watch for BLAKE2 as the hash to use over SHA256.