[TLS]Re: Curve-popularity data?

[Bas Westerbaan]

>
>
>
> One more thing: we are finalizing RFC 8446-bis right now, so if there is
> WG consensus to require that clients offer all MTI curves in the key_shares
> of their initial CH, then that would be a straightforward text change.
>
> I think we are closer to going in the other direction and allow TLS1.3
> spec-compliant implementations aiming at post-quantum support to drop
> support for P-256 entirely.
>
Agreed.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

[Bas Westerbaan]

X25519+ML-KEM will be acceptable for FIPS, just like P-256+Kyber is today.
We just need to wait for the final standard, and (crucially) for the
verified modules with ML-KEM.

On Mon, Jun 3, 2024 at 8:56 PM Stephen Farrell 
wrote:

>
> I'm afraid I have no measurements to offer, but...
>
> On 03/06/2024 19:05, Eric Rescorla wrote:
> > The question is rather what the minimum set of algorithms we need is. My
> >   point is that that has to include P-256. It may well be the case that
> > it needs to also include X25519.
>
> Yep, the entirely obvious answer here is we'll end up defining at least
> x25519+PQ and p256+PQ. Arguing for one but not the other (in the TLS
> WG) seems pretty pointless to me. (That said, the measurements offered
> are as always interesting, so the discussion is less pointless than
> the argument:-)
>
> Cheers,
> S.
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Bas Westerbaan]

On Mon, Jun 3, 2024 at 4:02 PM Filippo Valsorda 
wrote:

> 2024-06-03 15:34 GMT+02:00 Bas Westerbaan :
>
> More importantly, there are servers that will HRR to X25519 if presented a
> P-256 keyshare. (Eg. BoringSSL's default behaviour.) Unfortunately I don't
> have data at hand how often that happens.
>
>
> Are you saying that some of the 97.6% of servers that support P-256 still
> HRR to X25519 if presented a P-256 keyshare and a {P-256, X25519} supported
> groups list, and that's BoringSSL's default behavior?
>

Yes.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Bas Westerbaan]

On Mon, Jun 3, 2024 at 3:24 PM Salz, Rich 
wrote:

> Thank you for collecting and sharing these numbers! I think this here is
> the most interesting bit in terms of curve popularity, since any difference
> in CPU time is ultimately marginal compared to the cost of a HRR.
>
>
>
> I’m not so sure.   This is really CDN to origin, or server-to-server
> traffic. You’d expect latency to not be as important as client to server,
> but more importantly that persistent connections and resumption would
> amortize the cost hugely.
>

We do care about it. We're scanning origins so that we can send a supported
keyshare immediately and avoid HRR (not rolled out yet.) That's not just
for performance, but also to deal with origins that don't support HRR.

I also don't think this data supports the conclusion that P-256 will have
fewer HRRs. As you mention the population is quite skewed: only origins
that configured Cloudflare in front. More importantly, there are servers
that will HRR to X25519 if presented a P-256 keyshare. (Eg. BoringSSL's
default behaviour.) Unfortunately I don't have data at hand how often that
happens.

Best,

 Bas

>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Bas Westerbaan]

Numbers from Cloudflare server-side in the last hour. Restricted to TLS 1.3
and counting by handshake. "sent" column lists the group identifiers for
the keyshares sent by the cleint, and "supported" lists the identifiers for
the groups the client reports being supported. Both lists are sorted, and
grease has been removed. Recall X25519=29, X25519Kyber768=25497, P-256=23.
[1] "frac" is percents.

┌─frac─┬─sent───┬─supported──┐
│46.08025597692571 │ [29]   │ [23,24,29]
  │
│19.10472730561162 │ [29]   │ [23,24,25,29]
 │
│   12.634492333471034 │ [29]   │ [23,24,25,29,30]
  │
│9.969397483263833 │ [29,25497] │ [23,24,29,25497]
  │
│7.245082433725522 │ [29]   │ [23,24,25,29,30,256,257,258,259,260]
  │
│   0.9836423280948468 │ [23,29]│ [23,24,25,29,256,257]
 │
│   0.9693757351437323 │ [23,29]│ [23,24,25,29,30,256,257,258,259,260]
  │
│   0.7147137542915519 │ [23]   │ [16,19,21,23,24,25,256]
 │
│   0.5387597287371817 │ [23]   │ [23,24,25]
  │
│   0.3216808337902684 │ [24]   │ [23,24]
 │
│   0.3077268972274922 │ [29]   │ [23,24,29,30]
 │
│   0.2895491193771448 │ [23]   │ [23,24,25,256,257,258,259,260]
  │
│   0.2310142062284145 │ [23,29]│ [23,24,25,29]
 │
│  0.13238812679791004 │ [29]   │ [23,24,25,29,25497,65074]
 │
│   0.0837752734900604 │ [23]   │ [23]
  │
│ 0.057858939606985335 │ [29]   │ [23,24,25,29,256,257,258,259,260]
 │
│   0.0405672284711662 │ [29]   │ [23,24,25,29,30,249]
  │
│ 0.036025019042332365 │ [23]   │ [23,24]
 │
│ 0.027518977252528012 │ [23]   │
[9,10,11,12,13,14,22,23,24,25,256,257,258,259,260] │
│ 0.021650399459822143 │ [23,29]│ [23,24,25,29,256,257,258,259,260]
 │
└──┴┴┘

We're not just a server, but also a client proxying requests to our
customer's origins. We routinely scan customer's origin servers for their
support of keyshares. [2]

When we sent an empty ClientHello, advertising support for X25519,
X25519Kyber768, P-256, P-384 and P-521, those origins that support TLS 1.3
(and HelloRetryRequest [3]) picked as follows. We can call this server
preference.

96.7% X25519
1.8% P-384
0.7% P-256
0.54% X25519Kyber768
0.15% P-521

We also measure server support for each. (We send just the single keyshare
for the group and only advertise support for that group.)

97.6% P-256
97.0% X25519
94% P-384
89% P-521
0.54% X25519Kyber768

Best,

 Bas


[1] For your convenience link to the full list:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
[2] https://blog.cloudflare.com/post-quantum-to-origins
[3] About 1% of origins fails to do HelloRetryRequest.


On Mon, Jun 3, 2024 at 12:09 PM Martin Thomson  wrote:

> Some numbers from our telemetry.  This is purely connection-volume-based
> (so sites with lots of connections will be over-represented), but overall
> fairly stable.
>
> Key exchange:
>   ECDHE 99.21%, RSA 0.76%, ECDHE+KYBER: 0.03%
> ECDHE curve: X25519 84.50%, P-256 14.03%, P-384 0.93%, P-521 0.53%
> RSA size: 1024 0.25% (!), 2048 98.45%, 3072 0.26%, 4096 1.03%
>
> Authentication:
>   RSA Sign 70.10%, ECDSA 29.14%, RSA KEA 0.76%
> ECDSA curve:  P-256 99.69%, P-384 0.31%
> RSA size: 1024 0.09% (!), 2048 97.22%, 3072 0.28%, 4096 2.41%
>
> We do not expose Ed25519 signing in TLS at this stage, even though we
> could use delegated credentials so that it could be enabled without needing
> certificate support.
>
> On Sun, Jun 2, 2024, at 19:47, D. J. Bernstein wrote:
> > Information about the popularity of specific cryptosystems plays a role
> > in decisions of what to standardize and deploy. I've been pointed to a
> > surprising statement (quoted below) regarding popularity of curves, in
> > particular in TLS handshakes. The statement is from one of the current
> > TLS co-chairs, a month before the co-chair appointment. I'm wondering
> > what data the statement is based on; the statement doesn't have a
> > description of the data sources, and the statement seems impossible to
> > reconcile with various public statements that have clear data sources.
> >
> > A specific reason that I'd like to resolve this is that I'm concerned
> > about the impact on post-quantum deployment. To explain:
> >
> >* We're failing to protect confidentiality of most user data against
> >  future quantum attacks---but switching to a post-quantum system has
> >  an unacceptably high chance of making security even worse. See
> >  https://cr.yp.to/papers.html#qrcsp for how much has been broken.
> >
> >* The obvious path forward is to immediately roll out ECC+PQ hybrids,
> >  as illustrated by X25519+sntrup761 in 

[TLS]Re: Adoption Call for draft-davidben-tls-key-share-prediction

[Bas Westerbaan]

I support adoption, and am happy to review.

On Sat, May 4, 2024 at 12:05 AM Joseph Salowey  wrote:

> This is a working group call for adoption
> for draft-davidben-tls-key-share-prediction.  This document was presented
> at IET 118 and has undergone some revision based on feedback since then.
> The current draft is available here:
> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/.
> Please read the document and indicate if and why you support or do not
> support adoption as a TLS working group item. If you support adoption
> please, state if you will help review and contribute text to the document.
> Please respond to this call by May 20, 2024.
>
> Thanks,
>
> Joe, Deidre, and Sean
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Re: [TLS] WG Adoption for TLS Trust Expressions

[Bas Westerbaan]

On Tue, Apr 30, 2024 at 6:17 AM Brendan McMillion <
brendanmcmill...@gmail.com> wrote:

> but you could just as easily do this with a simple extension from the
> private range, so I'm not sure that was a big blocker.
>

No need for a new extension: a government can use a specific signature
algorithm for that (say, a national flavour of elliptic curve, or a
particular PQ/T hybrid).
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

[Bas Westerbaan]

On Thu, Mar 28, 2024 at 4:22 PM John Mattsson  wrote:

