Re: [IPsec] Clarification on my comments during the WG about possible KE payloads > 64k

[Yoav Nir]

Hi, Scott.

That was me. When they started talking about about PQC a decade ago, they 
mentioned algorithms like McEliece with public keys around 1MB.

Not that this is a deal-killer. If necessary, we would come up with an IKE 
extension to have “jumbo-sized payloads” that had 24-bit lengths. IKE over TCP 
(RFC 8229) can handle this easily.

But anyway, since the current state of the art seems to not need such an 
extension, I guess there’s no point it bringing this up now.

Yoav

> On 25 Mar 2018, at 20:36, Scott Fluhrer (sfluhrer)  wrote:
> 
> During the WG meeting in London, somebody (I forget who) asked me whether KE 
> payloads larger than 64k.  I thought I ought to clarify matters (as they are 
> more complex than the brief answer I gave indicated).
> 
> Of the proposed postquantum key exchange (and public key encryption 
> algorithms, which can be used to transport keys) submitted to NIST, the 
> majority of them have key shares (or public keys/ciphertexts) smaller than 
> 64k; there are a handful that are larger.  Now, it is possible (albeit 
> unlikely) that all the algorithms with key shares < 64k will be broken; 
> unless this happens, it would be reasonable (IMHO) that we mandate that any 
> algorithm he allow have a KE payload that fits within 64k.  Now, in the event 
> that we feel the need to support larger key shares, there are possible ways 
> to support that; I don’t feel that we need to talk about those options now.
> ___
> IPsec mailing list
> IPsec@ietf.org 
> https://www.ietf.org/mailman/listinfo/ipsec 
> 


signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv

[Scott Fluhrer (sfluhrer)]

Rereading this, I have to do one correction:

From: IPsec  On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Sunday, March 25, 2018 2:11 PM
To: IPsecme WG (ipsec@ietf.org) 
Subject: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv


-  Section 4: "Section 3.5 of [RFC6407] explains how repetition MAY BE 
prevented by using a prefix for each group member"
Actually, RFC6407 just refers to RFC6054; that has the SID in the top 8 bits of 
the 8 byte sequence number.
I meant "the top 8 bits of the 8 byte explicit IV"...

Sorry about that...
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Comments on draft-ietf-ipsecme-implicit-iv

[Scott Fluhrer (sfluhrer)]

-  Section 4: "Section 3.5 of [RFC6407] explains how repetition MAY BE 
prevented by using a prefix for each group member"
Actually, RFC6407 just refers to RFC6054; that has the SID in the top 8 bits of 
the 8 byte sequence number.  Used literally, this doesn't work, as the top 8 
bits of the 8 byte sequence number are never expressed in the packet in 
implicit-iv.  You could put them in the top 8 bits of the 4 byte sequence 
number (which means you can't use ESN, but it didn't work in the multisender 
case anyways), but that would mean that each sender would be limited to 16M 
packets. I believe that these details are distinct enough that (if this is 
considered a viable alternative) they should be explicitly listed (including 
the 16M packet restriction).  Alternatively, we can just forbid this transform 
in the multisender case.


-  Section 6: "The rules of SA payload processing ensure that the 
responder will never send an SA payload containing the IIV indicator to an 
initiator that does not support IIV"

I believe that this is stale text; the current draft doesn't use an indicator; 
instead, it defines separate transforms IDs.


-  Section 8 has "AES-CTR ... [is] likely to implement the implicit IV 
described in this document"; however the transform ENCR_AES_CTR_IIV is not 
defined.  Is this intended?  Should we either remove the AES-CTR algorithm from 
the list of "likely to implement", or should we actually define the transform 
id for it?


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

[IPsec] Clarification on my comments during the WG about possible KE payloads > 64k

[Scott Fluhrer (sfluhrer)]

During the WG meeting in London, somebody (I forget who) asked me whether KE 
payloads larger than 64k.  I thought I ought to clarify matters (as they are 
more complex than the brief answer I gave indicated).

Of the proposed postquantum key exchange (and public key encryption algorithms, 
which can be used to transport keys) submitted to NIST, the majority of them 
have key shares (or public keys/ciphertexts) smaller than 64k; there are a 
handful that are larger.  Now, it is possible (albeit unlikely) that all the 
algorithms with key shares < 64k will be broken; unless this happens, it would 
be reasonable (IMHO) that we mandate that any algorithm he allow have a KE 
payload that fits within 64k.  Now, in the event that we feel the need to 
support larger key shares, there are possible ways to support that; I don't 
feel that we need to talk about those options now.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec