On 4/26/17 9:34 PM, Kathleen Moriarty wrote:
The final paragraph, I believe is referring to how the key is stored -
either a KEK is used and it's encrypted or it's not and it's advising
obfuscation at a minimum.
That's how I read it too: it's talking about how the key is stored. If
it's encrypted with a real crypto operation, it's going to have a KEK
(which isn't necessarily the same KEK as is used to decrypt the
information received from a remote node, right?); and, if it's
obfuscated, it doesn't even necessarily have a key at all, just some
kind of reversible transformation.
Let's focus on the "obfuscation" case, because I think it's easier to
reason about (and less likely to get conflated with other operations),
and then we can extend that reasoning to the crypto case if we come to
agreement. I'm making certain assumptions here which you may have a
different read on (and, as before, this is your area, so I'd take your
assumptions over my own) -- please correct me where I'm overstating or
misstating things.
In the obfuscation case -- and barring any advanced anti-debugger and
anti-ICE defenses -- reverse-engineering the obfuscation technique would
be a fairly straightforward exercise. So I think we can safely assume
that any such obfuscation performed by popular routers will be
reversible by your average black-hat hacker.
That seems to negate most of the benefit obtained by obfuscation.
At the same time, an administrator observing that the stored value is
not the same as the actual key may make the erroneous assumption that
the on-disk value itself is not particularly high value, and may take
steps that make it more likely to fall into the hands of an attacker
than if the administrator saw the literal key present in the configuration.
That seems to make the obfuscation potentially harmful.
Little benefit with possible harm would, to me, indicate that
obfuscation should not be employed.
Does that help? I'll defer to the authors and AD and get back to the
part of the thread where I'm hoping we can add the KEK back into the
draft.
I hope so too. As a process point: removing this from the document seems
like a material change. If this went through WGLC and IETF LC with the
KEK as part of the data model, I would think its removal would require
WG buy-in, and running through IETF LC again.
/a
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
