Hi Scott,
thank you for the list of requirements. My answers are inline.
In Berlin, we decided to take up Quantum Resistance as a work item, and that
we should start talking about requirements. I'm starting this thread in a hope
of kicking off the discussion.
First of all, a solution to Quantum Resistance that is applicable everywhere
would involve replacing the (EC)DH exchange with a postquantum key exchange.
While this would be ideal, the cryptographical community currently doesn't have
a solution that is sufficiently trusted and is of reasonable cost. So, it
would make sense to divide this into two efforts, a long term solution (which
we may initially put on the shelf, as the crypto pieces aren't there yet), and
a short term solution, to address the needs of customers that aren't willing to
wait; instead, they feel the need to protect traffic that is encrypted now.
For this short term solution, it's sufficient if we don't necessarily cover all
cases, a number of interesting cases (in particular, ones for which
redistributing secrets is doable) would be sufficient. Does everyone agree
with that general assessment?
If so, there here is a list of potential requirements (based on Tero's list
that he gave during the IETF, but with a few of my own), along with my opinion:
- Simplicity; how large of a change to IKE (and IKE implementations)
are we willing to contemplate?
Of course it is preferrable if the solution is simple. However, the simplicity
is difficult to measure,
so it is mostly subjective. I would put the simplicity closer to the end of the
list of requirements.
In other words - our goal is to provide a (temporary) QC-resistant solution. If
we manage to
get it simple - then it's good.
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.
- 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?
This is important.
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.
- 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.
This requirement is related to the previous one. If we we want to
preserve existing IKE properties.
then we should provide the solution that protects both IPsec and
IKE traffic. And I think it is important
that IKE traffic is protected. It will allow to re-use this
solution in G-IKEv2 protocol without the need
to re-invent it.
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.
- 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?
I think the ID protection is a nice thing to have, but I won't
consider it as the first proirity requirement.
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.
- PPK management; how much support do we provide for automatically
managing the secrets?
No strong opinion here.
o My opinion: we already have preshared keys in IKE, and we don't
define any particular management scheme for them (even though they are used
quite often in practice). I don't see why we need to go out of our way when it
comes to these postquantum secrets.
- 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)?
Again, no strong opinion here.
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.
- 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?
It would be nice if authentication is protected also. At least to
some extent (by the way, the curent
draft seems to achive that, because the SKEYSEED is dependant on
the PPK, so any authentication
method would be "augmented" by PPK).
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.
- Algorithm agility; how important is it that we negotiate any
cryptoprimitives involved?
I think it is important. I don't buy the argument that the solution
is intended to be temporary,
so we can sacrifice the algorith agility. As far as I understand
the situation with "persistent"
solution is currently very moot, so it is unpredictable for how
long this "temporary" solution
will be in use. Probably it is 1-2 years, probably it is 10-20
years. I definitely don't want
to have a 20-year long solution without algorithm agility.
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?
Thanks!
Regards,
Valery.
------------------------------------------------------------------------------
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
