Re: [secdir] Secdir review of draft-ietf-rtgwg-yang-key-chain-17

[Vincent Roca <[e-mail]>]

Hello Acee,

Thanks for the update of your document: https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-18 <https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-18>

I missed it when reading your previous version, but using MD5 and HMAC SHA 1 in the examples
of appendix A is a very bad idea that will trigger negative comments from IESG. Please remove them.
Furthermore you’ll also be in line with your new recommendations of Section 5.

Cheers,

  Vincent


> Le 10 avr. 2017 à 17:14, Acee Lindem (acee) <[e-mail]> a écrit :
> 
> Hi Vincent, 
> 
> From: Vincent Roca <[e-mail] <mailto:[e-mail]>>
> Date: Monday, April 10, 2017 at 11:02 AM
> To: Acee Lindem <[e-mail] <mailto:[e-mail]>>
> Cc: Vincent Roca <[e-mail] <mailto:[e-mail]>>, IESG <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "Brian Weis (bew)" <[e-mail] <mailto:[e-mail]>>
> Subject: Re: Secdir review of draft-ietf-rtgwg-yang-key-chain-17
> 
> Hello Acee,
> 
>> Thanks for your review. 
> 
> You’re welcome.
> 
> 
>> ** Question: when saying:
>> 
>>         "When configured, the key-strings can be encrypted using the AES Key Wrap algorithm"
>> 
>>    you do not provide any recommendation. I understand it is possible, but is there any good
>>    reason to recommend it or do you believe the NETCONF access control feature is sufficient?
>>    Are there environments where recommending it would be meaningful? I'd like to have more
>>    information.
>>    This is a bit surprising when I compare with last paragraph where keys are RECOMMENDED
>>    to be encrypted when stored within network devices.
>> 
>> This was added after a conversation with Brian Weis who I believe is also on the directorate. At this time, we didn’t avail NCAM. As one would surmise, it was for additional security for the key strings themselves. I’m not opposed to removing the feature completely since no one has implemented it and it is somewhat unwieldy to have to distribute the key-encryption password out-of-band. 
> 
> I don’t have any opinion on the topic, just asked the question.
> Let’s see what our ADs think.
> 
> Note that I meant NCACM (RFC 6536). Yes, lets see the opinions here. I believe that RFC 6536 will be substantially more widely implemented and deployed than RFC 5649. 
> 
> 
>> ** Minor comment: I don't see any good reason to separate paragraphs 2 and 4.
>> 
>> Where? 
> 
> I forgot to mention, sorry. I was considering the « Security Considerations » section.
> Re-ordering those two closely related paragraphs could make sense.
> 
> Yes – I will combine them. The first two paragraphs are recent boiler plate paragraphs for the “Security Considerations” in all YANG model drafts. 
> 
> 
>> Other comments:
>> 
>> ** section 1.2: it says:
>>         " o  Brackets "[" and "]" enclose list keys."
>>    There may be a confusion with the term "keys" here (i.e., something different from
>>    a cryptographic key).
>> 
>>    For instance, in section 3.3:
>>         |  +--rw key-chain* [name]
>>    name is not a cryptographic key.
>> 
>> This is pretty much boiler plate text for YANG model trees. I guess I could add the statement: 
>> 
>> “These YANG list keys should not be confused with the key-chain keys."
>> 
> 
> Yes, in an I-D entirely devoted to key exchanges, using the key term with a totally
> different meaning is error prone (it took me some time to identify the point).
> 
> 
>> ** section 2.2: there's something I don't understand. It says:
>>     3.  When the send lifetime of the new key becomes valid, the network
>>         devices within the domain of key chain will start sending the new
>>         key.
>> 
>>   I have the feeling you mean that this new key will start to be used for transmissions
>>   (instead of "start sending the new key"). Did I misunderstood something?
>> 
>> Absolutely, I will correct this. 
> 
> That was a big mistake then. 
> It’s nice to see that SecDir reviews are useful.
> 
> Cheers,
> 
>   Vincent
>