[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Will the real PFS please stand up?



> >What concerns me is the use of g^xj to protect the ephemeral
> >certificates; it appears to me as if subsequent compromise of j will
> >allow an eavesdropper to decrypt previously recorded [Cert_I]g^xj,
> >revealing the identities of everyone who has corresponded with j
> >during the period of interest.
> 
> Does this mean that an escrowing of J can yield j?  And thus escrowing is
> effective against SKIP PFS?  If so, this is unexceptable.  PFS must be
> immune to key escrowing.  

well, if we assume:
 a) escrowing of the long-term secret j
 b) no escrowing of the short-term secrets x and y
then release of `j' from escrow will reveal the identity of the
entities communicating with `J', but won't compromise their traffic.

I'm not sure these assumptions about key escrow policy are realistic;
in any situation where key escrow is mandated, skip-pfs, photuris, and
OAKLEY will all be illegal as specified.

> >Now, if I and J are just host identities, this isn't interesting
> >(because the same information is found in their IP addresses) but if
> >SKIP gets extended to do per-user keying I think we have a potential
> >problem.
> 
> Huh?  Please enlighten me.

Ok:

A certificate creates a binding between a principal's name and its
public key.

If the `name' in the certificate is just an IP address, then
compromise of the contents of Cert_I and Cert_J reveals no information
not already available to eavesdroppers, and skip-pfs's lack of PFS
protection on the exchanged certificates is moot.

If the `name' in the certificate contains something other than an IP
address, or something more than an IP address, then skip-pfs's lack of
PFS protection on the exchanged certificates becomes interesting.

> >It would be fairly simple to fix this by adding another round trip,
> >but the resulting protocol would would look a lot like OAKLEY or
> >Photuris.
> 
> Meaning that these are not open to recorded attacks in this manner.

Right; photuris doesn't exchange certificates until after a purely
ephemeral DH exchange is completed.

I believe OAKLEY has at least one mode which behaves the same way.

> But what about your comment: "if I and J are just host identities".
> How does this relate in Oakley or Photuris?

As above.. if principal names are always IP addresses, there's no
benefit in keeping them secret in the key mgt protocol because they're
sent in the clear in every packet..

					- Bill