> Hi,
>
>
>
> I looked into what RFC 8446(bis) says about Raw Public Keys. As correctly
> stated in RFC 8446, TLS 1.3 with signatures and certificates is an
> implementation of SIGMA-I:
>
>
>
> SIGMA does however require that the identities of the endpoints (called A
> and B in [SIGMA]) are included in the messages. This is not true for TLS
> 1.3 with RPKs and TLS 1.3 with RPKs is therefore not SIGMA. TLS 1.3 with
> RPKs is vulnerable to what Krawczyk’s SIGMA paper calls misbinding attacks:
>
>
>
> “This attack, to which we refer as an “identity misbinding attack”,
> applies to many seemingly natural and intuitive protocols. Avoiding this
> form of attack and guaranteeing a consistent binding between a session key
> and the peers to the session is a central element in the design of SIGMA.”
>
>
>
> “Even more significantly we show here that the misbinding attack applies
> to this protocol in any scenario where parties can register public keys
> without proving knowledge of the corresponding signature key.”
>

With a bit more context (emphasis my own):

Yet, no proof of security of the *STS protocol*
exists (see more on this below). Even more significantly we show here that
the
misbinding attack applies to this protocol in any scenario where parties can
register public keys without proving knowledge of the corresponding
signature
key. (We note that while such “proof of possession” is required by some CAs
for
issuing a certificate, this is not a universal requirement for public key
certificates;
in particular it is not satisfied in many “out-of-band distribution”
scenarios, webs
of trust, etc.) In this case Eve can register A’s public key as its own and
then
simply replace A’s identity (or certificate) in the third message of STS
with her
own. B verifies the incoming message and accepts it as coming from Eve.
Thus,
in this case the STS protocol fails to defend against the misbinding
attack. Thus,
for the STS to be secure one must assume that a secure external mechanism
for
proof of possession of signature keys is enforced. *As we will see both the
ISO*
*protocol discussed in Section 4 and the SIGMA protocols presented here do
not*
*require such a mechanism.*





>
>
> As stated in Appendix E.1, at the completion of the handshake, each side
> outputs its view of the identities of the communicating parties. On of the
> TLS 1.3 security properties are “Peer Authentication”, which says that the
> client’s and server’s view of the identities match. TLS 1.3 with PRKs does
> not fulfill this unless the out-of-band mechanism to register public keys
> proved knowledge of the private key. RFC 7250 does not say anything about
> this either.
>
>
>
> I think this needs to be clarified in RFC8446bis. The only reason to ever
> use an RPK is in constrained IoT environments. Otherwise a self-signed
> certificate is a much better choice. TLS 1.3 with self-signed certificates
> is SIGMA-I.
>
>
>
> It is worrying to find comments like this:
>
>
>
> “I'd like to be able to use wireguard/ssh-style authentication for my app.
> This is possible currently with self-signed certificates, but the proper
> solution is RFC 7250, which is also part of TLS 1.3.”
>
> https://github.com/openssl/openssl/issues/6929
>
>
>
> RPKs are not the proper solution.
>
>
>
> (Talking about misbinding, does RFC 8446 say anything about how to avoid
> selfie attacks where an entity using PSK authentication ends up talking to
> itself?)
>
>
>
> Cheers,
>
> John Preuß Mattsson
>
>
>
> [SIGMA] https://link.springer.com/chapter/10.1007/978-3-540-45146-4_24
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] A suggestion for handling large key shares

[Bas Westerbaan]

Hi Scott,

I generally agree with David, in particular that the keyshare prediction
draft is the way forward.

There is a different use-case for your mechanism, which you didn't mention:
it's less likely to trip over buggy servers / middleboxes. We use it as the
default mechanism to talk to our customer's origins.
https://blog.cloudflare.com/post-quantum-to-origins

Thanks to Chrome's efforts, for browsers, we luckily don't need to use this
slower mechanism.

One inline comments down below.

Best,

 Bas


On Tue, Mar 19, 2024 at 5:47 AM Scott Fluhrer (sfluhrer)  wrote:

> Recently, Matt Campagna emailed the hybrid KEM group (Douglas, Shay and
> me) about a suggestion about one way to potentially improve the performance
> (in the ‘the server hasn’t upgraded yet’ case), and asked if we should add
> that suggestion to our draft.  It occurs to me that this suggestion is
> equally applicable to the pure ML-KEM draft (and future PQ drafts as well);
> hence putting it in our draft might not be the right spot.
>
>
>
> Here’s the core idea (Matt’s original scenario was more complicated):
>
>
>
>- Suppose we have a client that supports both P-256 and P256+ML-KEM.
>What the client does is send a key share for P-256, and also indicate
>support for P256+ML-KEM.  Because we’re including only the P256 key share,
>the client hello is short
>- If the server supports only P256, it accepts it, and life goes on as
>normal.
>- If the server supports P256+ML-KEM, what Matt suggested is that,
>instead of accepting P256, it instead a ClientHelloRetry with P256+ML_KEM.
>We then continue as expected and end up negotiating things in 2 round 
> trips.
>
>
>
> Hence, the non-upgraded scenario has no performance hit; the upgraded
> scenario does (because of the second round trip), but we’re transmitting
> more data anyways
>

The roundtrip is quite a bit more costly than the extra kilobyte of upload
with respect to latency.


> (and the client could, if it communicates with the server again, lead off
> with the proposal that was accepted last time).
>
>
>
> Matt’s suggestion was that this should be a SHOULD in our draft.
>
>
>
> My questions to you: a) do you agree with this suggestion, and b) if so,
> where should this SHOULD live?  Should it be in our draft?  The ML-KEM
> draft as well (assuming there is one, and it’s not just a codepoint
> assignment)?  Another RFC about how to handle large key shares in general
> (sounds like overkill to me, unless we have other things to put in that
> RFC)?
>
>
>
> Thank you.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Time to first byte vs time to last byte

[Bas Westerbaan]

>
> Given that especially for the web, CDNs used much higher initcwnds,


Please, let us not assume every website is behind a CDN.



> let's focus on Figure 10. Based on Fig 10, 50-100KB of data over a PQ
> connection, the TTLB would be 10-15% slower for 1Mbps and 200ms RTT. At
> higher speeds, this percentage is much less (1-1.5% based on Fig 9b), but
> let's focus on the slow link.
>
> If we consider the same case for handshake, then the PQ handshake slowdown
> is 30-35% which definitely looks like a very impactful slowdown. A 10-15%
> for the TTLB is much less, but someone could argue that even that is a
> significant slowdown. Note we are still in a slow link, so even the
> classical conn transferring 72KB is probably suffering. To quantify that I
> looked at my data from these experiments. A classical connection TTLB for
> 50-100KB of data at 1Mbps and 200ms RTT and 0% loss was ~1.25s. This is not
> shown in the paper because I only included text about the 10% loss case.
> 1.25s for a 72KB page to start getting rendered on a browser over a
> classical conn vs 1.25*1.15=1.44s for a PQ one. I am not sure any user
> waiting for 1.25s will close the browser at 1.44s.
>
> Btw, the Google PageSpeed Insights TTFB metric which includes (DNS lookup,
> redirects and more) considers 0.8s - 1.8s as "Needs improvement". In our
> experiments, the handshake time for 1Mbps and 200ms RTT amounted to 436ms
> and 576ms for the classical and PQ handshakes respectively. I am not sure
> the extra 140ms (30-35% slowdown) for the PQ handshake would even throw the
> Google PageSpeed Insights TTFB metric to the "Needs improvement" category.
>
>
>
> -Original Message-
> From: Martin Thomson 
> Sent: Thursday, March 7, 2024 10:26 PM
> To: Kampanakis, Panos ; David Benjamin <
> david...@chromium.org>; Deirdre Connolly ; Rob
> Sayre 
> Cc: TLS@ietf.org; Childs-Klein, Will 
> Subject: RE: [EXTERNAL] [TLS] Time to first byte vs time to last byte
>
> 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.
>
>
>
> Hi Panos,
>
> I realize that TTLB might correlate well for some types of web content,
> but it's important to recognize that lots of web content is badly bloated
> (if you can tolerate the invective, this is a pretty good look at the
> situation, with numbers:
> https://infrequently.org/series/performance-inequality/).
>
> I don't want to call out your employer's properties in particular, but at
> over 3M and with relatively few connections, handshakes really don't play
> much into page load performance.  That might be typical, but just being
> typical doesn't mean that it's a case we should be optimizing for.
>
> The 72K page I linked above looks very different.  There, your paper shows
> a 20-25% hit on TTLB.  TTFB is likely more affected due to the way
> congestion controllers work and the fact that you never leave slow start.
>
> Cheers,
> Martin
>
> On Fri, Mar 8, 2024, at 13:56, Kampanakis, Panos wrote:
> > Thx Deirdre for bringing it up.
> >
> > David,
> >
> > ACK. I think the overall point of our paper is that application
> > performance is more closely related to PQ TTLB than PQ TTFB/handshake.
> >
> > Snippet from the paper
> >
> > *> Google’s PageSpeed Insights [12] uses a set of metrics to measure
> > the user experience and webpage performance. The First Contentful
> > Paint (FCP), Largest Contentful Paint (LCP), First Input Delay (FID),
> > Interaction to Next Paint (INP), Total Blocking Time (TBT), and
> > Cumulative Layout Shift (CLS) metrics include this work’s TTLB along
> > with other client-side, browser application-specific execution delays.
> > The PageSpeed Insights TTFB metric measures the total time up to the
> > point the first byte of data makes it to the client. So, PageSpeed
> > Insights TTFB is like this work’s TTFB/TLS handshake time with
> > additional network delays like DNS lookup, redirect, service worker
> > startup, and request time.*
> >
> > Specifically about the Web, TTLB (as defined in the paper) is directly
> > related to FCP, LCP, FID, INP, TBT, CLS, which are 6 of the 7 metrics
> > in Google’s PageSpeed Insights. We don’t want to declare that TTLB is
> > the ultimate metric, but intuitively, I think it is a better indicator
> > when it comes to application performance than TTFB.
> >
> > That does not intend to underestimate the importance of the studies on
> > handshake performance which was crucial to identify the best
> > performing new KEMs and signatures. It also does not intend to
> > underestimate the importance of slimming down PQ TLS 1.3 handshakes as
> much as possible.
> >
> > Side note about Rob’s point:
> > We have not collected QUIC TTLB data yet, but I want to say that the
> > paper’s TTLB experimental results could more or less be extended to
> > QUIC be subtracting one RTT. OK, I don’t have experimental
> > measurements to prove it yet. So I 

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Bas Westerbaan]

