[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal: Perfect forward (proactive) SECURITY a MUST
Ashar and all,
>
> > Again: I don't see this as black and white... It's a tradeoff. But, we must
> > decide, and therefore I also state my position: the price is reasonable.
> > Let's require perfect forward (proactive) security.
>
> I think I have already stated my position on this.
Sorry but a clarification is still in place. I'm not talking about perfect
forward secrecy. I"m talking about the ability to recover security after
a break-in discovers your secret keys, which works when the attacker cannot
completely control all communication. Namely, the security is based on
a recovery mechanism such that the attacker has to break into several
processors at the same time.
I think these are good properties we want to support when the price is right.
Now it's for the
> rest of the group to voice their opinion (if they haven't already
> done so).
Agree!
>
> Now for a clarification. I didn't see a perfect forward secrecy
> proposal in your MKMP document, other than one which was SKIP
> based (in the appendix), i.e using SKIP to exchange ephemeral
> DH values. (The master key update protocol in the body of the
> MKMP document provides good as opposed to perfect forward
> secrecy).
Yes, this is what is proposed in the MKMP draft. But I think we can do better.
>
> As I have already confirmed offline with Hugo, this is the same
> proposal that I made at the San Jose IETF, (and which I also
> mentioned verbally at the Toronto IETF). So, is this the proposal
> that you are advocating for perfect forward secrecy? If so,
> we are at least coming closer to an agreement.
Almost. However I think we can do better by authenticating the ephemeral DH
using the keys from the _previous_instance_ of the ephemeral DH. One can
either use just the previous shared ephemeral key or use the public
exponents from previous time by computing
shared value in round i = g^{y_{i-1}}^x_i XOR g^{y_i}^x_{i-1}
Therefore in each round we authenticate the DH keys for next round.
the result is that breaking req' breaking into both processors together
and then an active attack (rather than just message injection as is possible
in SKIP).
Furthermore, processors can broadcast and compare the ephemeral DH public
keys, making it even harder to cheat without being detected.
This idea was developed in a new work with Ran Canetti which we would submit
soon (maybe to Crypto).
So my proposal is to have a protocol completely based on DH with a
non-interactive and interactive modes (we can later decide if one of them
is only optional). This protocol would have protection against clogging
(even from unknown addresses and even non-interactive), anonymity if we
desire (I'll explain how to do it non-interactively later - or ask Hugo),
and proactive security at least in the interactive modes.
> Also, as I mentioned in my IETF talk (and as your MKMP document also notes
> in the appendix) it is possible to have perfect forward secrecy on top
> of SKIP, without requiring a different crypto algorithm's (e.g RSA)
> authenticated public keys.
Sure!! Even proactive security (of course both forward secrecy and of course
proactive req' interaction but we could have less secure non-interactive
SKIP option)
The authentic DH public keys may be obtained
> either from secure DNS (per the Kaufman-Eastlake draft) or using
> some certificate format distributed using a standard directory service.
Or using PGP-like web of trust... I don't worry about this aspect so much.
>
> I should point out that this would have the lowest computational
> overhead of any perfect forward secrecy scheme, (including, I believe,
> the Yacobi scheme) and furthermore does not suffer from the
> (admittedly theoretical) triangle attack (Burmeister, Crypto '94).
I agree.
>
> If we can agree on these two modes, one session-less, simple and
> efficient, and the other heavier-weight, more complex and session oriented,
> then we will have essentially the equivalent of what already exists
> in the Internet for transport protocols, namely UDP and TCP.
Completely agree. That's what we should do. The interactive protocol is
also tunable (freq of updates)
>
> We can then argue over which one should be required and which
> one should be optional. Can we at least agree on this?
Exactly what I want us to do. And it can achieve all goals of all existing
proposals.
>
> Or do you have another perfect forward secrecy proposal that you
> would like to support?
See above, my proposal is a slight modification in using `chained DH' - this
provides even better security.
>
> This is related because perfect forward secrecy is only important
> if you have secrecy!
>
> Authentication-only with perfect-forward secrecy is an oxymoron.
>
> > Ashar, you got it upside down. First, this feature is great for authentication,
> > not just secrecy.
>
> What are you talking about? Perfect forward secrecy is great
> for authentication? How can forward secrecy make sense, when
> there is no secrecy to begin with?
NOt secrecy - SECUIRTY!!
have to run, happy new year, Amir
>
> (I will address Hugo's concerns later, which are related to key
> compromise and dont really fall in the category of perfect forward
> secrecy, as the way the term is used in the literature, and by the
> person who invented it).
>
> > Agreed. However I don't think the overhead of a rarely-invoked protocol is so
> > significant. Compare this to SKIP, where you essentially suggest that the
> > public keys would be changed by some off-line operation.
>
> I am afraid you lost me here. What are you referring to? I suggested
> offline computation of ephemeral DH keys, wrt the perfect forward
> secrecy-on-SKIP proposal. When did I refer to changing SKIP public
> keys offline?
>
> > I understand and respect your position. I'm happy to observe that we both
> > want both modes, one to be the default and the other as option. We just have
> > different preferences to which is default.
>
> I also respect your work and position, and hope our disagreements will not
> prevent continued joint work in helping define/discuss the requirements/details
> of the key-management scheme that will ultimately be deployed.
>
> Best regards, peace and goodwill,
> Ashar.
References: