Subject: [karp] karp-design-guide

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 10 Nov 2010 16:25:38 +0530

Folks,

I *think* we have addressed most, if not all, comments that were sent for the design-guide. If you believe some of your comments have not been addressed then it would be most helpful if you could send a mail on the list. We would either address them or give you a reason of why those were not included in the first place. 

Yes, I know we should have done this earlier, but I was extremely busy with some work when I was working on updating this, and didn't really get a time to send a mail on why some comments were not included. I believe the few that were left out had appeared to me as personal opinions without any substantitive basis or a good working group consensus behind them -- but I could be wrong and I don't mind being corrected!

At this point, the design-guide looks in a good shape and I would request everyone to have a good look at it and let us know if there is anything further that they think needs to be fixed.

Manav and Gregory

--
Manav Bhatia,
IP Division, Alcatel-Lucent,
Bangalore - India

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Nov 2010 09:24:36 -0500

here are a few comments from Eric's review that I don't think you
addressed.
In one case, while I don't think you addressed the comment, I think the
text is correct as it stands.

3.1.
     The use of asymmetric keys can be a very powerful way to authenticate
     machine peers as are found in routing protocol peer exchanges. If
     generated on the machine, and never moved off the machine, these keys
     will be very secret, and will not be subject to change if an
     administrator leaves the organization. Since the keys are totally
     random, and very long, they are far less susceptible to off-line
     dictionary and guessing attacks.

If never moved off the machine is difficult to ensure w/o an HSM. You
oneed to explain this.

[Sam] If we think this discussion is better in the ops model I'd be
     happy to stick it there.

     Another reason for limiting the lifetime of a key is to minimize the
     damage from a compromised key. It is unlikely a user will discover an
     attacker has compromised his or her key if the attacker remains
     "passive." Relatively frequent key changes will limit any potential
     damage from compromised keys.

Given that we're talking about keys which are used for integrity, this
guidance doesn't really make sense.

[sam] The text was changed to add a bunch of words to weaken the
statement. I don't think that makes anything better: if Eric is right,
then the advice still doesn't make sense even if it is weaker. However,
I'm not sure I believe Eric is right. Attackers will keep the fact that
they have compromised a key to themselves if they are able until the
value of exposing the compromise exceeds the value of the key. For
integrity keys, the attacker does not gain value from simply observing
packets. However, the attacker might well hide a compromise until a
particularly valuable moment to use a key. So, changing a key does seem
to have value because it decreases the set of opportunities the attacker
will have to use the key before it is changed.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Nov 2010 09:27:16 -0500

Hi.  I'd like to write in support of the operational advice that sites
should change keys when the set of people who have access to those keys
leave/move around in an organization.

I also think periodic key changes may make sense in cases where there
may be errors in the above procedures.  For example if you tend to have
rotations of people within a 3 month basis, changing keys around this
frequency even if there is not an explicit change in authorized
operators may be desirable.

I believe the design guide is consistent with this advice.  I'm writing
in support of this because I think it is somewhat of a change from 00.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 11 Nov 2010 02:39:54 +0530

> [Sam] If we think this discussion is better in the ops model I'd be

Will get back to you on this.

> then the advice still doesn't make sense even if it is 

If you notice, the current text does not assert this - its says that its an "often cited reason" which I believe is true.

> I'm not sure I believe Eric is right. Attackers will keep the 

I personally don't and *all* the people that I have spoken to don't believe it either.

> fact that

I completely agree with this.

Cheers, Manav

---

From: Gregory Lebovitz <[email-masked]>
Date: Wed, 10 Nov 2010 15:50:03 -0800

Thanks for the comments, Sam. Inline below...

On Wed, Nov 10, 2010 at 6:24 AM, Sam Hartman <[email-masked]> wrote:
--SNIP--

> If never moved off the machine is difficult to ensure w/o an HSM. You

GML> Ack. We did miss that one. Good catch. Will add statement in -02 as to
the utility of a Hardware Security Module (HSM) for keeping locally
generated key pairs secret.

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Nov 2010 17:03:00 -0800

On Wed, Nov 10, 2010 at 1:09 PM, Bhatia, Manav (Manav) <
[email-masked]> wrote:
> If you notice, the current text does not assert this - its says that its an
> "often cited reason" which I believe is true.

Look, either this reason is right or it's wrong. If it's right, then great.
If not, then the fact that people
believe it is not a reason to actually say it, except to debunk it.

> I personally don't and *all* the people that I have spoken to don't believe

