Subject: [karp] Review of the threats and requirements document

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Aug 2010 10:17:11 -0400

Hi.

1) Terminology.  I found the terminology section had some minor errors
that never the less are likely to be fairly grating for some of us in
the security community.  I think I may have reported these against the
design guide as well as I believe a lot of text is shared for
terminology.  I don't consider this a major comment--I want to write it
down but it is not my main focus for review nor spending time fixing. We
should work through this eventually before publication.

* PRF: A PRF is not the same thing as a PRNG. I'm not convinced sha-256
  is a PRF; hmac-sha-256 is a PRF under some assumptions but I'd either
  not give an example or give an example like an ideal block cipher
  that's more clearly a PRF.

* I don't understand this concept of a peer key, or the text surrounding
  proof-of-identity.

Section 2.1:

Looks good.

Section 2.2:
I don't understand what all we're ruling out of scope by ruling other
DOS threats out of scope.
One example given is ruling out protection of routing messages when a
link is full. However past discussions have suggested than we need to
carefully design our cryptographic protocols so they can work with the
prioritization mechanisms that routing protocols employ. As best I can
tell we're doing this in order to address DOS threats.
So, I'd like to understand better what we're trying to rule out of scope
here as I suspect it's over-broad.

Section 3:

1. I agree clear definitions of what is protected are important. However
I think it is also important that we protect the right thing. As Dacheng
and I demonstrated in our OSPF analysis draft, significant problems can
result from not protecting the right parts of an exchange.

I do not understand requirement 4 (simple use of PSKs) and would not
know how to evaluate it.

If we're going to talk about inter and intra-connection attacks we need
to define what a connection means.
It's obvious for BGP and other TCP-based RPs. It is less obvious for
other things.

I'm not sure what you mean by manual keying must be supported. In
particular I'm trying to distinguish manual keying from PSKs.  This is
very tied up in the discussion we had about whether protocol extensions
for nonce exchange etc are acceptable.
I agree there is a backward compatability requirement with what people
are doing today. I also agree there is a requirement for a key
management approach that presents the same configuration interface as
group and per-peer PSKs. If this is what you mean by manual keying must
be supported, let's split it into two requirements and say that
explicitly.  If you mean more, let's discuss what you mean.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Aug 2010 07:26:02 -0700

Note: a bunch of this material duplicates my review from like 4 months ago.
Not your fault. In response to one technical point.

On Mon, Aug 23, 2010 at 7:17 AM, Sam Hartman <[email-masked]> wrote:

>  is a PRF;

SHA-256 most certainly is not a PRF. PRFs are keyed.

> hmac-sha-256 is a PRF under some assumptions but I'd either

HMAC is actually the standard example in the cryptographic community.

Block ciphers aren't good PRFs because they leak the length of the input
string. You might argue that a block cipher in e.g., CMAC mode is a PRF,
I suppose.

-Ekr