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

Chris Lonvick <lonvick.ietf@gmail.com> Wed, 28 September 2016 01:26 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 B018512B3A7; Tue, 27 Sep 2016 18:26:16 -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 gg9vudPiALbj; Tue, 27 Sep 2016 18:26:14 -0700 (PDT)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 C5C9312B3A1; Tue, 27 Sep 2016 18:26:14 -0700 (PDT)
Received: by mail-pf0-x22d.google.com with SMTP id l25so11415177pfb.1; Tue, 27 Sep 2016 18:26:14 -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=XhUSxczEkA4LX0l2Ab7C0OrE5p2+2CTAayTyytXi+FE=; b=glORpHnltExOXfB5+O1JaOXQ6zczT6r3FInNbTGfZDHXx1tYZAmzhkliCoZSSsizSi cTkZJ/y+x8Ck9IIHBikNhHbH5LJp5In09tGNQCba56DpcbFu45nKgAy7dYgl5EqdDPks C8x0SRffP1cHZxIVjVJ8NSI4kE9Nktdgiv35JmWPUiGRE3qDM8ZGXT3hIpUsz4ay94A7 ZCAJ63oYL8wPc4dfPP1awhn/+3OTxHfUYjOoYqCGHp9Obz9XMcC1jYzl6ZVhkCzrSanR LlwPlcF7A5Yi6jey0At0pp+H7FQ+w8yjdb1eXKcnnThCI29Negj1QL2rFwa3QgvRHiY5 v5nQ==
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=XhUSxczEkA4LX0l2Ab7C0OrE5p2+2CTAayTyytXi+FE=; b=VYHfy4BH/aVoKYvPZRBn122yZLC/ufm/p4gtWT6JSA61dp5cL2+2ReSLWNLNYr3uOW Z0A5tkVYfKToBO+Pr4/vH3VWl4Adto8GuDntfra1h5KUVol1Cz8fOS5rfVlZ6duTXJOW uBi+f6Qi7bvvXN5tWH9/ufYlqIMCNPXb7uNkB6HruX0LxOO/NUVspmhUGfKHmVBSQAx7 ST1EIZyAOvskkb+klL4Df4U/BhxiMU8HFmCiFQFy0rqTCTLEdsEDz11fc6nAFQrVlYFB AyYCItoqK79s318JAoNOXWvPGNJ4vdATbGw6AdmqsxdxkEghn58xjikn9GzPurKHKKDc 2tlg==
X-Gm-Message-State: AE9vXwONgKLdHUrGrhMFwlkhcuaHkwDMG28he6ItxNZVD5tfFir0hkaaglHGha6UxuuTHQ==
X-Received: by 10.98.152.138 with SMTP id d10mr52116094pfk.8.1475025974363; Tue, 27 Sep 2016 18:26:14 -0700 (PDT)
Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:b47b:b432:d33f:ea09]) by smtp.googlemail.com with ESMTPSA id s82sm7577954pfg.42.2016.09.27.18.26.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Sep 2016 18:26:12 -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> <57E95D87.4090104@gmail.com>
From: Chris Lonvick <lonvick.ietf@gmail.com>
Message-ID: <57EB1C33.60000@gmail.com>
Date: Tue, 27 Sep 2016 20:26:11 -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: <57E95D87.4090104@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/6BFnwDFW73Ugyatez0J3U_AEEMU>
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: Wed, 28 Sep 2016 01:26:17 -0000

Resending - Looks like Dino didn't get this.

Best regards,
Chris

On 9/26/16 12:40 PM, Chris Lonvick wrote:
> 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
>>>
>