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

Chris Lonvick <lonvick.ietf@gmail.com> Mon, 26 September 2016 17:40 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 B6B1C12B31B; Mon, 26 Sep 2016 10:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 qhkrgGKW5g7w; Mon, 26 Sep 2016 10:40:28 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 D026512B118; Mon, 26 Sep 2016 10:40:27 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id r126so215551715oib.0; Mon, 26 Sep 2016 10:40:27 -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=1HmfuACH9wwa2apw3UBYd/PskyWOlcZnvgBlBhgqsPY=; b=QAtIhbU416p/CsGVVQ48jPEL2uibFy2R1zDGqvHP/3xWVbWASSkIVbWfaMvT2pg4sO iZS2ze0nvDzz1hJ6IOJYWRul6NlYJMD7bmqdha5XO1XN40M+vCZnGVnlo8QSlVpxGwFD 6/caojZaKXZF5mkpnXvROZy3R4hE01tMHqFqWJUxyYABQ5ERzmgxe5Pf4n9CX0B/GEVD OkwNBrUMzu7UBKbWgEvcGdlR+ZxRpuXwWCFZUzPjBfFfqOWTiymH9/MWcXVuHqxI6uRU p7fHm4eNrXz+NvctKgSN0n3QBSfC7vlQ44ss2rZp/mgF7MxQ27LVbOjXdqul7+VOxOVU a+cg==
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=1HmfuACH9wwa2apw3UBYd/PskyWOlcZnvgBlBhgqsPY=; b=aor0XGs3a3PRtAZp+1GlCFIPh9dL6QNa+n+/SNpzMuWeF3l3f3R8x1dq7/b5m30uuC 6FOBphPDpxx68/oN5KXcVNaW7uWsuGiBaqscx/EA+gdYMIzZfij7D8bOb536IPbHXLi/ sMAx8wCQR9JPj8Zdf7Be2IHfaWSackHv29lP4a09msoH6bIJaG1TMC98kKpGccbmb1JU U/NNOeIF5bhj2DoyDpk14JKoAfTNLryZMLJlSORqa5BpFcPiy8Z0tgosU/Rw0+gvVms7 abQtuOfBwfUWGWoaz4tk8SYXy04wUhTbHz+i2P9RmVLhr7k6TdQeY3YeUkAQQ+su3AVz 3Sew==
X-Gm-Message-State: AE9vXwPaLBORwmUQ1oDrKG8aa3c7vNs1X/YPTvYpr7uMLvL/66C5kISaaWvqaORkyUef1w==
X-Received: by 10.202.90.196 with SMTP id o187mr26121592oib.176.1474911625653; Mon, 26 Sep 2016 10:40:25 -0700 (PDT)
Received: from chriss-air.smd.local ([216.201.230.154]) by smtp.googlemail.com with ESMTPSA id z196sm7659339oig.13.2016.09.26.10.40.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Sep 2016 10:40:24 -0700 (PDT)
To: Dino Farinacci <farinacci@gmail.com>, Brian Weis <bew@cisco.com>
References: <57E68FB7.10408@gmail.com> <57E690AD.2030207@gmail.com> <65A320B3-F8AD-461B-8F4B-1EF029E538DD@gmail.com> <57E87980.2050209@gmail.com> <7345DDFF-0D4F-4F47-87D1-56459ED94D2A@cisco.com> <067010BC-5EE7-46AF-B06F-B227BEE9A565@gmail.com>
From: Chris Lonvick <lonvick.ietf@gmail.com>
Message-ID: <57E95D87.4090104@gmail.com>
Date: Mon, 26 Sep 2016 12:40:23 -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: <067010BC-5EE7-46AF-B06F-B227BEE9A565@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/SiVkRzT0IyaL1NRL1CrKfXfvw6Y>
Cc: "draft-ietf-lisp-crypto.all@ietf.org" <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 17:40:30 -0000

Hi Dino and Brian,

Yup - all looks good. I didn't mean to push too much on the point 
because I figured that it wasn't needed or wanted for being an 
experimental document. Good luck with it.

Best regards,
Chris

On 9/26/16 11:47 AM, Dino Farinacci wrote:
> Chris, if you are fine with Brian’s response, I can post the -08. Please ack. Thanks.
>
> Dino
>
>> On Sep 25, 2016, at 8:11 PM, Brian Weis (bew) <bew@cisco.com> wrote:
>>
>> Hi Chris,
>>
>> Thanks for the review. I’ve added one comment below.
>>
>>> On Sep 25, 2016, at 6:27 PM, Chris Lonvick <lonvick.ietf@gmail.com> wrote:
>>>
>>> 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.
>> Thanks for the suggestions. In this effort we were intentionally avoiding the complexities and added security analysis requirements of a multiple round-trip method capabilities negotiation such as TLS. But maybe a capabilities declaration more along the lines of the version number you suggest might be appropriate.  I agree that at such time as the protocol was prepared for standards-track that this would be important to add.
>>
>> Thanks,
>> Brian
>>
>>> Best regards,
>>> Chris
>> -- 
>> Brian Weis
>> Security, CSG, Cisco Systems
>> Telephone: +1 408 526 4796
>> Email: bew@cisco.com
>>