On Thu, Apr 27, 2017 at 10:28 AM, Eric Rescorla <[email protected]> wrote: > > > 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.
As I understand it, the KEK is not generated on device, so they are not stored together. The KEK would be out-of-band and how it's accessed will be implementation specific. > > -Ekr > >> >> Acee >> >> >> -Ekr >> >>> >>> >>> Regards, >>> Alia >>> >>> >>>> >>>> /a >>>> >>> >> > -- Best regards, Kathleen _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
