Subject: Last Call Comments on draft-ietf-shim6-hba-04

From: Eric Rescorla <[email-masked]>
Date: Sat, 24 Nov 2007 14:03:32 -0800

$Id: draft-ietf-shim6-hba-04-rev.txt,v 1.1 2007/11/24 21:57:16 ekr Exp $

The basic goal of this draft is to securely bind together multiple
IPv6 addresses that belong to the same multihomed host. This allows
rerouting of traffic without worrying that you're being redirected
to an attacker. The technique that's used is to use a hash of the
permitted prefixes in the low order bits of the v6 address. 

For me, the big unanswered question is why this is a good general
approach. Far preferable, IMO, would be to simply to cryptographically
sign the prefix list using some key bound to the association.
Section 8.1 describes exactly such a mechanism using CGA. This
mechanism has the following advantages:

(1) A more standard style mechanism.
(2) Not tied to SHA-1.
(3) Superior attacker/defender dynamics by increasing the
    key size (note that this doesn't help with CGA, but it
    would with other approaches). By contrast, this
    scheme has an attacker/defender work factor spread of 2^59.
(4) Can add new prefixes in real-time.

As far as I can tell, the only real rationale for this scheme
as opposed to one like I describe above is performance. S 3.3 
reads:

   Fourth, performance considerations as described in [17] motivated the
   usage of a hash based approach as oposed to a public key based
   approach based on pure Cryptographic Generated Addresses (CGA), in
   order to avoid imposing the performance of public key operations for
   every communication in multihomed environments.  The HBA appraoch
   presented in this document presents a cheaper alternative that is
   attractive to many common usage cases.  Note that the HBA approach
   and the CGA approaches are not mutually exclusive and that it is
   possible to generate addresses that are both CGA and HBA providing
   the benefits of both approaches if needed.

This is extremely unconvincing. You don't need to impose the
performance of public key operations for "every communication."
Rather, one pair of public key operations is required for each
notification of the prefix set. Unless you are experiencing a truly
amazing amount of address churn, this will be fairly rare, and the
receiving node can simply cache the current prefix list. If that's not
possible for some reason, it's a deficiency in the existing protocols
and is easily fixed.  Is there any evidence at all that this is too
expensive in real systems?

Given the flexibility advantages of signature-key based approaches,
the fact that these mechanisms appear to already exist, the advantages
of having only one security mechansim, and the dubious value of the
performance advantages of this mechanism, IMO the IETF would be better
served by not advancing this document at this time. It can always be
resurrected if clear evidence emerges that signature-based approaches
represent a real bottleneck.

DETAILED COMMENTS (unfixed from my review of -01)
S 6.
I wouldn't say "leftmost" or "rightmost". MSB and LSB are superior
terms for SHA-1.

Why are three collisions a boundary here in step 6.4. Have you
analyzed the chance of this happening? Why not just continue 
until you're out of collision bits.

-Ekr

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 24 Nov 2007 23:23:58 +0100

I reviewed the document as well.

I got the impression that CGAs are not really going to see larger 
deployment anytime soon.
HBA seems to be a simple and lightweight alternative (although I am not 
convinced about SHIM6 in general).

This document is fine for me.

Ciao
Hannes

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 24 Nov 2007 14:35:16 -0800

At Sat, 24 Nov 2007 23:23:58 +0100,
> I got the impression that CGAs are not really going to see larger 

Well, that may be true, but if that's the rationale for this work
it has a number of implications:

1. It casts severe doubt on any proposed future work on CGAs--such
   as the CSI BoF being held in YVR.

2. There needs to be some plausible rationale for why HBA won't
   suffer the same nondeployment fate as CGA, not just that
   HBA has a cooler sounding acronym.

That said, there are a number of ways to do signature-based
binding other than CGA, so I'm not convinced that !CGA -> HBA.

> convinced about SHIM6 in general).

In what way is HBA any more lightweight than CGA?

-Ekr

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 25 Nov 2007 10:35:20 +0100

Hi Ekr,

>    as the CSI BoF being held in YVR.
I see it differently. The proposed BOF tries to incorporate the fact 
that most networks use DHCP for address configuration.
Reflecting deployment facts seems to be reasonable to me.

>    HBA has a cooler sounding acronym.
Well. A lot of the mobility work is an investment into the future. 
Almost everything done in the area of mobility has been done many, many 
years before there was concrete interesting in deploying it.

> binding other than CGA, so I'm not convinced that !CGA -> HBA.
Maybe.
Getting these protocols deployed is obviously quite difficult. 
Nevertheless, I believe that HBA is more likely to see deployment than a 
CGA based approach.

> In what way is HBA any more lightweight than CGA?
Computational overhead.

There are a couple of schemes that use a lot of crypto but couldn't find 
a lot of excitement outside the academic world.
Many of the real-world attacks happen at higher layers where you have 
more semantic. There, you have other ways to deal with the attacks.

Ciao
Hannes

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 Nov 2007 07:38:02 -0800

At Sun, 25 Nov 2007 10:35:20 +0100,
> Reflecting deployment facts seems to be reasonable to me.

I'm really confused by this argument. Either CGA has a future or
it doesn't. If it does, then the arguments for HBA become
incredibly weak. If it doesn't, then there's no point in
doing work on new ways to issue CGAs.

> years before there was concrete interesting in deploying it.

Yes, I understand that, but again, your argument precedes from the
premise that people won't want to deploy CGA. Given that substantial
effort was invested in that, I think it's reasonable to take
a step back and ask why some new approach will be more attractive,
not just assume that it will be because it points in some different
direction.

> > In what way is HBA any more lightweight than CGA?

