Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[D. J. Bernstein]

Bas Westerbaan writes:
> At the moment the choice of hybrid is left to the application/protocol.
> This has led to many different proposals for hybrids, which wastes a lot of
> engineering, standardisation and security review time. I think it's better
> if hybridisation is done at the level of cryptographic primitive.

I agree that it's desirable to have KEMs that are internally using
double encryption and that can be reviewed independently of the target
application---not relying on details of TLS 1.3, for example.

For the same reasons (reducing security-review time, simplifying
standardization, etc.), it's desirable to minimize the number of
different double-encryption mechanisms. So I'd think that the default
path forward would be to pick a single combiner such as

   hybridss = H(ssECDH,ssKEM,H(hybridct),H(hybridpk),context)

where H is SHA3-256, hybridpk is (receiverpkECDH,receiverpkKEM), and
hybridct is (senderpkECDH,senderctKEM).

If there's instead a mechanism where the security analysis makes
reference to the Kyber details, then that's more effort to review, and
people plugging in KEMs other than Kyber (for good reasons: worrying
about the Kyber patent claim from http://tinyurl.com/5cu2j5hf, trusting
McEliece more, etc.) will need a different mechanism, so we end up with
more mechanisms than necessary. What's the advantage justifying this?

I saw the "hashing the typically large PQ ciphertexts" comment, but the
dollar-cost calculations from https://cr.yp.to/papers.html#pppqefs imply
that several thousand cycles to hash 1KB cost roughly 2^-38 dollars,
whereas sending or receiving 1KB costs roughly 2^-30 dollars. Is there
evidence of applications where the hashing cost is an issue?

---D. J. Bernstein

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] X-Wing: the go-to PQ/T hybrid KEM?

[Watson Ladd]

On Wed, Jan 10, 2024 at 12:14 PM Bas Westerbaan
 wrote:
>
> Dear tls and cfrg working groups,
>
> With ML-KEM (née Kyber) expected to be finalized this year, it’s time to 
> revisit the question of which PQ/T hybrid KEMs to standardize, and which to 
> recommend.

My preference would be that we use an KEM hybrid that works not just
for TLS but for HPKE etc with all the parameters set. I think its fine
if adapted for ML-KEM as is. Remembering which works here and which
doesn't there is work that we don't need to do and if gotten wrong
could cause problems.

Sincerely,
Watson


-- 
Astra mortemque praestare gradatim

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Bas Westerbaan]

On Thu, Jan 11, 2024 at 10:48 PM Martin Thomson  wrote:

>
>
> On Thu, Jan 11, 2024, at 07:13, Bas Westerbaan wrote:
> > X-Wing aims for 128-bit security, and for that combines the time-tested
> > X25519 with ML-KEM-768 [8]. X-Wing uses the combiner
> >
> >   SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 ||
> pk_X25519 )
>
> At least for TLS, I'm not convinced that any combiner is necessary, in
> line with the analysis done for draft-ietf-tls-hybrid-design.
>

I agree, for TLS this is not required for security.

For TLS the trade-off is this: we add one single keccak permutation, so
that we can eliminate the need of two different KEMs both called
X25519Kyber768, which are both used in PQ TLS with PQ ECH.

Best,

 Bas
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] X-Wing: the go-to PQ/T hybrid KEM?

[Martin Thomson]

On Thu, Jan 11, 2024, at 07:13, Bas Westerbaan wrote:
> X-Wing aims for 128-bit security, and for that combines the time-tested 
> X25519 with ML-KEM-768 [8]. X-Wing uses the combiner
>
>   SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519 )

At least for TLS, I'm not convinced that any combiner is necessary, in line 
with the analysis done for draft-ietf-tls-hybrid-design.

TLS hashes the entire transcript.  Would you poke holes in it to make the 
savings real?  That seems inadvisable, not only because it would be a pain to 
implement.  The existing draft-tls-westerbaan-xyber768d00 seems adequate in 
that regard.

I'm of the view that draft-westerbaan-cfrg-hpke-xyber768d00 is also fine for 
HPKE (modulo an update to the latest ML-KEM).  If the analysis shows that you 
can avoid the ML-KEM ciphertext, then I'm not opposed to cost savings for HPKE.

In other words, though I can see the value in modularity of analysis that 
something like this brings, if that modularity comes at the cost of efficiency 
or complexity in real applications, I don't see the point.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Scott Fluhrer (sfluhrer)]

I can’t say I agree with this argument.

If we have a combiner with a proof that “if either of the primitives we have 
meet security property A, then the output of the combiner meets security 
property B”, and we have proofs that both our primitives meet security property 
A”, then doesn’t that mean that our system has a proof that it meets security 
property B?  Wouldn’t that proof still apply even if one of our primitives 
fails due to some cryptanalytic attack?

Wouldn’t that also mean that if we have several primitives that all have proofs 
of security property A, we could mix-and-match as convenient, and that we don’t 
need to generate N^2 proofs to handle each of the combinations?  [Note: I’m not 
arguing that we should have this level of flexibility; only that we could]

As an analogy, consider the current TLS 1.3 situation.  There are multiple key 
agreements allowable (DH and ECDH), multiple ways to do authentication (PSK and 
certificate), multiple signature types (RSA and ECDSA), multiple data 
protection algorithms (GCM, ChaCha20).  For some reason, they don’t feel the 
need to prove each specific combination separately, but instead show that the 
various primitives meet some security assumptions, and go from there…


From: CFRG  On Behalf Of Orie Steele
Sent: Thursday, January 11, 2024 2:58 PM
To: Sophie Schmieg 
Cc: Salz, Rich ; Karolin Varner 
; Peter C ; IRTF CFRG 
; Bas Westerbaan ; 
 ; Kampanakis, Panos 

Subject: Re: [CFRG] [TLS] X-Wing: the go-to PQ/T hybrid KEM?

Hybrids by their very nature are the explosion.

If there will only ever be X-Wing, I think it's fine to not make it generic 
(since we admit that it is a special case, not an instance of a generic).

However, if B-Wing (brainpool + kyber) and P-Wing (p curve + kyber) also end up 
getting made, we never stopped the explosion, and we made it harder to evaluate 
the security properties, and we delayed the rollout against harvest and 
decrypt... for the cases where X-Wing could not fit.

Yes, we will need proofs for all those other hybrids, sounds like that will 
keep people busy for a while... It feels like promising false hope to say that 
making X-Wing not generic will stop all that other work from happening... If 
anything, making X-Wing generic will reduce the cost of doing the work, that 
seems inevitable at this point.

I do think it's important for this to not end up as "crabs in a bucket", where 
each candidate holds the others back, and then they all get cooked together.

If arguing over generic's causes that, I suggest we not make generics a 
requirement.

OS



On Thu, Jan 11, 2024 at 1:35 PM Sophie Schmieg 
mailto:40google@dmarc.ietf.org>> 
wrote:
I very much appreciate having a concrete hybrid scheme that is intentionally 
not generic. This avoids the explosion of ciphertext suites that would 
otherwise occur, and allows for better compatibility of libraries. Fixing the 
key sizes to ML-KEM 768 and X25519 is aligned with our preferred choices as 
well, and further increases interoperability.

On Thu, Jan 11, 2024 at 9:31 AM Salz, Rich 
mailto:40akamai@dmarc.ietf.org>> wrote:
I'm going to echo Bas to highlight that X-Wing is not generic to any IND-CCA 
KEM, it is a particular primitive construction based on the internal 
construction of ML-KEM in particular:

I don’t think it’s our place to try to shoe-horn everything into one construct. 
 Particularly when we are in the experimentation phase of things.

If people want to have ML-KEM as a material in their composites, it sounds like 
they might want to learn from X-Wing, but not try to chop them to fit into that 
one keyhole, as it were.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--

Sophie Schmieg | Information Security Engineer | ISE Crypto | 
sschm...@google.com

___
CFRG mailing list
c...@irtf.org
https://mailman.irtf.org/mailman/listinfo/cfrg


--



ORIE STEELE
Chief Technology Officer
www.transmute.industries

[https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Orie Steele]

Hybrids by their very nature are the explosion.

If there will only ever be X-Wing, I think it's fine to not make it generic
(since we admit that it is a special case, not an instance of a generic).

However, if B-Wing (brainpool + kyber) and P-Wing (p curve + kyber) also
end up getting made, we never stopped the explosion, and we made it harder
to evaluate the security properties, and we delayed the rollout against
harvest and decrypt... for the cases where X-Wing could not fit.

Yes, we will need proofs for all those other hybrids, sounds like that will
keep people busy for a while... It feels like promising false hope to say
that making X-Wing not generic will stop all that other work from
happening... If anything, making X-Wing generic will reduce the cost of
doing the work, that seems inevitable at this point.