Back to the topic at hand. I think it'd very bad if we'd have a codepoint
for pure ML-KEM before we have a codepoint for an ML-KEM hybrid. Process
wise, I think that's up to the designated experts of the IANA registry.

Best,

 Bas


On Wed, Mar 6, 2024 at 3:16 AM Deirdre Connolly 
wrote:

> I have uploaded a preliminary version of ML-KEM for TLS 1.3
> 
> and have a more fleshed out
>  version to
> be uploaded when datatracker opens. It is a straightforward new
> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
> very similar style to -hybrid-design
> .
>
> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
> compatible) ready to go when users are ready to use them.
>
> Cheers,
> Deirdre
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Bas Westerbaan]

The cost of hybrids is not high, but it's certainly not negligible. I can't
share the exact number of servers we'd be able to cut if we'd go pure PQ,
but with a back of the envelope calculation I think you can convince
yourself that we could've at least hired an engineer instead. We think it's
worth it now, but of course we're not going to keep hybrids around when the
CRQC arrives.

Best,

 Bas

On Thu, Mar 7, 2024 at 1:56 AM Dennis Jackson  wrote:

> I'd like to understand the argument for why a transition back to single
> schemes would be desirable.
>
> Having hybrids be the new standard seems to be a nice win for security
> and pretty much negligible costs in terms of performance, complexity and
> bandwidth (over single PQ schemes).
>
> On 07/03/2024 00:31, Watson Ladd wrote:
> > On Wed, Mar 6, 2024, 10:48 AM Rob Sayre  wrote:
> >> On Wed, Mar 6, 2024 at 9:22 AM Eric Rescorla  wrote:
> >>>
> >>>
> >>> On Wed, Mar 6, 2024 at 8:49 AM Deirdre Connolly <
> durumcrustu...@gmail.com> wrote:
> > Can you say what the motivation is for being "fully post-quantum"
> rather than hybrid?
>  Sure: in the broad scope, hybrid introduces complexity in the
> short-term that we would like to move off of in the long-term - for TLS 1.3
> key agreement this is not the worst thing in the world and we can afford
> it, but hybrid is by design a hedge, and theoretically a temporary one.
> >>>
> >>> My view is that this is likely to be the *very* long term.
> >>
> >> Also, the ship has sailed somewhat, right? Like Google Chrome,
> Cloudflare, and Apple iMessage already have hybrids shipping (I'm sure
> there many more, those are just really popular examples). The installed
> base is already very big, and it will be around for a while, whatever the
> IETF decides to do.
> > People can drop support in browsers fairly easily especially for an
> > experimental codepoint. It's essential that this happen: if everything
> > we (in the communal sense) tried had to be supported in perpetuity, it
> > would be a recipe for trying nothing.
> >
> >> thanks,
> >> Rob
> >>
> >> ___
> >> TLS mailing list
> >> TLS@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tls
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
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]

>
> The arguments for multiple KEMs are
> stronger than the arguments for multiple combiners.
>

X-Wing is a KEM — not a combiner. I agree there should preferably be one
go-to generic combiner. Insisting that X-Wing use that generic combiner, is
not dissimilar to insisting that every KEM that uses an FO transform,
should use the same generic FO transform.

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?

[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] [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 th

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$
>  
> <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$
>  
> <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$
>  
> <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/202

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/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/__;!!FJ-Y8qCqXTj2!YuGyk3egE_PIU03oVixCUPtatL8PHtv4HwoB1vN5giqCIDkH6AQcs-lATDzPlozu91nN60pT2kp1AwmLESgzB4xc58lF-Y-JP2DY$>
> Proof: https://eprint.iacr.org/2024/0

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

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

[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
https://twitter.com/bwesterb/status/1734586155868287457
[4] https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/
[5] https://link.springer.com/chapter/10.1007/978-3-319-76578-5_7
[6] https://datatracker.ietf.org/doc/draft-westerbaan-cfrg-hpke-xyber768d00/
[7] https://datatracker.ietf.org/doc/draft-ounsworth-cfrg-kem-combiners/
[8] Following earlier deployment of X25519Kyber768, despite targeting 128
bits, we use ML-KEM-768 instead of ML-KEM-512 to hedge against advances in
lattice attacks.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

[Bas Westerbaan]

On Tue, Jan 2, 2024 at 3:30 PM Salz, Rich 
wrote:

> Those who can move to 1.3+, will do so, regardless of this draft. Those
> who can’t, would do whatever’s appropriate in their case – again,
> regardless of this draft.
>
>
>
> Same as for any other IETF document. :)
>
>
>
> One difference in the current wording is that it would become trivially
> more difficult to get a multi-vendor PQ solution for current TLS 1.2
> implementations.  Assuming, of course, that “just use what was defined for
> TLS 1.3 or later” somehow doesn’t occur to everyone.
>

It is more difficult than "just use what was defined for TLS 1.3 or later".
TLS 1.2 has a downgrade attack where a MitM can force a broken commonly
supported group even if the handshake signature is secure/PQ (CurveSwap).
TLS 1.3 fixed that. I do have to add that the scope (I can imagine now) is
limited: it affects clients that can disable classical authentication, but
cannot disable classical key agreement everywhere.

Best,

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

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Bas Westerbaan]

sgtm

On Wed, Dec 13, 2023 at 4:36 PM Russ Housley  wrote:

> Bas:
>
> Thanks.  I've adjusted the proposed text to address your comments:
>
>Implementations must use a ciphersuite that includes a symmetric
>encryption algorithm with sufficiently large keys.  For protection
>against the future invention of a CRQC, the symmetric key needs to be
>at least 128 bits.  While Grover’s algorithm (described in
>Section 7.1 of [I-D.ietf-pquip-pqc-engineers]) allows a quantum
>computer to perform a brute force key search using quadratically
>fewer steps than would be required with classical computers, there
>are a number of mitigating factors suggesting that Grover’s algorithm
>will not speed up brute force symmetric key search as dramatically as
>one might suspect.  First, quantum computing hardware will likely be
>more expensive to build and use than classical hardware.  Second, to
>obtain the full quadratic speedup, all the steps of Grover’s
>algorithm must be performed in series.  However, attacks on
>cryptography use massively parallel processing, the advantage of
>Grover’s algorithm will be smaller.
>
>Implementations must use sufficiently large external PSKs.  For
>protection against the future invention of a CRQC, the external PSK
>needs to be at least 128 bits.
>
> Russ
>
>
> On Dec 13, 2023, at 8:18 AM, Bas Westerbaan  wrote:
>
> I think there is a companion point to be made.  I suggest:
>>
>>Implementations must use a ciphersuite that includes a symmetric
>>encryption algorithm with sufficiently large keys.  For protection
>>against the future invention of a CRQC, the symmetric key needs to be
>>at least 256 bits.
>>
>
> Not true.128 bit symmetric keys are fine for PQ.
>
> Right, I think that means that ECH as-is can be used, but in the face
>> of a CRQC, ECH as-is won't protect against the leakage about which
>> John was concerned.
>
>
> Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's
> deployable, and whether its performance is acceptable, is something we
> should figure out.)
>
>  Best,
>
>  Bas
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Bas Westerbaan]

> By contrast the PQ version "just" has key size issues to worry about
> with the DNS advertising bits and maybe some structures that get
> tight.
>

I have the same intuition. Instead of guessing, we should plop Kyber in ECH
and see if it works.

If not then there are still other paths besides PSK — for instance using
BAT [1].

Best,

 Bas

[1] https://eprint.iacr.org/2022/031
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Bas Westerbaan]

>
> PS: I do not want us to hold up producing the ECH RFC while
> we figure that out - we should get the current thing out the
> door first!
>

Completely agree.

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

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Bas Westerbaan]

>
> I think there is a companion point to be made.  I suggest:
>
>Implementations must use a ciphersuite that includes a symmetric
>encryption algorithm with sufficiently large keys.  For protection
>against the future invention of a CRQC, the symmetric key needs to be
>at least 256 bits.
>

Not true.128 bit symmetric keys are fine for PQ.

Right, I think that means that ECH as-is can be used, but in the face
> of a CRQC, ECH as-is won't protect against the leakage about which
> John was concerned.


Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's
deployable, and whether its performance is acceptable, is something we
should figure out.)

 Best,

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Bas Westerbaan]

The draft itself is an exercise in clear communication, and mentioning PQC
explicitly fits with that.  Thus I agree with Rich to keep it.

Best,

 Bas

On Mon, Dec 11, 2023 at 6:18 PM Salz, Rich  wrote:

>
>- that is implied by a "feature freeze". No reason to highlight PQC
>(even though it is a hype topic right now).
>
> Yes, to both of these.  But I still think it should be explicitly called
> out.  If the WG thinks otherwise, then fine, the document is that much
> shorter :)
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Bas Westerbaan]

I support adoption, and am happy to review.

Best,

 Bas

On Wed, Dec 6, 2023 at 6:34 AM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TurboTLS: handshaking over UDP to remove 1 round trip

[Bas Westerbaan]

I would like to see examples of these use cases where using QUIC is
impossible, but using TurboTLS is.

Best,

 Bas

On Wed, Nov 15, 2023 at 6:37 PM David Joseph  wrote:

> Hi everyone,
>
> We wanted to speak about this draft on *TurboTLS* at 118 but didn't
> manage to squeeze into the packed session.
>
> Forwarding a new draft here that describes an idea for UDP handshaking in
> parallel to setting up the TCP stream, then switching back to TLS-over-TCP
> for the session portion. This enables *removing one round trip from all
> TLS versions* in the best case, and in the worst case scenario, falling
> back to TLS-over-TCP with an extremely small latency boost.
>
> TurboTLS doesn't change the contents of any TLS messages, only how some
> handshake messages are delivered over UDP instead of TCP. This technique
> supports *transparent proxying*, whereby standard TLS requests can be
> intercepted and turbo charged, by sitting one proxy in front of both client
> and server. First client requests are intercepted, translated to UDP,
> received by the server proxy, translated back to TCP, and sent back without
> client nor server being aware that their exchange has been turbo charged.
>
> Proxying enables legacy systems using all versions of TLS to obtain faster
> connection establishment without touching their network stack. TurboTLS has
> most potential *where migration to QUIC is not possible *in the near
> term due to legacy servers, or due to firewall visibility/deep packet
> inspection concerns, yet for systems which handle many short-lived TLS
> connections per second with non-trivial network latency.
>
> We managed to speak with a few of you privately about your thoughts on the
> benefits and drawbacks of this technique, and would like you to share any
> more opinions with us below so that we can understand whether it is worth
> developing this draft further.
>
> If this sounds like it might be useful to you/your use case, please get in
> touch!
>
> Kind regards,
> David
>
> -- Forwarded message -
> From: 
> Date: Sun, Nov 5, 2023 at 12:43 AM
> Subject: New Version Notification for draft-joseph-tls-turbotls-00.txt
> To: Carlos Aguilar-Melchor , David Joseph <
> d...@sandboxaq.com>, Douglas Stebila , Jason
> Goertzen 
>
>
> A new version of Internet-Draft draft-joseph-tls-turbotls-00.txt has been
> successfully submitted by Deirdre Connolly and posted to the
> IETF repository.
>
> Name: draft-joseph-tls-turbotls
> Revision: 00
> Title:TurboTLS for faster connection establishment
> Date: 2023-11-05
> Group:Individual Submission
> Pages:16
> URL:  https://www.ietf.org/archive/id/draft-joseph-tls-turbotls-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-joseph-tls-turbotls/
> HTML:
> https://www.ietf.org/archive/id/draft-joseph-tls-turbotls-00.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-joseph-tls-turbotls
>
>
> Abstract:
>
>This document provides a high level protocol description for
>handshaking over UDP in the Transport Layer Security (TLS) protocol
>(version independent).  In parallel, a TCP session is established,
>and once this is done, the TLS session reverts to TCP.  In the event
>that the UDP handshaking portion fails, TurboTLS falls back to TLS-
>over-TCP as is usually done, resulting in negligible latency cost in
>the case of failure.
>
>Discussion of this work is encouraged to happen on the TLS IETF
>mailing list tls@ietf.org or on the GitHub repository which contains
>the draft: https://github.com/PhDJsandboxaq/draft-ietf-turbotls-design
>
>
>
> The IETF Secretariat
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[Bas Westerbaan]

On Mon, Nov 6, 2023 at 7:06 PM Kris Kwiatkowski  wrote:

> So, based on FIPS 140-3 I.G., section C.K., resolution 5, [1]. "SP800-186
> does not impact the curves permitted under SP 800-56Arev3. Curves that are
> included in SP 800-186 but not included in SP 800-56Arev3 are not approved
> for key agreement. E.g., the ECDH X25519 and X448 key agreement schemes
> (defined in RFC 7748) that use Curve25519 and Curve448, respectively, are
> not compliant to SP 800-56Arev3…”. This may potentially be a problem, right?
>

SP 800-56Crev2 allows a hybrid mode Z' := Z || T (§2, page 2). "Z" would be
ML-KEM and "T" X25519. That means we have to put ML-KEM first (instead of
X25519 now.)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[Bas Westerbaan]

On Mon, Nov 6, 2023 at 5:40 PM Kampanakis, Panos  wrote:

> > Concretely, after ML-KEM is finished, I was planning to update
> draft-schwabe-cfrg-kyber to match it, and proposing to register a codepoint
> for a single ML-KEM-768 hybrid in draft-ietf-tls-hybrid-design.
>
>
>
> Agreed, but I would suggest three (x25519-mlkem768, p256-mlkem768,
> p384-mlkem1024) to cover FIPS and CNSA 2.0 compliance. More than three
> combinations is unnecessary imo.
>

x25519-mlkem768 will be FIPS thanks to mlkem768. Have you seen x25519 is in
SP 800-186 now? So I say we can leave out p256-mlkem768.

Best,

 Bas

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

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[Bas Westerbaan]

> (3)-(5) are exactly the hard problems I’ve been thinking a lot about
> lately.  I’d actually be tempted to say that AuthKEM vs signatures is
> something we should figure out ASAP.  I read AuthKEM again this morning,
> and it has a lot of attractive features, but I’m not quite sure what the
> right answer is yet.
>

I don't think we can settle the future of PQ authentication in TLS just yet
— there are still many unknowns. To name a few:

1. What signature schemes are on the horizon? MAYO [1] from the NIST
signatures on-ramp would be great, if it doesn't turn out to be broken.

2. How will the confidence in existing schemes develop? AuthKEM will look
different depending on whether it can use Kyber-512 or Kyber-1024. Also,
will it replace Dilithium5 or Dilithium2?

3. What other higher level changes is the ecosystem able to adopt? For
instance Merkle Tree Certs [2].

These are all hard questions, and although I do not believe we can answer
them now, we should be thinking about them right now. I think we should
have different pots on the fire, so to say.

Best,

 Bas

[1] https://pqmayo.org/params-times/
[2] https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[Bas Westerbaan]

Thanks for bringing this up. There are a bunch of (implicit) questions in
your e-mail.

1. Do we want rfc describing the final NIST standards? And for which? I'm
ok with that — in this order of priority: ml-kem, ml-dsa, slh-dsa.

2. For which algorithms do we want to assign codepoints once the NIST
standards are out? Codepoints are cheap and use cases/rules are different,
but especially with the hybrids, I'd encourage us to try to be disciplined
and keep the list as short as we can for now, so that early adopters for
which it doesn't matter, all choose the same thing. The DNS mechanism
of draft-davidben-tls-key-share-prediction helps on the performance side,
but it doesn't solve the duplicate engineering/validation if there are a
dozen essentially equivalent KEMs.

3. Do we want to standardise non-hybrid KEMs for TLS? I don't care for them
yet, but others might.

4. Do we need hybrid signatures for the TLS handshake? I don't see the use,
but could be convinced otherwise.

5. What is the future of AuthKEM? That's definitely a different e-mail
thread.

Concretely, after ML-KEM is finished, I was planning to update
draft-schwabe-cfrg-kyber to match it, and proposing to register a codepoint
for a single ML-KEM-768 hybrid in draft-ietf-tls-hybrid-design.

Best,

 Bas


On Mon, Nov 6, 2023 at 10:10 AM John Mattsson  wrote:

> Hi,
>
>
> NIST has released draft standards for ML-KEM, ML-DSA, and ML-SLH. Final
> standards are expected in Q1 2024.
>
>
> https://csrc.nist.gov/news/2023/three-draft-fips-for-post-quantum-cryptography
>
>
>
> I would like to have standard track TLS (and DTLS, QUIC) RFCs for ML-KEM
> and ML-DSA (all security levels standardized by NIST) as soon as possible
> after the final NIST standards are ready. 3GPP is relying almost
> exclusively on IETF RFCs for uses of public key cryptography (the exception
> is ECIES for IMSI encryption but that will likely use HPKE with ML-KEM in
> the future).
>
>
>
> Looking at the TLS document list, it seems severely lacking when it comes
> to ML-KEM, ML-DSA…
>
>
>
> The adopted draft-ietf-tls-hybrid-design is an informal draft dealing with
> the pre-standard Kyber.
>
> https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>
> AuthKEM is a quite big change to TLS
>
> https://datatracker.ietf.org/doc/draft-wiggers-tls-authkem-psk/
>
>
>
> This is not adopted, informal, and dealing with the pre-standard Kyber.
>
> https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-kyber/
>
>
>
> What is the TLS WG plan for quantum-resistant algorithms? My current view
> is that I would like ML-KEM-512, ML-KEM-768, ML-KEM-1024, ML-DSA-44,
> ML-DSA-65, and ML-DSA-87 registered asap. For hybrid key exchange I think
> X25519 and X448 are the only options that make sense. For hybrid signing,
> ECDSA, EdDSA, and RSA could all make sense.
>
>
>
> Cheers,
> John
>
>
>
> *From: *TLS  on behalf of internet-dra...@ietf.org <
> internet-dra...@ietf.org>
> *Date: *Friday, 8 September 2023 at 02:48
> *To: *i-d-annou...@ietf.org 
> *Cc: *tls@ietf.org 
> *Subject: *[TLS] I-D Action: draft-ietf-tls-hybrid-design-09.txt
>
> Internet-Draft draft-ietf-tls-hybrid-design-09.txt is now available. It is
> a
> work item of the Transport Layer Security (TLS) WG of the IETF.
>
>Title:   Hybrid key exchange in TLS 1.3
>Authors: Douglas Stebila
> Scott Fluhrer
> Shay Gueron
>Name:draft-ietf-tls-hybrid-design-09.txt
>Pages:   23
>Dates:   2023-09-07
>
> Abstract:
>
>Hybrid key exchange refers to using multiple key exchange algorithms
>simultaneously and combining the result with the goal of providing
>security even if all but one of the component algorithms is broken.
>It is motivated by transition to post-quantum cryptography.  This
>document provides a construction for hybrid key exchange in the
>Transport Layer Security (TLS) protocol version 1.3.
>
>Discussion of this work is encouraged to happen on the TLS IETF
>mailing list tls@ietf.org or on the GitHub repository which contains
>the draft:
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-c404f4af2592f2f4=1=367fabf2-370b-4cec-b657-05a8499decf6=https%3A%2F%2Fgithub.com%2Fdstebila%2Fdraft-ietf-tls-hybrid-design
> .
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-09.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-hybrid-design-09
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> 

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Bas Westerbaan]

