Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?
Jack Grigg writes: > As the paper states at the top of page 4, X-Wing includes the recipient's > X25519 public key "as a measure of security against multi-target attacks, > similarly to what is done in the ML-KEM design". Thanks for the data. Assuming arguendo that this matters (as in my first message), the basic risk to consider is that people end up mixing * a combiner that doesn't hash the post-quantum KEM public key because it expects the KEM to do that and * a KEM that doesn't hash the public key because it expects the combiner to do that, so that KEM's public key doesn't end up getting hashed at all. Given the basic goal of helping auditors, I think we should settle on principles of (1) always using double encryption, (2) having as few combiners as possible, and (3) having the combiner responsible for hashing public keys and ciphertexts along with the shared secrets. Rationale for assigning responsibility to the combiner rather than to the underlying KEM: (1) KEM designs and analyses are already hard, with breaks often taking years to appear---see the graph on slide 11 of https://cr.yp.to/talks/2024.01.11/slides-djb-20240111-pqcrypto-4x3.pdf for the timeline of breaks so far of round-1 NIST submissions---and adding more goals makes it harder. (2) KEM designs typically focus on IND-CCA2. Properties beyond IND-CCA2 might be achieved as experiments or accidents, but treating those as stable commitments is unjustified and unsafe. (3) We know how to convincingly analyze a combiner as a separate module, as in https://eprint.iacr.org/2018/024, starting purely from IND-CCA2 assumptions on KEMs. (4) The arguments for multiple KEMs are stronger than the arguments for multiple combiners. Having just one combiner, and thus just one universal review of whether ciphertexts and public keys are adequately hashed, seems more feasible than having just one KEM. ---D. J. Bernstein ___ 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?
> > The arguments for multiple KEMs are > stronger than the arguments for multiple combiners. > X-Wing is a KEM — not a combiner. I agree there should preferably be one go-to generic combiner. Insisting that X-Wing use that generic combiner, is not dissimilar to insisting that every KEM that uses an FO transform, should use the same generic FO transform. Best, Bas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?
Bas Westerbaan writes: > X-Wing is a KEM - not a combiner. Sure, but there's a combiner present inside it---and even advertised: see "X-Wing uses the combiner" etc. at the beginning of this thread. If people are motivated by things like http://tinyurl.com/5cu2j5hf to use the same combiner with a different KEM, would they be deterred by a presentation purely as a unified package? Or by enough warnings? Maybe, but a little more hashing has negligible cost and will reduce the risk. > Insisting that X-Wing use that generic combiner, is not dissimilar to > insisting that every KEM that uses an FO transform, should use the > same generic FO transform. The title and introduction of https://cr.yp.to/papers.html#tightkem recommend unifying FO transforms. This would have avoided various subsequent breaks of NIST submissions. To be clear, I think other concerns such as efficiency _can_ outweigh the advantages of unification, but this has to be quantified. When I see a complaint about "hashing the typically large PQ ciphertexts", I ask how this compares quantitatively to communicating the ciphertexts, and end up with a cost increment around 1%, which is negligible even in the extreme case that the KEM is the main thing the application is doing. ---D. J. Bernstein ___ 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?
On Tue, Jan 16, 2024 at 8:24 AM D. J. Bernstein wrote: > Bas Westerbaan writes: > > X-Wing is a KEM - not a combiner. > > Sure, but there's a combiner present inside it---and even advertised: > see "X-Wing uses the combiner" etc. at the beginning of this thread. > > If people are motivated by things like http://tinyurl.com/5cu2j5hf to > use the same combiner with a different KEM, would they be deterred by a > presentation purely as a unified package? Or by enough warnings? Maybe, > but a little more hashing has negligible cost and will reduce the risk. > > > Insisting that X-Wing use that generic combiner, is not dissimilar to > > insisting that every KEM that uses an FO transform, should use the > > same generic FO transform. > > The title and introduction of https://cr.yp.to/papers.html#tightkem > recommend unifying FO transforms. This would have avoided various > subsequent breaks of NIST submissions. > > To be clear, I think other concerns such as efficiency _can_ outweigh > the advantages of unification, but this has to be quantified. When I see > a complaint about "hashing the typically large PQ ciphertexts", I ask > how this compares quantitatively to communicating the ciphertexts, and > end up with a cost increment around 1%, which is negligible even in the > extreme case that the KEM is the main thing the application is doing. > Responding to Dan but really this is a question to the draft authors. Do you agree with Dan on the approximate overhead here? -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] [Errata Held for Document Update] RFC8446 (6205)
The following errata report has been held for document update for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6205 -- Status: Held for Document Update Type: Editorial Reported by: Martin Thomson Date Reported: 2020-06-04 Held by: Paul Wouters (IESG) Section: 4.3.2 Original Text - Servers which are authenticating with a PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see Section 4.6.2) provided that the client has sent the "post_handshake_auth" extension (see Section 4.2.6). Corrected Text -- Servers which are authenticating with a resumption PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see Section 4.6.2) provided that the client has sent the "post_handshake_auth" extension (see Section 4.2.6). Servers which are authenticating with an external PSK MUST NOT send the CertificateRequest message either in the main handshake or request post-handshake authentication. Future specifications MAY provide an extension to permit this. Notes - The lack of qualification on "authenticating with a PSK" implies that the statement applies equally to both external and resumption PSKs. However, there are two conditions being governed: whether a certificate can be requested during the handshake, and whether a certificate can be requested post-handshake. The latter of these requires different rules depending on the type of PSK. We know from the analysis of resumption (see https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/) that combining a PSK handshake of either type with a client certificate is not safe. Thus, the prohibition on CertificateRequest during the handshake applies equally to both resumption and external PSKs. For post-handshake, Appendix E.1 already discusses the risks of combining PSKs with certificates, citing the same analysis as above. [...] It is unsafe to use certificate-based client authentication when the client might potentially share the same PSK/key-id pair with two different endpoints. For this reason an external PSK is not safe to use with post-handshake authentication. A resumption PSK does not have this property, so the same prohibition doesn't apply. Splitting the requirements as proposed makes this split clearer. -- RFC8446 (draft-ietf-tls-tls13-28) -- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date: August 2018 Author(s) : E. Rescorla Category: PROPOSED STANDARD Source : Transport Layer Security Area: Security Stream : IETF Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] [Errata Held for Document Update] RFC8996 (7769)
The following errata report has been held for document update for RFC8996, "Deprecating TLS 1.0 and TLS 1.1". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7769 -- Status: Held for Document Update Type: Editorial Reported by: Martin Thomson Date Reported: 2021-03-23 Held by: Paul Wouters (IESG) Section: 1.1 Original Text - ServerHello.Random Corrected Text -- ServerHello.random Notes - Very pedantic, but RFC 8446 uses all lowercase for "random" to match the grammar. Paul Wouters (AD): RFC 8446 itself actually also has this problem once in Section 4.1.3 -- RFC8996 (draft-ietf-tls-oldversions-deprecate-12) -- Title : Deprecating TLS 1.0 and TLS 1.1 Publication Date: March 2021 Author(s) : K. Moriarty, S. Farrell Category: BEST CURRENT PRACTICE Source : Transport Layer Security Area: Security Stream : IETF Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] [Errata Verified] RFC8996 (7103)
The following errata report has been verified for RFC8996, "Deprecating TLS 1.0 and TLS 1.1". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7103 -- Status: Verified Type: Editorial Reported by: Martin Thomson Date Reported: 2022-08-24 Verified by: Paul Wouters (IESG) Section: GLOBAL Original Text - https://www.rfc-editor.org/rfc/rfc%E2%80%8B%204162"; class="eref"> 4162 Corrected Text -- https://www.rfc-editor.org/rfc/rfc4162"; class="eref">4162 Notes - (Note: the line wrapping here is mine; the errata tool assumes that this is text, so it won't accept long lines.) The text for this specification is OK, but the HTML rendering has some hard-to-notice errors in the "Updates" field in the metadata block that is being caused by errors in the XML source. The XML source includes a number of Unicode zero width space characters (U+200B) after commas in the rfc@updates attribute. xml2rfc is unable to handle these characters correctly, treating them - and the space that follows - as part of the RFC number. It generates the bad link as you see above. This can be addressed in xml2rfc, maybe, but this is probably not XML we want to permit. Paul Wouters (AD): Verified, as this RFC won't get any updates. -- RFC8996 (draft-ietf-tls-oldversions-deprecate-12) -- Title : Deprecating TLS 1.0 and TLS 1.1 Publication Date: March 2021 Author(s) : K. Moriarty, S. Farrell Category: BEST CURRENT PRACTICE Source : Transport Layer Security Area: Security Stream : IETF Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Errata Held for Document Update] RFC8446 (6205)
I believe that the current 8446-bis text addresses this. Martin? On Tue, Jan 16, 2024 at 4:59 PM RFC Errata System wrote: > The following errata report has been held for document update > for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6205 > > -- > Status: Held for Document Update > Type: Editorial > > Reported by: Martin Thomson > Date Reported: 2020-06-04 > Held by: Paul Wouters (IESG) > > Section: 4.3.2 > > Original Text > - >Servers which are authenticating with a PSK MUST NOT send the >CertificateRequest message in the main handshake, though they MAY >send it in post-handshake authentication (see Section 4.6.2) provided >that the client has sent the "post_handshake_auth" extension (see >Section 4.2.6). > > Corrected Text > -- >Servers which are authenticating with a resumption PSK MUST NOT send the >CertificateRequest message in the main handshake, though they MAY >send it in post-handshake authentication (see Section 4.6.2) provided >that the client has sent the "post_handshake_auth" extension (see >Section 4.2.6). Servers which are authenticating with an external PSK >MUST NOT send the CertificateRequest message either in the main > handshake >or request post-handshake authentication. Future specifications MAY >provide an extension to permit this. > > Notes > - > The lack of qualification on "authenticating with a PSK" implies that the > statement applies equally to both external and resumption PSKs. However, > there are two conditions being governed: whether a certificate can be > requested during the handshake, and whether a certificate can be requested > post-handshake. The latter of these requires different rules depending on > the type of PSK. > > We know from the analysis of resumption (see > https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/) > that combining a PSK handshake of either type with a client certificate is > not safe. Thus, the prohibition on CertificateRequest during the handshake > applies equally to both resumption and external PSKs. > > For post-handshake, Appendix E.1 already discusses the risks of combining > PSKs with certificates, citing the same analysis as above. > >[...] It is unsafe to use certificate-based client >authentication when the client might potentially share the same >PSK/key-id pair with two different endpoints. > > For this reason an external PSK is not safe to use with post-handshake > authentication. A resumption PSK does not have this property, so the same > prohibition doesn't apply. > > Splitting the requirements as proposed makes this split clearer. > > -- > RFC8446 (draft-ietf-tls-tls13-28) > -- > Title : The Transport Layer Security (TLS) Protocol Version > 1.3 > Publication Date: August 2018 > Author(s) : E. Rescorla > Category: PROPOSED STANDARD > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] [Errata Held for Document Update] RFC8422 (5468)
The following errata report has been held for document update for RFC8422, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid5468 -- Status: Held for Document Update Type: Editorial Reported by: Masato Gosui Date Reported: 2018-08-17 Held by: Paul Wouters (IESG) Section: 5.4 Original Text - namedCurve: Specifies a recommended set of elliptic curve domain Corrected Text -- namedcurve: Specifies a recommended set of elliptic curve domain Notes - This fixes mismatched names of the variable "namedcurve" in the "Structure of this message" paragraph. -- RFC8422 (draft-ietf-tls-rfc4492bis-17) -- Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier Publication Date: August 2018 Author(s) : Y. Nir, S. Josefsson, M. Pegourie-Gonnard Category: PROPOSED STANDARD Source : Transport Layer Security Area: Security Stream : IETF Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] [Errata Held for Document Update] RFC8446 (5682)
The following errata report has been held for document update
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5682
--
Status: Held for Document Update
Type: Technical
Reported by: Richard Barnes
Date Reported: 2019-04-01
Held by: Paul Wouters (IESG)
Section: 4.3.2, B.3.2
Original Text
-
--- rfc8446.txt 2018-08-10 20:12:08.0 -0400
+++ rfc8446.erratum.txt 2019-04-01 15:44:54.0 -0400
@@ -3341,7 +3341,7 @@
struct {
opaque certificate_request_context<0..2^8-1>;
- Extension extensions<2..2^16-1>;
+ Extension extensions<0..2^16-1>;
} CertificateRequest;
@@ -7309,7 +7309,7 @@
struct {
opaque certificate_request_context<0..2^8-1>;
- Extension extensions<2..2^16-1>;
+ Extension extensions<0..2^16-1>;
} CertificateRequest;
Corrected Text
--
--- rfc8446.txt 2018-08-10 20:12:08.0 -0400
+++ rfc8446.erratum.txt 2019-04-01 15:44:54.0 -0400
@@ -3341,7 +3341,7 @@
struct {
opaque certificate_request_context<0..2^8-1>;
- Extension extensions<2..2^16-1>;
+ Extension extensions<0..2^16-1>;
} CertificateRequest;
@@ -7309,7 +7309,7 @@
struct {
opaque certificate_request_context<0..2^8-1>;
- Extension extensions<2..2^16-1>;
+ Extension extensions<0..2^16-1>;
} CertificateRequest;
Notes
-
The length of this vector can never 2. It is either 0, if the vector is empty,
or >=4, if the vector has at least one extension. Nothing elsewhere in the
spec requires a non-zero number of extensions here, so this syntax should allow
a zero-length vector.
Paul Wouters (AD): Richard meant the diff to be the fix, not the
original/corrected text. The diff is not in the RFC itself. There are two
places in the mentioned sections that need this one liner fix.
--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s) : E. Rescorla
Category: PROPOSED STANDARD
Source : Transport Layer Security
Area: Security
Stream : IETF
Verifying Party : IESG
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] [Errata Held for Document Update] RFC7919 (4908)
The following errata report has been held for document update for RFC7919, "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid4908 -- Status: Held for Document Update Type: Technical Reported by: Martin Thomson Date Reported: 2017-01-16 Held by: Paul Wouters (IESG) Section: 4 Original Text - If a compatible TLS server receives a Supported Groups extension from a client that includes any FFDHE group (i.e., any codepoint between 256 and 511, inclusive, even if unknown to the server), and if none of the client-proposed FFDHE groups are known and acceptable to the server, then the server MUST NOT select an FFDHE cipher suite. In this case, the server SHOULD select an acceptable non-FFDHE cipher suite from the client's offered list. If the extension is present with FFDHE groups, none of the client's offered groups are acceptable by the server, and none of the client's proposed non-FFDHE cipher suites are acceptable to the server, the server MUST end the connection with a fatal TLS alert of type insufficient_security(71). Corrected Text -- If a compatible TLS server receives a Supported Groups extension from a client that includes any FFDHE group (i.e., any codepoint between 256 and 511, inclusive, even if unknown to the server), and if none of the client-proposed FFDHE groups are known and acceptable to the server, then the server MUST NOT select an FFDHE cipher suite. In this case, the server SHOULD select an acceptable non-FFDHE cipher suite from the client's offered list. Notes - The text is overly prescriptive about the alert code that needs to used if there are no acceptable cipher suites available. If the server is unable to pick a cipher suite, it can send a handshake_failure(40) alert, which this text would prohibit. handshake_failure is at least equally valid in practice. This eliminates the prescriptive text about the alert type. Servers eliminate cipher suites from considerations in numerous ways. Being able to definitively identify the reason as a (perceived) shortcoming in the strength of the offered security is actually quite challenging in practice. It's true that insufficient_security is perhaps a more desirable code to use in this case, but it's not generically possible to determine that the server configuration is "more secure" than the combinations on offer by the client. Consider also the possibility that it's the server that is insecure because it doesn't some of the options offered by the client. That's a general criticism of the value of insufficient_security, but it should at least motivate why insufficient_security should never be mandated in this way. Paul Wouters(AD): After discussion with Martin, we propose that the correction required is only the removal of "of type insufficient_security(71).". As Martin explains: Having a MUST on this is not appropriate in that sense. What would be acceptable is: [...] the server terminates the connection according to Section 4.1.1 of [RFC8446]. Of course, that would depend on time travel in the sense that RFC 7919 pre-dates TLS 1.3 by a fair bit and so it can't really refer to it like that. -- RFC7919 (draft-ietf-tls-negotiated-ff-dhe-10) -- Title : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) Publication Date: August 2016 Author(s) : D. Gillmor Category: PROPOSED STANDARD Source : Transport Layer Security Area: Security Stream : IETF Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Errata Held for Document Update] RFC8446 (6205)
Yeah, we talked about this one and came to a reasonable conclusion that was based on what I wrote at the time, but better because RFC 8773 exists. The added text: > In the absence of some other specification to the contrary, servers which are > authenticating with an external PSK MUST NOT send the CertificateRequest > message either in the main handshake or request post-handshake > authentication. [RFC8773] provides an extension to permit this, but has not > received the level of analysis as this specification. You could improve further, slightly, on an editorial basis: s/the level of analysis/the same level of analysis/ On Wed, Jan 17, 2024, at 13:12, Eric Rescorla wrote: > I believe that the current 8446-bis text addresses this. Martin? > > On Tue, Jan 16, 2024 at 4:59 PM RFC Errata System > wrote: >> The following errata report has been held for document update >> for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". >> >> -- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid6205 >> >> -- >> Status: Held for Document Update >> Type: Editorial >> >> Reported by: Martin Thomson >> Date Reported: 2020-06-04 >> Held by: Paul Wouters (IESG) >> >> Section: 4.3.2 >> >> Original Text >> - >>Servers which are authenticating with a PSK MUST NOT send the >>CertificateRequest message in the main handshake, though they MAY >>send it in post-handshake authentication (see Section 4.6.2) provided >>that the client has sent the "post_handshake_auth" extension (see >>Section 4.2.6). >> >> Corrected Text >> -- >>Servers which are authenticating with a resumption PSK MUST NOT send the >>CertificateRequest message in the main handshake, though they MAY >>send it in post-handshake authentication (see Section 4.6.2) provided >>that the client has sent the "post_handshake_auth" extension (see >>Section 4.2.6). Servers which are authenticating with an external PSK >>MUST NOT send the CertificateRequest message either in the main handshake >>or request post-handshake authentication. Future specifications MAY >>provide an extension to permit this. >> >> Notes >> - >> The lack of qualification on "authenticating with a PSK" implies that the >> statement applies equally to both external and resumption PSKs. However, >> there are two conditions being governed: whether a certificate can be >> requested during the handshake, and whether a certificate can be requested >> post-handshake. The latter of these requires different rules depending on >> the type of PSK. >> >> We know from the analysis of resumption (see >> https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/) that >> combining a PSK handshake of either type with a client certificate is not >> safe. Thus, the prohibition on CertificateRequest during the handshake >> applies equally to both resumption and external PSKs. >> >> For post-handshake, Appendix E.1 already discusses the risks of combining >> PSKs with certificates, citing the same analysis as above. >> >>[...] It is unsafe to use certificate-based client >>authentication when the client might potentially share the same >>PSK/key-id pair with two different endpoints. >> >> For this reason an external PSK is not safe to use with post-handshake >> authentication. A resumption PSK does not have this property, so the same >> prohibition doesn't apply. >> >> Splitting the requirements as proposed makes this split clearer. >> >> -- >> RFC8446 (draft-ietf-tls-tls13-28) >> -- >> Title : The Transport Layer Security (TLS) Protocol Version 1.3 >> Publication Date: August 2018 >> Author(s) : E. Rescorla >> Category: PROPOSED STANDARD >> Source : Transport Layer Security >> Area: Security >> Stream : IETF >> Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
