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

[Chris Lonvick <[e-mail]>]

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) <[e-mail]> wrote:
>>>
>>> Hi Chris,
>>>
>>> Thanks for the review. I’ve added one comment below.
>>>
>>>> On Sep 25, 2016, at 6:27 PM, Chris Lonvick <[e-mail]> 
>>>> 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: [phone]
>>> Email: [e-mail]
>>>
>