[TLS] Re: [DNSOP] AD review draft-ietf-tls-svcb-ech

[Deirdre Connolly]

> We could add a recommendation like "Clients using ECH SHOULD select a DNS
resolver that they trust to preserve the confidentiality of their queries
and return authentic answers, and communicate using an authenticated and
confidential transport", but this draft seems like an odd place for that
text.

I support this more than the DNSSEC recommendation

On Mon, Sep 30, 2024 at 1:21 PM Ben Schwartz  wrote:

> I've written up adjusted references based on Paul's recommendations [1].
> (I haven't deleted the reference to RFC 1034, as I believe it remains the
> authoritative RFC on what DNS is all about.)
>
> Regarding Section 3.1 of SVCB (RFC 9460) [2], we imagine the client uses
> DoT to issue  and SVCB queries for the destination domain.   The
> attacker observes each response as an encrypted TLS record.  It drops the
> second one, and all subsequent TLS data.  This gives the attacker at least
> 50/50 odds of dropping only the SVCB response.  The client might then
> observe successful resolution of the  record, and a timeout for the
> SVCB response.  Similar attacks apply to DNSSEC.
>
> If the client proceeds with non-SVCB connection, it forfeits the
> possibility of ECH and reveals the SNI to this attacker.  Section 3.1 of
> SVCB says "don't do that".  Instead, ECH-capable clients have to fail hard
> in this situation.
>
> Trusted, DNSSEC-validating resolvers and confidential query transport are
> important for ECH to achieve its privacy aims.  Stub DNSSEC is not helpful
> for ECH: whether or not they validate DNSSEC, ECH clients must trust their
> resolver to protect the privacy of their queried names.
>
> We could add a recommendation like "Clients using ECH SHOULD select a DNS
> resolver that they trust to preserve the confidentiality of their queries
> and return authentic answers, and communicate using an authenticated and
> confidential transport", but this draft seems like an odd place for that
> text.
>
> --Ben
>
> [1] https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/15
> [2] https://datatracker.ietf.org/doc/html/rfc9460#section-3.1
> --
> *From:* Eric Rescorla 
> *Sent:* Monday, September 30, 2024 6:40 AM
> *To:* Paul Wouters 
> *Cc:* draft-ietf-tls-svcb-ech.auth...@ietf.org <
> draft-ietf-tls-svcb-ech.auth...@ietf.org>;  ;
> dn...@ietf.org WG 
> *Subject:* Re: [DNSOP] AD review draft-ietf-tls-svcb-ech
>
> On Sun, Sep 29, 2024 at 7: 34 PM Paul Wouters  dmarc. ietf. org> wrote: Hi, I have done my AD review of
> draft-ietf-tls-svcb-ech. Some history was well summarized by the Document
> Shepherd: Please note that the text
>
>
>
> On Sun, Sep 29, 2024 at 7:34 PM Paul Wouters  40aiven...@dmarc.ietf.org> wrote:
>
> Hi,
>
> I have done my AD review of draft-ietf-tls-svcb-ech. Some history was well
> summarized by the Document
> Shepherd:
>
> Please note that the text in this I-D was initially developed in the DNSOP WG,
> went through IETF LC, and IESG review. The result of the IESG review was to 
> take
> the text in this I-D out of RFC 9460 
> 
>  (was draft-ietf-dnsop-svcb-http) and run the
> new I-D through the TLS WG. The text in this I-D is essentially the same text
> taken from -11 of draft-ietf-dnsop-svcb-http.
>
>
> This is why I sent this review to both the TLS and DNSOP list. I have a
> few minor issues in the draft that I think
> need fixing:
>
> These downgrade attacks can prevent a client from being aware that
> "ech"
> is configured which could result in the client sending the ClientHello
> in cleartext.
>
> However, when DNSSEC is used and the TLS client can see the errors at the
> DNS layer,
> it can detect this downgrade attack is happening, and decide whether or
> not to continue with
> starting a TLS connection. I think the text should explain the difference
> in attack scenario in the
> presence and absence of DNSSEC. It might even be worth it to RECOMMEND
> DNSSEC, or recommend
> a DoH / DoT / DoQ connection to a DNSSEC supported DNS service. When
> referring to "DNSSEC", please
> use a normative reference to RFC9364.
>
>
> TBH, this whole section is kind of confusing, but I think it actually
> is noting exactly what you are suggesting:
>
>An attacker who can prevent SVCB resolution can deny clients any
>associated security benefits. A hostile recursive resolver can
>always deny service to SVCB queries, but network intermediaries can
>often prevent resolution as well, even when the client and
>recursive resolver validate DNSSEC and use a secure
>transport. These downgrade attacks can prevent a client from being
>aware that "ech" is configured which could result in the client
>sending the ClientHello in cleartext. To prevent downgrades,
>Section 3.1 of [SVCB] recommends that clients abandon the
>connection attempt when such an attack is dete

[TLS] Re: [DNSOP] AD review draft-ietf-tls-svcb-ech

[Deirdre Connolly]

> I do not, however, think that we should have a SHOULD for using DNSSEC
as it would be more in the nature of a RFC 6919 "MUST (BUT WE KNOW YOU
WON'T)".

I agree

On Mon, Sep 30, 2024 at 6:43 AM Eric Rescorla  wrote:

>
>
>
> On Sun, Sep 29, 2024 at 7:34 PM Paul Wouters  40aiven...@dmarc.ietf.org> wrote:
>
>> Hi,
>>
>> I have done my AD review of draft-ietf-tls-svcb-ech. Some history was
>> well summarized by the Document
>> Shepherd:
>>
>> Please note that the text in this I-D was initially developed in the DNSOP 
>> WG,
>> went through IETF LC, and IESG review. The result of the IESG review was to 
>> take
>> the text in this I-D out of RFC 9460 
>>  (was draft-ietf-dnsop-svcb-http) 
>> and run the
>> new I-D through the TLS WG. The text in this I-D is essentially the same text
>> taken from -11 of draft-ietf-dnsop-svcb-http.
>>
>>
>> This is why I sent this review to both the TLS and DNSOP list. I have a
>> few minor issues in the draft that I think
>> need fixing:
>>
>> These downgrade attacks can prevent a client from being aware that
>> "ech"
>> is configured which could result in the client sending the ClientHello
>> in cleartext.
>>
>> However, when DNSSEC is used and the TLS client can see the errors at the
>> DNS layer,
>> it can detect this downgrade attack is happening, and decide whether or
>> not to continue with
>> starting a TLS connection. I think the text should explain the difference
>> in attack scenario in the
>> presence and absence of DNSSEC. It might even be worth it to RECOMMEND
>> DNSSEC, or recommend
>> a DoH / DoT / DoQ connection to a DNSSEC supported DNS service. When
>> referring to "DNSSEC", please
>> use a normative reference to RFC9364.
>>
>
> TBH, this whole section is kind of confusing, but I think it actually
> is noting exactly what you are suggesting:
>
>An attacker who can prevent SVCB resolution can deny clients any
>associated security benefits. A hostile recursive resolver can
>always deny service to SVCB queries, but network intermediaries can
>often prevent resolution as well, even when the client and
>recursive resolver validate DNSSEC and use a secure
>transport. These downgrade attacks can prevent a client from being
>aware that "ech" is configured which could result in the client
>sending the ClientHello in cleartext. To prevent downgrades,
>Section 3.1 of [SVCB] recommends that clients abandon the
>connection attempt when such an attack is detected.
>
> This section is kind of confusing, but I *think* what it's saying
> is that the attacker permits resolution of the A/ records
> but blocks resolution of SVCB (it's not clear to me how it does
> this in the case where you are using secure transport, is the
> idea that it's an intermediary between the recursive and the
> authoritative? If so, probably say so). As you say, this is
> observable when DNSSEC is in place, and S 3.1 of SVCB recommends
> abandoning the connection, just as you ask.
>
>If DNS responses are cryptographically protected (e.g., using DNSSEC
>or TLS [DoT] [DoH]) and SVCB resolution fails due to an
>authentication error, SERVFAIL response, transport error, or timeout,
>the client SHOULD abandon its attempt to reach the service, even if
>the client is SVCB-optional.  Otherwise, an active attacker could
>mount a downgrade attack by denying the user access to the SvcParams.
>
>A SERVFAIL error can occur if the domain is DNSSEC-signed, the
>recursive resolver is DNSSEC-validating, and the attacker is between
>the recursive resolver and the authoritative DNS server.  A transport
>error or timeout can occur if an active attacker between the client
>and the recursive resolver is selectively dropping SVCB queries or
>responses, based on their size or other observable patterns.
>
>If the client enforces DNSSEC validation on A/ responses, it
>SHOULD apply the same validation policy to SVCB.  Otherwise, an
>attacker could defeat the A/ protection by forging SVCB responses
>that direct the client to other IP addresses.
>
>If DNS responses are not cryptographically protected, clients MAY
>treat SVCB resolution failure as fatal or nonfatal.
>
> I do not, however, think that we should have a SHOULD for using DNSSEC
> as it would be more in the nature of a RFC 6919 "MUST (BUT WE KNOW YOU
> WON'T)".
>
> It's worth noting at this point that ECH is a somewhat special case in
> that if the attacker is able to observe the DNS request (e.g., if they
> are on the local network and secure transport is not used) then much
> of the value of ECH is lost, as the attacker learns the DNS name at
> resolution time, so it would be appropriate to stress that clients
> should use secure transport.
>
> -Ekr
>
>
>
>
>
>> I think referring to DNS as RFC1034 is a mistake. It would be much better
>> to refer to RFC9499
>>
>>  See Section 7.2.2
>> 

[TLS] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction

[Deirdre Connolly]

> We should reap what we sow and just use supported_groups

Agreed 🥲

On Wed, Sep 25, 2024 at 10:54 AM Bob Beck 
wrote:

>
>
> On Tue, Sep 24, 2024 at 5:12 PM David Benjamin 
> wrote:
>
>> I should add, another reason to call it tls-supported-groups is that this
>> is essentially what the server would have put in the supported_groups
>> extension, if negotiation order in TLS were inverted. Since TLS already saw
>> fit[*] to name this concept supported_groups, I think that's a fine name
>> for the equivalent DNS incarnation.
>>
>
>> David
>>
>> [*] Mind you, supported_groups is a horrible name, but because of
>> "groups", not "supported". It refers to Diffie-Hellman groups, but we're
>> sticking PQ KEMs in there now. But we already disruptively renamed "curves"
>> to "groups" and another rename would do it again. Honestly, we should have
>> just kept it at "curves", and saved our disruption budget for a
>> more appropriate name, but so it goes. :-)
>>
>
> ^^^ This.   having a third term to attempt to describe a concept because
> we keep changing our minds is not going to help implementers, but just
> cause confusion
>
> I don't personally like supported_curves^Wgroups but turning that into
> supported^Wpreferred_curves^Wgroups^Wkems is just adding confusion and
> possibly code churn for variable renaming. We should reap what we sow and
> just use supported_groups
>
> If we absolutely must name the DNS thing something else, treat it as an
> opaque list of strings and don't be opinionated about what those
> strings contain. The DNS doesn't know or care anyway. name it for what it's
> purpose is (keyshare_hint).
>
>
>
>> On Tue, Sep 24, 2024 at 7:07 PM David Benjamin 
>> wrote:
>>
>>> Ah, I see. I don't think "supported" vs "preferred" captures this
>>> because "preferred" in the context of TLS usually isn't a binary property
>>> but a preference order. But I agree there is some ambiguity over what to
>>> list if you've got a couple different values.
>>>
>>> I think, other than potentially changing the name, it's not likely that
>>> this will have any impact on the presentation syntax. At the end of the
>>> day, we're going to want to send a list of things that your service (being
>>> intentionally vague about multiple server instances) supports. But since
>>> "supported" vs "preferred" is not the right descriptor, I suspect we won't
>>> do better than "supported" anyway. In particular...
>>>
>>> > I interpret preferred as being a list that the target thinks
>>> > will help clients avoid HRR, and help clients choose what is
>>> > considered "best" (e.g. wrt PQ) and that should work with all
>>> > server instances concerned, and that's likely the shortest
>>> > such list.
>>>
>>> That's not right. Avoiding HRR is a matter of predicting the group that
>>> the server would have picked given yours and the server's preferences. For
>>> example, consider a server that supports:
>>>
>>> A > B > C > D > E > F
>>>
>>> By the short list theory, you might think the server should publish,
>>> say, "A, B, C". However all that accomplishes is that a client that only
>>> supports D, E, and F won't know that it should predict D. The right
>>> behavior is to publish your full preference list, so that all clients (up
>>> to differences in selection algorithm) have the best shot of predicting
>>> correctly.
>>>
>>> > The issue with "supported" may be that some server instances
>>> > might have support for all sorts of oddball groups, and it
>>> > might be counterproductive to list all of those for the
>>> > target. (And/or to collect/merge the list if we're thinking
>>> > about e.g. the wkech thing.)
>>>
>>> Variations in server instances may indeed result in mispredictions. If
>>> the variation is due to a temporary rollout inconsistency, this variation
>>> is shortlived and will eventually sort itself out. During that period of
>>> inconsistency, neither list is more correct than the other because you want
>>> to make the correct prediction for each server.
>>>
>>> If the variation is persistent because you've intentionally deployed
>>> different instances of your service differently... first of all, don't do
>>> that. The security properties are not what you might. (An attacker can
>>> always direct the client to the weaker of the two.) If, despite the
>>> security flaws, you insist on doing this, I suppose you can use different
>>> HTTPS records for each and use all the machinery that HTTPS-RR already has
>>> here. That's all orthogonal to this draft because describing multiple
>>> routes to a single service is a general HTTPS-RR feature.
>>>
>>> > I'm fine that the text is a bit ambiguous on that for now, but
>>> > if the presentation syntax says "supported" then someone may
>>> > take that literally and publish very long lists that could
>>> > result in failures, for some server instances. (Or else could
>>> > add complexity in how e.g. a front-end thing like haproxy has
>>> > to process client hellos.)
>>>
>>> Could you e

[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement

[Deirdre Connolly]

All of it was posted to the list in May:

https://mailarchive.ietf.org/arch/msg/tls/vK2N0vr83W6YlBQMIaVr9TeHzu4/

On Mon, Aug 26, 2024, 9:22 AM Salz, Rich  wrote:

> The current triage panel is not anonymous, and the feedback they gave
> on RFC8773bis included the complete input from all current members.
>
>
>
> Post it.  All of it.  To the WG mailing list.
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement

[Deirdre Connolly]

> I think if this is truly a problem it is symptomatic to participation in
a working group as a whole and should be addressed across the board for
everyone.

I agree that it is a problem and should be addressed across the IETF.
Unfortunately we keep making changes to TLS 1.3 in the meantime, so. I was
talking to more than one cryptographer at CRYPTO this week who have sworn
off all participation in the IETF after the curve flamewares in the past,
etc

On Sun, Aug 25, 2024 at 4:51 PM Bob Beck  wrote:

>
>
> On Aug 25, 2024, at 13:56, Salz, Rich 
> wrote:
>
> 
>
> I am opposed. Anonymous email recommendations are not how the IETF
> operates.
>
>
> I would also count myself as opposed. While I understand and am
> sympathetic to a reviewer possibly not wanting to get deluged in email or
> opinions unrelated to the task at hand, I think if this is truly a problem
> it is symptomatic to participation in a working group as a whole and should
> be addressed across the board for everyone. Anonymous reviewers have a
> number of problems as Rich has pointed out.
>
>
>
> Attached below is a note I wrote a month ago to the Chairs.  None of the
> points written there – and MOST of them were a summary of WG discussion –
> were addressed.
>
>
>
>
>
>
> * From: *Rich Salz 
> *Date: *Tuesday, July 30, 2024 at 1:49 PM
> *To: *"tls-cha...@ietf.org" 
> *Subject: *Rethinking the formal analysis triage
>
>
>
> TLS Chairs,
>
>
>
> I wasn’t sure whether to send this to you or the entire WG. I let another
> person read this and they suggested the Chairs.  So here you go.
>
>
>
> I re-read all the messages in the archive [1] and re-watched the 119 and
> 120 segments on the triage panel.  I believe that, as currently set up, it
> is so flawed that it should be taken down and rebuilt from scratch.
>
>
>
> After the idea was proposed in March, the two most common feedback
> suggestions were
>
> • Collaborate with UFMRG
>
> • Make all communications open and on the mailing list
>
> Neither of these were done. In fact, there was no response from the Chairs
> on either point.
>
>
>
> From the beginning, the stated intent was the that one thing the panel
> would provide is an estimate of how much work any suggested analysis would
> take. The one review that was done so far did not include that, other than
> “feasible.”
>
>
>
> Many people have already commented that collating all responses is a bad
> idea. I want to add one point that I have not seen before: if a subset of
> the triage reviewers recommends analysis, the WG has no information about
> the qualifications of those making the recommendation and no way to
> evaluate how to accept it.
>
>
>
> This brings up a related point. Anonymous evaluations are against the very
> nature of the IETF. How can we assess the value of someone’s contributions
> when we don’t know who they are? Will “Reviewer 1” always be the same
> person? If the entire panel did not do a review, are WG members expected to
> treat all members as equally competent and qualified?
>
>
>
> The WG is strongly in favor of more formal analysis. The Chairs tried to
> do too much and failed. Start over, respond to the feedback you got from
> the WG, and pick something easier.
>
>
>
> [1]  https:/mailarchive.ietf.org/arch/browse/tls/?q=triage
>
>
>
>
> ___
> 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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement

[Deirdre Connolly]

>  Anonymous reviewers have a number of problems

The current triage panel is not anonymous, and the feedback they gave
on RFC8773bis included the complete input from all current members.

On Sun, Aug 25, 2024 at 4:51 PM Bob Beck  wrote:

>
>
> On Aug 25, 2024, at 13:56, Salz, Rich 
> wrote:
>
> 
>
> I am opposed. Anonymous email recommendations are not how the IETF
> operates.
>
>
> I would also count myself as opposed. While I understand and am
> sympathetic to a reviewer possibly not wanting to get deluged in email or
> opinions unrelated to the task at hand, I think if this is truly a problem
> it is symptomatic to participation in a working group as a whole and should
> be addressed across the board for everyone. Anonymous reviewers have a
> number of problems as Rich has pointed out.
>
>
>
> Attached below is a note I wrote a month ago to the Chairs.  None of the
> points written there – and MOST of them were a summary of WG discussion –
> were addressed.
>
>
>
>
>
>
> * From: *Rich Salz 
> *Date: *Tuesday, July 30, 2024 at 1:49 PM
> *To: *"tls-cha...@ietf.org" 
> *Subject: *Rethinking the formal analysis triage
>
>
>
> TLS Chairs,
>
>
>
> I wasn’t sure whether to send this to you or the entire WG. I let another
> person read this and they suggested the Chairs.  So here you go.
>
>
>
> I re-read all the messages in the archive [1] and re-watched the 119 and
> 120 segments on the triage panel.  I believe that, as currently set up, it
> is so flawed that it should be taken down and rebuilt from scratch.
>
>
>
> After the idea was proposed in March, the two most common feedback
> suggestions were
>
> • Collaborate with UFMRG
>
> • Make all communications open and on the mailing list
>
> Neither of these were done. In fact, there was no response from the Chairs
> on either point.
>
>
>
> From the beginning, the stated intent was the that one thing the panel
> would provide is an estimate of how much work any suggested analysis would
> take. The one review that was done so far did not include that, other than
> “feasible.”
>
>
>
> Many people have already commented that collating all responses is a bad
> idea. I want to add one point that I have not seen before: if a subset of
> the triage reviewers recommends analysis, the WG has no information about
> the qualifications of those making the recommendation and no way to
> evaluate how to accept it.
>
>
>
> This brings up a related point. Anonymous evaluations are against the very
> nature of the IETF. How can we assess the value of someone’s contributions
> when we don’t know who they are? Will “Reviewer 1” always be the same
> person? If the entire panel did not do a review, are WG members expected to
> treat all members as equally competent and qualified?
>
>
>
> The WG is strongly in favor of more formal analysis. The Chairs tried to
> do too much and failed. Start over, respond to the feedback you got from
> the WG, and pick something easier.
>
>
>
> [1]  https:/mailarchive.ietf.org/arch/browse/tls/?q=triage
>
>
>
>
> ___
> 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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: [EXTERNAL] Re: Working Group Last Call for "Hybrid key exchange in TLS 1.3"

[Deirdre Connolly]

Yes, there are backwards-incompatible changes including domain-separating
key material by parameter set.

On Wed, Aug 14, 2024, 10:07 AM Salz, Rich  wrote:

> ZjQcmQRYFpfptBannerEnd
>
> I think it would make sense to get new code points for hybrids based on
> the final ML-KEM spec, so that implementers don’t need to use pre-standard
> Kyber.
>
>
>
> Has anyone read closely to see if the kybrid/kyber draft would need to
> change, other than the name?  If not, then we can just change the name in
> the registry by posting an updated draft. If there are changes, then we
> need a new codepoint, also just by posting an updated draft.
>
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Working Group Last Call for "Hybrid key exchange in TLS 1.3"

[Deirdre Connolly]

This email starts the working group last call for the Internet-Draft
"Hybrid key exchange in TLS 1.3", located here:

https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/

The WG last call will end 26th August 2024 @ 2359 UTC.

Please review the draft and submit issues and pull requests via the GitHub
repository that can be found at:

https://github.com/dstebila/draft-ietf-tls-hybrid-design

You can also send comments and feedback to tls@ietf.org.

Cheers and thank you,
Deirdre
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Meta deploying -hybrid-design

[Deirdre Connolly]

Starting with internal connections:

https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/

> For our deployment, we have chosen Kyber with X25519 in a hybrid setting.
Kyber is the only key encapsulation mechanism selected by NIST for
standardization so far. Kyber comes in different parameterizations:
Kyber512, Kyber768, and Kyber1024. Larger parameterizations provide
stronger security but also require more computational resources and
communication bandwidth. We aim to use Kyber768 by default, while using
Kyber512 in some cases where larger parameterizations lead to prohibitive
performance impact, to accelerate the deployment of PQC hybrid key exchange.

Challenges include large packet sizes:

> After evaluating various alternatives and workarounds, and given the
prohibitive key size of Kyber768, we opted to use Kyber512 in internal
communications affected by this problem for now, allowing us to accelerate
the PQC deployment. Kyber512’s 800-bytes-long public keys help with fitting
the ClientHello into a single TCP packet, while still being considered
secure by NIST. This choice ensures both security and efficient
communication. In the future, an increase in MTU, or utilizing QUIC, which
allows for multiple initial packets, may allow for larger ClientHellos
without an additional round trip.


and cross-domain session resumption handshake thrashing:

> As previously mentioned, we do Ephemeral Diffie-Hellman key exchange on
resumption. To facilitate efficient use of computation resources, the
client will send only the minimally required default keyshares, which in
the resumption case means the keyshare for the previously negotiated named
group. This means that when a client connects to a particular server and
negotiates a classical named group, then subsequently resumes on a server
with which the client should use a hybrid named group, the client would
advertise the hybrid named group but send only the keyshare for the
classical named group. This leads to the server negotiating the hybrid
named group and replying with a HelloRetryRequest to ask the client for the
hybrid keyshare, resulting in an additional 1-RTT to perform the key
exchange.

> To address this, we had the client split each service into different TLS
session scopes – one using classical key exchange, and one using hybrid key
exchange. Each session scope thus uses only one named group each, avoiding
the keyshare thrashing behavior described above. The tradeoff is space
consumption due to having to store more session tickets, but this has been
acceptable given the small size of each session ticket (a few hundred
bytes).

They also included more in-the-wild data on Kyber768 computational costs:

> Meta currently uses X25519 in Elliptic Curve Diffie-Hellman key exchange.
During the initial rollout of hybrid key exchange with the hybrid named
group X25519_kyber768, we observed a roughly 40 percent increase in CPU
cycles. Although this may seem like an undesirable result, it actually
indicates that Kyber768 standalone key exchange is faster than x25519,
which lines up with results others have found.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt

[Deirdre Connolly]

Yet another reason I would love full group elements included in these
protocols but alas

On Wed, Jul 24, 2024, 9:22 AM Peter C  wrote:

> Deirdre,
>
>
>
> I’m not familiar with the PQ3 protocol, but I think PRF-ODH can fail in
> practice due to the way that ECDH is usually instantiated.
>
>
>
> For NIST P-256, the input to the KDF is usually the x-coordinate of the
> ECDH shared secret rather than the full point.  Given a challenge (C,
> label), setting C’ = -C and querying the oracle with (C’, label) should
> give the same KDF output.
>
>
>
> For X25519, the private keys are clamped and there are usually no checks
> on the public keys.  Given a challenge (C, label), setting C’ = C + P for a
> point P of small order and querying the oracle with (C’, label) should give
> the same KDF output.
>
>
>
> Note that in both cases we are deviating from the idealised PRF-ODH
> setting so this does not contradict the proof that StDH implies PRF-ODH (
> https://ia.cr/2017/517).
>
>
>
> Peter
>
>
>
> *From:* Deirdre Connolly 
> *Sent:* Wednesday, July 24, 2024 3:34 PM
> *To:* Peter C 
> *Cc:* Douglas Stebila ; TLS List 
> *Subject:* Re: [TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt
>
>
>
> Not a direct reference for TLS 1.3, but recent related work from the
> document author, Douglas's analysis of PQ3 iMessage¹, has a hybrid
> encrypted session setup with commonalities with the TLS 1.3 key schedule,
> especially the layers of calls to HKDF.Expand and HKDF.extract, albeit in a
> different order than TLS. These proofs rely on PRF-ODH for the curves and
> that HKDF.Expand/Extract are PRFs in their first argument and more PRF
> assumptions of the ~equivalent of the large key schedule that it is also a
> PRF in two arguments (any chaining key material and the public session
> information, including the ephemeral public keys) to achieve session key
> indistinguishability.
>
> ¹
> https://security.apple.com/assets/files/Security_analysis_of_the_iMessage_PQ3_protocol_Stebila.pdf
>
> Maybe Douglas will be able to answer directly on TLS 1.3 but hopefully
> this is also useful ✨
>
>
>
>
>
> On Wed, Jul 24, 2024, 6:41 AM Peter C  40ncsc.gov...@dmarc.ietf.org> wrote:
>
> Douglas,
>
> The agenda for the TLS session is looking packed, and this is a very
> in-the-weeds comment, so I hope you don't mind me posting it to the list.
> Happy to take any discussion off-list, if you'd prefer.
>
> The draft-ietf-tls-hybrid-design security considerations currently say:
>
> The shared secrets computed in the hybrid key exchange should be
> computed in a way that achieves the "hybrid" property: the resulting
> secret is secure as long as at least one of the component key
> exchange algorithms is unbroken. See [GIACON] and [BINDEL] for an
> investigation of these issues.
>
> If you assume the PQ KEM is IND-CCA2 secure, then I agree that [GIACON]
> and [BINDEL] imply that the derived traffic secrets will be
> indistinguishable from random and from each other.  The same is true if the
> KEM is only OW-CCA2 secure by Petcher-Campagna (https://ia.cr/2023/972).
>
> If you assume the PQ KEM is broken, however, then [GIACON] and [BINDEL] do
> not apply since ECDH-as-a-KEM is not IND-CCA2 secure.  Similarly,
> Petcher-Campagna does not apply because ECDH is not OW-CCA2 secure.  Nor do
> I think it's possible to fall back on [DOWLING] since X25519 and NIST P-256
> (as they are used in RFC 8446) do not satisfy the dual-snPRF-ODH assumption
> for any choice of KDF.  In this case, I don't believe the derived traffic
> secrets are guaranteed to be indistinguishable from random.
>
> Flo raised similar points a couple of years ago which I don't think were
> fully addressed at the time.  I suspect this is just a security proof issue
> - the inclusion of the ciphertexts in the transcript hash should still
> protect against any actual attacks - and it's entirely possible that I've
> missed more recent results covering all of this.  If not, one easy solution
> might be to adopt the X-Wing approach and use
>
> concatenated_ss = pqkem_ss || ecdh_ss || ecdh_ct || ecdh_pk,
>
> although this currently only works with ML-KEM.
>
> Best,
>
> Peter
>
>
> > -Original Message-
> > From: TLS  On Behalf Of internet-dra...@ietf.org
> > Sent: Friday, April 5, 2024 9:24 PM
> > To: i-d-annou...@ietf.org
> > Cc: tls@ietf.org
> > Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-10.txt
> >
> > Internet-Draft draft-ietf-tls-hybrid-design-10.txt is now available. It
> is a
> > work item of the Transport Layer 

[TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt

[Deirdre Connolly]

Not a direct reference for TLS 1.3, but recent related work from the
document author, Douglas's analysis of PQ3 iMessage¹, has a hybrid
encrypted session setup with commonalities with the TLS 1.3 key schedule,
especially the layers of calls to HKDF.Expand and HKDF.extract, albeit in a
different order than TLS. These proofs rely on PRF-ODH for the curves and
that HKDF.Expand/Extract are PRFs in their first argument and more PRF
assumptions of the ~equivalent of the large key schedule that it is also a
PRF in two arguments (any chaining key material and the public session
information, including the ephemeral public keys) to achieve session key
indistinguishability.

¹
https://security.apple.com/assets/files/Security_analysis_of_the_iMessage_PQ3_protocol_Stebila.pdf

Maybe Douglas will be able to answer directly on TLS 1.3 but hopefully this
is also useful ✨



On Wed, Jul 24, 2024, 6:41 AM Peter C 
wrote:

> Douglas,
>
> The agenda for the TLS session is looking packed, and this is a very
> in-the-weeds comment, so I hope you don't mind me posting it to the list.
> Happy to take any discussion off-list, if you'd prefer.
>
> The draft-ietf-tls-hybrid-design security considerations currently say:
>
> The shared secrets computed in the hybrid key exchange should be
> computed in a way that achieves the "hybrid" property: the resulting
> secret is secure as long as at least one of the component key
> exchange algorithms is unbroken. See [GIACON] and [BINDEL] for an
> investigation of these issues.
>
> If you assume the PQ KEM is IND-CCA2 secure, then I agree that [GIACON]
> and [BINDEL] imply that the derived traffic secrets will be
> indistinguishable from random and from each other.  The same is true if the
> KEM is only OW-CCA2 secure by Petcher-Campagna (https://ia.cr/2023/972).
>
> If you assume the PQ KEM is broken, however, then [GIACON] and [BINDEL] do
> not apply since ECDH-as-a-KEM is not IND-CCA2 secure.  Similarly,
> Petcher-Campagna does not apply because ECDH is not OW-CCA2 secure.  Nor do
> I think it's possible to fall back on [DOWLING] since X25519 and NIST P-256
> (as they are used in RFC 8446) do not satisfy the dual-snPRF-ODH assumption
> for any choice of KDF.  In this case, I don't believe the derived traffic
> secrets are guaranteed to be indistinguishable from random.
>
> Flo raised similar points a couple of years ago which I don't think were
> fully addressed at the time.  I suspect this is just a security proof issue
> - the inclusion of the ciphertexts in the transcript hash should still
> protect against any actual attacks - and it's entirely possible that I've
> missed more recent results covering all of this.  If not, one easy solution
> might be to adopt the X-Wing approach and use
>
> concatenated_ss = pqkem_ss || ecdh_ss || ecdh_ct || ecdh_pk,
>
> although this currently only works with ML-KEM.
>
> Best,
>
> Peter
>
>
> > -Original Message-
> > From: TLS  On Behalf Of internet-dra...@ietf.org
> > Sent: Friday, April 5, 2024 9:24 PM
> > To: i-d-annou...@ietf.org
> > Cc: tls@ietf.org
> > Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-10.txt
> >
> > Internet-Draft draft-ietf-tls-hybrid-design-10.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-10.txt
> >Pages:   24
> >Dates:   2024-04-05
> >
> > 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://github/.
> > com%2Fdstebila%2Fdraft-ietf-tls-hybrid-
> > design&data=05%7C02%7CPeter.C%40ncsc.gov.uk%7Cec161933c97947c8a7e0
> > 08dc55ae8cd7%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C6384
> > 79455373796379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata
> > =qNBE50aYk4woYCLUj6Rq1wMeFur63hP1MnHXDGihg80%3D&reserved=0.
> >
> > The IETF datatracker status page for this Internet-Draft is:
> > https://datatra/
> > cker.ietf.org%2Fdoc%2Fdraft-ietf-tls-hybrid-
> > design%2F&data=05%7C02%7CPeter.C%40ncsc.gov.uk%7Cec161933c97947c8
> > a7e008dc55ae8cd7%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C
> > 638479455373796379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&s
> > data=k

[TLS]Re: Kicking off the TLS 1.3 formal analysis triage panel

[Deirdre Connolly]

 Is there a desire for a hybrid authentication
property based on the external PSK?  Or is one only relying on the public
key certificate for authentication?

As for the confidentiality analysis: the fixed key schedule already
provides locations for putting all the relevant inputs in and that's part
of the existing analyses of TLS, so I don't think you'd get any surprises
there.

The current security argument is insufficient and there should be a
meaningful security analysis.


*If so, what type / scope / effort is required?*
Symbolic analysis (Tamarin, ProVerif) would be suitable for identifying /
eliminating cross-protocol attacks. Extending the existing models seems
feasible.

For the authentication analysis, I think here a Tamarin-like analysis might
be useful for checking undesirable interactions; for example, could
anything go wrong if a single PSK is used both as a traditional PSK but
also as an external PSK?

---

I want to express major thanks to our triage panel for their participation
and expertise here! Now it's up to WG to discuss what to do with this
analysis. 😁

Cheers,
Deirdre, for the chairs


On Thu, Apr 18, 2024 at 11:36 AM Deirdre Connolly 
wrote:

> Hello everyone! We're kicking off our TLS 1.3 formal analysis triage
> panel.
>
> We have these volunteers participating:
>
> - Douglas Stebila
> - Dennis Jackson
> - Franziskus Kiefer
> - Cas Cremers
> - Karthikeyan Bhargavan
> - Vincent Cheval
>
> Some of them are on this list, some are not, major welcomes and thank yous
> all around!
>
> I will link to my write up to the working group
> <https://mailarchive.ietf.org/arch/msg/tls/RupKEHeJdAzxpNEZnRgerk4en1c/>and
> the recording of the most recent meeting
> <https://youtu.be/Oo1UzQtfRYw?feature=shared&t=1485> for more context if
> you want it.
>
> The goal of the triage panel is to maintain the high degree of
> cryptographic assurance in TLS 1.3 as it evolves as a living protocol. To
> paraphrase a recent analysis of Encrypted Client Hello, one can see three
> prongs motivating formal analysis of changes or extensions to TLS 1.3:
>
> - Preservation of existing security properties: the authentication,
> integrity, and confidentiality properties that have already been proven are
> preserved
> - New, stronger security properties: such as improved privacy demonstrated
> by ECH, prove that extensions satisfies new goals
> - Downgrade resilience: prove that active attackers cannot downgrade the
> changed/updated/extended protocol to bypass/remove the new guarantees
>
> These are especially salient for new features like Encrypted Client Hello,
> but I would say the top bullet is the front of mind for most proposed
> documents coming through TLSWG: people want to use TLS 1.3 in new settings,
> in updated contexts, and want to tweak it a bit for their use case, and we
> want to make sure these changes do not degrade the already proven security
> properties of TLS 1.3.
>
> Here's how I envision this going: every few weeks or so, more likely than
> not spurred by a document introduced at a (March, July, November) IETF
> meeting, we chairs ping the triage panel directly with document drafts that
> we'd like a first pass sniff test on whether these proposals:
>
> - imply a change to previous security analysis assumptions (via pen and
> paper, formal methods tools, computer-aided provers, any/all of the above)
> - whether such a change behooves updated analysis
> - if updated analysis is recommended, of what type, what scope, and
> estimated time to complete, given such and such a person or team
>
> We (the chairs) will collect responses, collate them, and bring them to
> the working group as part of an adoption call or other working group
> discussions about a document. If this process did not occur (say something
> was adopted long ago and has been dormant but now is being revived etc) we
> may come back and run a similar procedure again. If the working group
> agrees on requiring formal analysis for a document before it goes through a
> last call, we will ask the triage panel for recommendations or advice on
> trying to match the project with a group or a researcher who can work with
> the document authors on delivering the analysis.
>
> The first thing on deck is 8773bis
> <https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis/>, with more to
> come. Hopefully this is useful.
>
> Yay!
>
> Deirdre, for the chairs
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Kicking off the TLS 1.3 formal analysis triage panel

[Deirdre Connolly]

Hello everyone! We're kicking off our TLS 1.3 formal analysis triage panel.

We have these volunteers participating:

- Douglas Stebila
- Dennis Jackson
- Franziskus Kiefer
- Cas Cremers
- Karthikeyan Bhargavan
- Vincent Cheval

Some of them are on this list, some are not, major welcomes and thank yous
all around!

I will link to my write up to the working group
and
the recording of the most recent meeting
 for more context if
you want it.

The goal of the triage panel is to maintain the high degree of
cryptographic assurance in TLS 1.3 as it evolves as a living protocol. To
paraphrase a recent analysis of Encrypted Client Hello, one can see three
prongs motivating formal analysis of changes or extensions to TLS 1.3:

- Preservation of existing security properties: the authentication,
integrity, and confidentiality properties that have already been proven are
preserved
- New, stronger security properties: such as improved privacy demonstrated
by ECH, prove that extensions satisfies new goals
- Downgrade resilience: prove that active attackers cannot downgrade the
changed/updated/extended protocol to bypass/remove the new guarantees

These are especially salient for new features like Encrypted Client Hello,
but I would say the top bullet is the front of mind for most proposed
documents coming through TLSWG: people want to use TLS 1.3 in new settings,
in updated contexts, and want to tweak it a bit for their use case, and we
want to make sure these changes do not degrade the already proven security
properties of TLS 1.3.

Here's how I envision this going: every few weeks or so, more likely than
not spurred by a document introduced at a (March, July, November) IETF
meeting, we chairs ping the triage panel directly with document drafts that
we'd like a first pass sniff test on whether these proposals:

- imply a change to previous security analysis assumptions (via pen and
paper, formal methods tools, computer-aided provers, any/all of the above)
- whether such a change behooves updated analysis
- if updated analysis is recommended, of what type, what scope, and
estimated time to complete, given such and such a person or team

We (the chairs) will collect responses, collate them, and bring them to the
working group as part of an adoption call or other working group
discussions about a document. If this process did not occur (say something
was adopted long ago and has been dormant but now is being revived etc) we
may come back and run a similar procedure again. If the working group
agrees on requiring formal analysis for a document before it goes through a
last call, we will ask the triage panel for recommendations or advice on
trying to match the project with a group or a researcher who can work with
the document authors on delivering the analysis.

The first thing on deck is 8773bis
, with more to
come. Hopefully this is useful.

Yay!

Deirdre, for the chairs
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

[Deirdre Connolly]

> KEMs are not "key agreement" algorithms as suggested by this draft name.
In a key agreement algorithm, both parties contribute to the shared
secret.  With a KEM, only one party generates the the shared secreat value.

This is not generally accurate with the KEM schemes under consideration for
adoption by any standards bodies: in the -hybrid-design and
-mlkem-key-agreement documents, the `Client` generates an ephemeral
keypair, and the `Server` encapsulates to that keypair, but especially in
ML-KEM which is under consideration in both documents, the KEM randomly
sampled message `m` is sampled by the `Server` but the final
`shared_secret` resulting from `Encaps` and `Decaps` is based on computing
over the message `m`, the public key `PK` generated by the `Client`, as
well as the randomized ciphertext `CT` generated by the `Server`. The
encapsulated message `m` is not actually the `shared_secret` that is the
input to the TLS 1.3  key schedule, even independent of the entire
handshake transcript being included into the full key schedule as well.

The naming of the document excluded 'key exchange' and 'key establishment',
and went with 'key agreement', but that is a weakly held name,

On Thu, Mar 28, 2024 at 5:08 PM Russ Housley  wrote:

> Sean:
>
> I observe that ML-KEM is not a Elliptic curve group or a Finite Field
> Diffie-Hellman group.  I really think we want to include sepport for KEMs.
> but a separate range is needed.  I assume it will be carved out of the
> Elliptic curve group range.
>
> KEMs are not "key agreement" algorithms as suggested by this draft name.
> In a key agreement algorithm, both parties contribute to the shared
> secret.  With a KEM, only one party generates the the shared secreat value.
>
> Russ
>
> > On Mar 28, 2024, at 10:52 AM, Sean Turner  wrote:
> >
> > 
> >
> > **WARNING: Potential bikeshed**
> >
> > -connolly-tls-mlkem-key-agreement has suggested that code points for the
> NIST PQ be registered in the TLS Supported Groups IANA registry [1].
> Currently [2], the registry is carved up into three blocks as follows:
> >
> > Range: 0-255, 512-65535
> > Registration Procedures: Specification Required
> > Note: Elliptic curve groups
> >
> > Range 256-511
> > Registration Procedures: Specification Required
> > Note: Finite Field Diffie-Hellman groups
> >
> > Assuming that the proposal in -connolly-tls-mlkem-key-agreement is the
> path for PQ KEM algorithms (and maybe regardless of whether this is the
> path), we should really replace the “Elliptic curve groups” note in the
> 0-255, 512-65535 range row with something else.  I am open to suggestions,
> but would like to propose “unallocated”. I have submitted the following
> issue:
> > https://github.com/tlswg/rfc8447bis/issues/54
> > and this PR:
> > https://github.com/tlswg/rfc8447bis/pull/55
> > to address this.
> >
> > spt
> >
> > [1]
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
> >
> > [2] Originally, RFC 8442 defined the name of the registry as "EC Named
> Curve Registry” and then RFC 7919 re-named it “Supported Groups” and carved
> out the FFDH space.
>
> ___
> 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] Proposal: a TLS formal analysis triage panel

[Deirdre Connolly]

I do think a 'reference' Tamarin model would be useful. It would of course
only model part of TLS (1.3, for example) and only through a particular
symbolic model/tool. And would require maintenance by...someone.

For the triage panel, I do think the preliminary triage is key: we'd ask a
group of experts /if/ formal analysis (new or updated) is warranted /at
all/, and if warranted, of what kind, what scope, if it needs novel
modeling work, if it can build on existing work, or even if pen and paper
analysis would suffice. I do not think there are any prerequisites to
standing such a triage panel up.


On Mon, Mar 18, 2024, 10:34 AM Muhammad Usama Sardar <
muhammad_usama.sar...@tu-dresden.de> wrote:

> Hi Deirdre,
>
> Just in case I miss the meeting (which is unfortunately after midnight for
> me), I would like to mention that this is great idea and I would be happy
> to contribute to this.
>
> In our recent research on integrating attestation in Inria's ProVerif
> artifacts [1] for TLS 1.3, we faced several challenges, such as:
>
>- There are very few comments in the code. Main processes (such as
>Client12, Server12, Client13, Server13, appData, channelBindingQuery and
>secrecyQuery) have literally no comments at all.
>- The latest version of the artifacts (modeling draft 20 of TLS 1.3)
>has incorrectly modeled the key schedule [2,3]. The same incorrect model
>has been used in a number of TLS extensions, including the recent LURK [4].
>- WG seems to have no understanding of why some of the decisions were
>taken in TLS 1.3. In a discussion over mailing list [5] as well as with
>other experts, nobody has been able to justify the intuition of
>Derive-Secret for Master Secret, and whether there is any practical attack
>if that Derive-Secret is missing.
>
> So I believe one initial useful thing that the 'formal analysis triage
> panel' could do is to create RFC8446-consistent baseline artifacts, which
> are well-commented, thoroughly validated and reviewed by a few experts
> (both TLS as well as formal methods). Then these artifacts can be used for
> any TLS extension for which formal analysis is required.
>
> Regards,
>
> Usama
>
> [1] https://github.com/Inria-Prosecco/reftls/tree/master/pv
>
> [2] https://github.com/Inria-Prosecco/reftls/issues/6
>
> [3] https://github.com/Inria-Prosecco/reftls/issues/7
>
> [4] https://github.com/lurk-t/proverif
>
> [5] https://mailarchive.ietf.org/arch/msg/tls/ZGmyHwTYh2iPwPrirj_rkSTYhDo/
> On 06.03.24 02:37, Deirdre Connolly wrote:
>
> A few weeks ago, we ran a WGLC on 8773bis, but it basically came up
> blocked because of a lack of formal analysis of the proposed changes. The
> working group seems to be in general agreement that any changes to TLS 1.3
> should not degrade or violate the existing formal analyses and proven
> security properties of the protocol whenever possible. Since we are no
> longer in active development of a new version of TLS, we don't necessarily
> have the same eyes of researchers and experts in formal analysis looking at
> new changes, so we have to adapt.
>
> I have mentioned these issues to several experts who have analyzed TLS (in
> total or part) in the past and have gotten tentative buy-in from more than
> one for something like a 'formal analysis triage panel': a rotating group
> of researchers, formal analysis experts, etc, who have volunteered to give
> 1) a preliminary triage of proposed changes to TLS 1.3¹ and _whether_ they
> could do with an updated or new formal analysis, and 2) an estimate of the
> scope of work such an analysis would entail. Such details would be brought
> back to the working group for discussion about whether the proposed changes
> merit the recommended analysis or not (e.g., a small, nice-to-have change
> may actually entail a fundamentally new security model change, whereas a
> large change may not deviate significantly from prior analysis and be
> 'cheap' to do). If the working group agrees to proceed, the formal analysis
> triage panel consults on farming out the meat of the analysis work (either
> to their teams or to students they supervise, etc.).\ Group membership can
> be refreshed on a regular schedule or on an as-needed basis. Hopefully the
> lure of 'free' research questions will be enticing.
>
> The goal is to maintain the high degree of cryptographic assurance in TLS
> 1.3 as it evolves as one of the world's most-used cryptographic protocols.
>
> I would like to hear thoughts on this idea from the group and if we would
> like to put it on the agenda for 119.
>
> Cheers,
> Deirdre
>
> ¹ 1.3 has the most robust analysis; we'll see about other versions
>
> ___
> 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

[Deirdre Connolly]

Good points. I've included these notes in the GitHub tracking issue, and
will leave the document as-is for now.

On Thu, Mar 14, 2024, 3:41 PM Sophie Schmieg  wrote:

> There was a push to change the parsing logic for ML-KEM public keys to
> never fail, by silently reducing, without changing the hash of the public
> key. I am not sure if NIST ended up adopting that change for their final
> standard (I hope they did, I think it's the best way to handle this
> problem), which would mean that any appropriately sized binary string is a
> valid ML-KEM public key. For ciphertexts, this property is already the
> case, due to the compression that is applied in ML-KEM. If NIST
> incorporated this change, there would be no way for the ML-KEM based key
> agreement to fail explicitly, any failure would result in an implicit
> rejection.
> In the end, this seems to be the same as with elliptic curves as is as
> well, point-not-on-curve checks can result in an explicit rejection of a
> keyshare (for the curves where it can occur), and manipulation of the
> keyshare (by an attacker or some accidental bit flip that somehow was not
> caught) would result in an implicit rejection here as well, with server and
> client computing a different shared secret. The only new possible error
> path I see is due to random decryption failure of a KEM, but given the
> cryptographically low chance, I'm not certain if this failure needs special
> handling in any case, and shouldn't be treated the same as a corrupted key
> share. After all, they are so unlikely that "cosmic rays flipped all the
> right bits for QUIC error correction to not notice" is far more likely to
> result in a decryption error, so treating it the same as a decryption
> failure due to a corrupted ciphertext seems fine to me.
>
> On Thu, Mar 14, 2024 at 11:43 AM David A. Cooper  40nist@dmarc.ietf.org> wrote:
>
>> I do not believe that "decode_error" would be the correct alert. As the
>> text currently says:
>>
>> *Failures* Some post-quantum key exchange algorithms, including ML-KEM,
>> have non-zero probability of failure, meaning two honest parties may derive
>> different shared secrets. This would cause a handshake failure. ML-KEM has
>> a cryptographically small failure rate; implementers should be aware of the
>> potential of handshake failure. Clients can retry if a failure is
>> encountered.
>>
>> At least in the case of ML-KEM, decapsulation failures are implicit. As
>> noted in the text above, the parties would derive different shared secrets
>> (but they wouldn't know it). So, the client would not know that
>> decapsulation failed, it would just be unable to decrypt the encrypted
>> extensions, certificate, etc. The client would have no way of knowing
>> whether this happened because of an ML-KEM decapsulation failure (extremely
>> unlikely) or because some data was changed in transit (much more likely).
>>
>> Given how small the ML-KEM decapsulation failure rate is (2^-139 or
>> less), I wouldn't be surprised if random bit flips in transit that aren't
>> caught by a CRC or other check are more likely than ML-KEM decapsulation
>> failures. Since the two are indistinguishable to the client, the client
>> would have to handle them in the same way. So, I would suggest either
>> omitting this paragraph or just note that a decapsulation failure would be
>> indistinguishable from a scenario in which some data was changed in
>> transit, and so would be handled in the same way.
>>
>> On 3/13/24 7:08 PM, Deirdre Connolly wrote:
>>
>> 4. In the Discussion section (on github), does the portion on failures
>>> need to contain more information about how a failure should be handled in
>>> TLS? Should a decrypt_error alert be sent?
>>
>>
>> Oh very good point, DH doesn't usually fail like this; either because of
>> fundamental (incredibly unlikely) decapsulation failure rates, or just a
>> bug, this is good to handle, and we should probably update -hybrid-design
>> to match. I've tracked this in this GitHub issue
>> <https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/issues/1>
>> for now. For my own sake, here's the `decode_error` defintion from RFC
>> 8446:
>>
>> decode_error:  A message could not be decoded because some field was
>>
>>   out of the specified range or the length of the message was
>>
>>   incorrect.  This alert is used for errors where the message does
>>
>>   not conform to the formal protocol syntax.  This alert should
>>
>>   never be observed in communication between proper implementations,
>>
>>   except when messages were corrupted in the network.
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> --
>
> Sophie Schmieg | Information Security Engineer | ISE Crypto |
> sschm...@google.com
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Deirdre Connolly]

Whoops, I copy-pasted the wrong section, this is the definition for
'decrypt_error':

> decrypt_error:  A handshake (not record layer) cryptographic

operation failed, including being unable to correctly verify a
signature or validate a Finished message or a PSK binder.



On Wed, Mar 13, 2024, 10:08 PM Deirdre Connolly 
wrote:

> Thank you very much for the notes!
>
> A few specific comments:
>
>
>
>> 1. In Section 1.1 (or Introduction - Motivation in the github version), I
>> would suggest that the second sentence ("Having a fully post-quantum...")
>> is not needed, i.e. that there need not be a justification for why it is
>> necessary to specify how to use ML-KEM in TLS 1.3 (vs. hybrid). It could be
>> appropriate to contextualize the specification of ML-KEM w.r.t the advent
>> of a CRQC, though I also don't think that is necessary. As an example, we
>> can compare to the Introduction in draft-ietf-lamps-cms-kyber-03.
>
>
> Noted, tweaked on github slightly.
>
>
>
>> 2. Section 3 (Construction on github) currently reads, "We align with
>> [hybrid] except that instead of joining ECDH options with a KEM, we just
>> have the KEM as a NamedGroup." I think it is a more useful framing to base
>> this specification (for the use of a standalone algorithm) off of RFC 8446
>> instead of the draft spec for a hybrid solution. I understand wanting to
>> align the approach with the approach taken for the hybrid solution, but I
>> don't think that fact needs to be explicitly documented in this draft. When
>> this draft is standardized, I think it's important that it is able to be
>> read, understood, and implemented without needing to refer to the hybrid
>> draft. It could be stated (how it is in the hybrid draft), "ML-KEM-512 (if
>> included), ML-KEM-768, and ML-KEM-1024 are represented as a NamedGroup and
>> sent in the supported_groups extension."
>
>
> Good point, tweaked 👍
>
> 3. On a related note, the hybrid draft says, "Note that TLS 1.3 uses the
>> phrase "groups" to refer to key exchange algorithms -- for example, the
>> supported_groups extension -- since all key exchange algorithms in TLS 1.3
>> are Diffie-Hellman-based.  As a result, some parts of this document will
>> refer to data structures or messages with the term "group" in them despite
>> using a key exchange algorithm that is not Diffie-Hellman-based nor a
>> group."
>> This seems okay, but on the IANA registry for TLS Supported Groups, it
>> indicates 0-255 and 512-65535 are for elliptic curve groups, and 256-511
>> are for FFDH groups. Where does ML-KEM fit in? Do ranges need to be
>> re-evaluated? As an example, for IKEv2, RFC 9370 changes the name of
>> Transform Type 4 from Diffie-Hellman Group to Key Exchange Method in order
>> to accommodate QR KEMs.
>
>
> This is a good point: -hybrid-design allocates 0x6399 and 0x639A for the
> two hybrid `NamedGroup`s so far. I don't have a strong opinion here, I
> basically followed -hybrid-design's lead and picked 0x0768 and 0x1024 for
> ML-KEM-768 and ML-KEM-1024.
>
>
>
>> 4. In the Discussion section (on github), does the portion on failures
>> need to contain more information about how a failure should be handled in
>> TLS? Should a decrypt_error alert be sent?
>
>
> Oh very good point, DH doesn't usually fail like this; either because of
> fundamental (incredibly unlikely) decapsulation failure rates, or just a
> bug, this is good to handle, and we should probably update -hybrid-design
> to match. I've tracked this in this GitHub issue
> <https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/issues/1>
> for now. For my own sake, here's the `decode_error` defintion from RFC
> 8446:
>
> decode_error:  A message could not be decoded because some field was
>
>   out of the specified range or the length of the message was
>
>   incorrect.  This alert is used for errors where the message does
>
>   not conform to the formal protocol syntax.  This alert should
>
>   never be observed in communication between proper implementations,
>
>   except when messages were corrupted in the network.
>
>
>
> 5. In Section 4 (or Security Considerations on github), this may be a
>> silly question, but is the definition of "commits" well-understood (in the
>> first sentence on datatracker; in the first sentence of Binding properties
>> on github)? It is not used in RFC 8446 so it might be worth explaining the
>> meaning or using different phrasing in this sentence.
>
>
> 

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

[Deirdre Connolly]

I would argue adding `ML-KEM` as a standalone NamedGroup is not more
complex than adding ECDH groups, the hybrid part is the already complex
part. To minimize complexity even more, one can 'just' do the X-Wing style
of having a hybrid NamedGroup that doesn't know anything about the other
available component NamedGroups, ie, no shared ephemeral ECDH or KEM
keypairs: less complex, a little more compute. I want there to be an option
to negotiate ML-KEM alone, and turn off / not compile in the hybrid
NamedGroups if I want to in my TLS 1.3 stack, and I think there will be a
non-trivial user base for such an option very soon.




On Thu, Mar 14, 2024 at 7:34 AM Dennis Jackson  wrote:

> On 14/03/2024 01:41, Deirdre Connolly wrote:
>
> Oh and one more consideration: hybrid brings complexity, and presenting
> the pure-PQ solutions and their strictly lesser complexity (at the tradeoff
> of maybe taking more risk against newer schemes no matter how good we feel
> about their fundamental cryptographic foundations) is worthwhile in my
> opinion.
>
> On Wed, Mar 13, 2024 at 9:39 PM Deirdre Connolly 
> wrote:
>
>> [...] Shaking out all the negotiation decisions is desirable as well as
>> 'drawing the rest of the owl' for the pure PQ option implied in the
>> negotiation (are we going to copy the same ~1000 bytes for the PQ and
>> hybrid name groups, when sharing an ephemeral KEM keypair?).
>>
> This is an argument that supporting PQ-only and PQ-hybrid simultaneously
> will be more complex than just PQ-hybrids and require further changes at
> the TLS layer.
>
> Given we've already paid the (minimal) complexity cost of hybrids and
> switching to PQ-only seems strictly less secure, I'm really struggling to
> see the motivation at this point in time. Once we're in a position to
> remove the classical key exchanges from TLS entirely because we know
> they're ineffective, switching to PQ-only might then have more benefit
> since we could retire a lot of old code.
>
>
>> For CNSA 2.0, it is cited not as a compatibility _requirement_ of TLS,
>> but a note that a non-trivial segment of users of standard TLS that have
>> been traditionally compliant will not be in a few years, and they will come
>> knocking anyway. This is trying to skate where the puck is going.
>>
>> But also, the fact that CNSA 2.0 explicitly requires ML-KEM _only_ key
>> agreement in the next ~6-9 years is a strong vote of confidence in any
>> protocol doing this at all, so, TLS wouldn't be out on a limb to support
>> this, basically.
>>
>> I don't have a strong opinion on whether this should be Recommended = Y.
>>
>> On Wed, Mar 13, 2024 at 6:42 PM Eric Rescorla  wrote:
>>
>>>
>>>
>>> On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie >> 40uwe.nsa@dmarc.ietf.org> wrote:
>>>
>>>> Greetings Deirdre and TLS,
>>>>
>>>>
>>>>
>>>> I read through draft-connolly-tls-mlkem-key-agreement-00 (and
>>>> https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
>>>> and I have a few comments. First, though, I want to say thank you for
>>>> writing this draft. I'll echo some of what has already been voiced on this
>>>> thread and say that, while some plan to use composite key establishment, it
>>>> makes sense to also specify the use of standalone ML-KEM in TLS 1.3 as
>>>> another option. Other WGs (lamps and ipsecme) have already begun to specify
>>>> the use of standalone FIPS 203, 204, and 205 in various protocols. With
>>>> respect to this draft, there is certainly interest from National Security
>>>> System vendors in using standalone ML-KEM-1024 in TLS 1.3 for CNSA 2.0
>>>> compliance (as CNSA 2.0 does not require nor recommend hybrid solutions for
>>>> security).
>>>>
>>>
>>> I wanted to address this CNSA 2.0 point, as I've now seen it brought up
>>> a couple of times.
>>>
>>> The IETF, together with the IRTF, needs to make an independent judgement
>>> on whether using PQ-only algorithms is advisable, and if we do not think
>>> so, then we should not standardize them, regardless of what CNSA 2.0
>>> requires. The supported groups registry policies are designed explicitly to
>>> allow people to register non Standards Track algorithms, so nothing
>>> precludes the creation of an ML-KEM only code point if some vendors find
>>> that necessary, without the IETF standardizing them or marking them as
>>> Recommende

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

[Deirdre Connolly]

gt; thread and say that, while some plan to use composite key establishment, it
> makes sense to also specify the use of standalone ML-KEM in TLS 1.3 as
> another option. Other WGs (lamps and ipsecme) have already begun to specify
> the use of standalone FIPS 203, 204, and 205 in various protocols. With
> respect to this draft, there is certainly interest from National Security
> System vendors in using standalone ML-KEM-1024 in TLS 1.3 for CNSA 2.0
> compliance (as CNSA 2.0 does not require nor recommend hybrid solutions for
> security).
>
>
>
> A few specific comments:
>
>
>
> 1. In Section 1.1 (or Introduction - Motivation in the github version), I
> would suggest that the second sentence ("Having a fully post-quantum...")
> is not needed, i.e. that there need not be a justification for why it is
> necessary to specify how to use ML-KEM in TLS 1.3 (vs. hybrid). It could be
> appropriate to contextualize the specification of ML-KEM w.r.t the advent
> of a CRQC, though I also don't think that is necessary. As an example, we
> can compare to the Introduction in draft-ietf-lamps-cms-kyber-03.
>
>
>
> 2. Section 3 (Construction on github) currently reads, "We align with
> [hybrid] except that instead of joining ECDH options with a KEM, we just
> have the KEM as a NamedGroup." I think it is a more useful framing to base
> this specification (for the use of a standalone algorithm) off of RFC 8446
> instead of the draft spec for a hybrid solution. I understand wanting to
> align the approach with the approach taken for the hybrid solution, but I
> don't think that fact needs to be explicitly documented in this draft. When
> this draft is standardized, I think it's important that it is able to be
> read, understood, and implemented without needing to refer to the hybrid
> draft. It could be stated (how it is in the hybrid draft), "ML-KEM-512 (if
> included), ML-KEM-768, and ML-KEM-1024 are represented as a NamedGroup and
> sent in the supported_groups extension."
>
>
>
> 3. On a related note, the hybrid draft says, "Note that TLS 1.3 uses the
> phrase "groups" to refer to key exchange algorithms -- for example, the
> supported_groups extension -- since all key exchange algorithms in TLS 1.3
> are Diffie-Hellman-based.  As a result, some parts of this document will
> refer to data structures or messages with the term "group" in them despite
> using a key exchange algorithm that is not Diffie-Hellman-based nor a
> group."
>
> This seems okay, but on the IANA registry for TLS Supported Groups, it
> indicates 0-255 and 512-65535 are for elliptic curve groups, and 256-511
> are for FFDH groups. Where does ML-KEM fit in? Do ranges need to be
> re-evaluated? As an example, for IKEv2, RFC 9370 changes the name of
> Transform Type 4 from Diffie-Hellman Group to Key Exchange Method in order
> to accommodate QR KEMs.
>
>
>
> 4. In the Discussion section (on github), does the portion on failures
> need to contain more information about how a failure should be handled in
> TLS? Should a decrypt_error alert be sent?
>
>
>
> 5. In Section 4 (or Security Considerations on github), this may be a
> silly question, but is the definition of "commits" well-understood (in the
> first sentence on datatracker; in the first sentence of Binding properties
> on github)? It is not used in RFC 8446 so it might be worth explaining the
> meaning or using different phrasing in this sentence.
>
>
>
> Also, what are the WG's thoughts on including standalone PQC signatures in
> the same draft?
>
>
>
> Thanks in advance!
>
>
>
> Rebecca
>
>
>
> Rebecca Guthrie
>
> she/her
>
> Center for Cybersecurity Standards (CCSS)
>
> Cybersecurity Collaboration Center (CCC)
>
> National Security Agency (NSA)
>
>
>
> *From:* TLS  *On Behalf Of * Deirdre Connolly
> *Sent:* Tuesday, March 5, 2024 9:15 PM
> *To:* TLS@ietf.org
> *Subject:* [TLS] ML-KEM key agreement for TLS 1.3
>
>
>
> I have uploaded a preliminary version of ML-KEM for TLS 1.3
> <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/>
> and have a more fleshed out
> <https://github.com/dconnolly/draft-tls-mlkem-key-agreement> 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
> <https://datatracker.ietf.org/doc/draft-ietf-tls-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

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

[Deirdre Connolly]

Oh and one more consideration: hybrid brings complexity, and presenting the
pure-PQ solutions and their strictly lesser complexity (at the tradeoff of
maybe taking more risk against newer schemes no matter how good we feel
about their fundamental cryptographic foundations) is worthwhile in my
opinion.

On Wed, Mar 13, 2024 at 9:39 PM Deirdre Connolly 
wrote:

> Some considerations for ML-KEM alone (or another trusted PQ-only key
> agreement) are mainly looking towards the desired next step after hybrid
> key agreement, and instead of leaving that fuzzy and far off, talking about
> it in the present. This is also motivated by -hybrid-design allowing
> several traditional NamedGroups to be negotiated on their own, as hybrid
> NamedGroups with ML-KEM (although currently both are specified as Kyber but
> those will change), but no option to negotiate the other side of the hybrid
> alone, the PQ algorithm alone, Shaking out all the negotiation decisions is
> desirable as well as 'drawing the rest of the owl' for the pure PQ option
> implied in the negotiation (are we going to copy the same ~1000 bytes for
> the PQ and hybrid name groups, when sharing an ephemeral KEM keypair?).
>
> For CNSA 2.0, it is cited not as a compatibility _requirement_ of TLS, but
> a note that a non-trivial segment of users of standard TLS that have been
> traditionally compliant will not be in a few years, and they will come
> knocking anyway. This is trying to skate where the puck is going.
>
> But also, the fact that CNSA 2.0 explicitly requires ML-KEM _only_ key
> agreement in the next ~6-9 years is a strong vote of confidence in any
> protocol doing this at all, so, TLS wouldn't be out on a limb to support
> this, basically.
>
> I don't have a strong opinion on whether this should be Recommended = Y.
>
> On Wed, Mar 13, 2024 at 6:42 PM Eric Rescorla  wrote:
>
>>
>>
>> On Wed, Mar 13, 2024 at 2:36 PM Rebecca Guthrie > 40uwe.nsa@dmarc.ietf.org> wrote:
>>
>>> Greetings Deirdre and TLS,
>>>
>>>
>>>
>>> I read through draft-connolly-tls-mlkem-key-agreement-00 (and
>>> https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/blob/main/draft-connolly-tls-mlkem-key-agreement.md)
>>> and I have a few comments. First, though, I want to say thank you for
>>> writing this draft. I'll echo some of what has already been voiced on this
>>> thread and say that, while some plan to use composite key establishment, it
>>> makes sense to also specify the use of standalone ML-KEM in TLS 1.3 as
>>> another option. Other WGs (lamps and ipsecme) have already begun to specify
>>> the use of standalone FIPS 203, 204, and 205 in various protocols. With
>>> respect to this draft, there is certainly interest from National Security
>>> System vendors in using standalone ML-KEM-1024 in TLS 1.3 for CNSA 2.0
>>> compliance (as CNSA 2.0 does not require nor recommend hybrid solutions for
>>> security).
>>>
>>
>> I wanted to address this CNSA 2.0 point, as I've now seen it brought up a
>> couple of times.
>>
>> The IETF, together with the IRTF, needs to make an independent judgement
>> on whether using PQ-only algorithms is advisable, and if we do not think
>> so, then we should not standardize them, regardless of what CNSA 2.0
>> requires. The supported groups registry policies are designed explicitly to
>> allow people to register non Standards Track algorithms, so nothing
>> precludes the creation of an ML-KEM only code point if some vendors find
>> that necessary, without the IETF standardizing them or marking them as
>> Recommended=Y.
>> -Ekr
>>
>>
>>
>>
>>>
>>> A few specific comments:
>>>
>>>
>>>
>>> 1. In Section 1.1 (or Introduction - Motivation in the github version),
>>> I would suggest that the second sentence ("Having a fully post-quantum...")
>>> is not needed, i.e. that there need not be a justification for why it is
>>> necessary to specify how to use ML-KEM in TLS 1.3 (vs. hybrid). It could be
>>> appropriate to contextualize the specification of ML-KEM w.r.t the advent
>>> of a CRQC, though I also don't think that is necessary. As an example, we
>>> can compare to the Introduction in draft-ietf-lamps-cms-kyber-03.
>>>
>>>
>>>
>>> 2. Section 3 (Construction on github) currently reads, "We align with
>>> [hybrid] except that instead of joining ECDH options with a KEM, we just
>>> have the KEM as a NamedGroup." I think it is a more useful framing to base
>>&

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

[Deirdre Connolly]

ension."
>>
>>
>>
>> 3. On a related note, the hybrid draft says, "Note that TLS 1.3 uses the
>> phrase "groups" to refer to key exchange algorithms -- for example, the
>> supported_groups extension -- since all key exchange algorithms in TLS 1.3
>> are Diffie-Hellman-based.  As a result, some parts of this document will
>> refer to data structures or messages with the term "group" in them despite
>> using a key exchange algorithm that is not Diffie-Hellman-based nor a
>> group."
>>
>> This seems okay, but on the IANA registry for TLS Supported Groups, it
>> indicates 0-255 and 512-65535 are for elliptic curve groups, and 256-511
>> are for FFDH groups. Where does ML-KEM fit in? Do ranges need to be
>> re-evaluated? As an example, for IKEv2, RFC 9370 changes the name of
>> Transform Type 4 from Diffie-Hellman Group to Key Exchange Method in order
>> to accommodate QR KEMs.
>>
>>
>>
>> 4. In the Discussion section (on github), does the portion on failures
>> need to contain more information about how a failure should be handled in
>> TLS? Should a decrypt_error alert be sent?
>>
>>
>>
>> 5. In Section 4 (or Security Considerations on github), this may be a
>> silly question, but is the definition of "commits" well-understood (in the
>> first sentence on datatracker; in the first sentence of Binding properties
>> on github)? It is not used in RFC 8446 so it might be worth explaining the
>> meaning or using different phrasing in this sentence.
>>
>>
>>
>> Also, what are the WG's thoughts on including standalone PQC signatures
>> in the same draft?
>>
>>
>>
>> Thanks in advance!
>>
>>
>>
>> Rebecca
>>
>>
>>
>> Rebecca Guthrie
>>
>> she/her
>>
>> Center for Cybersecurity Standards (CCSS)
>>
>> Cybersecurity Collaboration Center (CCC)
>>
>> National Security Agency (NSA)
>>
>>
>>
>> *From:* TLS  *On Behalf Of * Deirdre Connolly
>> *Sent:* Tuesday, March 5, 2024 9:15 PM
>> *To:* TLS@ietf.org
>> *Subject:* [TLS] ML-KEM key agreement for TLS 1.3
>>
>>
>>
>> I have uploaded a preliminary version of ML-KEM for TLS 1.3
>> <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/>
>> and have a more fleshed out
>> <https://github.com/dconnolly/draft-tls-mlkem-key-agreement> 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
>> <https://datatracker.ietf.org/doc/draft-ietf-tls-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] [EXT] Re: ML-KEM key agreement for TLS 1.3

[Deirdre Connolly]

Agreed with ekr.

On Wed, Mar 13, 2024 at 6:27 PM Eric Rescorla  wrote:

>
>
> On Wed, Mar 13, 2024 at 3:07 PM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
>> Also, what are the WG's thoughts on including standalone PQC signatures
>> in the same draft?
>>
>>
>>
>> I think that including standalone PQC sigs would be very desirable.
>>
>
> I don't think there is any particular reason to include PQC signatures in
> the same draft as PQ key establishment. In TLS 1.3, key establishment and
> signature are orthogonal concepts, and it will be easier to review if they
> are kept in separate documents.
>
> -Ekr
>
>
>>
>>
>>
>> *From:* TLS  *On Behalf Of *Deirdre Connolly
>> *Sent:* Tuesday, March 5, 2024 9:15 PM
>> *To:* TLS@ietf.org
>> *Subject:* [TLS] ML-KEM key agreement for TLS 1.3
>>
>>
>>
>> I have uploaded a preliminary version of ML-KEM for TLS 1.3
>> <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/>
>> and have a more fleshed out
>> <https://github.com/dconnolly/draft-tls-mlkem-key-agreement> 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
>> <https://datatracker.ietf.org/doc/draft-ietf-tls-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

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

[Deirdre Connolly]

"At the 2024 Workshop on Measurements, Attacks, and Defenses for the Web
(MADweb), we presented a paper¹ advocating time to last byte (TTLB) as a
metric for assessing the total impact of data-heavy, quantum-resistant
algorithms such as ML-KEM and ML-DSA on real-world TLS 1.3 connections. Our
paper shows that the new algorithms will have a much lower net effect on
connections that transfer sizable amounts of data than they do on the TLS
1.3 handshake itself."

https://www.amazon.science/blog/delays-from-post-quantum-cryptography-may-not-be-so-bad

¹
https://www.amazon.science/publications/the-impact-of-data-heavy-post-quantum-tls-1-3-on-the-time-to-last-byte-of-real-world-connections/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Deirdre Connolly]

> Isn't support for the component mandatory to support the hybrid anyway?

Strictly speaking, not necessarily: I could see support for X-Wing or
another hybrid key agreement as a standalone unit, both from a software
dependency perspective and protocol API perspective. Whether that works in
the long term that also supports the standalone component algorithms,
that's another question

On Wed, Mar 6, 2024, 11:30 PM Orie Steele  wrote:

> Does the argument about hybrid code points first generalize to all PQ Code
> points?
>
> Is it equally true of hybrid signatures?
>
> I don't understand why registering composite components first wouldn't be
> assumed.
>
> Isn't support for the component mandatory to support the hybrid anyway?
>
> Let's assume CRQC drops tomorrow, why did we not register ML-KEM first?
>
> Assume it never drops, you still needed to implement ML-KEM to use the
> hybrid.
>
> If the goal is to prohibit ML-KEM without a traditional component, just
> register it as prohibited.
>
> OS
>
> On Wed, Mar 6, 2024, 10:10 PM Bas Westerbaan  40cloudflare@dmarc.ietf.org> wrote:
>
>> 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
>>> <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/>
>>> and have a more fleshed out
>>> <https://github.com/dconnolly/draft-tls-mlkem-key-agreement> 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
>>> <https://datatracker.ietf.org/doc/draft-ietf-tls-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
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Deirdre Connolly]

No objection there 👍

On Wed, Mar 6, 2024, 11:10 PM Bas Westerbaan  wrote:

> 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
>> <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/>
>> and have a more fleshed out
>> <https://github.com/dconnolly/draft-tls-mlkem-key-agreement> 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
>> <https://datatracker.ietf.org/doc/draft-ietf-tls-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

[Deirdre Connolly]

> So I think the question here should be focused on "what level of
confidence would IETF need to specify ML-KEM standalone at Proposed
Standard with Recommended=Y".

On 'Recommended=Y' I figured it would not be for a while, but it is
available.

>  I don't think there is anywhere near enough confidence in any of the PQ
algorithms to confidently use it standalone,

Crystals-Kyber was introduced in at least 2017, it has gone through many
rounds of analysis, and is now over 7 years old, close to the '10 years' I
often hear quoted as a benchmark for new crypto to marinate I guess. I
understand caution but having the option (not the recommendation) to
support pure-PQ seems reasonable to sort out sooner than later, both to
face the complexity of managing pure traditional, hybrid, and pure PQ
negotiation now, but also to keep the eventual goal of pure PQ clear in
mind, and taken seriously.

On Wed, Mar 6, 2024 at 12:21 PM Eric Rescorla  wrote:

>
>
> On Wed, Mar 6, 2024 at 8:49 AM Deirdre Connolly 
> 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.
>
> I'm open to being persuaded, but at the moment, I don't think there is
> anywhere near enough confidence in any of the PQ algorithms to confidently
> use it standalone, which means we're going to see a lot of hybrid
> deployment sooner rather than later. This also means that we're going to
> have a long tail of clients and servers which only do hybrid and not
> PQ-only, so that complexity is baked in for quite some time to come.
>
>
>> In the more concrete scope, FIPS / CNSA 2.0 compliance guidelines
>> <https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF>
>> currently are a big 'maybe' at best for 'hybrid solutions', and the
>> timetables for compliant browsers, servers, and services are to exclusively
>> use FIPS 203 at level V (ML-KEM-1024) by 2033. I figure there will be
>> demand for pure ML-KEM key agreement, not hybrid (with no questions that
>> come along with it of whether it's actually allowed or not).
>>
>
> I'm honestly not moved by this very much. IETF should form its own opinion
> about the security of algorithms, not just take whatever opinions are
> handed down from NIST. If that means that IETF doesn't standardize what
> NIST wants, then NIST is free to register its own codepoints and try to
> persuade implementors to take them.
>
> So I think the question here should be focused on "what level of
> confidence would IETF need to specify ML-KEM standalone at Proposed
> Standard with Recommended=Y".
>
> -Ekr
>
>
>> Relatedly, the currently adopted -hybrid-design
>> <https://dstebila.github.io/draft-ietf-tls-hybrid-design/draft-ietf-tls-hybrid-design.html>
>> outlines several combinations of ECDH and KEM, and allows computing the
>> ECDH share once and sharing it between an ECDH share and a hybrid ECDH+KEM
>> share, but there is no equivalent for just using a KEM on its own, and
>> computing its shared secret once and advertising it as both standalone and
>> in a hybrid share. So I think defining these standalone ML-KEM
>> `NamedGroup`s also 'draws the rest of the owl' implied by -hybrid-design.
>>
>> On Wed, Mar 6, 2024 at 10:12 AM Eric Rescorla  wrote:
>>
>>> Deirdre, thanks for submitting this. Can you say what the motivation is
>>> for being "fully post-quantum" rather than hybrid?
>>>
>>> Thanks,
>>> -Ekr
>>>
>>>
>>>
>>> On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly <
>>> durumcrustu...@gmail.com> wrote:
>>>
>>>> I have uploaded a preliminary version of ML-KEM for TLS 1.3
>>>> <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/>
>>>> and have a more fleshed out
>>>> <https://github.com/dconnolly/draft-tls-mlkem-key-agreement> 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
>>>> <https://datatracker.ietf.org/doc/draft-ietf-tls-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

[Deirdre Connolly]

My current draft does not include ML-KEM-512, mostly because there seems to
be alignment around ML-KEM-768 being ~equivalent to say X25519 or P-256
ECDH in terms of security level. I'm not married strongly to excluding it
but that was kind of the thinking.

On Wed, Mar 6, 2024 at 11:25 AM John Mattsson 
wrote:

> I think TLS should register all algorithm variants standardized by NIST.
> That means ML-KEM-512, ML-KEM-768, and ML-KEM-1024. And in the future a
> subset of HQC/BIKE/Classic McEliece.
>
> I think the TLS discussions are way too focused on a single ephemeral key
> exchange. A growing use of TLS is for mutually authenticated interfaces.
> When IPsec is used, rekeying is typically done with ephemeral key exchange
> every 1 hour or 100 GB following ANSSI requirements. The telecom industry
> would like to keep that practice when TLS/DTLS/QUIC is used instead. In TLS
> 1.3 that means resumption with psk_dhe_ke. I don’t think you need to use
> the same algorithm in the initial handshake and the resumption. You can
> e.g., use ML-KEM-1024 + x25519 in the initial handshake and then ML-KEM-512
> in resumption. You could also use McEliece initially and then ML-KEM. I
> think you could even use ML-KEM + x25519 in the initial handshake and then
> x25519 during resumption. I think these choices should be left to the
> application.
>
> Cheers,
> John Preuß Mattson
>
> Sent from Outlook for iOS <https://aka.ms/o0ukef>
> --
> *From:* TLS  on behalf of John Mattsson
> 
> *Sent:* Wednesday, March 6, 2024 4:57:10 PM
> *To:* Deirdre Connolly 
> *Cc:* TLS@ietf.org 
> *Subject:* Re: [TLS] ML-KEM key agreement for TLS 1.3
>
>
> Thanks Deirdre,
>
>
>
> I would like to use hybrid but I strongly believe that registering things
> as standalone NamedGroups and then let TLS negotiate which combinations to
>  use is the right one long-term. This is the approch chosen be IKEv2.
>
>
>
> - As EKR pointed out the word "fully" would need explanation.
>
>
>
> - We align with [hybrid] except that instead of joining ECDH options
>
>   with a KEM, we just have the KEM as a NamedGroup.
>
>
>
>   I don't understand. We align with hybrid by not being hybrid?
>
>
>
> - encapsulated shared secret ciphertext
>
>
>
> Maybe shared secret encapsulated in the ciphertext?
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *TLS  on behalf of Eric Rescorla <
> e...@rtfm.com>
> *Date: *Wednesday, 6 March 2024 at 16:12
> *To: *Deirdre Connolly 
> *Cc: *TLS@ietf.org 
> *Subject: *Re: [TLS] ML-KEM key agreement for TLS 1.3
>
> Deirdre, thanks for submitting this. Can you say what the motivation is
> for being "fully post-quantum" rather than hybrid?
>
>
>
> Thanks,
>
> -Ekr
>
>
>
>
>
>
>
> On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly 
> wrote:
>
> I have uploaded a preliminary version of ML-KEM for TLS 1.3
> <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/>
> and have a more fleshed out
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-864093ca9ffba626&q=1&e=c11b4b5f-f194-49c4-a720-c34e25cc52c2&u=https%3A%2F%2Fgithub.com%2Fdconnolly%2Fdraft-tls-mlkem-key-agreement>
>  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
> <https://datatracker.ietf.org/doc/draft-ietf-tls-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

[Deirdre Connolly]

>  I don't understand. We align with hybrid by not being hybrid?

Ah sorry, I mean on the design of how the client shares an
ephemeral encapsulation key in their `ClientHello` and how the server
replies with the ciphertext in their `ServerHello`, and generally aligning
in design and encoding with -hybrid-design, I'll clarify.

On Wed, Mar 6, 2024 at 10:57 AM John Mattsson 
wrote:

> Thanks Deirdre,
>
>
>
> I would like to use hybrid but I strongly believe that registering things
> as standalone NamedGroups and then let TLS negotiate which combinations to
>  use is the right one long-term. This is the approch chosen be IKEv2.
>
>
>
> - As EKR pointed out the word "fully" would need explanation.
>
>
>
> - We align with [hybrid] except that instead of joining ECDH options
>
>   with a KEM, we just have the KEM as a NamedGroup.
>
>
>
>   I don't understand. We align with hybrid by not being hybrid?
>
>
>
> - encapsulated shared secret ciphertext
>
>
>
> Maybe shared secret encapsulated in the ciphertext?
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *TLS  on behalf of Eric Rescorla <
> e...@rtfm.com>
> *Date: *Wednesday, 6 March 2024 at 16:12
> *To: *Deirdre Connolly 
> *Cc: *TLS@ietf.org 
> *Subject: *Re: [TLS] ML-KEM key agreement for TLS 1.3
>
> Deirdre, thanks for submitting this. Can you say what the motivation is
> for being "fully post-quantum" rather than hybrid?
>
>
>
> Thanks,
>
> -Ekr
>
>
>
>
>
>
>
> On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly 
> wrote:
>
> I have uploaded a preliminary version of ML-KEM for TLS 1.3
> <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/>
> and have a more fleshed out
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-864093ca9ffba626&q=1&e=c11b4b5f-f194-49c4-a720-c34e25cc52c2&u=https%3A%2F%2Fgithub.com%2Fdconnolly%2Fdraft-tls-mlkem-key-agreement>
>  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
> <https://datatracker.ietf.org/doc/draft-ietf-tls-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

[Deirdre Connolly]

> 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.

In the more concrete scope, FIPS / CNSA 2.0 compliance guidelines
<https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF>
currently are a big 'maybe' at best for 'hybrid solutions', and the
timetables for compliant browsers, servers, and services are to exclusively
use FIPS 203 at level V (ML-KEM-1024) by 2033. I figure there will be
demand for pure ML-KEM key agreement, not hybrid (with no questions that
come along with it of whether it's actually allowed or not).

Relatedly, the currently adopted -hybrid-design
<https://dstebila.github.io/draft-ietf-tls-hybrid-design/draft-ietf-tls-hybrid-design.html>
outlines several combinations of ECDH and KEM, and allows computing the
ECDH share once and sharing it between an ECDH share and a hybrid ECDH+KEM
share, but there is no equivalent for just using a KEM on its own, and
computing its shared secret once and advertising it as both standalone and
in a hybrid share. So I think defining these standalone ML-KEM
`NamedGroup`s also 'draws the rest of the owl' implied by -hybrid-design.

On Wed, Mar 6, 2024 at 10:12 AM Eric Rescorla  wrote:

> Deirdre, thanks for submitting this. Can you say what the motivation is
> for being "fully post-quantum" rather than hybrid?
>
> Thanks,
> -Ekr
>
>
>
> On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly 
> wrote:
>
>> I have uploaded a preliminary version of ML-KEM for TLS 1.3
>> <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/>
>> and have a more fleshed out
>> <https://github.com/dconnolly/draft-tls-mlkem-key-agreement> 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
>> <https://datatracker.ietf.org/doc/draft-ietf-tls-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] Proposal: a TLS formal analysis triage panel

[Deirdre Connolly]

> it's unclear to me whether this review would be a hard requirement to
pass WGLC. Let's say a document makes it to that stage, and it is sent to
the triage panel, but the panel never produces a formal analysis of it.
(This could happen for example if the researchers don't find the extension
at hand interesting enough, they're volunteering to help so I wouldn't
blame them for picking what they want to work on.) In that hypothetical
scenario, does the document proceed without formal analysis, or is it
blocked?

Indeed; the interaction with the panel would be in two phases: any changes
that are being proposed by/to the WG would have a preliminary triage of
whether such changes _should_ have formal analysis, and of what scope/type.
This would probably be nicely triggered by an adoption call. Ideally we'd
have a sense from the panel of whether the proposed changes would entail a
significant amount of formal analysis work from the get-go, or not. This
preliminary triage can help inform the adoption call discussion.

If the proposal is adopted, and the working group has received a formal
analysis triage from the panel, and accepts the general scope of work to be
a requirement / blocker before moving to WGLC, then it is. We then work
with the panel to select the researchers/whomever to conduct the analysis,
which may entail rounds of back and forth if the document changes over
time.

There may be changes that, on triage from the panel, are 'easy' and may not
require updated analysis at all, or very little. The WG may agree to adopt
the document and agree to proceed to WGLC _without_ formal analysis, with
the implicit understanding that the adopted document and the one
approaching WGLC will not have significantly diverged from each other. If
we are worried about this, we can implement a sort of 'last chance' review
with the panel to make sure we aren't missing something on such a document
before actually triggering the WGLC.

This is sort of what I had in mind, but am of course welcome to suggestions
or changes. 😁

On Tue, Mar 5, 2024 at 9:12 PM David Schinazi 
wrote:

> Hi Deirdre,
>
> Thanks for this, I think this is a great plan. From the perspective of
> standards work, more formal analysis is always better, and this seems like
> a great way to motivate such work.
>
> That said, it's unclear to me whether this review would be a hard
> requirement to pass WGLC. Let's say a document makes it to that stage, and
> it is sent to the triage panel, but the panel never produces a formal
> analysis of it. (This could happen for example if the researchers don't
> find the extension at hand interesting enough, they're volunteering to help
> so I wouldn't blame them for picking what they want to work on.) In that
> hypothetical scenario, does the document proceed without formal analysis,
> or is it blocked?
>
> Thanks,
> David
>
> On Tue, Mar 5, 2024 at 5:38 PM Deirdre Connolly 
> wrote:
>
>> A few weeks ago, we ran a WGLC on 8773bis, but it basically came up
>> blocked because of a lack of formal analysis of the proposed changes. The
>> working group seems to be in general agreement that any changes to TLS 1.3
>> should not degrade or violate the existing formal analyses and proven
>> security properties of the protocol whenever possible. Since we are no
>> longer in active development of a new version of TLS, we don't necessarily
>> have the same eyes of researchers and experts in formal analysis looking at
>> new changes, so we have to adapt.
>>
>> I have mentioned these issues to several experts who have analyzed TLS
>> (in total or part) in the past and have gotten tentative buy-in from more
>> than one for something like a 'formal analysis triage panel': a rotating
>> group of researchers, formal analysis experts, etc, who have volunteered to
>> give 1) a preliminary triage of proposed changes to TLS 1.3¹ and _whether_
>> they could do with an updated or new formal analysis, and 2) an estimate of
>> the scope of work such an analysis would entail. Such details would be
>> brought back to the working group for discussion about whether the proposed
>> changes merit the recommended analysis or not (e.g., a small, nice-to-have
>> change may actually entail a fundamentally new security model change,
>> whereas a large change may not deviate significantly from prior analysis
>> and be 'cheap' to do). If the working group agrees to proceed, the formal
>> analysis triage panel consults on farming out the meat of the analysis work
>> (either to their teams or to students they supervise, etc.).\ Group
>> membership can be refreshed on a regular schedule or on an as-needed basis.
>> Hopefully the lure of 

[TLS] ML-KEM key agreement for TLS 1.3

[Deirdre Connolly]

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] Proposal: a TLS formal analysis triage panel

[Deirdre Connolly]

A few weeks ago, we ran a WGLC on 8773bis, but it basically came up blocked
because of a lack of formal analysis of the proposed changes. The working
group seems to be in general agreement that any changes to TLS 1.3 should
not degrade or violate the existing formal analyses and proven security
properties of the protocol whenever possible. Since we are no longer in
active development of a new version of TLS, we don't necessarily have the
same eyes of researchers and experts in formal analysis looking at new
changes, so we have to adapt.

I have mentioned these issues to several experts who have analyzed TLS (in
total or part) in the past and have gotten tentative buy-in from more than
one for something like a 'formal analysis triage panel': a rotating group
of researchers, formal analysis experts, etc, who have volunteered to give
1) a preliminary triage of proposed changes to TLS 1.3¹ and _whether_ they
could do with an updated or new formal analysis, and 2) an estimate of the
scope of work such an analysis would entail. Such details would be brought
back to the working group for discussion about whether the proposed changes
merit the recommended analysis or not (e.g., a small, nice-to-have change
may actually entail a fundamentally new security model change, whereas a
large change may not deviate significantly from prior analysis and be
'cheap' to do). If the working group agrees to proceed, the formal analysis
triage panel consults on farming out the meat of the analysis work (either
to their teams or to students they supervise, etc.).\ Group membership can
be refreshed on a regular schedule or on an as-needed basis. Hopefully the
lure of 'free' research questions will be enticing.

The goal is to maintain the high degree of cryptographic assurance in TLS
1.3 as it evolves as one of the world's most-used cryptographic protocols.

I would like to hear thoughts on this idea from the group and if we would
like to put it on the agenda for 119.

Cheers,
Deirdre

¹ 1.3 has the most robust analysis; we'll see about other versions

-- Forwarded message -
From: Joseph Salowey 
Date: Tue, Jan 23, 2024 at 10:51 AM
Subject: [TLS] Completion of Update Call for RFC 8773bis
To:  


The working group last call for RFC8773bis has completed
(draft-ietf-tls-8773bis). There was general support for moving the document
forward and upgrading its status. However, several working group
participants raised the concern that formal analysis has not been conducted
on this modification to the TLS protocol. We should at least have consensus
on whether this document has the required analysis before upgrading it, but
we also need a more general statement on this requirement since the TLS
working group currently does not have a policy for what does and does not
need formal analysis or what constitutes proper formal analysis.

The chairs are working on a proposal for handling situations like this that
we plan to post to the list in a week or so.

Thanks,

Joe, Deirdre, and Sean
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Deirdre Connolly]

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

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

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

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

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

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

[Deirdre Connolly]

Hi all,

Thanks to everyone who chimed in on this adoption call. It looks like there
is consensus to adopt this as a WG item and volunteers to help review.
Rich, can you please submit draft-ietf-tls-tls12-frozen-00 to datatracker,
and transfer the GitHub repo to the tlswg GitHub org?
Thank you!

Cheers,
Deirdre, for the holiday chairs ✨

On Thu, Dec 14, 2023 at 6:40 AM William Stratton Apsokardu <
williamsapsokardu...@outlook.com> wrote:

> Facebook Facebook
> FacebookFacebook
> Get Outlook for iOS 
> --
> *From:* TLS  on behalf of Nimrod Aviram <
> nimrod.avi...@gmail.com>
> *Sent:* Wednesday, December 13, 2023 9:49:55 AM
> *To:* Ilari Liusvaara 
> *Cc:* TLS@ietf.org 
> *Subject:* Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
>
> Hi Ilari, thanks for the clarification!
>
> I attempted to correct the text.
> Would you be willing to review the change? It's here:
>
> https://github.com/richsalz/tls12-frozen/commit/a1ce7ede97897e291af44f0c2f4fc225a2ca4447
>
> thanks,
> Nimrod
>
>
> On Tue, 12 Dec 2023 at 19:22, Ilari Liusvaara 
> wrote:
>
> On Fri, Dec 08, 2023 at 05:47:01PM +, Salz, Rich wrote:
> >
> > Good point.  https://github.com/richsalz/tls12-frozen/pull/12 has the
> > change.  I’ll wait until/if this is adopted by the WG to merge it.
>
> Reading through the document, I noticed the following:
>
> "To securely deploy TLS 1.2, either renegotiation must be disabled
> entirely, or this extension must be present." (where this extension
> means renegotiation_info)
>
>
> Entirely disabling renegotiation is not sufficient to fix the
> renegotiation issue in TLS 1.2. For fixing the issue, renegotiation_info
> MUST be required both ways.
>
> And then there is the other part to the triple handshake attack where
> using TLS exporters for authentication without extended_master_secret
> extension is insecure, even if renegotiation is not supported at all
> by either side and both sides implement renegotiation_info.
>
> And then there is more dangerously flawed stuff, e.g., session tickets
> (technically an extension).
>
>
>
>
> -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

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

[Deirdre Connolly]

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

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

[Deirdre Connolly]

Whoops wrong one, strike that

On Sun, Dec 3, 2023, 3:28 PM Deirdre Connolly 
wrote:

> At least one bit of work:
> https://dl.acm.org/doi/abs/10.1145/3548606.3559360
>
> On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla  wrote:
>
>> What do we have in terms of formal analysis for this extension?
>>
>> -Ekr
>>
>>
>> On Fri, Dec 1, 2023 at 11:40 AM Russ Housley 
>> wrote:
>>
>>> I think this should move forward.  I am encouraged that at least two
>>> people have spoken to me about their implementations.
>>>
>>> Russ
>>>
>>> On Nov 29, 2023, at 10:51 AM, Joseph Salowey  wrote:
>>>
>>> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an
>>> External Pre-Shared Key) was originally published as experimental due to
>>> lack of implementations. As part of implementation work for the EMU
>>> workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
>>> ongoing implementation work. Since the implementation status of RFC 8773 is
>>> changing, this is a consensus call to move RFC 8773 to standards track as
>>> reflected in [RFC8773bis](
>>> https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). This will
>>> also help avoid downref for the EMU draft.  Please indicate if you approve
>>> of or object to this transition to standards track status by December 15,
>>> 2023.
>>>
>>> Thanks,
>>>
>>> Joe, Sean, and 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
>>>
>> ___
>> 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] Call to Move RFC 8773 from Experimental to Standards Track

[Deirdre Connolly]

At least one bit of work:
https://dl.acm.org/doi/abs/10.1145/3548606.3559360

On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla  wrote:

> What do we have in terms of formal analysis for this extension?
>
> -Ekr
>
>
> On Fri, Dec 1, 2023 at 11:40 AM Russ Housley  wrote:
>
>> I think this should move forward.  I am encouraged that at least two
>> people have spoken to me about their implementations.
>>
>> Russ
>>
>> On Nov 29, 2023, at 10:51 AM, Joseph Salowey  wrote:
>>
>> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an
>> External Pre-Shared Key) was originally published as experimental due to
>> lack of implementations. As part of implementation work for the EMU
>> workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
>> ongoing implementation work. Since the implementation status of RFC 8773 is
>> changing, this is a consensus call to move RFC 8773 to standards track as
>> reflected in [RFC8773bis](
>> https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). This will also
>> help avoid downref for the EMU draft.  Please indicate if you approve of or
>> object to this transition to standards track status by December 15, 2023.
>>
>> Thanks,
>>
>> Joe, Sean, and 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
>>
> ___
> 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] TLS chair update: Deirdre Connolly replacing Christopher Wood

[Deirdre Connolly]

Thanks Paul! Happy to contribute. 😁

On Fri, Nov 17, 2023, 7:33 AM Paul Wouters  wrote:

> Hi everyone,
>
> At the IETF we try to change chairs regularly for a variety of reasons. We
> like to encourage new participants to gain chairing experience alongside
> more experienced chairs. This also prevents ossification of WGs :)
>
> Christopher Wood has stepped down as TLS WG chair and Deirdre Connolly has
> stepped up to replace him. Thanks to Chris for all his work and welcome to
> Deirdre!
>
> Paul
> ___
> 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] Clarifying generating key exchange values for hybrid key_change in draft-ietf-tls-hybrid-design

[Deirdre Connolly]

Hey there TLSWG ✨

I have opened a PR to make explicit the supported mechanisms for generating
ephemeral keys in hybrid TLS 1.3 key exchanges, especially where the
component algorithms of the hybrid `NamedGroup` may also be supported as
their own `NamedGroup`s in a `ClientHello`, and how to share (or not share)
values in that message:

https://github.com/dstebila/draft-ietf-tls-hybrid-design/pull/31

There are at least two documents instantiating new hybrid `NamedGroup`s as
laid out in this document and they are all a bit... loose in what is the
correct or acceptable methods of generating this ephemeral key material, so
I am suggesting explicit supported mechanisms to take the guess work out of
it.

Cheers,
Deirdre
___
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?

[Deirdre Connolly]

There are several documents in a cluster that define new hybrid
`NamedGroup`s and how those operate / are combined, abstracted away from
the rest of the TLS handshake. Treating hybrid schemes (key establishment,
signatures) as /separate and distinct from their component algorithms/ is a
good idea.

https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-09.html
https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-03.html
https://www.ietf.org/archive/id/draft-kwiatkowski-tls-ecdhe-kyber-01.html

I am aware of multiple implementations
 and at least one deployment

of the proposed `NamedGroup` `X25519Kyber768Draft00`, so


On Thu, Nov 9, 2023 at 12:01 PM Scott Fluhrer (sfluhrer)  wrote:

> We had that argument several IETF’s ago (IETF 105?), and the clear
> consensus of the working group was that explicit named hybrid combinations
> (e.g. one for ML-KEM-512 + X25519) was the way to go.
>
>
>
> Do we want to reopen that argument?  Now, I was on the other side (and I
> still think it would be a better engineering decision, given the right
> negotiation mechanism), but if it delays actual deployment, I would prefer
> if we didn’t.
>
>
>
> *From:* TLS  *On Behalf Of *John Mattsson
> *Sent:* Thursday, November 9, 2023 3:48 AM
> *To:* Sophie Schmieg ; tls@ietf.org
> *Subject:* Re: [TLS] What is the TLS WG plan for quantum-resistant
> algorithms?
>
>
>
> Hi,
>
>
>
> Everybody seem to agree that hybrids should be specified. Looking in my
> crystal ball, I predict that registering hybrids as code points will be a
> big mess with way too many opinions and registrations similar to the TLS
> 1.2 cipher suites. The more I think about it, the more I think TLS 1.3
> should standardize a generic solution for combining two or more key shares.
>
>
>
> My understanding of what would be needed:
>
>
>
> - New "split_key_PRF" extension indicating that client supports split-key
> PRF.
>
>
>
> - When "split_key_PRF" is negotiated the server may chose more than one
> group/key share.
>
>
>
>   struct {
>
>   NamedGroup selected_groups<0..2^16-1>;
>
>   } KeyShareHelloRetryRequest;
>
>
>
>  struct {
>
>   KeyShareEntry server_shares<0..2^16-1>;
>
>   } KeyShareServerHello;
>
>
>
> - When "split_key_PRF" is negotiated HKDF-Expand(Secret, HkdfLabel,
> Length) is replaced by a split-key PRF(Secret1, Secret2, ... , HkdfLabel,
> Length)
>
>
>
> I think the current structure that the TLS server makes the decisions on
> “groups” and “key shares” should be kept.
>
>
>
> There was a short discussion earlier on the list
>
> https://mailarchive.ietf.org/arch/msg/tls/Z-s8A0gZsRudZ9hW4VoCsNI9YUU/
>
>
>
>
>
> Sophie Schmieg sschm...@google.com wrote:
>
> ”Our stated intention is to move to Kyber once NIST releases the standard”
>
> “I do not think it makes a lot of sense to have multiple schemes based on
> structured lattices in TLS, and Kyber is in my opinion the superior
> algorithm.”
>
>
>
> I agree with that.
>
>
>
> Cheers,
>
> John Preuß Mattsson
>
>
>
>
>
>
>
> *From: *TLS  on behalf of Sophie Schmieg <
> sschmieg=40google@dmarc.ietf.org>
> *Date: *Thursday, 9 November 2023 at 08:40
> *To: *tls@ietf.org 
> *Subject: *Re: [TLS] What is the TLS WG plan for quantum-resistant
> algorithms?
>
> > > On 8 Nov 2023, at 8:34, Loganaden Velvindron 
> wrote:
> > >
> > > I support moving forward with hybrids as a proactively safe deployment
> > > option. I think that supporting
> > > only Kyber for KEX  is not enough. It would make sense to have more
> options.
> > >
> > > Google uses NTRU HRSS internally:
> > >
> https://cloud.google.com/blog/products/identity-security/why-google-now-uses-post-quantum-cryptography-for-internal-comms
> 
> > >
> > > If Google decides to use this externally, how easy would it be to get
> > > a codepoint for TLS ?
> > As easy as writing it up in a stable document (may or may not be an
> Internet-draft) and asking IANA for a code point assignment.
> >
> > It can be done in days, if needed.
> >
> >  Yoav
>
> Just to clarify a few things about our internal usage of NTRU-HRSS: This
> is for historic reasons.
>
> Our stated intention is to move to Kyber once NIST releases the standard,
> see e.g. my talk at PQCrypto [1], where I go into some detail on this topic.
>
> Long story short, we had to choose a candidate well before even NIST's
> round 3 announcement, and haven't changed since changing a ciphersuite,
> while relatively straightforward is not free, so we would like to avoid
> doing it twice in a year.
>
> The only security consideration that went into the decision for NTRU was

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

[Deirdre Connolly]

https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-03
defines the `X25519Kyber768Draft00` `NamedGroup` as 0x6399
https://datatracker.ietf.org/doc/html/draft-kwiatkowski-tls-ecdhe-kyber-01
defines the `SecP256r1Kyber768Draft00` `NamedGroup` as 0x639A


On Mon, Nov 6, 2023 at 11:42 AM Watson Ladd  wrote:

> I'm most interested in Level I which I think is what the current
> browser deployments have targeted. Higher security levels are much
> less relevant at least for now, and I think the platforms will likely
> look different.
>
> I think ML-KEM-768 codepoint and a hybrid one make sense to grab now:
> AFAIK it's easy to do. Happy to contribute to drafts, but I think we
> have some floating around.
>
> KEMTLS is a great idea, but I think for now we can make do without:
> it's ok for the PKI to evolve slower.
>
> On Mon, Nov 6, 2023 at 5:32 AM Thom Wiggers  wrote:
> >
> > Hi,
> >
> > Op 6 nov 2023, om 14:24 heeft Tim Hollebeek  40digicert@dmarc.ietf.org> het volgende geschreven:
> >
> > I’m fine if the cocktail napkin says “we’ll either do A or B, we’re
> still figuring that out”.
> >
> >
> > I’m not sure if we will be able to say this as strictly as “A xor B”, we
> might need to do A and B in different environments. CNSA 2.0’s requirement
> of level-V parameters results in very different behaviour than what we see
> at NIST level I, for example. The platforms on which we deploy things are
> also subject to wildly varying constraints.
> >
> > Cheers,
> >
> > Thom
> >
> >
> >
> >
> >
> > What I’m trying to avoid is the situation where everyone has a different
> notional quantum-safe TLS design in their heads, but nobody realizes it
> because nobody has bothered to try to write down the details, even at a
> very high level.
> >
> > If it changes in the future due to new events or analysis, that’s ok too.
> >
> > -Tim
> >
> > From: Bas Westerbaan 
> > Sent: Monday, November 6, 2023 1:14 PM
> > To: Tim Hollebeek 
> > Cc: John Mattsson ; TLS@ietf.org
> > Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant
> algorithms?
> >
> >
> >
> > (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
> >
> >
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
>
>
> --
> Astra mortemque praestare gradatim
>
> ___
> 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] NIST on addressing visibility challenges with TLS 1.3

[Deirdre Connolly]

👀

On Tue, Sep 28, 2021, 12:54 PM Salz, Rich 
wrote:

> This will be of interest to some on this list.  Quoting: “The NCCoE at
> NIST recognizes the challenges associated with compliance, operations, and
> security when enterprises employ encrypted protocols, in particular
> Transport Layer Security (TLS) 1.3, in their data centers. This project
> will use commercially available technologies to demonstrate a range of
> approaches for enabling necessary intra-enterprise access to
> unencrypted/decrypted information. “
>
>
>
>
>
> More at
> https://www.nccoe.nist.gov/projects/building-blocks/applied-cryptography/addressing-visibility-challenges-tls-13
> including how to participate.
> ___
> 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] Early code point assignment request for curve25519 and curve448

[Deirdre Connolly]

On Nov 14, 2015 2:18 PM, "Eric Rescorla"  wrote:
> I'm fine either way. As Adam says, it wouldn't be harmful to wait for
> the signature code point assignments for a bit, but I doubt it would
> be that harmful not to. People who deploy the signature schemes
> before they are stable do so at their own risk. Also, that risk seems
> low since you're not going to have public certificates with these
> schemes until they are stable.

+1

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

Re: [TLS] sect571r1

[Deirdre Connolly]

> So, should it stay or should it go now? Opinions?
>

+1 that sect571r1 be removed.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls