> -----Original Message-----
> From: Michael Richardson [mailto:[email protected]]
> Sent: Friday, August 12, 2016 10:13 AM
> To: Scott Fluhrer (sfluhrer)
> Cc: IPsecme WG ([email protected])
> Subject: Re: [IPsec] Quantum Resistance Requirements
>
>
> Scott Fluhrer (sfluhrer) <[email protected]> wrote:
> > - Simplicity; how large of a change to IKE (and IKE implementations)
> > are we willing to contemplate?
>
> > o My opinion: minimizing changes to IKE should be given high priority,
> > both because “complexity is the enemy of security” and this is a short
> > term solution; if we have a solution that we can’t implement in a few
> > years, well, we might as well wait for the crypto people to give us the
> > long term one.
>
> Still, I'd like to know what the properties are of the cryptographically long
> term solution. It seems to me, having read your email and a few of the
> documents that the long-term solutions are architecturally least disruptive,
> and the short-term "hacks" are more disruptive.
>
> Is this a fair characterisation?
Since we don't have a long term solution in hand, to answer that would require
speculation; if I do indulge in that, I'd have to say that it's a bit on the
murky side
As I mentioned earlier, the "long term" solution would be to define another
"Diffie-Hellman group", which is not really DH at all (or at least, not only
DH), but includes some other key exchange protocol; the group is negotiated
just like any other group, and the initiator sends its KE payload, the
responder sends its KE payload, and both sides generate the shared secret. So,
at a protocol level, everything remains essentially the same (and the protocol
always makes it clear for each KE payload whether it's an initiator KE payload,
or a response (and if it's a response, which KE payload it's in response to).
However, at an implementation level, that's not necessarily as clean. I've
gone through a number of (believed) postquantum key exchanges; one thing I have
noticed is those protocols are all asymmetric in some way. With (EC)DH, both
sides do exactly the same thing; each side picks a secret value 'x', computes
'g**x', and that's its KE value; it receives the 'g**y' KE payload, and after
optionally validating it, computes the shared secret in a uniform manner. This
symmetry is not there in any postquantum key exchange I've looked at:
- With LWE-based key exchanges, both sides select a secret value and an error
vector; however the responder also sends some additional data along to the
initiator ("masking bits") which allow both sides to derive the same secret
(even though both sides add random error vectors); this additional data needs
to be computed in response to the initiator's KE payload, which implies that
(unlike DH) the responder's crypto code needs access to the initiator's KE
payload when generating its KE payload
- There are a number of schemes that are really public key encryption methods;
the initiator's KE payload really is a public encryption key, and the
responder's KE payload is a random value encrypted with that public key. This
works just fine; however it is obviously asymmetric.
- The closest to true symmetry I've come across is Supersingular EC Isogeny;
there, both side's KE payload can be produced without access to the other
side's KE payload. On the other hand, both sides necessarily need to be in
distinct roles (the references I've seen called them the "Alice" and "Bob"
role), and so the responder's crypto code needs to know that it's acting as a
responder.
My take-away from this speculation; while it's quite clean from the protocol
perspective, it might not end up being quite clean from the implementation
perspective, especially if the assumption that we can generate a key share
without reference to much else (which is true with DH) is buried fairly deep in
the implementation. On the other hand, if the responder implementation has a
single 'here's a KE payload, generate a response KE payload and the shared
secret' primitive, it might not be that bad.
</WildSpeculation>
As for the disruptiveness of the short term idea, well, from a crypto
perspective, it's actually fairly clean; once we have the secret, we stir that
as an input to the KDF, and we're good; what's actually disruptive is the
negotiation of the secret (are we using a secret with this negoatiion? If so,
which one?); if we go with the idea that only the IPsec SAs need to be QR, then
when we compute the KDF for the IPsec SAs, we know the other side's identity,
and so that would be rather straight-forward.
>
> Or could we introduce some things now that would make "dropping in" a
> replacement easier?
Nothing comes to mind; according to the above wild speculation, the
difficulties that people are likely to encounter are more to do with the
implementations, and less with the protocol.
Actually, there are some interesting postquantum protocols (e.g. McEliece)
which look good, except that they have massively large key shares. I've
considered them impractical; however if there was something easy we could do to
make those more practical, that may help. I'm not suggesting that we do; you
just asked if there was anything we might do that would help...
>
> > - Preserving existing IKE properties; how important is it that our
> > solution do not induce any weaknesses in IKE against an adversary with
> > a convention computer; that is, whatever we do, we must not make
> things
> > worse?
>
> > o My opinion: I’m pretty sure that we’ll all agree that this is
> > important (except for possibly the identity protection, see below); I
> > just want to state this as something we need to remember.
>
> Yes, very very important.
>
> > - What do we feel needs to protected from someone with a Quantum
> > Computer? Do we feel the need to protect only the IPsec traffic, or do
> > we need to protect the IKE traffic as well.
>
> > o My opinion: I’m going to abstain on this one, except to note that
> > protecting only the IPsec traffic allows for a rather simple
> > implementation; now, if the WG decides that protecting the IKE traffic
> > is important, this simplicity is irrelevant.
>
> I think it depends upon what the affect on the IKE traffic is.
Do we care if someone with a Quantum Computer can decrypt the IKE traffic?
>
> > - What level of identity protection do we need to provide? If two
> > different IKE negotiations use the same shared secret, do we mind if
> > someone can deduce that?
>
> > o My opinion: identity protection in IKE is rather overrated; I suspect
> > there’s enough in the data exchange that an advanced adversary (how
> can
> > look at things such as packet length and packet timings) is likely to
> > get a fairly decent guess regardless.
>
> I think you didn't answer the question you posed.
> You asked, "different IKE negotiations use the same shared secret, do we
> mind if
> someone can deduce that?"
>
> which I don't think it strictly about identity protection.
> I also think that leaking the identity of a mobile end point effectively
> could be
> painting a target on them. Consider how much effort is going into
> IPv6 privacy extensions.
Here's what I'm concerned with; Alice connects (from Starbucks) to Bob, using
their jointly shared PPK. Alice then goes to McDonald, then also connects to
Bob, using their jointly shared PPK. My question: are we concerned if someone
listening into the IKE negotiations, could determine whether the PPK Alice used
from Starbucks is the same as the one she used from McDonalds (and from that,
deduce that it's likely that the same person was at both Starbucks and
McDonalds)?
>
>
> > - How much support do we provide for nonstatic secrets, for example, by
> > QKD, or via something like HIMMO (a key distribution mechanism that
> > appears to be post quantum)?
>
> > o My opinion: I’d prefer it if we didn’t spend a great deal of time
> > trying to come up with a solution that covers everything. However, if
> > we could include a hook that these schemes could take advantage of
> > (such as an opaque identifier that’s passed that has meaning to the PPK
> > manager), that might be reasonable.
>
> Yes, I agree.
>
> > - Authentication; if someone with a Quantum Computer can break the
> DH
> > in real time, do we care if he can act as a man-in-the-middle?
>
> > o My opinion: this draft is here mainly to protect
> > ‘store-and-decrypt-later’ attacks, and so this attack isn’t as large of
> > a concern. On the other hand, we may very well get this for free; if we
> > include our ‘post quantum secret’ as an input to the KDF, then an
> > active attacker is foiled just like a passive attacker.
>
> I think that this is important, if we can do it without getting into IKEv1 PSK
> stupids.
That brings up another potential requirement (although I'm not certain how to
express it); something like "how important is it to avoid the problems that
IKEv1 had with preshared keys" (although a correct statement of the requirement
would list exactly what problems we're seeking to avoid)
>
> > - Algorithm agility; how important is it that we negotiate any
> > cryptoprimitives involved?
>
> > o My opinion: this is of lesser importance, as this is a short term
> > solution. On the other hand, I am quite aware that others on this list
> > would disagree with me…
>
> > Well, here’s my list of requirements (and my opinions); did I miss any
> > requirement that you think is important? What are you opinions about
> > these requirements?
>
> We have to be able to negotiate to use of these extensions.
> I want to suggest something further: that we might want to negotiate use of
> some of these extensions as a *rekey* of a "conventional" IKEv2 PARENT.
> I.e. even the use of these extensions might be too big a red flag.
Another potential requirement: do we care if someone listening in can determine
whether we're using this extension?
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
