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

[David Benjamin]

> If the server supports P256+ML-KEM, what Matt suggested is that, instead
of accepting P256, it instead a ClientHelloRetry with P256+ML_KEM.  We then
continue as expected and end up negotiating things in 2 round trips.

I assume ClientHelloRetry was meant to be HelloRetryRequest? If so, yeah, a
server which aims to prefer P256+ML-KEM over P256 should, well, prefer
P256+ML-KEM over P256. :-) See the discussions around
draft-davidben-tls-key-share-prediction. In particular, RFC 8446 is clear
on the semantics of such a ClientHello:

   This vector MAY be empty if the client is requesting a
   HelloRetryRequest.  Each KeyShareEntry value MUST correspond to a
   group offered in the "supported_groups" extension and MUST appear in
   the same order.  However, the values MAY be a non-contiguous subset
   of the "supported_groups" extension and MAY omit the most preferred
   groups.  Such a situation could arise if the most preferred groups
   are new and unlikely to be supported in enough places to make
   pregenerating key shares for them efficient.

rfc8446bis contains further clarifications:
https://github.com/tlswg/tls13-spec/pull/1331

Now, some servers (namely OpenSSL) will instead unconditionally select from
key_share first. This isn't wrong, per se. It is how you implement a server
which believes all of its supported groups are of comparable security level
and therefore prioritizes round trips. Such a policy is plausible when you
only support, say, ECDH curves. It's not so reasonable if you support both
ECDH and a PQ KEM. But all the spec text for that is in place, so all that
is left is that folks keep this in mind when adding PQ KEMs to a TLS
implementation. A TLS stack that always looks at key_share first is not
PQ-ready and will need some changes before adopting PQ KEMs.

Regarding the other half of this:

> Suppose we have a client that supports both P-256 and P256+ML-KEM.  What
the client does is send a key share for P-256, and also indicate support
for P256+ML-KEM.  Because we’re including only the P256 key share, the
client hello is short

I don't think this is a good tradeoff and would oppose such a SHOULD here.
PQ KEMs are expensive as they are. Adding a round-trip to it will only make
it worse. Given the aim is to migrate the TLS ecosystem to PQ, penalizing
the desired state doesn't make sense. Accordingly, Chrome's Kyber
deployment includes X25519Kyber768 in the initial ClientHello. While this
does mean paying an unfortunate upfront cost, this alternative would
instead disincentivize servers from deploying post-quantum protections.

If you're interested in avoiding the upfront cost, see
draft-davidben-tls-key-share-prediction-01. That provides a mechanism for
clients to predict more accurately, though it's yet to even be adopted, so
it's a bit early to rely on that one. Note also the Security Considerations
section, which further depends on the server expectations above.

David

On Tue, Mar 19, 2024 at 2:47 PM Scott Fluhrer (sfluhrer)  wrote:

> Recently, Matt Campagna emailed the hybrid KEM group (Douglas, Shay and
> me) about a suggestion about one way to potentially improve the performance
> (in the ‘the server hasn’t upgraded yet’ case), and asked if we should add
> that suggestion to our draft.  It occurs to me that this suggestion is
> equally applicable to the pure ML-KEM draft (and future PQ drafts as well);
> hence putting it in our draft might not be the right spot.
>
>
>
> Here’s the core idea (Matt’s original scenario was more complicated):
>
>
>
>- Suppose we have a client that supports both P-256 and P256+ML-KEM.
>What the client does is send a key share for P-256, and also indicate
>support for P256+ML-KEM.  Because we’re including only the P256 key share,
>the client hello is short
>- If the server supports only P256, it accepts it, and life goes on as
>normal.
>- If the server supports P256+ML-KEM, what Matt suggested is that,
>instead of accepting P256, it instead a ClientHelloRetry with P256+ML_KEM.
>We then continue as expected and end up negotiating things in 2 round 
> trips.
>
>
>
> Hence, the non-upgraded scenario has no performance hit; the upgraded
> scenario does (because of the second round trip), but we’re transmitting
> more data anyways (and the client could, if it communicates with the server
> again, lead off with the proposal that was accepted last time).
>
>
>
> Matt’s suggestion was that this should be a SHOULD in our draft.
>
>
>
> My questions to you: a) do you agree with this suggestion, and b) if so,
> where should this SHOULD live?  Should it be in our draft?  The ML-KEM
> draft as well (assuming there is one, and it’s not just a codepoint
> assignment)?  Another RFC about how to handle large key shares in general
> (sounds like overkill to me, unless we have other things to put in that
> RFC)?
>
>
>
> Thank you.
> ___
> TLS mailing list
> TLS@ietf.org
> 

[TLS] A suggestion for handling large key shares

[Scott Fluhrer (sfluhrer)]

Recently, Matt Campagna emailed the hybrid KEM group (Douglas, Shay and me) 
about a suggestion about one way to potentially improve the performance (in the 
'the server hasn't upgraded yet' case), and asked if we should add that 
suggestion to our draft.  It occurs to me that this suggestion is equally 
applicable to the pure ML-KEM draft (and future PQ drafts as well); hence 
putting it in our draft might not be the right spot.

Here's the core idea (Matt's original scenario was more complicated):


  *   Suppose we have a client that supports both P-256 and P256+ML-KEM.  What 
the client does is send a key share for P-256, and also indicate support for 
P256+ML-KEM.  Because we're including only the P256 key share, the client hello 
is short
  *   If the server supports only P256, it accepts it, and life goes on as 
normal.
  *   If the server supports P256+ML-KEM, what Matt suggested is that, instead 
of accepting P256, it instead a ClientHelloRetry with P256+ML_KEM.  We then 
continue as expected and end up negotiating things in 2 round trips.

Hence, the non-upgraded scenario has no performance hit; the upgraded scenario 
does (because of the second round trip), but we're transmitting more data 
anyways (and the client could, if it communicates with the server again, lead 
off with the proposal that was accepted last time).

Matt's suggestion was that this should be a SHOULD in our draft.

My questions to you: a) do you agree with this suggestion, and b) if so, where 
should this SHOULD live?  Should it be in our draft?  The ML-KEM draft as well 
(assuming there is one, and it's not just a codepoint assignment)?  Another RFC 
about how to handle large key shares in general (sounds like overkill to me, 
unless we have other things to put in that RFC)?

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

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

[Kris Kwiatkowski]

Hello,

I would like to express my support for getting a codepoint for ML-KEM (the 
queue was closed quicker than I expected, so didn’t have a chance to do it at 
the meeting). 

The motivation:
* First of all the integration is rather straightforward.
* MLKEM already got a large amount of research from the crypto community, from 
a large number of various research groups - theorists, designers, implementers 
as well as experts in side-channel protection. Deirdre mentioned that schemes 
were studied for the last 7 years, but it is worth remembering that Kyber is a 
modification of the LPR cryptosystem, introduced already in 2010. 
* There is a cost of 2-step migration (to hybrid and then pure PQ), I don’t 
believe it’s good to force you to pay the cost.

Additionally, I think I would also get a codepoint for MLKEM-512.

-- 
Kris Kwiatkowski
Cryptography Dev




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

Re: [TLS] Feedback on draft-tschofenig-tls-extended-key-update-01

[Ilari Liusvaara]

On Mon, Mar 18, 2024 at 06:46:51PM +, John Mattsson wrote:
> Hi,
> 
> I thought the old version was a quite good starting point. This new
> version seems significantly worse. I think it has three major
> problems:
> 
> 1. It uses the application layer and therefore requires changes in the
> application layer. For many uses of TLS, it is not acceptable to
> change the application layer.

I expect that in many applications, it is not even possible to change
the application layer.


> 3. I don't see the need for HPKE. All discussions, specifications,
> and deployments of PQC KEMs in TLS 1.3 and DTLS 1.3 uses the ordinary
> "KeyShareEntry". Replacing the existing key exchange mechanism in TLS
> with the public key encryption mechanism HPKE. This seems to add a
> lot of code to an TLS implementation already doing quantum-resistant
> key exchange in the initial handshake.

Yes, using existing TLS mechanisms is much easier for implementations.


> I think a solution to do post-handshake ephemeral-ephemeral key
> exchange as well as mutual post-handshake authentication on the
> TLS/DTLS/QUIC layer would be very welcome. I think ephemeral-
> ephemeral key exchange as well as not using the application layer
> should be requirements.

Note that TLS-level post-handshake authentication has very nontrivial
implications on application protocols. E.g., HTTP/2 explicitly bans
TLS post-handshake authentication for very good reasons.

For supporting application-layer authentication, there already are
TLS exporter and exported authenticators.

For EE key exchange, TLS is the relatively easy case. Everything in
TLS is in-order and lossless. The only possible race condition is the
crossed update, and it is easy to make both sides agree that happened.

DTLS is much more difficult due to all the race conditions caused by
reordering and packet loss. Which is something TLS does not have to
deal with, and is especially problematic with the crossed update case.

And while QUIC is based on TLS, it replaces some of the key parts
this mechanism touches. Which means it has to have its own version.
And looks like it has to deal with similar problems (reordering and
packet loss) as DTLS does.


> I think frequent rekeying with ephemeral-ephemeral key exchange is a
> must for long-lived interfaces. This has for a long time been an
> established requirement. Typical requirements are 1 hour of 100 GB in
> IPsec and 1 hour or 1 GB in SSH. Note that there is no problem with
> TLS 1.3 when you can frequently setup new connection with psk_dhe_ke.
> Discussing with Eric Rescorla and Martin Thomson in the past, they
> suggested that this was the way forward. It would be interesting to
> hear if there are more use cases than RFC 6083 where frequently
> setting up a new connection with psk_dhe_ke is problematic. I expect
> there is.

Any application that associates resources with connection poses major
problems with setting up new connections.

While I don't think anybody uses it with TLS, up until recently BGP
(extremely important, to put it mildly) was infamous of recting very
badly to connection loss.




-Ilari

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

Re: [TLS] Feedback on draft-tschofenig-tls-extended-key-update-01

[John Mattsson]

Hi,

I thought the old version was a quite good starting point. This new version 
seems significantly worse. I think it has three major problems:

1. It uses the application layer and therefore requires changes in the 
application layer. For many uses of TLS, it is not acceptable to change the 
application layer. I also don't think it makes sense to do the TLS key exchange 
on the application layer. As Dennis Jacksson writes: " This seems rather 
complex and likely to go wrong. The original version of this draft where the 
key exchange was carried in the extended key update message seems much simpler 
to implement and easier to analyse". I would add that I would not want my keys 
to leave the TLS library. Authentication on the application layer makes sense 
for web applications using HTTP/2 and QUIC where the endpoints might need to 
correlate the certificate request with the application-level event that 
triggered it. For infrastructure use of TLS/DTLS/QUIC I think reauthentication 
on the transport layer is a must.

2. As pointed out by Dennis Jacksson, it uses static-ephemeral key exchange 
instead of ephemeral-ephemeral key exchange, which does not at all give the 
same security properties. I think all requests have been for 
ephemeral-ephemeral key exchange.

3. I don't see the need for HPKE. All discussions, specifications, and 
deployments of PQC KEMs in TLS 1.3 and DTLS 1.3 uses the ordinary 
"KeyShareEntry". Replacing the existing key exchange mechanism in TLS with the 
public key encryption mechanism HPKE. This seems to add a lot of code to an TLS 
implementation already doing quantum-resistant key exchange in the initial 
handshake.

I think a solution to do post-handshake ephemeral-ephemeral key exchange as 
well as mutual post-handshake authentication on the TLS/DTLS/QUIC layer would 
be very welcome. I think ephemeral-ephemeral key exchange as well as not using 
the application layer should be requirements.

I think frequent rekeying with ephemeral-ephemeral key exchange is a must for 
long-lived interfaces. This has for a long time been an established 
requirement. Typical requirements are 1 hour of 100 GB in IPsec and 1 hour or 1 
GB in SSH. Note that there is no problem with TLS 1.3 when you can frequently 
setup new connection with psk_dhe_ke. Discussing with Eric Rescorla and Martin 
Thomson in the past, they suggested that this was the way forward. It would be 
interesting to hear if there are more use cases than RFC 6083 where frequently 
setting up a new connection with psk_dhe_ke is problematic. I expect there is.

Long-term, I think QUIC is much more important than TLS and DTLS. The telecom 
sector work in 10-year generation (4G, 5G, 6G). In 6G, expected to be 
standardized in 2029, I expect most use of TCP, SCTP, TLS, and DTLS to be 
replaced by QUIC.

The citation (R13) from ANSSI only talks about rekeying. Equally important is 
R12 which says that

"If available, one shall activate the PFS property in IKEv2 second phase" 
(a.k.a “quick mode”) using a Diffie-Hellman key exchange or its elliptic curve 
variant."

Cheers,
John Preuß Mattsson

From: TLS  on behalf of Dennis Jackson 

Date: Tuesday, 19 March 2024 at 02:38
To: TLS List 
Subject: [TLS] Feedback on draft-tschofenig-tls-extended-key-update-01
A new version of this draft was published a few weeks ago with an
entirely new design. Unless I missed it, the new version hasn't yet been
discussed on the TLS list and I was unaware of the changes until I came
to prepare for the meeting. I have quite a few concerns - I'm sorry to
bring them up so close to the meeting.

Firstly, the draft as specified does not achieve the claimed security goal:

> Security Considerations:
>
> To perform public key encryption the sender needs to have access to
> the public key of the recipient. This document makes the assumption
> that the public key in the exchanged end-entity certificate can be
> used with the HPKE KEM. The use of HPKE, and the recipients long-term
> public key, in the ephemeral-static Diffie-Hellman exchange provides
> perfect forward secrecy of the ongoing connection and demonstrates
> possession of the long-term secret key.

An ephemeral-static Diffie-Hellman exchange does not provide forward
secrecy. If the attacker can compromise the endpoint with the static
public key, they can decrypt all previously transmitted ciphertexts to
this peer and so recover all past keys, violating forward secrecy. This
wasn't an issue in the old draft where ephemeral-ephemeral DH exchanges
were used.

Secondly, I think there is some confusion about what forward secrecy is.
Forward secrecy means that compromise in the future will not enable the
decryption of past messages. The existing KeyUpdate mechanism in TLS1.3
achieves forward secrecy by ratcheting forwards the used keys and
throwing away the old ones. So no changes are required to TLS1.3 to
enjoy forward secrecy in long-lived connections, just do the existing
key update and be sure to 

Re: [TLS] Proposal: a TLS formal analysis triage panel

[Muhammad Usama Sardar]

On 18.03.24 16:56, Deirdre Connolly wrote:

I do think a 'reference' Tamarin model would be useful.

Why should it be a Tamarin model? Why not a ProVerif model?
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.


Are you expecting any major changes in TLS 1.3? If not, then I think the 
baseline formal model will not change a lot. So probably there is not 
much maintenance required. I think it is just a one-time effort to 
create well-understood and well-reviewed formal artifacts as a baseline, 
and then most extensions (for which formal analysis is signaled by the 
panel) can use this baseline.


Also, TLS WG can work together with UFMRG to achieve this.

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.


Agree. However, the baseline for each "kind" (e.g., one for symbolic and 
one for computational and within symbolic, one for ProVerif and one for 
Tamarin) will still be helpful to avoid repetitive work.


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

[TLS] Feedback on draft-tschofenig-tls-extended-key-update-01

[Dennis Jackson]

A new version of this draft was published a few weeks ago with an 
entirely new design. Unless I missed it, the new version hasn't yet been 
discussed on the TLS list and I was unaware of the changes until I came 
to prepare for the meeting. I have quite a few concerns - I'm sorry to 
bring them up so close to the meeting.


Firstly, the draft as specified does not achieve the claimed security goal:


Security Considerations:

To perform public key encryption the sender needs to have access to 
the public key of the recipient. This document makes the assumption 
that the public key in the exchanged end-entity certificate can be 
used with the HPKE KEM. The use of HPKE, and the recipients long-term 
public key, in the ephemeral-static Diffie-Hellman exchange provides 
perfect forward secrecy of the ongoing connection and demonstrates 
possession of the long-term secret key.


An ephemeral-static Diffie-Hellman exchange does not provide forward 
secrecy. If the attacker can compromise the endpoint with the static 
public key, they can decrypt all previously transmitted ciphertexts to 
this peer and so recover all past keys, violating forward secrecy. This 
wasn't an issue in the old draft where ephemeral-ephemeral DH exchanges 
were used.


Secondly, I think there is some confusion about what forward secrecy is. 
Forward secrecy means that compromise in the future will not enable the 
decryption of past messages. The existing KeyUpdate mechanism in TLS1.3 
achieves forward secrecy by ratcheting forwards the used keys and 
throwing away the old ones. So no changes are required to TLS1.3 to 
enjoy forward secrecy in long-lived connections, just do the existing 
key update and be sure to throw away the old keys correctly.



Introduction:

If a traffic secret (referred as application_traffic_secret_N) has 
been compromised, an attacker can passively eavesdrop on all future 
data sent on the connection, including data encrypted with 
application_traffic_secret_N+1, application_traffic_secret_N+2, etc.


This is not forward secrecy but post-compromise security (PCS) [1] 
(sometimes called Backwards Secrecy as it is the complement of Forward 
Secrecy). As the draft identifies, a fresh key exchange is needed to 
ensure PCS. However, as mentioned earlier in the PFS case, this key 
exchange needs to be with freshly generated ephemeral keys. It does no 
good to use an existing static key since the attacker might have already 
compromised it.


Finally, I'm really not sure about the decision to mix the TLS and 
Application layers by having the application carry the HPKE ciphertexts. 
This seems rather complex and likely to go wrong. The original version 
of this draft where the key exchange was carried in the extended key 
update message seems much simpler to implement and easier to analyse.


If the authors do want to go with some kind of application specific key 
exchange, I would suggest rethinking this draft as purely a way to bring 
entropy into the TLS1.3 key exchange, a TLS1.3 Key Importer if you will. 
This would work by having the application to signal to the TLS1.3 layer 
that a key was ready to be imported (with a particular key-id and key 
material). The TLS library would communicate this to the peer with a 
message similar to the one currently defined in the draft carrying the 
key-id. The new key material would be mixed to the current secret in 
when the peer confirmed it had also been passed the key id and material 
by its application. The details about some kind of application layer key 
exchange would then need to go in a different document and use 
ephemeral-ephemeral exchange as highlighted.


Given the complexities around the use of middleboxes which may not be 
available to the peers, it might be necessary to use an exported 
authenticator so the applications could confirm they were sharing a 
single TLS connection and not two duct-taped together (which would be 
unable to successfully import new keys). This seems like a like of 
complexity compared to the initial draft.


Best,
Dennis

[1] https://eprint.iacr.org/2016/221.pdf

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

[Muhammad Usama Sardar]

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

Re: [TLS] [EXTERNAL] Re: Next steps for key share prediction

[Loganaden Velvindron]

Any change of getting this adopted by the WG ?

On Mon, 18 Mar 2024 at 15:47, David Benjamin  wrote:
>
> > …and now I'm coming around to the idea that we don't need to do anything 
> > special to account for the "wrong" server behavior. Since RFC8446 already 
> > explicitly said that clients are allowed to not predict their most 
> > preferred groups, we can already reasonably infer that such servers 
> > actively believe that all their groups are comparable in security.
>
> I've now updated the draft to do this.
> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-01.html
>
> It is now considerably simpler and just contains the DNS mechanism, plus a 
> discussion in Security Considerations why this is OK.
>
> On Tue, Mar 12, 2024 at 10:04 AM Andrei Popov  
> wrote:
>>
>> …and now I'm coming around to the idea that we don't need to do anything 
>> special to account for the "wrong" server behavior. Since RFC8446 already 
>> explicitly said that clients are allowed to not predict their most preferred 
>> groups, we can already reasonably infer that such servers actively believe 
>> that all their groups are comparable in security.
>>
>> It makes sense for some services to prioritize RTT reduction; others may 
>> prioritize group strength. There are a lot of services out there 
>> prioritizing weaker groups for CPU savings (e.g., this is one of the reasons 
>> why Curve 25519 is so popular).
>>
>>
>>
>> I... question whether taking that position is wise, given the ongoing 
>> postquantum transition, but so it goes
>>
>> Servers will have to be updated and reconfigured for PQC/hybrid support, at 
>> which time they will likely apply a different policy.
>>
>>
>>
>> Hopefully your TLS server software, if it advertises pluggable cryptography 
>> with a PQ use case, and yet opted for a PQ-incompatible selection criteria, 
>> has clearly documented this so it isn't a surprise to you. ;-)
>>
>> Correct.
>>
>>
>>
>> Between all that, we probably can reasonably say that's the server 
>> operator's responsibility?
>>
>> Yes.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Andrei
>>
>>
>>
>> From: TLS  On Behalf Of David Benjamin
>> Sent: Friday, March 8, 2024 3:25 PM
>> To: Watson Ladd 
>> Cc:  
>> Subject: [EXTERNAL] Re: [TLS] Next steps for key share prediction
>>
>>
>>
>> On Thu, Mar 7, 2024 at 6:34 PM Watson Ladd  wrote:
>>
>> On Thu, Mar 7, 2024 at 2:56 PM David Benjamin  wrote:
>> >
>> > Hi all,
>> >
>> > With the excitement about, sometime in the far future, possibly 
>> > transitioning from a hybrid, or to a to-be-developed better PQ algorithm, 
>> > I thought it would be a good time to remind folks that, right now, we have 
>> > no way to effectively transition between PQ-sized KEMs at all.
>> >
>> > At IETF 118, we discussed draft-davidben-tls-key-share-prediction, which 
>> > aims to address this. For a refresher, here are some links:
>> > https://davidben.github.io/tls-key-share-prediction/draft-davidben-tls-key-share-prediction.html
>> > https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-key-share-prediction-00
>> > (Apologies, I forgot to cut a draft-01 with some of the outstanding 
>> > changes in the GitHub, so the link above is probably better than draft-00.)
>> >
>> > If I recall, the outcome from IETF 118 was two-fold:
>> >
>> > First, we'd clarify in rfc8446bis that the "key_share first" selection 
>> > algorithm is not quite what you want. This was done in 
>> > https://github.com/tlswg/tls13-spec/pull/1331
>> >
>> > Second, there was some discussion over whether what's in the draft is the 
>> > best way to resolve a hypothetical future transition, or if there was 
>> > another formulation. I followed up with folks briefly offline afterwards, 
>> > but an alternative never came to fruition.
>> >
>> > Since we don't have another solution yet, I'd suggest we move forward with 
>> > what's in the draft as a starting point. (Or if this email inspires folks 
>> > to come up with a better solution, even better! :-D) In particular, 
>> > whatever the rfc8446bis guidance is, there are still TLS implementations 
>> > out there with the problematic selection algorithm. Concretely, OpenSSL's 
>> > selection algorithm is incompatible with this kind of transition. See 
>> > https://github.com/openssl/openssl/issues/22203
>>
>> Is that asking whether or not we want adoption? I want adoption.
>>
>>
>>
>> I suppose that would be the next step. :-) I think, last meeting, we were a 
>> little unclear what we wanted the document to be, so I was trying to take 
>> stock first. Though MT prompted me to ponder this a bit more in 
>> https://github.com/davidben/tls-key-share-prediction/issues/5, and now I'm 
>> coming around to the idea that we don't need to do anything special to 
>> account for the "wrong" server behavior. Since RFC8446 already explicitly 
>> said that clients are allowed to not predict their most preferred groups, we 
>> can already reasonably infer that such servers actively 

Re: [TLS] [EXTERNAL] Re: Next steps for key share prediction

[David Benjamin]

> …and now I'm coming around to the idea that we don't need to do anything
special to account for the "wrong" server behavior. Since RFC8446 already
explicitly said that clients are allowed to not predict their most
preferred groups, we can already reasonably infer that such servers
actively believe that all their groups are comparable in security.

I've now updated the draft to do this.
https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-01.html

It is now considerably simpler and just contains the DNS mechanism, plus a
discussion in Security Considerations why this is OK.

On Tue, Mar 12, 2024 at 10:04 AM Andrei Popov 
wrote:

>
>- …and now I'm coming around to the idea that we don't need to do
>anything special to account for the "wrong" server behavior. Since RFC8446
>already explicitly said that clients are allowed to not predict their most
>preferred groups, we can already reasonably infer that such servers
>actively believe that all their groups are comparable in security.
>
> It makes sense for some services to prioritize RTT reduction; others may
> prioritize group strength. There are a lot of services out there
> prioritizing weaker groups for CPU savings (e.g., this is one of the
> reasons why Curve 25519 is so popular).
>
>
>
>- I... question whether taking that position is wise, given the
>ongoing postquantum transition, but so it goes
>
> Servers will have to be updated and reconfigured for PQC/hybrid support,
> at which time they will likely apply a different policy.
>
>
>
>- Hopefully your TLS server software, if it advertises pluggable
>cryptography with a PQ use case, and yet opted for a PQ-incompatible
>selection criteria, has clearly documented this so it isn't a surprise to
>you. ;-)
>
> Correct.
>
>
>
>- Between all that, we probably can reasonably say that's the server
>operator's responsibility?
>
> Yes.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS  *On Behalf Of *David Benjamin
> *Sent:* Friday, March 8, 2024 3:25 PM
> *To:* Watson Ladd 
> *Cc:*  
> *Subject:* [EXTERNAL] Re: [TLS] Next steps for key share prediction
>
>
>
> On Thu, Mar 7, 2024 at 6:34 PM Watson Ladd  wrote:
>
> On Thu, Mar 7, 2024 at 2:56 PM David Benjamin 
> wrote:
> >
> > Hi all,
> >
> > With the excitement about, sometime in the far future, possibly
> transitioning from a hybrid, or to a to-be-developed better PQ algorithm, I
> thought it would be a good time to remind folks that, right now, we have no
> way to effectively transition between PQ-sized KEMs at all.
> >
> > At IETF 118, we discussed draft-davidben-tls-key-share-prediction, which
> aims to address this. For a refresher, here are some links:
> >
> https://davidben.github.io/tls-key-share-prediction/draft-davidben-tls-key-share-prediction.html
> >
> https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-key-share-prediction-00
> > (Apologies, I forgot to cut a draft-01 with some of the outstanding
> changes in the GitHub, so the link above is probably better than draft-00.)
> >
> > If I recall, the outcome from IETF 118 was two-fold:
> >
> > First, we'd clarify in rfc8446bis that the "key_share first" selection
> algorithm is not quite what you want. This was done in
> https://github.com/tlswg/tls13-spec/pull/1331
> >
> > Second, there was some discussion over whether what's in the draft is
> the best way to resolve a hypothetical future transition, or if there was
> another formulation. I followed up with folks briefly offline afterwards,
> but an alternative never came to fruition.
> >
> > Since we don't have another solution yet, I'd suggest we move forward
> with what's in the draft as a starting point. (Or if this email inspires
> folks to come up with a better solution, even better! :-D) In particular,
> whatever the rfc8446bis guidance is, there are still TLS implementations
> out there with the problematic selection algorithm. Concretely, OpenSSL's
> selection algorithm is incompatible with this kind of transition. See
> https://github.com/openssl/openssl/issues/22203
>
> Is that asking whether or not we want adoption? I want adoption.
>
>
>
> I suppose that would be the next step. :-) I think, last meeting, we were
> a little unclear what we wanted the document to be, so I was trying to take
> stock first. Though MT prompted me to ponder this a bit more in
> https://github.com/davidben/tls-key-share-prediction/issues/5, and now
> I'm coming around to the idea that we don't need to do anything special to
> account for the "wrong" server behavior. Since RFC8446 already explicitly
> said that clients are allowed to not predict their most preferred groups,
> we can already reasonably infer that such servers actively believe that all
> their groups are comparable in security. OpenSSL, at least, seems to be
> taking that position. I... question whether taking that position is wise,
> given the ongoing postquantum transition, but so it goes. Hopefully your
> 