I do think it's important for this to not end up as "crabs in a bucket",
where each candidate holds the others back, and then they all get cooked
together.

If arguing over generic's causes that, I suggest we not make generics a
requirement.

OS




On Thu, Jan 11, 2024 at 1:35 PM Sophie Schmieg  wrote:

> I very much appreciate having a concrete hybrid scheme that is
> intentionally not generic. This avoids the explosion of ciphertext suites
> that would otherwise occur, and allows for better compatibility of
> libraries. Fixing the key sizes to ML-KEM 768 and X25519 is aligned with
> our preferred choices as well, and further increases interoperability.
>
> On Thu, Jan 11, 2024 at 9:31 AM Salz, Rich  40akamai@dmarc.ietf.org> wrote:
>
>> I'm going to echo Bas to highlight that X-Wing is not generic to any
>> IND-CCA KEM, it is a particular primitive construction based on the
>> internal construction of ML-KEM in particular:
>>
>>
>>
>> I don’t think it’s our place to try to shoe-horn everything into one
>> construct.  Particularly when we are in the experimentation phase of things.
>>
>>
>>
>> If people want to have ML-KEM as a material in their composites, it
>> sounds like they might want to learn from X-Wing, but not try to chop them
>> to fit into that one keyhole, as it were.
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> --
>
> Sophie Schmieg | Information Security Engineer | ISE Crypto |
> sschm...@google.com
>
> ___
> CFRG mailing list
> c...@irtf.org
> https://mailman.irtf.org/mailman/listinfo/cfrg
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Blumenthal, Uri - 0553 - MITLL]

 

 

--

V/R,

Uri

 

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

>nnerEndI very much appreciate having a concrete hybrid scheme that is 
>intentionally not generic.

 

Totally agree.

 

> This avoids the explosion of ciphertext suites that would otherwise occur, 
> and allows for better compatibility of libraries.

>  Fixing the key sizes to ML-KEM 768 and X25519 is aligned with our preferred 
> choices as well, and further increases interoperability.

 

Yes.

 

Except that I want also an option with ML-KEM 1024.

 

 

 

On Thu, Jan 11, 2024 at 9:31 AM Salz, Rich  
wrote:

I'm going to echo Bas to highlight that X-Wing is not generic to any IND-CCA 
KEM, it is a particular primitive construction based on the internal 
construction of ML-KEM in particular: 

 

I don’t think it’s our place to try to shoe-horn everything into one construct. 
 Particularly when we are in the experimentation phase of things.

 

If people want to have ML-KEM as a material in their composites, it sounds like 
they might want to learn from X-Wing, but not try to chop them to fit into that 
one keyhole, as it were.

 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


 

-- 


Sophie Schmieg | Information Security Engineer | ISE Crypto | 
sschm...@google.com

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Sophie Schmieg]

I very much appreciate having a concrete hybrid scheme that is
intentionally not generic. This avoids the explosion of ciphertext suites
that would otherwise occur, and allows for better compatibility of
libraries. Fixing the key sizes to ML-KEM 768 and X25519 is aligned with
our preferred choices as well, and further increases interoperability.

On Thu, Jan 11, 2024 at 9:31 AM Salz, Rich  wrote:

> I'm going to echo Bas to highlight that X-Wing is not generic to any
> IND-CCA KEM, it is a particular primitive construction based on the
> internal construction of ML-KEM in particular:
>
>
>
> I don’t think it’s our place to try to shoe-horn everything into one
> construct.  Particularly when we are in the experimentation phase of things.
>
>
>
> If people want to have ML-KEM as a material in their composites, it sounds
> like they might want to learn from X-Wing, but not try to chop them to fit
> into that one keyhole, as it were.
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
sschm...@google.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Salz, Rich]

I'm going to echo Bas to highlight that X-Wing is not generic to any IND-CCA 
KEM, it is a particular primitive construction based on the internal 
construction of ML-KEM in particular:

I don’t think it’s our place to try to shoe-horn everything into one construct. 
 Particularly when we are in the experimentation phase of things.

If people want to have ML-KEM as a material in their composites, it sounds like 
they might want to learn from X-Wing, but not try to chop them to fit into that 
one keyhole, as it were.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Deirdre Connolly]

I'm going to echo Bas to highlight that X-Wing is not generic to any
IND-CCA KEM, it is a particular primitive construction based on the
internal construction of ML-KEM in particular:

> Note that it doesn’t hash in the ML-KEM ciphertext. For a generic KEM one
cannot leave out the ciphertext, but in the case of ML-KEM we can, assuming
we can model SHA3/SHAKE as a random oracle. This is proven in [0]. The gist
is that FO transform in ML-KEM makes it “ciphertext collision resistant”:
even if the underlying lattice problem is broken, it’s infeasible to create
from one ciphertext another different ciphertext with the same shared
secret.

While we have put some of this in the I-D the paper has the meat of this
analysis: https://eprint.iacr.org/2024/039.pdf

On Thu, Jan 11, 2024, 11:58 AM Kampanakis, Panos  wrote:

