Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS)

[Sandy Harris <sandy@storm.ca>]

Tylor Allison wrote:

> But that's the point... it's very possible to design a bad interface for
> handling public keys (and innumerable ways to design a good one).  Without
> a clear and concise mandate from this WG on the minimum requirements for
> PK/PKI, there will be interoperability problems (NOTE: this is not a
> bits-on-the-wire issue but a deployment issue).... IKEv1 should serve as
> an example for that! 

Yes, but I think that's an argument for including a spec for PK in SOI,
in particular for specifying a format for exchange of RSA keys. If my
implementation cannot export a public key in a format yours can read,
then we cannot interoperate. Methinks the standard must specify, as a
MUST, a text format usable for such export/import operations on public
keys.

(Perhaps it should handle export/import of private keys as well, for
the case where you want a central server to create keys for a bunch
of lesser devices such as point-of-sale terminals which might lack
the CPU power or random number generator to do it themselves. This is
a separate issue; perhaps a SHOULD in the standard?)

> The same really can't be said for pre-shared keys...
> they are simple, straight-forward, and almost guaranteed to interoperate
> between any two vendors.  Why throw it away?

Compared to public key methods, they have several disadvantages.
See:
http://www.freeswan.org/freeswan_snaps/CURRENT-SNAP/doc/adv_config.html#adv-pk 

In particular, they require secure out-of-band communication of the
secrets, which adds both cost and risk, and they scale much less
well. For an n-way mesh, you need n(n-1)/2 shared secrets, but only
n public/private key pairs.

If we get public key right, we can scrap shared secret. KISS in
this case means use one good technique,