[TLS] [Errata Verified] RFC6176 (5536)

[RFC Errata System]

The following errata report has been verified for RFC6176,
"Prohibiting Secure Sockets Layer (SSL) Version 2.0". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5536

--
Status: Verified
Type: Technical

Reported by: Eugene Adell 
Date Reported: 2018-10-19
Verified by: Paul Wouters (IESG)

Section: 1

Original Text
-
   RFC 4346 [TLS1.1], and later RFC 5246 [TLS1.2], explicitly warned
   implementers that the "ability to send version 2.0 CLIENT-HELLO
   messages will be phased out with all due haste".  This document
   accomplishes this by updating the backward compatibility sections
   found in TLS [TLS1.0][TLS1.1][TLS1.2].

Corrected Text
--
   RFC 2246 [TLS1.0], and later RFC 4346 [TLS1.1], then RFC 5246
   [TLS1.2] explicitly warned implementers that the "ability to send
   version 2.0 CLIENT-HELLO messages will be phased out with all due
   haste". This document accomplishes this by updating the backward
   compatibility sections found in TLS [TLS1.0][TLS1.1][TLS1.2].

Notes
-
The warning on the version 2.0 Client Hello is as old as the first TLS version 
(RFC 2246 Appendix E). That's what the authors meant and wanted to highlight by 
listing two of the three RFCs containing this warning. This is confirmed by 
their last sentence. It looks like a small mistake without concrete effects, I 
push this errata considering "IESG Processing of RFC Errata for the IETF Stream 
rule 6"

--
RFC6176 (draft-ietf-tls-ssl2-must-not-04)
--
Title   : Prohibiting Secure Sockets Layer (SSL) Version 2.0
Publication Date: March 2011
Author(s)   : S. Turner, T. Polk
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

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

Re: [TLS] TLSFlags ambiguity

[David Benjamin]

Oh, perfect! I was trying to find the GitHub repo to make the PR but missed
it somehow. Here's a PR: https://github.com/tlswg/tls-flags/pull/37

On Mon, Mar 18, 2024 at 5:01 PM Sean Turner  wrote:

> I just threw in a couple of PRs to align this I-D with 8446bis & 8447bis,
> but forgot to add this issue.  I have corrected this now so that we won’t
> forget again:
> https://github.com/tlswg/tls-flags/issues/36
>
> spt
>
> > On Mar 17, 2024, at 13:53, David Benjamin  wrote:
> >
> > Did this ever get resolved? I noticed that there was a draft-13 cut, but
> the issue Jonathan pointed out was still there.
> >
> > Looking at Section 2 again, it's actually even goofier than the original
> email suggests. Section 2 first says:
> >
> > > The FlagExtensions field contains 8 flags in each octet. The length of
> the extension is the minimal length that allows it to encode all of the
> present flags. Within each octet, the bits are packed such that the first
> bit is the least significant bit and the eighth bit is the most significant.
> >
> > This is LSB first. Then there's an example, which is also LSB first:
> >
> > > For example, if we want to encode only flag number zero, the
> FlagExtension field will be 1 octet long, that is encoded as follows:
> > >
> > >0001
> >
> > So that's all consistent. But then the last paragraph of section 2 says:
> >
> > > Note that this document does not define any particular bits for this
> string. That is left to the protocol documents such as the ones in the
> examples from the previous section. Such documents will have to define
> which bit to set to show support, and the order of the bits within the bit
> string shall be enumerated in network order: bit zero is the high-order bit
> of the first octet as the flags field is transmitted.
> >
> > This says it's MSB first for some reason. But this is not only
> inconsistent, but also redundant with the text at the start of section 2.
> It seems to me we could simply delete the redundant text and move on:
> >
> > > Note that this document does not define any particular bits for this
> string. That is left to the protocol documents such as the ones in the
> examples from the previous section. Such documents will have to define
> which bit to set to show support.
> >
> > David
> >
> > On Wed, Sep 27, 2023, 17:50 David Benjamin 
> wrote:
> > Nice catch! I agree those don't match. I think bit zero should be the
> least-significant bit. That is, we should leave the examples as-is and then
> fix the specification text.
> >
> > Ordering bits MSB first doesn't make much sense. Unlike bytes, there is
> no inherent order to bits in memory, so the most natural order is the power
> of two represented by the bit. Put another way, everyone accesses bit N by
> ANDing with 1 << N and that's least-significant bits first. I can think of
> a couple systems (DER, GCM) that chose to order bits most-significant first
> and both have caused endless confusion and problems. (It's particularly bad
> for GCM which is actually representing a polynomial, but then messed up the
> order. Let's not repeat this blunder.)
> >
> > On Fri, Sep 15, 2023 at 1:37 PM Jonathan Hoyland <
> jonathan.hoyl...@gmail.com> wrote:
> > Hi TLSWG,
> >
> > I'm working on implementing the TLS Flags extension, and I just wanted
> to clarify a potential ambiguity in the spec.
> >
> > In Section 2 the spec says:
> > Such documents will have to define which bit to set to show support, and
> the order of the bits within the bit string shall be enumerated in network
> order: bit zero is the high-order bit of the first octet as the flags field
> is transmitted.
> >
> > And also gives the example for encoding bit zero:
> > For example, if we want to encode only flag number zero, the
> FlagExtension field will be 1 octet long, that is encoded as follows:
> >0001
> > In which it seems that the low-order bit of the first octet represents
> zero.
> >
> > I have no preference either way, but when transmitted on the wire,
> should flag 0 be transmitted as
> > 0x01 or 0x80?
> >
> > Regards,
> >
> > Jonathan
> > ___
> > 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] Working Group Last Call for ECH

[Salz, Rich]

Is there value in citing the security analysis for ECH as an informative 
reference?

Yes!

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

Re: [TLS] Working Group Last Call for ECH

[Eric Rescorla]

On Sun, Mar 17, 2024 at 11:53 PM Karthikeyan Bhargavan <
karthikeyan.bharga...@inria.fr> wrote:

> Is there value in citing the security analysis for ECH as an informative
> reference?
>
> [image: 3548606.cover.jpg]
>
> A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello |
> Proceedings of the 2022 ACM SIGSAC Conference on Computer and
> Communications Security
> 
> dl.acm.org 
> 
>
>
> I expect this is quite late in the process for that:
>

Not at all, I think we just need to update the existing reference:

   [ECH-Analysis]
  "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted
  Client Hello", November 2022.

Care to send a PR?


-Ekr


>
>
>
> On 12 Mar 2024, at 01:21, Christopher Patton  40cloudflare@dmarc.ietf.org> wrote:
>
> security
>
>
> ___
> 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] TLSFlags ambiguity

[Sean Turner]

I just threw in a couple of PRs to align this I-D with 8446bis & 8447bis, but 
forgot to add this issue.  I have corrected this now so that we won’t forget 
again:
https://github.com/tlswg/tls-flags/issues/36

spt

> On Mar 17, 2024, at 13:53, David Benjamin  wrote:
> 
> Did this ever get resolved? I noticed that there was a draft-13 cut, but the 
> issue Jonathan pointed out was still there.
> 
> Looking at Section 2 again, it's actually even goofier than the original 
> email suggests. Section 2 first says:
> 
> > The FlagExtensions field contains 8 flags in each octet. The length of the 
> > extension is the minimal length that allows it to encode all of the present 
> > flags. Within each octet, the bits are packed such that the first bit is 
> > the least significant bit and the eighth bit is the most significant.
> 
> This is LSB first. Then there's an example, which is also LSB first:
> 
> > For example, if we want to encode only flag number zero, the FlagExtension 
> > field will be 1 octet long, that is encoded as follows:
> >
> >0001
> 
> So that's all consistent. But then the last paragraph of section 2 says:
> 
> > Note that this document does not define any particular bits for this 
> > string. That is left to the protocol documents such as the ones in the 
> > examples from the previous section. Such documents will have to define 
> > which bit to set to show support, and the order of the bits within the bit 
> > string shall be enumerated in network order: bit zero is the high-order bit 
> > of the first octet as the flags field is transmitted.
> 
> This says it's MSB first for some reason. But this is not only inconsistent, 
> but also redundant with the text at the start of section 2. It seems to me we 
> could simply delete the redundant text and move on:
> 
> > Note that this document does not define any particular bits for this 
> > string. That is left to the protocol documents such as the ones in the 
> > examples from the previous section. Such documents will have to define 
> > which bit to set to show support.
> 
> David
> 
> On Wed, Sep 27, 2023, 17:50 David Benjamin  wrote:
> Nice catch! I agree those don't match. I think bit zero should be the 
> least-significant bit. That is, we should leave the examples as-is and then 
> fix the specification text.
> 
> Ordering bits MSB first doesn't make much sense. Unlike bytes, there is no 
> inherent order to bits in memory, so the most natural order is the power of 
> two represented by the bit. Put another way, everyone accesses bit N by 
> ANDing with 1 << N and that's least-significant bits first. I can think of a 
> couple systems (DER, GCM) that chose to order bits most-significant first and 
> both have caused endless confusion and problems. (It's particularly bad for 
> GCM which is actually representing a polynomial, but then messed up the 
> order. Let's not repeat this blunder.)
> 
> On Fri, Sep 15, 2023 at 1:37 PM Jonathan Hoyland  
> wrote:
> Hi TLSWG,
> 
> I'm working on implementing the TLS Flags extension, and I just wanted to 
> clarify a potential ambiguity in the spec.
> 
> In Section 2 the spec says:
> Such documents will have to define which bit to set to show support, and the 
> order of the bits within the bit string shall be enumerated in network order: 
> bit zero is the high-order bit of the first octet as the flags field is 
> transmitted.
> 
> And also gives the example for encoding bit zero:
> For example, if we want to encode only flag number zero, the FlagExtension 
> field will be 1 octet long, that is encoded as follows:
>0001
> In which it seems that the low-order bit of the first octet represents zero.
> 
> I have no preference either way, but when transmitted on the wire, should 
> flag 0 be transmitted as 
> 0x01 or 0x80?
> 
> Regards,
> 
> Jonathan
> ___
> 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] Working Group Last Call for ECH

[Karthikeyan Bhargavan]

Is there value in citing the security analysis for ECH as an informative 
reference?

https://dl.acm.org/doi/abs/10.1145/3548606.3559360
A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello | 
Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications 
Security
dl.acm.org


I expect this is quite late in the process for that:



> On 12 Mar 2024, at 01:21, Christopher Patton 
>  wrote:
> 
> security

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