Subject: [karp] Propose dropping requirement 19

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Dec 2010 13:52:29 -0500

Hi.
I was reading over the requirements document again and noticed something
I missed on the last read-through:

Requirement 19 
   19.  Routing protocols MUST only send minimal information regarding
           the authentication mechanisms and the parameters in its
   protocol
           packets to avoid exposing the information to parties on the
                   path.

I don't think that requirement is appropriate.  There are obvious
reasons in terms of performance and bandwidth not to send too much
information in a packet.  However there's no security reason to hide
anything besides the key.  Even if you are thinking that you want an
attacker to have to try multiple algorithms to break your security,
that's only one or two bits of additional security in practice.  Whether
those one or two bits of security are worth increased debugging
complexity or difficulty with algorithm agility should be left up to
the individual design teams.  In practice, I think we'll end up meeting
requirement 19.  However, the rationale will have nothing to do with
security and will be based on operational and performance
justifications. So, since the requirement gives bad security advice and
since the tradeoffs are best handled in the individual design teams, I'd
like to see it dropped.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 2 Dec 2010 05:07:51 +0530

Sounds reasonable. Will remove 19 if there are no strong objections to this.

Cheers, Manav

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sam Hartman
> Sent: Thursday, December 02, 2010 12.22 AM
> To: [email-masked]
> Subject: [karp] Propose dropping requirement 19
> 
> 
> Hi.
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 01 Dec 2010 18:46:55 -0500

While as a I participant, I agree that 19 is probably counter-productive,
I would hope to hear from some additional participants before we remove 
it from a WG document.

Hint: everyone else, if you have even a weak opinion, please speak up.

Thank you,
Joel

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 2 Dec 2010 05:23:09 +0530

I agree and I could like to hear from the security guys about this. I had added this point to eliminate a possibility of an attack where the attacker can infer something by sniffing the packets. As long as we are not sending any information that aids an attacker in doing this we should be fine.

Cheers, Manav

> From: Joel M. Halpern [mailto:[email-masked]] 
> Sent: Thursday, December 02, 2010 5.17 AM
> To: Bhatia, Manav (Manav)
> Cc: [email-masked]
> Subject: Re: [karp] Propose dropping requirement 19
>

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 1 Dec 2010 15:55:07 -0800

Hi,

I think "Security by Obsecurity" provides a level of security.

Thanks,
Vishwas

On Wed, Dec 1, 2010 at 3:46 PM, Joel M. Halpern <[email-masked]> wrote:
> I would hope to hear from some additional participants before we remove it
> from a WG document.
>

---

From: Richard Graveman <[email-masked]>
Date: Wed, 1 Dec 2010 19:26:55 -0500

> I think "Security by Obsecurity" provides a level of security.

Can you give me an example where one has _good_ cryptographic security
and hiding details about the system provides a useful enhancement?

I think SbO provides a level of security when one does not have good
cryptographic security, so SbO is sometimes used as an excuse not to
have good cryptographic security.

Once one has adequate cryptographic protection, then the important
things are not hiding the system being used but rather:

1. Having a sound way to enforce policy and prevent end runs around
the cryptography

2. Worrying about all the weaknesses in the implementation of the
crypto: random numbers, leakage, error handling, personnel security,
key management life cycle, system penetrations, etc.

These are the more important things to worry about after the
cryptographic protection is chosen.

So drop 19, and concentrate on other things. There are enough of them.

Rich Graveman

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 1 Dec 2010 16:30:05 -0800

Richard,

If A spoke in a language that only person A and B know it will take a
lot longer for C and D to figure what is being spoken. They would have
to spend more resources for the same.

Thanks,
Vishwas

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 2 Dec 2010 11:28:35 +0700

+1

Hope this helps.

 ~gwz

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sam Hartman
> Sent: Thursday, December 02, 2010 1:52 AM
> To: [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Dec 2010 08:49:43 -0500

>>>>> "Vishwas" == Vishwas Manral <[email-masked]> writes:

    Vishwas> Richard, If A spoke in a language that only person A and B
    Vishwas> know it will take a lot longer for C and D to figure what
    Vishwas> is being spoken. They would have to spend more resources
    Vishwas> for the same.

I addressed this in my original message.  This sort of
security-by-obscurity may get you 1-3 bits of additional security.
We're hoping that you have between 80 and 512 bits of security depending
on what algorithms you're talking about and on what attacks you're
talking about.  If you're concerned that 80 bits of security isn't good
enough, upgrading to SHA-256 is a much better solution than hoping that
the fact that the attacker doesn't realize you're using SHA-1 may give
you 82 bits.

Also, the obscurity may cost you debugging and operational simplicity.
I think that deciding whether actually having our technology easy to use
is worth a couple bits of security is something we should leave to the
design teams.

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Dec 2010 19:38:48 -0800

Hi, all,

On 12/1/2010 10:52 AM, Sam Hartman wrote:
> anything besides the key.

Let's consider a system that supports multiple authentication 
algorithms, one of which is newly compromised.

Indicating the algorithm in the packet serves no purpose to the 
endpoints, but in this case helps attackers focus their attention on 
streams that have not been upgraded to avoid the vulnerable algorithm.

Overall, good security assumes not sending more information than is 
absolutely necessary at all times, IMO, since you don't know what 
portion of that additional information might be leveraged to compromise 
a system in the future. This isn't security-by-obscurity; it's need-to-know.

Joe

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Dec 2010 13:20:34 -0500

>>>>> "Joe" == Joe Touch <[email-masked]> writes:

    Joe> Let's consider a system that supports multiple authentication
    Joe> algorithms, one of which is newly compromised.

    Joe> Indicating the algorithm in the packet serves no purpose to the
    Joe> endpoints, 

That's false.
It is likely to help with algorithm negotiation and detecting
misconfigurations to simplify operational issues.
Both of these seem like valid purposes to the endpoint.

    Joe> but in this case helps attackers focus their
    Joe> attention on streams that have not been upgraded to avoid the
    Joe> vulnerable algorithm.

In the situation you've described, it gives the attacker at most one bit of help from a security attack
standpoint.

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Dec 2010 10:28:00 -0800

Hi, Sam,

On 12/2/2010 10:20 AM, Sam Hartman wrote:
>>>>>> "Joe" == Joe Touch<[email-masked]>  writes:
>
> It is likely to help with algorithm negotiation

I've heard that before, but algorithm negotiation is not the same as 
putting the value in a packet that is not negotiating

 > and detecting

I've heard that before as well, but that argues for passing the key in 
the clear as well. Anything that simplifies the life of a debugger 
simplifies the life of an attacker, AFAICT.

> In the situation you've described, it gives the attacker at most one bit of help from a security attack

It's more than one bit; if there are 256 algorithms, you've provided 8 
bits - and reduced their attack effort by that corresponding amount.

I'm not arguing that these values should never appear on the wire, but 
they should be, IMO, coordinated and exchanged like the key. IMO, 
they're basically just extensions of the key - they're relevant only in 
the context of the key, and they require exactly the same coordination.

Overall, then, IMO they should be protected just like the key.

Joe

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Dec 2010 13:41:41 -0500

>>>>> "Joe" == Joe Touch <[email-masked]> writes:
I've sent enough messages on this topic; this will be my last.
    >> In the situation you've described, it gives the attacker at most
    >> one bit of help from a security attack standpoint.

    Joe> It's more than one bit; if there are 256 algorithms, you've
    Joe> provided 8 bits - and reduced their attack effort by that
    Joe> corresponding amount.

I've never been aware of a situation where there were 256 algorithms
likely to be in use.  Knowledge of the protocol has always narrowed
things down to under 8 algorithms likely to be in use.  However, you
gave a constructed example; in your example the attacker only cares
about one algorithm. Thus the attacker needs to distinguish "that
algorithm," from "not that algorithm." At most that's one bit. In
practice it will be a lot less than one bit of information because the
attacker probably knows a fair bit about the probability distribution of
algorithms in use.

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Dec 2010 11:09:07 -0800

Hi, Sam,

On 12/2/2010 10:41 AM, Sam Hartman wrote:
> things down to under 8 algorithms likely to be in use.

Agreed; I was being glib, but there are easily more than 1 bit of info 
for some modern examples (e.g., beyond just the algorithm).

 > However, you
> algorithm," from "not that algorithm." At most that's one bit.

If there are 256 algorithms (yes, a constructed example), then I've 
reduced his uncertainty from 256 down to 1. That's 8 bits of info.

Deciding whether he HAS that info is 1 bit - yes, he either has it or 
not. But he gains 8 bits of info by knowing it.

And yes, the probability of each algorithm in use reduces this from 8 
bits to a lower number, but again, that's not part of the issue in this 
example, and there are other pieces of info that could also be useful.

Joe

---

From: Stephen Kent <[email-masked]>
Date: Thu, 2 Dec 2010 10:51:47 -0500

>I would hope to hear from some additional participants before we 
>remove it from a WG document.
>

I agree with Sam. The requirement is badly worded and makes no sense
from  a secruity perspective.

The "Security by Obsecurity" suggestion is counter to the principles we
have adopted for all major security protocols in the IETF.

Steve