> On 23 Aug 2016, at 9:32 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
> 
> On 23 Aug 2016, at 10:55, Paul Wouters wrote:
> 
>> On Mon, 8 Aug 2016, Paul Wouters wrote:
>> 
>> I haven't heard any objection to making 128 bit key sizes MUST- and
>> 256 bit key sizes MUST.
> 
> You can hear one now.
> 
>> Answers that agree or disagree would be good
>> to hear.
> 
> The proposed change is based on the existence of quantum computers that have 
> a sufficient number of properly-interacting qbits. We have literally no idea 
> if those computers will ever exist. All current data indicates that we will 
> see the progressing of "sufficient number" and "properly-interacting" and be 
> able to increase key sizes well ahead of widespread use of quantum computers.

Perhaps, but those quantum computers will be able to decrypt the traffic we are 
sending now where the key is only 128-bit long.

The vast majority of implementations support both 128-bit and 256-bit keys for 
AES. When the day arrives that we feel it’s time to take the performance hit 
and more to 256-bit AES, all of us will merely have to reconfigure existing 
deployments. My company’s implementation has supported AES-256 since 2001, and 
I’m sure others are similar. But those outliers who support only one key length 
(presumably 128) will impede everyone’s transition to 256-bits. 

So I’m sympathetic to Paul W’s idea to make 256-bit a MUST. I don’t think it’s 
reasonable to release a product in 2016 that only supports 128-bit AES. I’m not 
saying anything about what the defaults should be and what configuration advice 
should be, but requiring support for 256-bit as a precaution seems prudent. 

I’m less sympathetic to reducing AES-128 to MUST-. This algorithm with that key 
length is the most common, most widely deployed for IKE, IPsec, TLS, and SSH. 
It’s by far the most commonly deployed. Our focus in these documents in 
interoperability, so this needs to be a MUST. As you’ve said, we don’t know if 
quantum computers are going to become practical in our lifetimes. Without them, 
AES-256 offers little advantage. I don’t think we should be signalling that 
AES-128 is on its way out.

Yoav

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to