Re: [secdir] SECDIR review of draft-ietf-lisp-crypto-07

Chris Lonvick <lonvick.ietf@gmail.com> Mon, 26 September 2016 01:27 UTC

Return-Path: <lonvick.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A0A12B056; Sun, 25 Sep 2016 18:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 2pVPzaIQ-3Kv; Sun, 25 Sep 2016 18:27:32 -0700 (PDT)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BCA312B05B; Sun, 25 Sep 2016 18:27:32 -0700 (PDT)
Received: by mail-pf0-x22f.google.com with SMTP id l25so11543472pfb.1; Sun, 25 Sep 2016 18:27:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Vy8rgSjS2ezXrBIsT+Pny5wXXOKdsmN+E+sY/S9pI4k=; b=visI3TDy8iVHmoXRllNV9xZZV0aVmebei95YYu9pSGArS4Lj6U9G+9o3qFCn1rj+tJ XP88n/uHD/EmEFrfkh/yH7QzHhG39wcFpvH54z0fb35G74gAwk90SAZFt/E/BFGZrJxa jxcHNP8zEEgL+RU33sbOeHgwadztPZ+NcddICOeDojAfZAyFx9jrwrKyx8lDyrBL5nMk pldnTXe8kfMAASjkPAxD8TL71aXdeEGYrvGVwH5nwX3wKcOiNbXS+MnehQ6U3A6odRJ5 VNuzI0zo3dGOtJ2CPenBSDNYUQsAke1axvBHZtjvfW9ad47178s3YpzKxNGRLfWn0fab qlSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Vy8rgSjS2ezXrBIsT+Pny5wXXOKdsmN+E+sY/S9pI4k=; b=VIRsl4n/lFcIe7I7fsa1dCHYUus6YDH10a5IuoNFytLww7IRPomUmFnYhbk7Z0kNZI Ttx8RDOLiAgbaDfFZK/PUMmAOraCqTVSe8Gbmz3BZqaqYOHREhRL4aBrJu4YM3OUgYRV lJURNLjlVYyhiLMCLOHgW6hy8k1DMNL2Nworl352wCeQ5DZbWqE3dPmsFry7paSJ8B5L A4haKLZA7j/tdKl+js1BnxTpHOeIiXrO62tb08MxL8ox1Tm2n0PudsiIsj2J1Pgg6o/W CBw9Wj9lPb6veOrojxxEnAggStAHee843bNvmlBl3WMdknKn0Qe+Jww5dQgQ1U9NoY11 Vmkw==
X-Gm-Message-State: AE9vXwOGjqjbjzTifKctOoWfduHDdPQIl6y6YO0gS6KKnkGB/WLWXG4POroGMeKRr3GCBA==
X-Received: by 10.98.0.69 with SMTP id 66mr33490663pfa.140.1474853251794; Sun, 25 Sep 2016 18:27:31 -0700 (PDT)
Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:d15c:ae35:aaa4:7fa4]) by smtp.googlemail.com with ESMTPSA id xv9sm26100160pab.36.2016.09.25.18.27.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Sep 2016 18:27:31 -0700 (PDT)
To: Dino Farinacci <farinacci@gmail.com>
References: <57E68FB7.10408@gmail.com> <57E690AD.2030207@gmail.com> <65A320B3-F8AD-461B-8F4B-1EF029E538DD@gmail.com>
From: Chris Lonvick <lonvick.ietf@gmail.com>
Message-ID: <57E87980.2050209@gmail.com>
Date: Sun, 25 Sep 2016 20:27:28 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <65A320B3-F8AD-461B-8F4B-1EF029E538DD@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/5mtFpJSyhMEPUQA1yejMsf-IFK8>
Cc: draft-ietf-lisp-crypto.all@ietf.org, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SECDIR review of draft-ietf-lisp-crypto-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2016 01:27:34 -0000

Hi Dino,

On 9/25/16 4:37 PM, Dino Farinacci wrote:
>>> I don't follow LISP so I'm not sure if there is an actual mechanism for a device receiving a map request packet to decline an offered cipher suite. If there is, I didn't see it explained in the
> Yes, there is. If the Map-Reply this is returned contains no Security LCAF that means to the ITR that it either needs to go unencrypted encapsulating packets to the ETR or try another cipher text.
>
>>> >>draft. You should address this in a future draft. This will be needed for when new cipher suites are
> Understand the need. We intentionally wanted to support this.
>
>>> >>added and a receiving device does not have the capability to handle the new cipher suite, or the case where an old cipher suite has been administratively disabled; like if it's been compromised and shouldn't be used. There are several ways to do this.
> We have this in section x of the draft. Is it not sufficient?
>
>     If an ITR, PITR, or RTR sends a Map-Request with the Security Type
>     LCAF included and the ETR or RTR does not want to have encapsulated
>     traffic encrypted, they will return a Map-Reply with no RLOC records
>     encoded with the Security Type LCAF.  This signals to the ITR, PITR
>     or RTR not to encrypt traffic (it cannot encrypt traffic anyways
>     since no ETR public-key was returned).
>
That text just says that if the cipher suite is declined then there will 
be no encryption. I was interpreting that to mean that the receiver just 
isn't going to accept any attempt at encryption. If it's just meant to 
be for that particular cipher suit then you'll need to add a line to 
that paragraph to say that the ITR, PITR, or RTR can attempt a different 
cipher suite if it is administratively configured to do so. However, 
that could get to be very inefficient if the ITR has to make 6 attempts 
before understanding that the ETR just isn't going to accept any 
encryption request - if it's so configured, or if it just doesn't 
support the feature whatsoever. So even if you allow the sender to make 
offer after offer, it would still be a good idea to have a way for the 
receiver to entirely decline encrypting packets from the sender.

But, with all that being said, I'm figuring that we're getting outside 
the intent of your experimental specification. When you do get around to 
getting this onto a standards track, then you should make some decisions 
around how to convey capabilities between the sender and receiver so 
they can quickly and efficiently figure out what's going to work, or if 
it's just not, rather than making one offer after another. TLS and SSH 
have ways for a sender to offer a list from which the receiver can 
choose, if you're looking for examples. Another way is for the sender to 
proffer a version number which is associated with a select group of 
capabilities. From that, the receiver can make a choice, or efficiently 
decline all.

Best regards,
Chris