You realize this isn't an actual argument right?

> I completely agree with this.

Except that changing the keys itself introduces risk because you're futzing
with them
and it's a great time to have them leak so this analysis is highly
incomplete.

Look, the situation here is simple: there is no real empirical or even
strong theoretical
evidence to support any particular rate of key changes. I appreciate that
there is
a bunch of lore, but it's just that, lore. If you have actual evidence (you
know, like
citations to peer reviewed papers, etc.) that supports this position, then
great.
Otherwise, it's just unsubstantiated handwaving, no matter how many people
happen to believe it.

-Ekr

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 11 Nov 2010 07:09:59 +0530

Traditionally the onus is on the person who refutes a claim to provide evidence, citations to peer reviewed papers, etc to support a claim. I dont think you have done any of that. Why dont you first do that, rather than saying that the "guidance doesn't really make sense" or its a "bunch of lore".

We have, despite most people agreeing with us, diluted the statement because you insisted on it. If you want us to do anything else, then please explain us why there cannot ever be any damage with a compromised key when its being used for integrity. If you are able to convince us, i am sure all of us will be happy to remove that text.

Cheers, Manav

________________________________
From: Eric Rescorla [mailto:[email-masked]]
Sent: Thursday, November 11, 2010 6.33 AM
To: Bhatia, Manav (Manav)
Cc: Sam Hartman; [email-masked]
Subject: Re: [karp] karp-design-guide

Look, either this reason is right or it's wrong. If it's right, then great. If not, then the fact that people
believe it is not a reason to actually say it, except to debunk it.

Except that changing the keys itself introduces risk because you're futzing with them
and it's a great time to have them leak so this analysis is highly incomplete.

Look, the situation here is simple: there is no real empirical or even strong theoretical
evidence to support any particular rate of key changes. I appreciate that there is
a bunch of lore, but it's just that, lore. If you have actual evidence (you know, like
citations to peer reviewed papers, etc.) that supports this position, then great.
Otherwise, it's just unsubstantiated handwaving, no matter how many people
happen to believe it.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Nov 2010 18:02:02 -0800

On Wed, Nov 10, 2010 at 5:39 PM, Bhatia, Manav (Manav) <
[email-masked]> wrote:

>  Traditionally the onus is on the person who refutes a claim to provide
> evidence, citations to peer reviewed papers, etc to support a claim.
>

What the heck are you talking about? You have a statement in the draft. I
object to that statement. If you want to play the
burden of proof game, then you have the burden, not I.

> We have, despite most people agreeing with us, diluted the statement
because you insisted on it.

I'm sorry, did you present some evidence that "most people agreed with us"
other than blatant
assertion? If so, I must have missed it.

Regardless, if the chairs want to take a straw poll on this point I'll be
happy to abide by it.

If you want us to do anything else, then please explain us why there cannot
> ever be any damage with a compromised key when its being used for integrity.
>
>

I never said any such thing.

To recap, the offending text is:

      An often cited reason for limiting the lifetime of a key is to
      minimize the damage from a compromised key. It could be argued
      that it is likely a user will not discover an attacker has
      compromised his or her key if the attacker remains "passive"
      and thus relatively frequent key changes will limit any
      potential damage from compromised keys.

Now, I agree that this is factually true. I.e. people say this. However,
people
also say this is wrong, and having this in the document tacitly endorses it.
If you insert "However, there is no actual data or detailed cost/benefit
analysis in support of this assertion." I will be quite satisfied.

> If you are able to convince us, i am sure all of us will be happy to remove
> that text.
>

Huh? You're editor of the document, which means that your job is to document
WG consensus. Since I've been complaining
about this point ever since this was an individual submission and there's
not once been a hum on it, there's no consensus.
Whether you're "happy to remove it" really doesn't enter the equation.

-Ekr

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 11 Nov 2010 07:45:41 +0530

Eric,

If you want us to do anything else, then please explain us why there cannot ever be any damage with a compromised key when its being used for integrity.

<Manav>  Mea Culpa. I thought thats what your comment was.

Now, I agree that this is factually true. I.e. people say this. However, people
also say this is wrong, and having this in the document tacitly endorses it.

<Manav> And i am trying to understand which part of the above is wrong here. Is it (a) that the user will not discover an attacker if the attacker remains "passive" OR (b) there cannot be any potential damage from the compromised keys.

I thought it was the latter based on your original comment on the list. However, from this response of yours it turns out that i was incorrect (surprise! surprise!). Now, i am curious, as to which part of the above 6 lines, are you most uncomfortable with, and preferably, with a reason why. It patently cant be the first 2, since we are explaining the rationale behind the first 2, in the next 4. So the issue has to be in the next 4 - which means its either of (a) or the (b) above. You dont agree with (b) above so it has to be (a). Is this correct?

Cheers, Manav

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Nov 2010 00:07:36 -0500

I agree with several of Eric's observations re the text.

Here are some observations on the text in Section 3:

       The use of asymmetric keys can be a very powerful way to
       authenticate machine peers as are found in routing protocol
       peer exchanges. If generated on the machine, and never moved
       off the machine, these keys will be very secret, and will not
       be subject to change if an administrator leaves the
       organization. Since the keys are totally random, and very long,
       they are far less susceptible to off-line dictionary and
       guessing attacks.

"very secret" is not a meaningful term. "totally random" sounds like 
Valley Girl crypto. "very long" is not meaningful, in this context, 
because you have yet to say how long these keys would be.

       An easy and simple way to use asymmetric keys is to start by
       having the router generate a public/private key pair. At the
       time of this writing, the recommended key size for algorithms
       based on integer factorization cryptography like RSA is 1024
       bits and 2048 for extremely valuable keys like the root key
       pair used by a certifying authority. It is believed that a
       1024-bit RSA key is equivalent in strength to 80-bit symmetric
       keys and 2048-bit RSA keys to 112-bit symmetric keys. Elliptic
       Curve Cryptography [RFC4492] (ECC) appears to be secure with
       shorter keys than those needed by other asymmetric key
       algorithms. NIST guidelines state that ECC keys should be twice
       the length of equivalent strength symmetric key algorithms.
       Thus, a 224-bit ECC key would roughly have the same strength as
       a 112-bit symmetric key.

"certifying authority" -> "certification authority"

Not all CA keys are "root keys" but few CAs would use less than a 2048-bit
RSA key.

You referred to symmetric key lengths several times, but provide no 
rationale for this comparison basis. So, for example, IF one expected 
to use symmetric keys for session integrity/authentication, THEN it 
would make sense to align the public key sizes with the symmetric key 
sizes,  but I don't see words to that effect here.

The discussion of "identity proof" is confusing.

       Regardless which form we eventually standardize, the proof of
       this identity presentation can be as simple as the SHA-1
       fingerprint, which is represented in a very human readable and
       transferable form of 20 pairs of ASCII characters. More
       complexly, but also more securely, the identity proof could be
       verified through the use of a PKI system's revocation checking
       mechanism, (e.g. Certificate Revocation List (CRL) or OCSP
       responder). ...

CRLs and OCSP are, as you noted, cert revocation status mechanisms 
and, as such, are not really comparable to a SHA-1 key or cert 
fingerprint.

       Cryptographic keys should have a limited lifetime and must
       change when an operator who had access to them leaves. Using
       the key chains also does not help as one still has to change
       all the keys in the keychain when an operator having access to
       all those keys leaves the company. Additionally, key chains
       will not help if the routing transport subsystem does not
       support rolling over to the new keys without bouncing the
       adjacencies. So the first step is to fix all routing protocols
       so that they can change keys without breaking or bouncing the
       adjacencies.

The term "limited" probably conveys the wrong impression. I presume 
that you mean to say "delineated."

Passive attackers, by definition, do not modify messages. If the focus of
the crypto used here is integrity and authenticity, then there is no
apparent damage that a passive attacker can inflict by having access to a key.
Thus the paragraph above is misleading, and should be struck.

I have not read all of this document but, based on a quick review of 
just these sections, I am concerned about document quality overall.

Steve

---

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Nov 2010 01:46:18 -0500

I think what Eric is saying is that

1) Changing keys can prevent damage
2) Changing keys can cause damage
3) We don't know the value of 2 is less than 1

4) Thus we should not recommend changing keys.

I agree with statements 1-3 but not 4.
I understand this sounds strange.
However I don't care much; the chairs should make a consensus call at
some point.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 12 Nov 2010 08:48:59 +0530

> 3) We don't know the value of 2 is less than 1

Yes, that's my understanding too. I confess I hadn't realized the possibility of 2 earlier - I stand corrected and have updated the text in the draft to reflect that.

> I agree with statements 1-3 but not 4.

And this is exactly my point too.

> However I don't care much; the chairs should make a consensus call at

Sounds reasonable.

Cheers, Manav