> But if we can at least make it secure, that gives us a bit more breathing
> room in case anyone needs it.
>

For those who missed it: we need it for Edge -> Origin connections, as some
origins do break on split ClientHello. (See e-mail sept 29th.)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Bas Westerbaan]

>
> OK, I see. It's worse than a compatibility risk, though, isn't it? If you
> just let them break in case (a), and then maybe try again with (b), that
> opens up a downgrade attack. Intermediaries can observe the size of the
> Client Hello and make it break
>

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

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Bas Westerbaan]

> If the client is happy with either X25519 alone or X25519Kyber768, why not
> send shares for both in the first ClientHello?
>

This is what Chrome does, and what we do if the user opts for "preferred"
mode. [1]

Would be good if draft-tls-westerbaan-xyber768d00 either mentions this as a
> blessed implementation choice, or conversely disrecommends it and explains
> why.
>

Ah, you mean using the same X25519 key in both the X25519 and Xyber
keyshare? We do not use that optimisation, but I do not see anything wrong
with it from a protocol perspective. I would not want to encourage it, as
it complicates code to generate keyshares as it crosses abstraction layers.

Best,

 Bas

[1] The issue is, as I described in my previous e-mail, that a small
fraction of origins breaks on a large ClientHello. Whether we send X25519
along with X25519Kyber768 in the CH doesn't make a difference. It does
prevent issues with origins that have broken HRR, and do not support Kyber.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Bas Westerbaan]

This is a useful and very timely draft — I would like to see it adopted.

I'll argue it's more urgent than sketched by David.

We have been investigating turning on post-quantum key agreement for
connections from Cloudflare to origin servers. In testing, we found that
0.34% of origins will fail to establish a connection if we send
X25519Kyber768Draft00 keyshare directly (while still advertising support
for classical keyshares.)  As expected, a significant portion of failures
seem to be caused by the large ClientHello. Interestingly though, the
majority of these failures don't seem to be specific to the size of the
ClientHello, but are rather caused by the origin not supporting
HelloRetryRequest correctly. We're still digging into it, and will share
our findings later on.

Anyway, even though it's a small fraction of origins, we cannot send a PQ
keyshare immediately and completely break the websites in front of those
few origins. Instead, we are going [1] for the following approach: we send
a X25519 keyshare, but advertise support for Xyber. A server that supports
Xyber can then use HelloRetryRequest for a post-quantum connection.
Undoubtedly due to GREASE (thanks David), we did not see any issues with
this approach. [2]

This comes at the cost of an extra roundtrip. To get rid of it, we're
scanning key agreement support of origins, and in the future will send
Xyber immediately if we see the origin supports it without failing.

Now we come to the usefulness of this draft: without it we cannot guarantee
that we will negotiate PQ even if both the client and server are configured
to prefer it. The problem is that many TLS servers are content with a
supported keyshare, and will not HRR even if a more preferred key agreement
is available. Indeed: a MitM can break our PQ test connections, which will
make us send X25519, while advertising support for Xyber. Despite
advertising support for Xyber, many TLS servers will now be content with
X25519.

Best,

 Bas

[1] https://blog.cloudflare.com/post-quantum-to-origins/
[2] Of course, when a server that can't handle large ClientHello or HRR
adds Xyber, it will still need to fix those issues, but importantly they
don't block the rest anymore.

PS. We have also included some stats on classical key agreement support and
preference of origins in [1].




On Tue, Sep 26, 2023 at 6:46 PM David Benjamin 
wrote:

> Hi all,
>
> A while back, we discussed using a DNS hint to predict key shares and
> reduce HelloRetryRequest, but this was dropped due to downgrade issues. In
> thinking through post-quantum KEMs and the various transitions we'll have
> in the future, I realized we actually need to address those downgrade
> issues now. I've published a draft below which is my attempt at resolving
> this.
>
> We don't need a DNS hint for the *current* PQ transition—most TLS
> ecosystems should stick to the one preferred option, and then clients can
> predict that one and move on. However, I think we need to lay the
> groundwork for it now. If today's round of PQ supported groups cannot be
> marked "prediction-safe" (see document for what I mean by that),
> transitioning to the *next* PQ KEM (e.g. if someone someday comes up with
> a smaller one that we're still confident in!) will be extremely difficult
> without introducing downgrades.
>
> Thoughts?
>
> David
>
> -- Forwarded message -
> From: 
> Date: Mon, Sep 25, 2023 at 6:56 PM
> Subject: New Version Notification for
> draft-davidben-tls-key-share-prediction-00.txt
> To: David Benjamin 
>
>
> A new version of Internet-Draft
> draft-davidben-tls-key-share-prediction-00.txt
> has been successfully submitted by David Benjamin and posted to the
> IETF repository.
>
> Name: draft-davidben-tls-key-share-prediction
> Revision: 00
> Title:TLS Key Share Prediction
> Date: 2023-09-25
> Group:Individual Submission
> Pages:11
> URL:
> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/
> HTML:
> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-davidben-tls-key-share-prediction
>
>
> Abstract:
>
>This document clarifies an ambiguity in the TLS 1.3 key share
>selection, to avoid a downgrade when server assumptions do not match
>client behavior.  It additionally defines a mechanism for servers to
>communicate key share preferences in DNS.  Clients may use this
>information to reduce TLS handshake round-trips.
>
>
>
> The IETF Secretariat
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Bas Westerbaan]

>
> If you are going to do this, you might as well go the whole hog and
> provide a mechanism that allows the client to say if it already has a cert
> on file for that particular host, e.g. by means of a digest.
>

If clients cache intermediates as they go, then reporting that list to a
server is an obvious privacy issue. When you restrict to a fixed set,
updated in unison, we essentially return to reach Dennis' proposal.

Best,

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

Re: [TLS] Adoption call for draft-jackson-tls-cert-abridge

[Bas Westerbaan]

I support adoption and am willing to review.

On Tue, 1 Aug 2023 at 21:36, Christopher Wood  wrote:

> Hi all,
>
> Based on positive feedback received during IETF 117, this email begins an
> adoption call for "Abridged Compression for WebPKI Certificates"
> (draft-jackson-tls-cert-abridge).
>
> The datatracker page for this document can be found here:
> https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/
>
> And the GitHub repository can be found here:
> https://github.com/dennisjackson/draft-jackson-tls-cert-abridge
>
> Please indicate whether or not your support adoption of this document in
> its current state. Procedure questions raised during the WG meeting last
> week can be ironed out in the event of this item being adopted.
>
> This call for adoption will conclude on August 16.
>
> Thanks,
> Chris, for the chairs
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression

[Bas Westerbaan]

>
> On Wed, Jul 12, 2023, 11:31 AM Tim Hollebeek  40digicert@dmarc.ietf.org> wrote:
>
>> SCTs have always seemed surprisingly large to me, and it has always seemed
>> like there should be a more compact representation that has the same
>> security
>> properties, but I've never found the time to look more closely at it.  If
>> someone
>> does have the time, figuring out how to reduce the size of SCTs would be
>> quite
>> helpful.
>>
>
> I've always said SQI-Sign for this.
>

The 40ms verification time per SCT makes it a non-starter.

Best,

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

Re: [TLS] [Pqc] Post-Quantum TLS instantiations and synthetic benchmarks

[Bas Westerbaan]

Thanks for preparing the excerpt; this will be helpful for many use cases.
(For the WebPKI, as you already mention, we also need to consider SCTs and
realistically crappy networks.)

 "this is LTE in a city", and "this is what a poor-quality rural 3G link
> looks like". But alas, these don't seem to exist either.
>

Unfortunately, it will not be as simple as plugging in a single packet loss
number and then dropping that fraction of packets. Because TCP interpets
packet loss as congestion, it grinds down to a halt much earlier than at a
loss of 2%. Instead, lossy links such as WiFi and cellular have their own
retransmission protocols hidden from TCP.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] CRYSTALS Kyber and TLS

[Bas Westerbaan]

I do have to add to Thom's remarks that KEMTLS (a.k.a. AuthKEM) offers an
advantage here. If the private key of the leaf cert is not compromised (for
instance when it was generated elsewhere), then the attacker Stephan
describes cannot learn the shared secret.


On Mon, Jun 19, 2023 at 5:02 PM Thom Wiggers  wrote:

> Hi all,
>
> The attack that is described by Stephan is something that we considered
> while we were initially designing KEMTLS (in the papers, we also covered
> the ephemeral key exchange). I'll quickly write what we were thinking of
> and why we did not choose to do anything similar to what Stephan proposes.
>
> I will be correcting for the misunderstanding in the document put forward
> by Stephan, which suggests that Kyber is an asymmetric encryption scheme.
> Encapsulation and Decapsulation should not be confused with encryption and
> decryption, which are not part of the public API of Kyber and will not be
> part of the NIST standard as far as I'm aware.
>
> I believe we can summarize the argument as follows: in the straightforward
> replacement of ECDH by a KEM, the client generates a keypair and the server
> (through the encapsulate operation) computes a shared secret and a
> ciphertext. If either the secret key or the shared secret are made public,
> for example, due to an implementation flaw of either keygen or
> encapsulation, then the ephemeral handshake key is no longer secret.
>
> Bas correctly points out that this is not different from ECDH, where
> compromise of one of the two exponents leads to shared secret computation,
> but that in itself shouldn't necessarily be a reason not to investigate if
> we can do better.
>
> But, in my view, the proposed defense and the argument put forward assumes
> that the flaw that affects encapsulation does not affect the key generation
> (or vice versa); in particular, in the scenario of the broken server-side
> random number generator it seems far-fetched that the busted random number
> generator or implementation flaw affecting encapsulation won't *also*
> affect the keygen (or in other scenarios such as side-channel
> vulnerabilities, decapsulate) operation of the server. This, in my view,
> makes the additional security offered by the additional key exchange very
> marginal.
>
> The reason why we were investigating this issue was a bit different:
> having two KEM key exchanges gives the server more control to ensure that
> there will be at least one freshly-generated KEM keypair in the mix. This
> could improve the forward secrecy for handshakes (modeled via secret key
> exposure) in which the client just re-uses the ephemeral keypair every
> single time. But we also saw this as not significant enough to suffer the
> additional, significant transmission requirement of another full Kyber key
> exchange. Hopefully, we now have enough experience with evaluating
> implementations of TLS to find and fix these sorts of key-reuse flaws more
> easily, earlier, and in automated ways [1]. And again, this is the same
> situation with ECDH today.
>
> Cheers,
>
> Thom Wiggers
> PQShield
>
> [1] see e.g. https://github.com/tls-attacker/TLS-Scanner. Relying on
> implementers not to make mistakes is a dangerous game, but I do believe
> that it needs to factor into the cost/benefit analysis.
>
> PS: for marketing reasons I oppose comparisons between the post-quantum
> KEM schemes (which are primitives that easily can be used in fully
> ephemeral ways) and RSA key wrapping (which pretty much exclusively refers
> to the much-derided non-forward-secure RSA transport in TLS-old). ;-)
>
> Op ma 19 jun 2023 om 16:01 schreef Stephan Mueller :
>
>> Am Montag, 19. Juni 2023, 15:56:57 CEST schrieb Scott Fluhrer (sfluhrer):
>>
>> Hi Scott,
>>
>> > I do not believe that Müller is correct - we do not intend use the
>> Kyber CPA
>> > public key encryption interface, but instead the Kyber CCA KEM
>> interface.
>> > And, with that interface, the server does contribute to the shared
>> secret:
>> >
>> > The shared secret that Kyber KEM (round 3) generates on success is:
>> >
>> > KDF( G( m || H(pk)) || H(c) )
>> >
>> > where:
>> >   - m is the hash of a value that the server selects
>> >   - pk is the public key selected by the client
>> >   - c is the server's keyshare
>> >   - H is SHA3-256, G is SHA3-512, KDF - SHAKE-256
>> > Note that this formula includes a value (pk) that is selected solely by
>> the
>> > client; hence we cannot say that this value contains only values
>> selected
>> > by the server. (reference: algorithms 8, 9 of the round 3 Kyber
>> submission)
>>
>> My concern is that the security strength cannot depend on the pk, because
>> the
>> PK is sent in clear over the wire. Thus it cannot contain entropy. Thus,
>> entropy only comes from the message m in your listing which is a random
>> number
>> that is generated by the server. Further, c depends on m and thus does
>> not add
>> any entropy either.
>>
>> Ciao
>> Stephan
>>
>>
>> 

Re: [TLS] CRYSTALS Kyber and TLS

[Bas Westerbaan]

Hi Stephan,

>From your e-mail it's unclear which attack you worry about, but in the
attached document, you describe the problem unique to the implementation of
Kyber in TLS as:

If the random number generated
> for the encryption operation is weak, an attacker may sniff the pk sent
> over the wire and “guess” the random number to obtain the shared secret ss.


This is not unique to Kyber. If an attacker can successfully guess server
randomness, then they can guess the private key of the server's ephemeral
ECDH keypair (checking against the server keyshare), and compute the shared
secret as well.

Adding an extra ephemeral server KEM keypair to which the client
encapsulates doesn't change the situation: the attacker you describe can
still guess the KEM private key, and then decrypt the extra shared secret.

Best,

 Bas

On Mon, Jun 19, 2023 at 10:24 AM Stephan Müller  wrote:

> Hi,
>
> Post-quantum computing cryptographic algorithms are designed and available
> for
> use. Considering that the Kyber algorithm is going to be mandated by US
> authorities in the future as a complete replacement for asymmetric key
> exchange and agreement, a proposal integrating Kyber into TLS is specified
> with [1].
>
> This proposal, however, has one central shortcoming: only the TLS server
> contributes to the security strength of the shared secret generated by
> Kyber.
> This shortcoming can be solved with a slightly improved approach where the
> client and the server both independent of each other contribute to the
> security of the communication channel where the channel even retains its
> security when one side has insufficient entropy.
>
> The entire analysis and the suggested proposal to address the outlined
> issue
> is provided with [2]. I would like to share this proposal to contribute to
> the
> discussion how Kyber can be applied to TLS.
>
> [1] https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-06.txt
>
> [2] http://www.chronox.de/papers/TLS_and_Kyber_analysis.pdf
>
> Ciao
> Stephan
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Merkle Tree Certificates

[Bas Westerbaan]

>
> I mean, is there a cryptographic reason for it?


No.


> (However, absent cryptographic reasons, this all is way premature.)
>

Indeed. We like to have a concrete proposal, but thinking through these
details is premature at this point.

[snip] What that in effect does
> is to make it much more difficult to exploit chosen-prefix collisions in
> hash function.



However, that requirement holds irrespective of the hash function used,

and it has in fact been held for SHA-256 (regardless of there not being
> any known even remotely feasible attacks) instead of just being a dead
> letter from the past with much worse hash functions.
>

Ah, it would indeed be neat if we could design this, so that we do not
require (chosen prefix) collision resistance of the hash. I'd say it's nice
to have, but not a must. Tracking in
https://github.com/davidben/merkle-tree-certs/issues/45

Best,

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

Re: [TLS] Merkle Tree Certificates

[Bas Westerbaan]

> > Thanks! That’s indeed inconsistent, we’ll fix it.
> > https://github.com/davidben/merkle-tree-certs/issues/32
>
> Hmm... Looking at that construct, why is the pad there?


We pad to the hash block size. When computing the full Merkle tree, or
verifying an authentication path, the values before the pad are the same,
and thus we can precompute the hash state after digesting those fixed
values.

(With the current inputs and sha256, it will only make a difference for
HashAssertion though.)


> And there does not seem to be any way to salt the hash. WebPKI requires
> what effectively amounts to salting the hash via serial number (even
> for SHA-256).
>

Please elaborate.

Best,

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

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Bas Westerbaan]

Hi Panos,

No, for the final version of Kyber we'd need a different code point. (And
that one will presumably be defined in Douglas' hybrid I-D.)

The raison d'être of draft-schwabe-cfrg-kyber-02 and
draft-westerbaan-tls-xyber768d00 is to have a stable reference for this
preliminary version of Kyber.

Best,

 Bas

On Thu, May 11, 2023 at 4:17 PM Kampanakis, Panos  wrote:

> Great!
>
> So to clarify, when Kyber gets ratified as MLWE_KEM or something like
> that, will we still be using 0x6399 in the keyshare when we are
> negotiating? Or is  0x6399 just a temporary codepoint for Kyber768 Round 3
> combined with X25519?
>
>
>
>
>
> *From:* TLS  *On Behalf Of * Bas Westerbaan
> *Sent:* Wednesday, May 10, 2023 3:09 PM
> *To:* Christopher Wood 
> *Cc:* tls@ietf.org
> *Subject:* RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for
> draft-ietf-tls-hybrid-design
>
>
>
> *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.
>
>
>
> FYI IANA has added the following entry to the TLS Supported Groups
> registry:
>
>
> Value: 25497
> Description: X25519Kyber768Draft00
> DTLS-OK: Y
> Recommended: N
> Reference: [draft-tls-westerbaan-xyber768d00-02]
> Comment: Pre-standards version of Kyber768
>
> Please see
> https://www.iana.org/assignments/tls-parameters
>
>
>
> On Mon, May 1, 2023 at 11:59 AM Christopher Wood 
> wrote:
>
> It looks like we have consensus for this strategy. We’ll work to remove
> codepoints from draft-ietf-tls-hybrid-design and then get experimental
> codepoints allocated based on draft-tls-westerbaan-xyber768d00.
>
> Best,
> Chris, for the chairs
>
> > On Mar 28, 2023, at 9:49 PM, Christopher Wood 
> wrote:
> >
> > As discussed during yesterday's meeting, we would like to assess
> consensus for moving draft-ietf-tls-hybrid-design forward with the
> following strategy for allocating codepoints we can use in deployments.
> >
> > 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this
> document through the process towards publication.
> > 2. Write a simple -00 draft that specifies the target variant of
> X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully
> did this for us already [1].) Once this is complete, request a codepoint
> from IANA using the standard procedure.
> >
> > The intent of this proposal is to get us a codepoint that we can deploy
> today without putting a "draft codepoint" in an eventual RFC.
> >
> > Please let us know if you support this proposal by April 18, 2023.
> Assuming there is rough consensus, we will move forward with this proposal.
> >
> > Best,
> > Chris, Joe, and Sean
> >
> > [1]
> https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Bas Westerbaan]

FYI IANA has added the following entry to the TLS Supported Groups registry:

Value: 25497
Description: X25519Kyber768Draft00
DTLS-OK: Y
Recommended: N
Reference: [draft-tls-westerbaan-xyber768d00-02]
Comment: Pre-standards version of Kyber768

Please see
https://www.iana.org/assignments/tls-parameters

On Mon, May 1, 2023 at 11:59 AM Christopher Wood 
wrote:

> It looks like we have consensus for this strategy. We’ll work to remove
> codepoints from draft-ietf-tls-hybrid-design and then get experimental
> codepoints allocated based on draft-tls-westerbaan-xyber768d00.
>
> Best,
> Chris, for the chairs
>
> > On Mar 28, 2023, at 9:49 PM, Christopher Wood 
> wrote:
> >
> > As discussed during yesterday's meeting, we would like to assess
> consensus for moving draft-ietf-tls-hybrid-design forward with the
> following strategy for allocating codepoints we can use in deployments.
> >
> > 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this
> document through the process towards publication.
> > 2. Write a simple -00 draft that specifies the target variant of
> X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully
> did this for us already [1].) Once this is complete, request a codepoint
> from IANA using the standard procedure.
> >
> > The intent of this proposal is to get us a codepoint that we can deploy
> today without putting a "draft codepoint" in an eventual RFC.
> >
> > Please let us know if you support this proposal by April 18, 2023.
> Assuming there is rough consensus, we will move forward with this proposal.
> >
> > Best,
> > Chris, Joe, and Sean
> >
> > [1]
> https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Bas Westerbaan]

Regarding additional key agreements.

For the (public) web it would be best if we can agree on a default key
agreement. If one half uses P-256+Kyber768 and the other X25519+Kyber768,
then clients will either HRR half the time or need to send both. Neither
are ideal.

Obviously this point is moot for internal networks. So I do not
oppose specifying additional preliminary key agreements, but I do not like
to actively support it. What about specifying further preliminary key
agreements in yet again a separate draft?

Best,

 Bas

On Sat, Apr 1, 2023 at 1:56 AM Bas Westerbaan  wrote:

> The draft draft-tls-westerbaan-xyber768d00-00 references
>> draft-cfrg-schwabe-kyber-01, which has a number of annoying mistakes,
>> since fixed in editor's copy.
>>
>> And then, the correct reference for X25519 is probably RFC7748 instead
>> of RFC8037...
>>
>>
>> Really quick and dirty way to fix this would be to publish editor's
>> copy as draft-cfrg-schwabe-kyber-02 (or if CFRG adapts quickly, the
>> RG-00), and then publish draft-tls-westerbaan-xyber768d00-01, fixing
>> the references.
>>
>
> Thanks, done. Posted -02 of both the Kyber and Xyber drafts.
>
> Best,
>
>  Bas
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Bas Westerbaan]

>
> The draft draft-tls-westerbaan-xyber768d00-00 references
> draft-cfrg-schwabe-kyber-01, which has a number of annoying mistakes,
> since fixed in editor's copy.
>
> And then, the correct reference for X25519 is probably RFC7748 instead
> of RFC8037...
>
>
> Really quick and dirty way to fix this would be to publish editor's
> copy as draft-cfrg-schwabe-kyber-02 (or if CFRG adapts quickly, the
> RG-00), and then publish draft-tls-westerbaan-xyber768d00-01, fixing
> the references.
>

Thanks, done. Posted -02 of both the Kyber and Xyber drafts.

Best,

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

Re: [TLS] Merkle Tree Certificates

[Bas Westerbaan]

>
> Unpopular pages are much more likely to deploy a solution that doesn't
> require
> a parallel CA infrastructure and a cryptographer on staff.
>

CAs, TLS libraries, certbot, and browsers would need to make changes, but I
think we can deploy this without webservers or relying parties having to
make any changes if they're already using an ACME client except upgrading
their dependencies, which they would need to do anyway to get plain X.509
PQ certs.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] How are we planning to deprecate TLS 1.2?

[Bas Westerbaan]

>
> And of course, we really
> don't want to have to do major work on TLS 1.2, e.g. for Post-Quantum.
>

More to the point, I'd say the post-quantum transition is the natural
moment to move from ≤1.2 to 1.3.

(TLS 1.2 and earlier are vulnerable to PQ -> classical downgrades during
the transition because of CurveSwap like attacks.)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Bas Westerbaan]

>
> I don't see this as different to the current spam potential with CT logs
> right now - anyone could distribute out the creation of a bunch certificate
> requests with the likes of Let's Encrypt and submit a bunch of certificate
> chains to CT logs.


Let's Encrypt (and other free CAs) have tight rate limits [1], which would
be unreasonably tight for all applications. There is an escape hatch: if
the rate limit is a problem, you can just buy a certificate with some other
CA.

Best,

 Bas


[1] https://letsencrypt.org/docs/rate-limits/

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

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Bas Westerbaan]

I don't see how your proposal prevents spam. With your proposal as is,
nothing stops me from adding trillions of self-signed certificates to the
CT logs.

Best,

 Bas

On Wed, Nov 30, 2022 at 8:55 PM Ollie 
wrote:

> Hi Bas,
>
> Good question - my suggestion is for CT logs to check for the DANE records
> as explained in this git repo:
> https://github.com/OllieJC/justselfsigned.org
> Here's a copy:
>
> Unfortunately, existing CT logs do not support SSCs (self-signed
> certificates) due to spam concerns (rfc6962). The suggestion (being raised
> in rfc9162) is for CT logs to check for full DNSSEC compliance and TLSA
> records when generating a CT log entry for SSCs, which would work in the
> following way:
>
> 1. a new SSPC (Self-Signed Pre-Certificate) is generated with the
> following:
> - only valid domains
> - less than 90-day expiry (although this may start in the future)
> 2. the SSPC signature is added to tlsa._dane TLSA record for every domain
> 3. SSPC is submitted to a CT log
> 4. CT log checks for valid domains and associated TLSA signatures and
> issues an SCT (Signed Certificate Timestamp)
> 5. SSC (Self-Signed Certificates) is generated from the SSPC to include
> the SCT
> 6. SSC signature is added to TLSA records (likely replacing the
> pre-certificate signature)
> 7. SSC is submitted to the CT log
> 8. CT log checks for valid domains, associated TLSA records and a valid SCT
>
> Thanks,
> Ollie
>
>
>  Original Message 
> On 29 Nov 2022, 00:04, Bas Westerbaan < bas=
> 40cloudflare@dmarc.ietf.org> wrote:
>
>
> In essence, I'm proposing that user agents should trust a fully DNSSEC
>> domain with a TLS certificate set up using DANE, along with changes to CT
>> log submission process to allow self-signed certificates (looking to
>> suggest via rfc9162).
>>
>
> How do you propose we prevent CT from being DoSed by a deluge of
> self-signed certificates?
>
> Best,
>
>  Bas
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Bas Westerbaan]

>
> On the other hand, the actual certificates are not what one
> would want to log anyway.  Instead one would only want to log DS RRsets
> or NODATA proofs from eTLD registries (gTLDs, ccTLDs and also various
> 2LD, 3LD, ...  suffixes operated by TLD registries).


This is the case if you run your own authoritative DNS server. Most do not.
So you'd want transparency on the TLSA records as well.

Similar spamming would be possible by
> obtaining certificates from many CAs and rolling them over as frequently
> as possible.
>

CAs have quite strict rate-limits in place for free certificate issuance,
so it's not a problem.

Best,

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

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

[Bas Westerbaan]

>
> In essence, I'm proposing that user agents should trust a fully DNSSEC
> domain with a TLS certificate set up using DANE, along with changes to CT
> log submission process to allow self-signed certificates (looking to
> suggest via rfc9162).
>

How do you propose we prevent CT from being DoSed by a deluge of
self-signed certificates?

Best,

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

Re: [TLS] HRR delenda est (was Re: Published RFC 8446bis -05)

[Bas Westerbaan]

>
> OK, that's more than I expected, although I kind of wonder what
> combinations are doing this.
>

It varies a bit over time, but today most were caused by a certain client
sending a P-384 keyshare while also announcing support for P-256.

 On the other hand, most clients today send x25519 key share
> by default, which seems to be the weakest supported group in TLS 1.3.


I'd say that title goes to ffdhe2048.

Best,

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

Re: [TLS] HRR delenda est (was Re: Published RFC 8446bis -05)

[Bas Westerbaan]

On Tue, Oct 25, 2022 at 6:30 AM Rob Sayre  wrote:

> I don't think anyone actually uses it,
>

1% of Cloudflare's TLS 1.3 handshakes today used an HRR.

I hope a de facto PQ kex will emerge — the old strategy of just sending
multiple keyshares is more expensive with large PQ public keys (~1kB). We
probably will need to complicate how the server picks the keyshare [1]

By the way, forcing an HRR by not sending any keyshares might be a useful
workaround if it turns out large initial ClientHello's are problematic for,
say, QUIC load balancers.

For those reasons I think it's a bit early to consider retiring HRR.

Best,

 Bas


[1] https://mailarchive.ietf.org/arch/msg/tls/pmJMSyf1-PGlLwcgF_jtEYKxQ-g/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Bas Westerbaan]

For TLS on the Web it would be ideal if we can find a single[1] hybrid
which we can all be happy with because that will make keyshare negotiation
easier.

To wit, BoringSSL, when SSL_OP_CIPHER_SERVER_PREFERENCE is set, will pick
the group based on the supported_groups that the client sends.

Thus, in this case if the server prefers X25519 over P-256, and a client
sends a P-256 keyshare but also advertises support for X25519, the server
will send an HRR to get an X25519 agreement.

In practice this is not a problem, because X25519 has become the de facto
standard. Before that was the case, many clients sent both a P-256 and
X25519 keyshare.

The PQ hybrid situation is more painful. Suppose we end up with two
essentially equivalent hybrids, say P-256+Kyber768 and X25519+Kyber768, and
different servers have a different preference. Then clients are forced to
either send both keyshares or suffer an HRR.

Of course, we can change the server logic, but it isn't simple.

An OpenSSL server, for instance, with SSL_OP_CIPHER_SERVER_PREFERENCE set,
will accept a keyshare it supports even if the client announces support for
another group that the server prefers.

This has a disadvantage[2]: if a client sends a X25519 keyshare but
announces support for a PQ keyshare, we would want the server to HRR to
establish a PQ connection (as BoringSSL will do if the PQ groups are
preferred.)

Best,

 Bas

[1] That shouldn't prevent us from assigning code points for many hybrids.
[2] Thanks to David Benjamin for pointing that out to me.


On Tue, Aug 23, 2022 at 10:30 AM Kris Kwiatkowski 
wrote:

>
> On 23/08/2022 01:39, Martin Thomson wrote:
>
> On Tue, Aug 23, 2022, at 00:11, Kris Kwiatkowski wrote:
>
> As X25519 is not FIPS-approved, the lab won't be able to test it,
>
> OK, hypothetical question, but maybe an important one.
>
> Why would a certification lab care?  We compose secrets with non-secrets all 
> the time, so even if X25519 were replaced with a public value, as long as 
> Kyber is approved, can they not proceed to certify on the basis of the 
> strength of the Kyber algorithm and its implementation?
>
> FIPS lab won't care, as I've mentioned Kyber+x25519 can be certified when 
> Kyber is FIPS-approved. The customers may
> care. As FIPS developer, I would like to be able to provide hybrid 
> construction in which both algorithms are FIPS
> approved, so that in case Kyber gets broken, the key exchange is still is 
> safe (as per FIPS standards), rather then
> Kyber gets broken and now you are not FIPS compliant.
> Makes sense?
>
> Or, more realistically, maybe the composition method can be approved, just as 
> composing a secret with "chickenchickenchicken" can be rendered safe.  That 
> way, composing with an arbitrary primitive might be considered safe if the 
> composition method is approved.
>
> Composition method is an approved technique, see SP800-56Cr2 (point 2).
>
> ___
> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Bas Westerbaan]

>
> Ultimately, I want fewer choices, but the direction the discussion is
> headed seems about right.  At least in the short term, I think we need to
> eschew compression and only include one offer.


I also prefer fewer choices initially.

The only reason we're testing both X25519+Kyber512 and X25519+Kyber768 is
that there is a possibility that Kyber768 becomes the default [1] and
because of its size, X25519+Kyber768 causes fragmentation in some cases
where X25519+Kyber512 doesn't.

* (2) to be able to declare security of generated keys in FIPS-mode for
>   _both_ - classical and post-quantum schemes (once Kyber is
> standardized).—


Why is this required? NIST writes

Current NIST standards, which were not necessarily designed to provide
post-quantum security, can accommodate several hybrid key establishment
constructions in “FIPS mode,” as defined in FIPS 140. For example, assume
that the value Z is a shared secret that was generated within a
NIST-approved cryptographic scheme, and that a value T is generated or
distributed through other scheme(s), which could be the output of a key
encapsulation method (KEM). The following are the different ways to
incorporate the value T in the key derivation procedure to achieve a hybrid
mode which is permitted by current standards: [...]

Here they're speaking about adding non-FIPS PQ to a non-PQ FIPS kex,[2] but
the other way around is also ok — what am I missing?

Best,

 Bas

[1] Not expressing an opinion on whether that's good or not.
[2] https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs




On Thu, Aug 18, 2022 at 1:05 AM Martin Thomson  wrote:

> On Sat, Aug 13, 2022, at 04:13, Scott Fluhrer (sfluhrer) wrote:
> > Well, if we were to discuss some suggested hybrids (and we now know the
> > NIST selection), I would suggest these possibilities:
> >
> > - X25519 + Kyber512
> > - P256 + Kyber512
> > - X448 + Kyber768
> > - P384 + Kyber768
>
> Any specific pairs of primitives should be specified in a different
> document to this one.
>
> Ultimately, I want fewer choices, but the direction the discussion is
> headed seems about right.  At least in the short term, I think we need to
> eschew compression and only include one offer.  Partly because I think that
> there might be better options available to us than compression, partly
> because compression will be annoying to implement correctly, and partly
> because we're still in the phase where this is being trialed.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Bas Westerbaan]

Why both X25519+Kyber512 and P256+Kyber512?

Note that Anything+Kyber512, in particular X25519+Kyber512, will be FIPS
certifiable after NIST standardized Kyber512.*

Best,

 Bas

—
* With the tiny caveat that apparently the order of the shares does matter
atm. [insert facepalm.]



> - X25519 + Kyber512
> - P256 + Kyber512
> - X448 + Kyber768
> - P384 + Kyber768
>
> I don't see the point of including finite field groups.  I would hope to
> hold off on national curves, such as Brainpool and the GOST curves
> (although they're likely to be forced on us anyways).  I personally see
> Kyber1024 as overkill (of course, if you disagree, please say so).
>
> Of course, it's possible that NIST will tweak the definition of Kyber;
> that's just a possibility we'll need to live with (and wouldn't change what
> hybrid combinations we would initially define)
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Bas Westerbaan]

>
> That is not the only model of quantum computing. If it was, I would be
> saying this entire effort is a silly waste of time because the approach is
> fundamentally unscalable. They can throw lots of gates onto a chip but the
> entanglement collapses before they can be used.
>

The whole point of quantum error correction is that it preserves
entanglement. (QEC in practice is not a panacea, for instance, transmons
can escape in higher harmonics which are not corrected for.) For the claim,
"fundamentally unscalable" however you should bring some evidence.

Best,

 Bas


PS, for those that want to get into the topic, I recommend Nielsen &
Chuang.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PQC key exchange sizes

[Bas Westerbaan]

On the QUIC side, there is the "*Q*uantum Ready" interop test:


https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=438405370



On Wed, Jul 27, 2022 at 8:57 PM Kampanakis, Panos  wrote:

> Gotcha. This is a reasonable explanation for a potential problem, but I
> would also like to see experimental proof that DTLS implementation X, Y, Z
> have the problem. TLS implementations don't deal with big ClientHellos
> today so we could assume they would have a problem, but when tested they do
> OK for the most part.
>
>
> -Original Message-
> From: TLS  On Behalf Of Ilari Liusvaara
> Sent: Wednesday, July 27, 2022 10:42 AM
> To:  
> Subject: RE: [EXTERNAL][TLS] PQC key exchange sizes
>
> 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.
>
>
>
> On Wed, Jul 27, 2022 at 02:27:12AM +, Kampanakis, Panos wrote:
> > Hi Ilari,
> >
> > > - DTLS-level fragmentation. There are buggy implementations that
> > >   break if one tries this.
> >
> > DTLS servers have been fragmenting and sending cert chains that don’t
> > fit in the MTU for a long time. Is this buggy on the TLS client side?
>
> These problems are specific to fragmenting Client Hello. Handling
> fragmented DTLS Client Hello is different from handling fragmented DTLS
> Certificate (and even more so in DTLS 1.3). I think DTLS specification just
> pretends both cases are the same. They are not.
>
>
> QUIC implementations could have similar issues with multiple initial
> packets, but operating QUIC with fast failure-independent fallback would
> make failures soft.
>
>
> There is the general principle that if some protocol feature is not used
> in the wild, it tends to break, even if required part of the protocol.
> Either by implementation being poorly tested and buggy, assuming the
> feature does not exist, or being missing entierely.
> Combine this with interop failures having outsize impact and old versions
> sticking around far longer than desriable. And I do not think fragmented
> Client Hellos in DTLS or multiple initials in QUIC are seen much.
>
>
> One trick with DTLS would be sending client hello with no key shares.
> Causes extra round-trip, but any server that selects PQC causing
> fragmentation would presumably be capable of handling that.
>
>
>
> -Ilari
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

[Bas Westerbaan]

>
> I'm not sure I would agree that a 3-8 MB handshake to preserve the status
> quo is exactly low hanging fruit.
>

If we use Dilithium2 for every signature, we're looking at about 17kB extra
— not 3-8MB. ICA suppression removes one public key and signature, so 3.7kB.

This is where looking to see what can be done to remove the necessity of
> those SCTs and OCSPs, rather than trying to patch them into a PQ world.
>

If Rainbow or GeMMS doesn't make the cut, then replacing SCTs by inclusion
proofs (to some daily picked side-loaded STHs) could be interesting (as
they're ~1kB each), but that's not low hanging fruit.


> The viability of CT itself becomes more suspect in a world of ginormous
> signatures,
>

Dilithium2 and Falcon signatures+public keys are 2.4+1.3kB and 666+897B
respectively. That won't cause trouble for CT.

Best,

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