On Thu, Apr 27, 2017 at 7:23 AM, Acee Lindem (acee) <[email protected]> wrote:

>
>
> From: Eric Rescorla <[email protected]>
> Date: Thursday, April 27, 2017 at 10:17 AM
> To: Alia Atlas <[email protected]>
> Cc: Adam Roach <[email protected]>, "[email protected]" <
> [email protected]>, "[email protected]" <
> [email protected]>, Kathleen Moriarty <
> [email protected]>, The IESG <[email protected]>, Jeff
> Tantsura <[email protected]>, Routing WG <[email protected]>
> Subject: Re: Kathleen Moriarty's Discuss on 
> draft-ietf-rtgwg-yang-key-chain-20:
> (with DISCUSS and COMMENT)
> Resent-From: <[email protected]>
> Resent-To: Acee Lindem <[email protected]>, Jeffrey Zhang <[email protected]>,
> Derek Yeung <[email protected]>, Yingzhen Qu <[email protected]>,
> Ing-Wher Chen <[email protected]>
> Resent-Date: Thursday, April 27, 2017 at 10:17 AM
>
>
>
> On Thu, Apr 27, 2017 at 7:15 AM, Alia Atlas <[email protected]> wrote:
>
>> On Thu, Apr 27, 2017 at 10:05 AM, Adam Roach <[email protected]> wrote:
>>
>>> On 4/26/17 23:02, Alia Atlas wrote:
>>>
>>>> First, the YANG model is primarily for information in motion - either
>>>> for configuration to the device
>>>> or to read from the device.   It is much less likely to represent the
>>>> data structure and storage in the device.
>>>> I believe that this draft's context is strictly for information in
>>>> motion.
>>>>
>>>
>>>
>>> Thanks; I understand all that. I'm trying to focus on the final
>>> paragraph of section 5, though, which appears to be an exception to what
>>> you say above.
>>
>>
>> I don't understand why - IMHO, that paragraph is simply saying  - this
>> model passes keys around (in motion).  Of course, a system shouldn't store
>> such keys unencrypted.  From what Acee says, this "motherhood and apple
>> pie" additional advice was added due to secdir review.
>>
>
> I thought Adam's point was that storing keys encrypted with a key that's
> adjacent to them was not useful.
>
>
> Right. I’m not sure what the definition of “adjacent” is here since it is
> very implementation specific. I will remove the final paragraph in the next
> revision when I add KEK back (assuming we can agree on reasonable guidance
> and which RFC to reference). What I’m strongly opposed to is pushing this
> back in the process for such a change.
>

I'm not arguing for any particular outcome, merely making a technical
observation about what is and is not useful from a security perspective.

-Ekr


> Acee
>
>
> -Ekr
>
>
>>
>> Regards,
>> Alia
>>
>>
>>
>>> /a
>>>
>>>
>>
>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to