> +1 on making X-Wing a generic construction and stir in the KEM ciphertext.
>
>
>
> In the ML-KEM case, the SHAKE256 cost of an additional 1-1.5KB ciphertext
> c2 will be miniscule compared to the other operations. And this will be
> similar for other KEMs are well.
>
>
>
> For example, from https://bench.cr.yp.to/results-sha3.html it seems the
> total additional cost would be ~15 Kcycles for ML-KEM-1024 in most
> platforms which is pretty small compared to the
> sk2<-random(32)+ske<-random(32)+X25519.DH(ske, gX25519)+X25519.DH(sk2,
> gX25519) costs which amount to 400-1200 Kcycles (using
> https://bench.cr.yp.to/results-dh.html). Is a 5% savings worth the ML-KEM
> specific combiner?
>
>
>
>
>
>
>
> *From:* TLS  *On Behalf Of * Peter C
> *Sent:* Thursday, January 11, 2024 10:38 AM
> *To:* Mike Ounsworth ; Bas
> Westerbaan 
> *Cc:* IRTF CFRG ;  ;
> k...@cupdev.net
> *Subject:* RE: [EXTERNAL] [TLS] [CFRG] [EXTERNAL] X-Wing: the go-to PQ/T
> hybrid KEM?
>
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> Mike,
>
>
>
> X-Wing is not a profile of the generic construction.  Dropping the ML-KEM
> ciphertext changes the security assumptions you need to make.  If X25519 is
> secure then, in the generic construction, ML-KEM doesn’t need to satisfy
> any security properties at all for the hybrid to be secure.  In X-Wing, it
> still needs to be ciphertext collision resistant.  The X-Wing paper (
> https://ia.cr/2024/039) argues this holds for ML-KEM – or any similar KEM
> – but that depends on decapsulation functioning correctly.
>
>
>
> Peter
>
>
>
> *From:* CFRG  *On Behalf Of *Mike Ounsworth
> *Sent:* Thursday, January 11, 2024 2:57 PM
> *To:* Bas Westerbaan 
> *Cc:* IRTF CFRG ;  ;
> k...@cupdev.net
> *Subject:* Re: [CFRG] [EXTERNAL] X-Wing: the go-to PQ/T hybrid KEM?
>
>
>
> Right. I’m just thinking out loud here.
>
>
>
> If the Generic is
>
>
>
> KDF(counter || KEM1_ct || KEM1_ss || KEM2_ct  || KEM2_ss || fixedInfo)
>
>
>
> And X-Wing is:
>
>
>
> SHA3-256( “\.//^\” || ML-KEM_ss || X25519_ss || X25519_ct || X25519_pk )
>
>
>
> It looks pretty close to me; you’ve dropped the ML-KEM CT, added the
> X25519 recipient public key, and moved the fixedInfo from the end to the
> beginning.
>
>
>
> The question is: is that close enough to be considered a profile? Do we
> want to adapt the Generic so that X-Wing is properly a profile? Binding to
> the ECC public keys is probably not a bad idea in general. Certainly it
> would make no sense for some IETF protocols to use X-Wing while others use
> the ML-KEM + X25519 instantiation of the generic. I think I’m convincing
> myself that the Generic should be adjusted so that X-Wing is the obvious
> instantiation for ML-KEM + X25519.
>
>
>
> Aside: do you have an opinion about fixedInfo as a prefix vs a suffix? We
> chose suffix simply because it more obviously aligns with SP 800-56Cr2, and
> we’ve all had the experience of FIPS labs being picky about things like
> that.
>
>
>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* Bas Westerbaan 
> *Sent:* Thursday, January 11, 2024 7:07 AM
> *To:* Mike Ounsworth 
> *Cc:* IRTF CFRG ;  ; Deirdre
> Connolly ; k...@cupdev.net
> *Subject:* Re: [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?
>
>
>
> Speaking for myself (not for my co-authors), this feels like friendly,
> complementary work to draft-ounsworth-cfrg-kem-combiners; I agree. We could
> consider adding a section with concrete instantiations, and the first one
> would be X-Wing  (followed
>
>
>
>
>
> Speaking for myself (not for my co-authors), this feels like friendly,
> complementary work to draft-ounsworth-cfrg-kem-combiners;
>
>
>
> I agree.
>
>
>
> We could consider adding a section with concrete instantiations, and the
> first one would be X-Wing  (followed by ML-KEM + P-256, Brainpool, and
> RSA variants).
>
>
>
> I guess that leads to the following question: @Bas Westerbaan
> , @Deirdre Connolly
> , Peter, would you be open to merging X-Wing
> into the generic combiner draft, or is there value in it being standalone?
>
>
>
> X-Wing 

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Kampanakis, Panos]

+1 on making X-Wing a generic construction and stir in the KEM ciphertext.

In the ML-KEM case, the SHAKE256 cost of an additional 1-1.5KB ciphertext c2 
will be miniscule compared to the other operations. And this will be similar 
for other KEMs are well.

For example, from https://bench.cr.yp.to/results-sha3.html it seems the total 
additional cost would be ~15 Kcycles for ML-KEM-1024 in most platforms which is 
pretty small compared to the sk2<-random(32)+ske<-random(32)+X25519.DH(ske, 
gX25519)+X25519.DH(sk2, gX25519) costs which amount to 400-1200 Kcycles (using 
https://bench.cr.yp.to/results-dh.html). Is a 5% savings worth the ML-KEM 
specific combiner?



From: TLS  On Behalf Of Peter C
Sent: Thursday, January 11, 2024 10:38 AM
To: Mike Ounsworth ; Bas 
Westerbaan 
Cc: IRTF CFRG ;  ; k...@cupdev.net
Subject: RE: [EXTERNAL] [TLS] [CFRG] [EXTERNAL] X-Wing: the go-to PQ/T hybrid 
KEM?


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Mike,

X-Wing is not a profile of the generic construction.  Dropping the ML-KEM 
ciphertext changes the security assumptions you need to make.  If X25519 is 
secure then, in the generic construction, ML-KEM doesn’t need to satisfy any 
security properties at all for the hybrid to be secure.  In X-Wing, it still 
needs to be ciphertext collision resistant.  The X-Wing paper 
(https://ia.cr/2024/039) argues this holds for ML-KEM – or any similar KEM – 
but that depends on decapsulation functioning correctly.

Peter

From: CFRG mailto:cfrg-boun...@irtf.org>> On Behalf Of 
Mike Ounsworth
Sent: Thursday, January 11, 2024 2:57 PM
To: Bas Westerbaan 
mailto:bas=40cloudflare@dmarc.ietf.org>>
Cc: IRTF CFRG mailto:c...@irtf.org>>; 
mailto:tls@ietf.org>> mailto:tls@ietf.org>>; 
k...@cupdev.net
Subject: Re: [CFRG] [EXTERNAL] X-Wing: the go-to PQ/T hybrid KEM?

Right. I’m just thinking out loud here.

If the Generic is

KDF(counter || KEM1_ct || KEM1_ss || KEM2_ct  || KEM2_ss || fixedInfo)

And X-Wing is:

SHA3-256( “\.//^\” || ML-KEM_ss || X25519_ss || X25519_ct || X25519_pk )

It looks pretty close to me; you’ve dropped the ML-KEM CT, added the X25519 
recipient public key, and moved the fixedInfo from the end to the beginning.

The question is: is that close enough to be considered a profile? Do we want to 
adapt the Generic so that X-Wing is properly a profile? Binding to the ECC 
public keys is probably not a bad idea in general. Certainly it would make no 
sense for some IETF protocols to use X-Wing while others use the ML-KEM + 
X25519 instantiation of the generic. I think I’m convincing myself that the 
Generic should be adjusted so that X-Wing is the obvious instantiation for 
ML-KEM + X25519.

Aside: do you have an opinion about fixedInfo as a prefix vs a suffix? We chose 
suffix simply because it more obviously aligns with SP 800-56Cr2, and we’ve all 
had the experience of FIPS labs being picky about things like that.

---
Mike Ounsworth

From: Bas Westerbaan 
mailto:bas=40cloudflare@dmarc.ietf.org>>
Sent: Thursday, January 11, 2024 7:07 AM
To: Mike Ounsworth 
mailto:mike.ounswo...@entrust.com>>
Cc: IRTF CFRG mailto:c...@irtf.org>>; 
mailto:tls@ietf.org>> mailto:tls@ietf.org>>; 
Deirdre Connolly mailto:durumcrustu...@gmail.com>>; 
k...@cupdev.net
Subject: Re: [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

Speaking for myself (not for my co-authors), this feels like friendly, 
complementary work to draft-ounsworth-cfrg-kem-combiners; I agree. We could 
consider adding a section with concrete instantiations, and the first one would 
be X-Wing  (followed


Speaking for myself (not for my co-authors), this feels like friendly, 
complementary work to draft-ounsworth-cfrg-kem-combiners;

I agree.

We could consider adding a section with concrete instantiations, and the first 
one would be X-Wing  (followed by ML-KEM + P-256, Brainpool, and RSA variants).

I guess that leads to the following question: @Bas 
Westerbaan, @Deirdre 
Connolly, Peter, would you be open to merging 
X-Wing into the generic combiner draft, or is there value in it being 
standalone?

X-Wing explicitly trades genericity for simplicity. We will not get such a 
simple and efficient construction if it is the instantiation of an easy-to-use 
generic construction.

Best,

 Bas


---
Mike Ounsworth

From: CFRG mailto:cfrg-boun...@irtf.org>> On Behalf Of 
Bas Westerbaan
Sent: Wednesday, January 10, 2024 2:14 PM
To: IRTF CFRG mailto:c...@irtf.org>>; 
mailto:tls@ietf.org>> mailto:tls@ietf.org>>
Cc: k...@cupdev.net
Subject: [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

Dear tls and cfrg working groups, With ML-KEM (née Kyber) expected to be 
finalized this year, it’s time to revisit the question of which PQ/T hybrid 
KEMs 

Re: [TLS] X-Wing: the go-to PQ/T hybrid KEM?

[Filippo Valsorda]

This is excellent, especially the explicit decision to make concrete primitive 
choices, which allow the scheme to be both secure and efficient.

I have an implementation at filippo.io/mlkem768/xwing 
 which passes the test vectors in 
draft-connolly-cfrg-xwing-kem-00, Appendix A.

By the way, I really appreciate specifying "derandomized" versions of the 
functions for testing. It solves the problem of "randomness from the sky" 
 while 
providing a clear mandate not to expose the random input in high-level APIs. I 
would love to see this pattern adopted widely.

As Bas already mentioned, I suggested making sk = `concat(sk_M, sk_X, pk_X), to 
avoid the pk input to Decapsulate and mirroring in a sense the presence of pk_M 
in sk_M. We've learned with Ed25519 
 that designing APIs where 
key mismatches are possible is dangerous. In this case I *think* there would be 
no security impact, but it leads to questions like "what is the expected 
behavior of Decapsulate if the ML-KEM pk is invalid?" (This change is again 
cheap/possible because X-Wing targets `ML-KEM-768 and X25519 specifically, 
which further validates the team's decision to make concrete choices.)

2024-01-10 21:13 GMT+01:00 Bas Westerbaan :
> Dear tls and cfrg working groups,
> 
> With ML-KEM (née Kyber) expected to be finalized this year, it’s time to 
> revisit the question of which PQ/T hybrid KEMs to standardize, and which to 
> recommend.
> 
> # Status quo
> 
> For TLS at the time of writing there are two PQ/T hybrids registered: 
> X25519Kyber768 [1] and P256Kyber768 [2]. The former has been deployed widely 
> [3]. Both are instances of the hybrid-design draft [4], which use the simple 
> combiner ss_ECC || ss_Kyber, which is suitable for TLS, but not for other 
> applications such as HPKE, as it’s not IND-CCA2 robust [5].
> 
> For HPKE, there is a different KEM called X25519Kyber768 [6], which uses a 
> different combiner that mixes in the X25519 ephemeral key, by using HPKE’s 
> DHKEM construction instead of raw X25519.
> 
> There is also the ounsworth-kem-combiners I-D [7] that informed by [5] 
> proposes the generic combiner
> 
>   KDF( counter || ct1 || ss1 || ct2 || ss2 || fixedInfo, outputBits )
> 
> From a security standpoint that would be suitable for HPKE and TLS. To TLS it 
> is somewhat unattractive as it requires hashing the typically large PQ 
> ciphertexts, and adds some extra hashing in the conversion of the ECDH into a 
> KEM. On the other hand, for TLS it would be nice to have a KEM that is also 
> suitable for HPKE, as HPKE is used in ECH.
> 
> From a usability perspective, ounsworth-kem-combiners requires the user to 
> make several choices: which KEMs and in particular which method to use to 
> turn ECDH into a KEM, which security levels, which KDF, etc.
> 
> # The proposal: X-Wing
> 
> Let us introduce X-Wing [0]. The goal of X-Wing is to be *the* go-to PQ/T 
> hybrid KEM for the majority of use cases (including TLS and HPKE): no need to 
> make choices, or understand the subtleties.
> 
> X-Wing aims for 128-bit security, and for that combines the time-tested 
> X25519 with ML-KEM-768 [8]. X-Wing uses the combiner
> 
>   SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519 )
> 
> Here ss_X25519 is the plain X25519 shared secret; ct_X25519 is the ephemeral 
> public key; xwing-label a 6-byte label. Note that it doesn’t hash in the 
> ML-KEM ciphertext. For a generic KEM one cannot leave out the ciphertext, but 
> in the case of ML-KEM we can, assuming we can model SHA3/SHAKE as a random 
> oracle. This is proven in [0]. The gist is that FO transform in ML-KEM makes 
> it “ciphertext collision resistant”: even if the underlying lattice problem 
> is broken, it’s infeasible to create from one ciphertext another different 
> ciphertext with the same shared secret.
> 
> # Not final
> 
> We would love to hear your input: X-Wing is not final. For one, ML-KEM itself 
> might still change (presumably only in minor ways) before final 
> standardization. We think the CFRG would be a good venue to standardize 
> X-Wing — do you concur?
> 
> Best,
> 
> Bas, Deirdre, Karolin, Manuel, Peter
> 
> 
> PS. We want to mention explicitly that we see value in the kem-combiners and 
> hybrid-design drafts as generic safe methods to construct hybrids for those 
> use cases where X-Wing would not suffice.
> 
> 
> [0] Spec: https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/
> Proof: https://eprint.iacr.org/2024/039
> [1] Full name X25519Kyber768Draft00. 
> https://datatracker.ietf.org/doc/draft-tls-westerbaan-xyber768d00/
> [2] Full name SecP256r1Kyber768Draft00. 
> https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-kyber/
> [3] 
> https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html
> 

Re: [TLS] [CFRG] [EXTERNAL] X-Wing: the go-to PQ/T hybrid KEM?

[Mike Ounsworth]

Hi Peter.

 

Yeah, I get that; this is an optimization of the generic around the properties 
of ML-KEM.

 

My thinking-out-loud here is twofold:

 

1. Let’s avoid the situation where we have both X-Wing and 
generic-combiner-mlkem-x25519 floating around IETF protocols. I’m basically 
suggesting to put language in the generic combiner draft to say “If one of your 
KEMs is ML-KEM, then the follow optimization SHOULD be used”.

 

2. I’m on board with Bas, Deirdre, and Peter that X-Wing (ML-KEM-768 + X25519) 
satisfies a large number of majority usecases, and having it as a standalone 
document allows it to move ahead of the generics debate. HOWEVER, we will 
eventually need specifications for some fuller subset of {ML-KEM-512, 
ML-KEM-768, ML-KEM-1024} X {X25519, X448, P-256, P-384, Brainpool-P-256, 
Brainpool-P-384, RSA}, which can all also presumably benefit from the ML-KEM 
specific optimizations, so does that mean we’ll have a whole Rogue Squadron of 
drafts: A-Wing, B-Wing, Y-Wing? Or should the ML-KEM optimizations be 
considered in the generics draft?

 

Again, just thinking out loud here in front of the community.

 

---

Mike Ounsworth

 

From: Peter C  
Sent: Thursday, January 11, 2024 9:38 AM
To: Mike Ounsworth ; Bas Westerbaan 

Cc: IRTF CFRG ;  ; k...@cupdev.net
Subject: RE: [CFRG] [EXTERNAL] X-Wing: the go-to PQ/T hybrid KEM?

 

Mike, X-Wing is not a profile of the generic construction. Dropping the ML-KEM 
ciphertext changes the security assumptions you need to make. If X25519 is 
secure then, in the generic construction, ML-KEM doesn’t need to satisfy any 
security 



Mike,

 

X-Wing is not a profile of the generic construction.  Dropping the ML-KEM 
ciphertext changes the security assumptions you need to make.  If X25519 is 
secure then, in the generic construction, ML-KEM doesn’t need to satisfy any 
security properties at all for the hybrid to be secure.  In X-Wing, it still 
needs to be ciphertext collision resistant.  The X-Wing paper 
(https://ia.cr/2024/039 

 ) argues this holds for ML-KEM – or any similar KEM – but that depends on 
decapsulation functioning correctly.

 

Peter  

 

From: CFRG mailto:cfrg-boun...@irtf.org> > On Behalf Of 
Mike Ounsworth
Sent: Thursday, January 11, 2024 2:57 PM
To: Bas Westerbaan mailto:bas=40cloudflare@dmarc.ietf.org> >
Cc: IRTF CFRG mailto:c...@irtf.org> >; mailto:tls@ietf.org> > mailto:tls@ietf.org> >; k...@cupdev.net 
 
Subject: Re: [CFRG] [EXTERNAL] X-Wing: the go-to PQ/T hybrid KEM?

 

Right. I’m just thinking out loud here.

 

If the Generic is

 

KDF(counter || KEM1_ct || KEM1_ss || KEM2_ct  || KEM2_ss || fixedInfo)

 

And X-Wing is:

 

SHA3-256( “\.//^\” || ML-KEM_ss || X25519_ss || X25519_ct || X25519_pk )

 

It looks pretty close to me; you’ve dropped the ML-KEM CT, added the X25519 
recipient public key, and moved the fixedInfo from the end to the beginning.

 

The question is: is that close enough to be considered a profile? Do we want to 
adapt the Generic so that X-Wing is properly a profile? Binding to the ECC 
public keys is probably not a bad idea in general. Certainly it would make no 
sense for some IETF protocols to use X-Wing while others use the ML-KEM + 
X25519 instantiation of the generic. I think I’m convincing myself that the 
Generic should be adjusted so that X-Wing is the obvious instantiation for 
ML-KEM + X25519.

 

Aside: do you have an opinion about fixedInfo as a prefix vs a suffix? We chose 
suffix simply because it more obviously aligns with SP 800-56Cr2, and we’ve all 
had the experience of FIPS labs being picky about things like that.

 

---

Mike Ounsworth

 

From: Bas Westerbaan mailto:bas=40cloudflare@dmarc.ietf.org> > 
Sent: Thursday, January 11, 2024 7:07 AM
To: Mike Ounsworth mailto:mike.ounswo...@entrust.com> >
Cc: IRTF CFRG mailto:c...@irtf.org> >; mailto:tls@ietf.org> > mailto:tls@ietf.org> >; Deirdre Connolly 
mailto:durumcrustu...@gmail.com> >; k...@cupdev.net 
 
Subject: Re: [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

 

Speaking for myself (not for my co-authors), this feels like friendly, 
complementary work to draft-ounsworth-cfrg-kem-combiners; I agree. We could 
consider adding a section with concrete instantiations, and the first one would 
be X-Wing  (followed 

 

 

Speaking for myself (not for my co-authors), this feels like friendly, 
complementary work to draft-ounsworth-cfrg-kem-combiners;

 

I agree.

 

We could consider adding a section with concrete instantiations, and the first 
one would be X-Wing  (followed by ML-KEM + P-256, Brainpool, and RSA variants).

 

I guess that leads to the following question:  
 @Bas Westerbaan,  
 @Deirdre Connolly, 

Re: [TLS] [CFRG] [EXTERNAL] X-Wing: the go-to PQ/T hybrid KEM?

[Peter C]

Mike,

X-Wing is not a profile of the generic construction.  Dropping the ML-KEM 
ciphertext changes the security assumptions you need to make.  If X25519 is 
secure then, in the generic construction, ML-KEM doesn’t need to satisfy any 
security properties at all for the hybrid to be secure.  In X-Wing, it still 
needs to be ciphertext collision resistant.  The X-Wing paper 
(https://ia.cr/2024/039) argues this holds for ML-KEM – or any similar KEM – 
but that depends on decapsulation functioning correctly.

Peter

From: CFRG  On Behalf Of Mike Ounsworth
Sent: Thursday, January 11, 2024 2:57 PM
To: Bas Westerbaan 
Cc: IRTF CFRG ;  ; k...@cupdev.net
Subject: Re: [CFRG] [EXTERNAL] X-Wing: the go-to PQ/T hybrid KEM?

Right. I’m just thinking out loud here.

If the Generic is

KDF(counter || KEM1_ct || KEM1_ss || KEM2_ct  || KEM2_ss || fixedInfo)

And X-Wing is:

SHA3-256( “\.//^\” || ML-KEM_ss || X25519_ss || X25519_ct || X25519_pk )

It looks pretty close to me; you’ve dropped the ML-KEM CT, added the X25519 
recipient public key, and moved the fixedInfo from the end to the beginning.

The question is: is that close enough to be considered a profile? Do we want to 
adapt the Generic so that X-Wing is properly a profile? Binding to the ECC 
public keys is probably not a bad idea in general. Certainly it would make no 
sense for some IETF protocols to use X-Wing while others use the ML-KEM + 
X25519 instantiation of the generic. I think I’m convincing myself that the 
Generic should be adjusted so that X-Wing is the obvious instantiation for 
ML-KEM + X25519.

Aside: do you have an opinion about fixedInfo as a prefix vs a suffix? We chose 
suffix simply because it more obviously aligns with SP 800-56Cr2, and we’ve all 
had the experience of FIPS labs being picky about things like that.

---
Mike Ounsworth

From: Bas Westerbaan 
Sent: Thursday, January 11, 2024 7:07 AM
To: Mike Ounsworth 
Cc: IRTF CFRG ;  ; Deirdre Connolly 
; k...@cupdev.net
Subject: Re: [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

Speaking for myself (not for my co-authors), this feels like friendly, 
complementary work to draft-ounsworth-cfrg-kem-combiners; I agree. We could 
consider adding a section with concrete instantiations, and the first one would 
be X-Wing  (followed


Speaking for myself (not for my co-authors), this feels like friendly, 
complementary work to draft-ounsworth-cfrg-kem-combiners;

I agree.

We could consider adding a section with concrete instantiations, and the first 
one would be X-Wing  (followed by ML-KEM + P-256, Brainpool, and RSA variants).

I guess that leads to the following question: @Bas 
Westerbaan, @Deirdre 
Connolly, Peter, would you be open to merging 
X-Wing into the generic combiner draft, or is there value in it being 
standalone?

X-Wing explicitly trades genericity for simplicity. We will not get such a 
simple and efficient construction if it is the instantiation of an easy-to-use 
generic construction.

Best,

 Bas


---
Mike Ounsworth

From: CFRG mailto:cfrg-boun...@irtf.org>> On Behalf Of 
Bas Westerbaan
Sent: Wednesday, January 10, 2024 2:14 PM
To: IRTF CFRG mailto:c...@irtf.org>>; 
mailto:tls@ietf.org>> mailto:tls@ietf.org>>
Cc: k...@cupdev.net
Subject: [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

Dear tls and cfrg working groups, With ML-KEM (née Kyber) expected to be 
finalized this year, it’s time to revisit the question of which PQ/T hybrid 
KEMs to standardize, and which to recommend. # Status quo For TLS at the time 
of writing there
Dear tls and cfrg working groups,

With ML-KEM (née Kyber) expected to be finalized this year, it’s time to 
revisit the question of which PQ/T hybrid KEMs to standardize, and which to 
recommend.

# Status quo

For TLS at the time of writing there are two PQ/T hybrids registered: 
X25519Kyber768 [1] and P256Kyber768 [2]. The former has been deployed widely 
[3]. Both are instances of the hybrid-design draft [4], which use the simple 
combiner ss_ECC || ss_Kyber, which is suitable for TLS, but not for other 
applications such as HPKE, as it’s not IND-CCA2 robust [5].

For HPKE, there is a different KEM called X25519Kyber768 [6], which uses a 
different combiner that mixes in the X25519 ephemeral key, by using HPKE’s 
DHKEM construction instead of raw X25519.

There is also the ounsworth-kem-combiners I-D [7] that informed by [5] proposes 
the generic combiner

  KDF( counter || ct1 || ss1 || ct2 || ss2 || fixedInfo, outputBits )

From a security standpoint that would be suitable for HPKE and TLS. To TLS it 
is somewhat unattractive as it requires hashing the typically large PQ 
ciphertexts, and adds some extra hashing in the conversion of the ECDH into a 
KEM. On the other hand, for TLS it would be nice to have a KEM that is also 
suitable for HPKE, as HPKE is used in ECH.

From a usability perspective, ounsworth-kem-combiners requires 

Re: [TLS] [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Bas Westerbaan]

On Thu, Jan 11, 2024 at 3:56 PM Mike Ounsworth  wrote:

> Right. I’m just thinking out loud here.
>
>
>
> If the Generic is
>
>
>
> KDF(counter || KEM1_ct || KEM1_ss || KEM2_ct  || KEM2_ss || fixedInfo)
>
>
>
> And X-Wing is:
>
>
>
> SHA3-256( “\.//^\” || ML-KEM_ss || X25519_ss || X25519_ct || X25519_pk )
>
>
>
> It looks pretty close to me; you’ve dropped the ML-KEM CT, added the
> X25519 recipient public key, and moved the fixedInfo from the end to the
> beginning.
>
>
>
> The question is: is that close enough to be considered a profile? Do we
> want to adapt the Generic so that X-Wing is properly a profile?
>

The X-Wing combiner is not necessarily secure when instantiated with other
primitives. The big one is that we need a ciphertext collision resistant
KEM. Also we use that ML-KEM mixes in its own public key in the shared
secret. And then there are more assumptions: assuming fixed length
ciphertext/shared secrets, assuming we fit within the KDF block size (see
Dan's e-mail).

We could make the generic combiner simpler depending on the
primitives used, but that will make the generic combiner specification much
more complex/subtle.


Binding to the ECC public keys is probably not a bad idea in general.
> Certainly it would make no sense for some IETF protocols to use X-Wing
> while others use the ML-KEM + X25519 instantiation of the generic. I think
> I’m convincing myself that the Generic should be adjusted so that X-Wing is
> the obvious instantiation for ML-KEM + X25519.
>
>
>
> Aside: do you have an opinion about fixedInfo as a prefix vs a suffix? We
> chose suffix simply because it more obviously aligns with SP 800-56Cr2, and
> we’ve all had the experience of FIPS labs being picky about things like
> that.
>
>
>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* Bas Westerbaan 
> *Sent:* Thursday, January 11, 2024 7:07 AM
> *To:* Mike Ounsworth 
> *Cc:* IRTF CFRG ;  ; Deirdre
> Connolly ; k...@cupdev.net
> *Subject:* Re: [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?
>
>
>
> Speaking for myself (not for my co-authors), this feels like friendly,
> complementary work to draft-ounsworth-cfrg-kem-combiners; I agree. We could
> consider adding a section with concrete instantiations, and the first one
> would be X-Wing  (followed
>
>
>
> Speaking for myself (not for my co-authors), this feels like friendly,
> complementary work to draft-ounsworth-cfrg-kem-combiners;
>
>
>
> I agree.
>
>
>
> We could consider adding a section with concrete instantiations, and the
> first one would be X-Wing  (followed by ML-KEM + P-256, Brainpool, and
> RSA variants).
>
>
>
> I guess that leads to the following question: @Bas Westerbaan
> , @Deirdre Connolly
> , Peter, would you be open to merging X-Wing
> into the generic combiner draft, or is there value in it being standalone?
>
>
>
> X-Wing explicitly trades genericity for simplicity. We will not get such a
> simple and efficient construction if it is the instantiation of an
> easy-to-use generic construction.
>
>
>
> Best,
>
>
>
>  Bas
>
>
>
>
>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* CFRG  *On Behalf Of *Bas Westerbaan
> *Sent:* Wednesday, January 10, 2024 2:14 PM
> *To:* IRTF CFRG ;  
> *Cc:* k...@cupdev.net
> *Subject:* [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?
>
>
>
> Dear tls and cfrg working groups, With ML-KEM (née Kyber) expected to be
> finalized this year, it’s time to revisit the question of which PQ/T hybrid
> KEMs to standardize, and which to recommend. # Status quo For TLS at the
> time of writing there
>
> Dear tls and cfrg working groups,
>
> With ML-KEM (née Kyber) expected to be finalized this year, it’s time to
> revisit the question of which PQ/T hybrid KEMs to standardize, and which to
> recommend.
>
> # Status quo
>
> For TLS at the time of writing there are two PQ/T hybrids registered:
> X25519Kyber768 [1] and P256Kyber768 [2]. The former has been deployed
> widely [3]. Both are instances of the hybrid-design draft [4], which use
> the simple combiner ss_ECC || ss_Kyber, which is suitable for TLS, but not
> for other applications such as HPKE, as it’s not IND-CCA2 robust [5].
>
> For HPKE, there is a different KEM called X25519Kyber768 [6], which uses a
> different combiner that mixes in the X25519 ephemeral key, by using HPKE’s
> DHKEM construction instead of raw X25519.
>
> There is also the ounsworth-kem-combiners I-D [7] that informed by [5]
> proposes the generic combiner
>
>   KDF( counter || ct1 || ss1 || ct2 || ss2 || fixedInfo, outputBits )
>
> From a security standpoint that would be suitable for HPKE and TLS. To TLS
> it is somewhat unattractive as it requires hashing the typically large PQ
> ciphertexts, and adds some extra hashing in the conversion of the ECDH into
> a KEM. On the other hand, for TLS it would be nice to have a KEM that is
> also suitable for HPKE, as HPKE is used in ECH.
>
> From a usability perspective, ounsworth-kem-combiners requires the user to
> make several choices: which KEMs and in 

Re: [TLS] [EXTERNAL] Re: [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Bas Westerbaan]

>  Because for embedded devices that don’t have enough memory to hold all
> of those objects in simultaneously, this is likely the order in which it
> would have those things available to stream into SHA3.
>

That will not make a difference: the SHA3-256 rate is 136 bytes.


> Another thing to consider: thinking of how crypto libraries and HSMs are
> structures, will an X25519 decrypter necessarily have access to its own
> public key? For example I could imagine that to do X25519 based protocols
> today, an HSM only needs to store the X25519 private key. It’s probably
> worth a bit of a survey to see if adding a requirement for the HSM to know
> the X25519 public key will cause chaos with existing X25519 implementations.
>

Good point. Filippo also pointed out that having the pk as an argument to
decapsulate is inconvenient. He suggests to simply add the X25519 public
key to the X-Wing private key (similar to what ML-KEM also does), and that
makes sense to me.
https://github.com/dconnolly/draft-connolly-cfrg-xwing-kem/issues/8


>
>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* CFRG  *On Behalf Of *D. J. Bernstein
> *Sent:* Thursday, January 11, 2024 6:47 AM
> *To:* c...@irtf.org; tls@ietf.org
> *Subject:* [EXTERNAL] Re: [CFRG] X-Wing: the go-to PQ/T hybrid KEM?
>
>
>
> Do we have a survey of hybrid patents? To be clear, for security reasons I
> recommend a straightforward policy of always using hybrids (https:
> //urldefense. com/v3/__https: //blog. cr. yp. to/20240102-hybrid.
> html__;!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHAo-X8km$).
>
>
> Do we have a survey of hybrid patents?
>
>
>
> To be clear, for security reasons I recommend a straightforward policy
>
> of always using hybrids 
> (https://urldefense.com/v3/__https://blog.cr.yp.to/20240102-hybrid.html__;!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHAo-X8km$
>  
> ).
>
> NIST reportedly bought out some hybrid patents; I'm not aware of hybrid
>
> patents that predate the clear prior art; and in any case it has been
>
> obvious for many years to try hashing any selection of the available
>
> inputs that both sides see, such as ciphertexts, public keys, session
>
> keys, and/or context labels. But I worry that a profusion of hybrid
>
> mechanisms could have someone getting into trouble with a non-bought-out
>
> patent on some specific hybrid mechanism, because of an unfortunate
>
> choice of details matching what the patent happens to cover. A patent
>
> survey would reduce concerns here.
>
>
>
> Bas Westerbaan writes:
>
> > SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519
>
> > )
>
>
>
> 1. I'd include the post-quantum ciphertext (or a hash of it). Rationale:
>
> This makes the construction more generic, and simplifies security
>
> review. There's negligible performance cost compared to the cost of
>
> communicating the ciphertext in the first place. (For quantification of
>
> costs of communication etc., see 
> https://urldefense.com/v3/__https://cr.yp.to/papers.html*pppqefs__;Iw!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHM0iBL7o$
>  
> .)
>
>
>
> 2. I think it's good that both of the X25519 public keys are included
>
> where some hybrid constructions would include just one (labeled as
>
> ciphertext). Rationale: less chance of confusion regarding which key to
>
> include; better fit with some existing uses of X25519; might marginally
>
> simplify security review; even smaller performance cost than including
>
> the post-quantum ciphertext.
>
>
>
> 3. There are papers that recommend also including at least a 32-byte
>
> prefix of the post-quantum pk: (1) 
> https://urldefense.com/v3/__https://eprint.iacr.org/2021/708__;!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHFgGO8fn$
>  
> 
>
> recommends including some sort of user identifier and claims that it
>
> isn't "robust" to have ciphertexts that might be decryptable by multiple
>
> users; (2) 
> https://urldefense.com/v3/__https://eprint.iacr.org/2021/1351__;!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHGLYF4Sp$
>  
> 
>  recommends including a pk
>
> prefix for a different reason, namely to ensure that certain types of

Re: [TLS] [EXTERNAL] Re: [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Mike Ounsworth]

Bas Westerbaan writes:
> SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519
> )

 

 

One critique:

 

I would consider changing the order of the X25519 params to

 

SHA3-256( xwing-label || ss_ML-KEM || pk_X25519 || ct_X25519 || ss_X25519 )

 

Because for embedded devices that don’t have enough memory to hold all of those 
objects in simultaneously, this is likely the order in which it would have 
those things available to stream into SHA3.

 

Another thing to consider: thinking of how crypto libraries and HSMs are 
structures, will an X25519 decrypter necessarily have access to its own public 
key? For example I could imagine that to do X25519 based protocols today, an 
HSM only needs to store the X25519 private key. It’s probably worth a bit of a 
survey to see if adding a requirement for the HSM to know the X25519 public key 
will cause chaos with existing X25519 implementations.

 

---

Mike Ounsworth

 

From: CFRG  On Behalf Of D. J. Bernstein
Sent: Thursday, January 11, 2024 6:47 AM
To: c...@irtf.org; tls@ietf.org
Subject: [EXTERNAL] Re: [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

 

Do we have a survey of hybrid patents? To be clear, for security reasons I 
recommend a straightforward policy of always using hybrids (https: 
//urldefense. com/v3/__https: //blog. cr. yp. to/20240102-hybrid. 
html__;!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHAo-X8km$).
  



Do we have a survey of hybrid patents?
 
To be clear, for security reasons I recommend a straightforward policy
of always using hybrids 
(https://urldefense.com/v3/__https://blog.cr.yp.to/20240102-hybrid.html__;!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHAo-X8km$
 

 ).
NIST reportedly bought out some hybrid patents; I'm not aware of hybrid
patents that predate the clear prior art; and in any case it has been
obvious for many years to try hashing any selection of the available
inputs that both sides see, such as ciphertexts, public keys, session
keys, and/or context labels. But I worry that a profusion of hybrid
mechanisms could have someone getting into trouble with a non-bought-out
patent on some specific hybrid mechanism, because of an unfortunate
choice of details matching what the patent happens to cover. A patent
survey would reduce concerns here.
 
Bas Westerbaan writes:
> SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519
> )
 
1. I'd include the post-quantum ciphertext (or a hash of it). Rationale:
This makes the construction more generic, and simplifies security
review. There's negligible performance cost compared to the cost of
communicating the ciphertext in the first place. (For quantification of
costs of communication etc., see 
https://urldefense.com/v3/__https://cr.yp.to/papers.html*pppqefs__;Iw!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHM0iBL7o$
 

 .)
 
2. I think it's good that both of the X25519 public keys are included
where some hybrid constructions would include just one (labeled as
ciphertext). Rationale: less chance of confusion regarding which key to
include; better fit with some existing uses of X25519; might marginally
simplify security review; even smaller performance cost than including
the post-quantum ciphertext.
 
3. There are papers that recommend also including at least a 32-byte
prefix of the post-quantum pk: (1) 
https://urldefense.com/v3/__https://eprint.iacr.org/2021/708__;!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHFgGO8fn$
 

 
recommends including some sort of user identifier and claims that it
isn't "robust" to have ciphertexts that might be decryptable by multiple
users; (2) 
https://urldefense.com/v3/__https://eprint.iacr.org/2021/1351__;!!FJ-Y8qCqXTj2!eCunOU4zfX1vpARMymMYJyVdkjDscfW5QfvZotQ6soJwvvD8HKo-4gGHPJmhOhHuQVi78yuEHGLYF4Sp$
 

  recommends including a pk
prefix for a different reason, namely to ensure that certain types of
cryptanalytic attacks have to commit to the key they're attacking, which
might make multi-key attacks harder.
 
These arguments are weak, but the counterarguments that I see are also
weak. On balance, I'd think that it's best to just include the pk (or a
hash of the pk) in the hybrid-hash input, so people 

Re: [TLS] [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Mike Ounsworth]

Right. I’m just thinking out loud here.

 

If the Generic is

 

KDF(counter || KEM1_ct || KEM1_ss || KEM2_ct  || KEM2_ss || fixedInfo)

 

And X-Wing is:

 

SHA3-256( “\.//^\” || ML-KEM_ss || X25519_ss || X25519_ct || X25519_pk )

 

It looks pretty close to me; you’ve dropped the ML-KEM CT, added the X25519 
recipient public key, and moved the fixedInfo from the end to the beginning.

 

The question is: is that close enough to be considered a profile? Do we want to 
adapt the Generic so that X-Wing is properly a profile? Binding to the ECC 
public keys is probably not a bad idea in general. Certainly it would make no 
sense for some IETF protocols to use X-Wing while others use the ML-KEM + 
X25519 instantiation of the generic. I think I’m convincing myself that the 
Generic should be adjusted so that X-Wing is the obvious instantiation for 
ML-KEM + X25519.

 

Aside: do you have an opinion about fixedInfo as a prefix vs a suffix? We chose 
suffix simply because it more obviously aligns with SP 800-56Cr2, and we’ve all 
had the experience of FIPS labs being picky about things like that.

 

---

Mike Ounsworth

 

From: Bas Westerbaan  
Sent: Thursday, January 11, 2024 7:07 AM
To: Mike Ounsworth 
Cc: IRTF CFRG ;  ; Deirdre Connolly 
; k...@cupdev.net
Subject: Re: [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

 

Speaking for myself (not for my co-authors), this feels like friendly, 
complementary work to draft-ounsworth-cfrg-kem-combiners; I agree. We could 
consider adding a section with concrete instantiations, and the first one would 
be X-Wing  (followed 



 

Speaking for myself (not for my co-authors), this feels like friendly, 
complementary work to draft-ounsworth-cfrg-kem-combiners;

 

I agree.

 

We could consider adding a section with concrete instantiations, and the first 
one would be X-Wing  (followed by ML-KEM + P-256, Brainpool, and RSA variants).

 

I guess that leads to the following question:  
 @Bas Westerbaan,  
 @Deirdre Connolly, Peter, would you be open 
to merging X-Wing into the generic combiner draft, or is there value in it 
being standalone?

 

X-Wing explicitly trades genericity for simplicity. We will not get such a 
simple and efficient construction if it is the instantiation of an easy-to-use 
generic construction.

 

Best,

 

 Bas

 

 

---

Mike Ounsworth

 

From: CFRG mailto:cfrg-boun...@irtf.org> > On Behalf Of 
Bas Westerbaan
Sent: Wednesday, January 10, 2024 2:14 PM
To: IRTF CFRG mailto:c...@irtf.org> >; mailto:tls@ietf.org> > mailto:tls@ietf.org> >
Cc: k...@cupdev.net  
Subject: [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

 

Dear tls and cfrg working groups, With ML-KEM (née Kyber) expected to be 
finalized this year, it’s time to revisit the question of which PQ/T hybrid 
KEMs to standardize, and which to recommend. # Status quo For TLS at the time 
of writing there 

Dear tls and cfrg working groups,

With ML-KEM (née Kyber) expected to be finalized this year, it’s time to 
revisit the question of which PQ/T hybrid KEMs to standardize, and which to 
recommend.

# Status quo

For TLS at the time of writing there are two PQ/T hybrids registered: 
X25519Kyber768 [1] and P256Kyber768 [2]. The former has been deployed widely 
[3]. Both are instances of the hybrid-design draft [4], which use the simple 
combiner ss_ECC || ss_Kyber, which is suitable for TLS, but not for other 
applications such as HPKE, as it’s not IND-CCA2 robust [5].

For HPKE, there is a different KEM called X25519Kyber768 [6], which uses a 
different combiner that mixes in the X25519 ephemeral key, by using HPKE’s 
DHKEM construction instead of raw X25519.

There is also the ounsworth-kem-combiners I-D [7] that informed by [5] proposes 
the generic combiner

  KDF( counter || ct1 || ss1 || ct2 || ss2 || fixedInfo, outputBits )

>From a security standpoint that would be suitable for HPKE and TLS. To TLS it 
>is somewhat unattractive as it requires hashing the typically large PQ 
>ciphertexts, and adds some extra hashing in the conversion of the ECDH into a 
>KEM. On the other hand, for TLS it would be nice to have a KEM that is also 
>suitable for HPKE, as HPKE is used in ECH.

>From a usability perspective, ounsworth-kem-combiners requires the user to 
>make several choices: which KEMs and in particular which method to use to turn 
>ECDH into a KEM, which security levels, which KDF, etc.

# The proposal: X-Wing

Let us introduce X-Wing [0]. The goal of X-Wing is to be *the* go-to PQ/T 
hybrid KEM for the majority of use cases (including TLS and HPKE): no need to 
make choices, or understand the subtleties.

X-Wing aims for 128-bit security, and for that combines the time-tested X25519 
with ML-KEM-768 [8]. X-Wing uses the combiner

  SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519 )

Here ss_X25519 is the plain X25519 shared secret; 

Re: [TLS] Marvin reference to draft-ietf-tls-deprecate-obsolete-kex

[Salz, Rich]

> I don't know if you want to change the I-D in last call, but the
> Marvin Attack paper is now officially published:

I think this can be handled after LC and during AUTH48.

> Given that we have 17 CVEs and counting on top of ROBOT, I think that it's
> a good reference for disallowing RSA kex in TLS.

Agreed.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Marvin reference to draft-ietf-tls-deprecate-obsolete-kex

[Hubert Kario]

Hi,

I don't know if you want to change the I-D in last call, but the
Marvin Attack paper is now officially published:
https://doi.org/10.1007/978-3-031-51479-1_13

Given that we have 17 CVEs and counting on top of ROBOT, I think that it's
a good reference for disallowing RSA kex in TLS.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Bas Westerbaan]

> Speaking for myself (not for my co-authors), this feels like friendly,
> complementary work to draft-ounsworth-cfrg-kem-combiners;
>

I agree.


> We could consider adding a section with concrete instantiations, and the
> first one would be X-Wing  (followed by ML-KEM + P-256, Brainpool, and
> RSA variants).
>
>
>
> I guess that leads to the following question: @Bas Westerbaan
> , @Deirdre Connolly
> , Peter, would you be open to merging X-Wing
> into the generic combiner draft, or is there value in it being standalone?
>

X-Wing explicitly trades genericity for simplicity. We will not get such a
simple and efficient construction if it is the instantiation of an
easy-to-use generic construction.

Best,

 Bas


>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* CFRG  *On Behalf Of *Bas Westerbaan
> *Sent:* Wednesday, January 10, 2024 2:14 PM
> *To:* IRTF CFRG ;  
> *Cc:* k...@cupdev.net
> *Subject:* [EXTERNAL] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?
>
>
>
> Dear tls and cfrg working groups, With ML-KEM (née Kyber) expected to be
> finalized this year, it’s time to revisit the question of which PQ/T hybrid
> KEMs to standardize, and which to recommend. # Status quo For TLS at the
> time of writing there
>
> Dear tls and cfrg working groups,
>
> With ML-KEM (née Kyber) expected to be finalized this year, it’s time to
> revisit the question of which PQ/T hybrid KEMs to standardize, and which to
> recommend.
>
> # Status quo
>
> For TLS at the time of writing there are two PQ/T hybrids registered:
> X25519Kyber768 [1] and P256Kyber768 [2]. The former has been deployed
> widely [3]. Both are instances of the hybrid-design draft [4], which use
> the simple combiner ss_ECC || ss_Kyber, which is suitable for TLS, but not
> for other applications such as HPKE, as it’s not IND-CCA2 robust [5].
>
> For HPKE, there is a different KEM called X25519Kyber768 [6], which uses a
> different combiner that mixes in the X25519 ephemeral key, by using HPKE’s
> DHKEM construction instead of raw X25519.
>
> There is also the ounsworth-kem-combiners I-D [7] that informed by [5]
> proposes the generic combiner
>
>   KDF( counter || ct1 || ss1 || ct2 || ss2 || fixedInfo, outputBits )
>
> From a security standpoint that would be suitable for HPKE and TLS. To TLS
> it is somewhat unattractive as it requires hashing the typically large PQ
> ciphertexts, and adds some extra hashing in the conversion of the ECDH into
> a KEM. On the other hand, for TLS it would be nice to have a KEM that is
> also suitable for HPKE, as HPKE is used in ECH.
>
> From a usability perspective, ounsworth-kem-combiners requires the user to
> make several choices: which KEMs and in particular which method to use to
> turn ECDH into a KEM, which security levels, which KDF, etc.
>
> # The proposal: X-Wing
>
> Let us introduce X-Wing [0]. The goal of X-Wing is to be *the* go-to PQ/T
> hybrid KEM for the majority of use cases (including TLS and HPKE): no need
> to make choices, or understand the subtleties.
>
> X-Wing aims for 128-bit security, and for that combines the time-tested
> X25519 with ML-KEM-768 [8]. X-Wing uses the combiner
>
>   SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 ||
> pk_X25519 )
>
> Here ss_X25519 is the plain X25519 shared secret; ct_X25519 is the
> ephemeral public key; xwing-label a 6-byte label. Note that it doesn’t hash
> in the ML-KEM ciphertext. For a generic KEM one cannot leave out the
> ciphertext, but in the case of ML-KEM we can, assuming we can model
> SHA3/SHAKE as a random oracle. This is proven in [0]. The gist is that FO
> transform in ML-KEM makes it “ciphertext collision resistant”: even if the
> underlying lattice problem is broken, it’s infeasible to create from one
> ciphertext another different ciphertext with the same shared secret.
>
> # Not final
>
> We would love to hear your input: X-Wing is not final. For one, ML-KEM
> itself might still change (presumably only in minor ways) before final
> standardization. We think the CFRG would be a good venue to standardize
> X-Wing — do you concur?
>
> Best,
>
> Bas, Deirdre, Karolin, Manuel, Peter
>
>
> PS. We want to mention explicitly that we see value in the kem-combiners
> and hybrid-design drafts as generic safe methods to construct hybrids for
> those use cases where X-Wing would not suffice.
>
>
> [0] Spec: https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/
> 
> Proof: https://eprint.iacr.org/2024/039
> 
> [1] Full name X25519Kyber768Draft00.
> https://datatracker.ietf.org/doc/draft-tls-westerbaan-xyber768d00/
> 

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Bas Westerbaan]

Hi Dan,

Thanks for your detailed comments.

Bas Westerbaan writes:
> > SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519
> > )
>
> 1. I'd include the post-quantum ciphertext (or a hash of it). Rationale:
> This makes the construction more generic,


This construction is not meant to be generic, and we have security proof of
the IND-CCA robustness. I would be in favor of having Mike's draft
alongside X-Wing, so that people that are not satisfied with X-Wing, have a
safe recipe to create their own.


> 2. I think it's good that both of the X25519 public keys are included
> where some hybrid constructions would include just one (labeled as
> ciphertext). Rationale: less chance of confusion regarding which key to
> include; better fit with some existing uses of X25519; might marginally
> simplify security review; even smaller performance cost than including
> the post-quantum ciphertext.
>

And it is required for the IND-CCA robustness: without it, it's not.


> 3. There are papers that recommend also including at least a 32-byte
> prefix of the post-quantum pk:


ML-KEM already includes the public key in the derivation of the shared
secret (line 6 algorithm 17), so we see no need to include it a second
time. Again, we do not aim to be a generic construction with X-Wing.


> I think the hybrid construction is a good place to put this hash. If
> there are many different hybrid constructions then factoring out another
> layer might be useful for reviewers, but I'd rather settle on a minimal
> number of hybrid constructions.
>

At the moment the choice of hybrid is left to the application/protocol.
This has led to many different proposals for hybrids, which wastes a lot of
engineering, standardisation and security review time. I think it's better
if hybridisation is done at the level of cryptographic primitive.


> 4. I'd put ss_X25519 before the post-quantum session key. This has a
> two-part rationale.
>

All inputs fit within one SHA3-256 block. Because of that, if I understand
correctly, the order is inconsequential.

Best,

 Bas
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[D. J. Bernstein]

Do we have a survey of hybrid patents?

To be clear, for security reasons I recommend a straightforward policy
of always using hybrids (https://blog.cr.yp.to/20240102-hybrid.html).
NIST reportedly bought out some hybrid patents; I'm not aware of hybrid
patents that predate the clear prior art; and in any case it has been
obvious for many years to try hashing any selection of the available
inputs that both sides see, such as ciphertexts, public keys, session
keys, and/or context labels. But I worry that a profusion of hybrid
mechanisms could have someone getting into trouble with a non-bought-out
patent on some specific hybrid mechanism, because of an unfortunate
choice of details matching what the patent happens to cover. A patent
survey would reduce concerns here.

Bas Westerbaan writes:
> SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519
> )

1. I'd include the post-quantum ciphertext (or a hash of it). Rationale:
This makes the construction more generic, and simplifies security
review. There's negligible performance cost compared to the cost of
communicating the ciphertext in the first place. (For quantification of
costs of communication etc., see https://cr.yp.to/papers.html#pppqefs.)

2. I think it's good that both of the X25519 public keys are included
where some hybrid constructions would include just one (labeled as
ciphertext). Rationale: less chance of confusion regarding which key to
include; better fit with some existing uses of X25519; might marginally
simplify security review; even smaller performance cost than including
the post-quantum ciphertext.

3. There are papers that recommend also including at least a 32-byte
prefix of the post-quantum pk: (1) https://eprint.iacr.org/2021/708
recommends including some sort of user identifier and claims that it
isn't "robust" to have ciphertexts that might be decryptable by multiple
users; (2) https://eprint.iacr.org/2021/1351 recommends including a pk
prefix for a different reason, namely to ensure that certain types of
cryptanalytic attacks have to commit to the key they're attacking, which
might make multi-key attacks harder.

These arguments are weak, but the counterarguments that I see are also
weak. On balance, I'd think that it's best to just include the pk (or a
hash of the pk) in the hybrid-hash input, so people won't have to worry
about the possibility of protocols where omitting it causes issues.

There's a layering question regarding who's responsible for this hash. 
https://classic.mceliece.org/mceliece-security-20221023.pdf says the
following: "Classic McEliece follows the principle that any generic
transformation aiming at a goal beyond IND-CCA2 is out of scope for a
KEM specification. This is not saying that further hashing should be
avoided; it is saying that cryptographic systems should be appropriately
modularized."

I think the hybrid construction is a good place to put this hash. If
there are many different hybrid constructions then factoring out another
layer might be useful for reviewers, but I'd rather settle on a minimal
number of hybrid constructions.

4. I'd put ss_X25519 before the post-quantum session key. This has a
two-part rationale.

First, there's a rule of thumb saying to start with the input that's
least predictable for the attacker. This provides a principled way to
settle the order even in situations where there's no reason to think
that the order matters.

Second, available evidence such as https://kyberslash.cr.yp.to indicates
that the post-quantum session key is more likely to be predictable than
the X25519 shared secret. It's of course reasonable to argue that this
situation will be reversed eventually by a combination of quantum
computing and any required upgrades to the post-quantum KEMs, the same
way that it's reasonable to argue that hybrids will eventually be
unnecessary, but hybrid designs should disregard those arguments.

---D. J. Bernstein

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0RTT freshness test does not work well when delays are in minutes

[Martin Thomson]

On Thu, Jan 11, 2024, at 18:38, Christian Huitema wrote:
> If an implementation does not want to deal with the extra complexity, 
> then having a way to plug in some extra code for a specific scenario 
> makes sense...

My point was that the handling does not need to be complex, only the tolerance 
for time variation needs to be.  Tolerance is driven by two things: RTT and 
clock variations.  But - critically - that tolerance needs to be uniformly 
managed across the entire set of clients.  If you have clients that have very 
tight variance on timing, you can use a narrow window, but you risk excluding 
those with high variance.  If you want to allow for high variance, you spend 
more in doing so, largely by having to track more 0-RTT attempts over a wider 
window of time.

You can't selectively change that tolerance.  Otherwise, an attacker looking to 
exploit replay can choose whichever per-client reaction suits them best.

I'm assuming this is a DoS attack, I can't see how you would exploit this to 
mount a replay, though you might choose an option with false negatives on 
replay detection ... you shouldn't.  All of the distributed systems challenges 
that apply shouldn't be affected by long RTT unless you start increasing the 
distance between nodes that share 0-RTT state in ways that could be exploitable 
(note: do not do this, sharing state between collocated nodes is already risky 
enough).

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls