On 23 Aug 2016, at 12:43, Derek Atkins wrote:
Paul,
On Tue, August 23, 2016 3:28 pm, Paul Hoffman wrote:
On 23 Aug 2016, at 12:12, Derek Atkins wrote:
Just to play devil's advocate here, are you implying that we'll see
a
5-10-year lead time on quantum computer development sufficiently in
order
to spend those 5-10 years:
1) having this discussion again,
2) revving the documents
3) getting the revved documents through the process
4) getting the revved documents published
5) getting the revved documents implemented
6) getting that new implementation into the field, and (most
importantly)
7) getting the OLD hardware decommissioned?
No, not at all. PaulW's proposal is *not* about adding a new
algorithm,
it is changing the recommendation status for the algorithms. Both
algorithms will be in the deployed systems. So the 5-10 years lead
time
is getting users to change their configs. If we can't get them to
change
them in 10 years, we probably can't get them to change them ever. It
is
operator's responsibility to maintain their configurations, not ours
to
be the configuration police. Note that this thread is split off from
the
QR thread.
I apologize for jumping in, but my reading doesn't match your
statement.
My reading was Paul proposing to change the Implementation Level of
AES-256 from SHOULD to MUST.
Ah! If you're right, then I agree with that part of his proposal.
That implied subtext is that some devices
may not currently implement AES-256 (even though they SHOULD) and he
wants
to ensure that, if/when a quantum computer comes into existence then
all
that is requires *IS* a configuration change to move deployment to
AES-256.
That sounds fine.
I may have misunderstood his proposal because he also wanted to demote
AES-128 from MUST to MUST-. I object on the grounds that we have no idea
if there will quantum-capable computers that can erode AES-128 in the
foreseeable future, and that even if a dedicated adversary could weaken
AES-128 to say 80 bits of strength, that we would want to say to all
developers "don't implement this".
--PaulH
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