I already addressed this point in my review. The signatures
are performed so rarely that I don't see any evidence that
this is a significant bottleneck. If you have some model
that shows otherwise, I'd be happy to hear it.

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Nov 2007 09:48:39 +1300

On 2007-11-26 04:38, Eric Rescorla wrote:
...
> not just assume that it will be because it points in some different

I think the scenarios are very different. To pay the costs of deploying
CGAs, you have to be worried about threats from interlopers on your
own infrastructure, as I understand things. HBAs deal with threats from
interlopers anywhere between the two ends of the shim6 session.
They're much easier to deploy since they use a nonce instead of
a key pair.

I don't think this is really a case of solving the same problem twice.

    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 Nov 2007 13:11:15 -0800

At Mon, 26 Nov 2007 09:48:39 +1300,
> They're much easier to deploy since they use a nonce instead of

Hmm... I'm fairly familiar with crypto protocols and I don't see why
this makes them any easier to deploy. CAn you please explain?

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Nov 2007 10:33:17 +1300

> this makes them any easier to deploy. CAn you please explain?

Well, if I understand HBA correctly, the nonce is automatically
generated. I must confess I haven't studied CGA closely, but I
presume that some affirmative action is needed to generate the keys.

     Brian

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 Nov 2007 13:41:03 -0800

At Mon, 26 Nov 2007 10:33:17 +1300,
> presume that some affirmative action is needed to generate the keys.

Why?

I don't see why that would be any more the case with CGA than
with HBA.

-Ekr

---

From: Jari Arkko <[email-masked]>
Date: Sun, 25 Nov 2007 23:51:47 +0200

Brian,

> They're much easier to deploy since they use a nonce instead of

I do not think the above is an accurate reflection of the state of affairs.

HBA provides a secure binding between two addresses. And only that.

CGA provides a secure binding between an address and a key. It is most
often applied to, again, show a secure binding between two addresses.
But it does provide a more fundamental property; the key can be used to
sign statements that are known to come from the "owner" of the address.
Neither HBAs or CGAs require any deployment support other than code in
the hosts using them. All keys and bindings are created by the hosts
themselves.

In any case, from Shim6 perspective the security properties of both are
very similar. Shim6 supports both CGAs and HBAs within the same
generalized CGA format.

Eric is right that HBA does not appear to buy much additional value over
CGAs. On the other hand, HBAs are very easy to support if you already
support CGAs; and some people seem to think shared-key only crypto is
helpful. You might disagree with that assessment, but it was the WG's
decision. I do not personally feel a need to prevent them for including
this support.

Jari

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 Nov 2007 15:08:31 -0800

At Sun, 25 Nov 2007 23:51:47 +0200,
> decision. I do not personally feel a need to prevent them for including

This seems like precisely the situation for which Experimental
was created.

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Nov 2007 13:27:24 +1300

> I don't see why that would be any more the case with CGA than

The nonce generation in HBA will just happen when it's needed.
It isn't obvious to me from looking over the SeND and CGA documents
when the key pair for CGA is created, but it certainly doesn't
fit in naturally like the HBA nonce. CGA is complicated by comparison.

I guess I see the HBA-only mode as being much more important in
practice than CGA/HBA.

     Brian

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 Nov 2007 18:23:46 -0800

At Mon, 26 Nov 2007 13:27:24 +1300,
> The nonce generation in HBA will just happen when it's needed.

As will the CGA key generation.

> fit in naturally like the HBA nonce. CGA is complicated by comparison.

I don't see where you're getting this from. At the time when you need
to create a new address, you simply create a new asymmetric key pair
and build the CGA. This fits in perfectly naturally. Yes, if you're
using a very high security parameter this may take a few secconds,
but the situation with HBA is exactly the same in that regard.

Actually, it's the HBA interface that's complicated, because you need
to create all your addresses at once and whenever you get a new prefix
you need to generate all new addresses. CGA doesn't have this problem.

-Ekr

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 26 Nov 2007 11:18:42 +0100

> decision. I do not personally feel a need to prevent them for  

There are two differences:

- both generating and checking public key signatures is more expensive  
than just hashes

- for CGA, a host needs to store a private key somehwere, with HBA  
there are no secrets

---

From: Jari Arkko <[email-masked]>
Date: Mon, 26 Nov 2007 13:33:37 +0200

> - for CGA, a host needs to store a private key somehwere, with HBA

Yes, and in addition generating the key pair take some time. These are
not being disputed, Eric simply was disagreeing with the value of those
of differences.

Jari

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Nov 2007 06:44:53 -0800

At Mon, 26 Nov 2007 11:18:42 +0100,
> - both generating and checking public key signatures is more expensive  

Yes, it is, but as I said in my initial review, I don't see any
real evidence that these are limiting factors in any practical
setting. Premature optimization is one of the most common tropes
in cryptographic protocol engineering.

> - for CGA, a host needs to store a private key somehwere, with HBA  

I don't really see the relevance of this.

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Nov 2007 11:04:09 +1300

> not being disputed, Eric simply was disagreeing with the value of those

Exactly. No disagreement on the facts here. We may disagree on the
willingness of implementors (not to mention their evaluation of the
IPR claims involved).

     Brian

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 27 Nov 2007 01:33:10 +0000

On Mon, 26 Nov 2007 06:44:53 -0800
Eric Rescorla <[email-masked]> wrote:

> Premature optimization is one of the most common tropes
s/cryptographic protocol//

and probably s/tropes/mistakes/ -- unless I misunderstand you, you're
using an unusual and not particularly apt meaning of "trope" here...

		--Steve Bellovin, http://www.cs.columbia.edu/~smb