Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?
On Mon, Jan 15, 2024 at 11:21 PM D. J. Bernstein wrote: > If the goal is maximum streamlining for IND-CCA2 then > one shouldn't include the _recipient's_ X25519 public key in the hash, > so why exactly does X-Wing include it? > 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". Cheers, Jack ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] New Liaison Statement, "Quantum Safe Cryptographic Protocol Inventory"
Title: Quantum Safe Cryptographic Protocol Inventory Submission Date: 2024-01-10 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1893/ From: Matt Campagna To: Russ Housley ,Tim Hollebeek ,Yoav Nir ,Tero Kivinen ,Sofia Celi ,Paul Hoffman ,Joseph Salowey ,Sean Turner ,Deirdre Connolly Cc: Sean Turner ,Sofia Celi ,Limited Additional Mechanisms for PKIX and SMIME Discussion List ,Yoav Nir ,Paul Wouters ,Deirdre Connolly ,Tim Hollebeek ,Joseph Salowey ,Paul Hoffman ,Post-Quantum Use In Protocols Discussion List ,Russ Housley ,IP Security Maintenance and Extensions Discussion List ,Roman Danyliw ,Tero Kivinen ,Transport Layer Security Discussion List Response Contacts: cybersupp...@etsi.org Technical Contacts: Purpose: For information Body: Attachments: CYBERQSC(23)032007r2_QSC_Protocol_Inventory_LSOut https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2024-01-10-etsi-tc-cyber-qsc-wg-tls-ipsecme-lamps-pquip-quantum-safe-cryptographic-protocol-inventory-attachment-1.pdf ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] [Errata Verified] RFC5246 (4912)
The following errata report has been verified for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid4912 -- Status: Verified Type: Technical Reported by: Nikolai Malykh Date Reported: 2017-01-18 Verified by: Paul Wouters (IESG) Section: A.4.1 Original Text - SignatureAndHashAlgorithm supported_signature_algorithms<2..2^16-1>; Corrected Text -- SignatureAndHashAlgorithm supported_signature_algorithms<2..2^16-2>; Notes - Error in last sentence. See errata ID 2865. Paul Wouters (AD): From errata ID 2865: The supported_signature_algorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case). See section 7.4.1.4.1 for a valid definition of this field. This is already fixed in TLS 1.3 RFC8446 -- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date: August 2008 Author(s) : T. Dierks, 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 Verified] RFC5246 (4750)
The following errata report has been verified for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid4750 -- Status: Verified Type: Technical Reported by: Adrien de Croy Date Reported: 2016-07-27 Verified by: Paul Wouters (IESG) Section: 4.3 Vectors Original Text - The length of an encoded vector must be an even multiple of the length of a single element (for example, a 17-byte vector of uint16 would be illegal). Corrected Text -- The length of an encoded vector must be a whole multiple of the length of a single element (for example, a 17-byte vector of uint16 would be illegal). Notes - Original text implies vectors can only contain even (0,2,4,6,8...) numbers of elements. The example does not resolve this but indicates the intent is that parts of elements are not allowed. It is clear from other examples that odd numbers of elements are permitted. Paul Wouters (AD): As TLS 1.2 is obsoleted by TLS 1.3, this errata is closed as Verified. In TLS 1.3 in RFC 8447 the text states more clearly: Here, T' occupies n bytes in the data stream, where n is a multiple of the size of T. -- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date: August 2008 Author(s) : T. Dierks, 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
Re: [TLS] ECH: Changes to IANA consideration section
Hiya, On 19/12/2023 16:42, Stephen Farrell wrote: On 19/12/2023 16:34, Sean Turner wrote: FYI the assignments have been made. Great. Can I ask what's the plan for WGLC? Be great if that could be started before the holidays:-) Good that the IANA registrations are done. Can I ask when will we see the long-overdue WGLC? I would assert that this now almost 5 year old draft is pretty well-baked, having been widely deployed already, and it's time we extract it from of the IETF oven:-) Thanks, S. PS: There is a previously-stated reason to push on this - with some open source libraries, (in particular OpenSSL), having the RFC issued is required before code is merged, and getting ECH code into such libraries is a prerequisite for it getting into some web server applications, so the longer we take with this, the more we encourage centralisation of services and the worse we do with encouraging potential adoption for de-centralised sets of servers. So, how about we get off the pot? Ta, S. spt On Dec 12, 2023, at 09:11, Sean Turner wrote: I should also included a link to the revised PR: https://github.com/tlswg/draft-ietf-tls-esni/pull/597 spt On Dec 11, 2023, at 22:01, Sean Turner wrote: I am going to go ahead and forward this. Note that since the “Comments” column isn’t a thing until we get 8447bis through the door the note will follow. spt On Dec 6, 2023, at 14:46, Sean Turner wrote: Okay a new proposal the ech_outer_extensions registration: - Set "TLS 1.3" column to “CH” - Include the following note in our new “Comments” column [0]: "Only appears in inner CH." spt [0] PRs: https://github.com/tlswg/rfc8447bis/pull/48 https://github.com/tlswg/rfc8447bis/pull/49 On Nov 29, 2023, at 16:09, Stephen Farrell wrote: Hiya, On 27/11/2023 14:35, Sean Turner wrote: Bumping this up in case anybody missed it. 'case it helps, I'm fine with the original mail you sent and any of "n/a" or "CH" being used rather than "-". If it helps, I've a very minuscule hint of a preference for "CH" so you can count me as agreeing with MT. But I won't object to any other thing, 'cause I don't think there's a perfect answer, and it matters very little, and defining a new thing like "CHI" just for this seems OTT, but meh, I could even live with that too. I'd also be fine with this just left to chair/editor discretion FWIW. While it's good to bring things like that to the list, I don't think you need to delay based on a small-ish set of responses. Cheers, S. spt On Nov 21, 2023, at 21:03, Sean Turner wrote: Hi! I sent over the early allocation request and the IANA folks rightly pointed out two things that need to be added. This email is to make sure we have agreement on the two changes to the registrations in s11.1. If you don’t agree with the values proposed below please let the list know by 1 December 2023. 1. The encrypted_client_hello and ech_outer_extensions registrations need to indicate the value for the "DTLS-Only” column. Unless I am mistaken, “N” is the obvious value for both. See https://github.com/tlswg/draft-ietf-tls-esni/pull/584 2. The "TLS 1.3” column for ech_outer_extensions registration needs to indicate a value; remember, this column indicates the messages in which the extension may appear. Currently, it’s “”. “N/A" has been suggested, which makes sense to me considering this extension never directly appears in CH, SH, EE, CT, CR, NST, or HRR extensions field. We can’t use “-“ because that means not used in TLS 1.3. “” is used elsewhere in the registry by only for unassigned and reserved values. The following PR change “” to “N/A”: https://github.com/tlswg/draft-ietf-tls-esni/pull/59 Cheers, spt ___ 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 OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] [Errata Verified] RFC5246 (4507)
The following errata report has been verified for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid4507 -- Status: Verified Type: Technical Reported by: Benjamin Kaduk Date Reported: 2015-10-19 Verified by: Paul Wouters (IESG) Section: 7.4.1.2 Original Text - After sending the ClientHello message, the client waits for a ServerHello message. Any handshake message returned by the server, except for a HelloRequest, is treated as a fatal error. Corrected Text -- After sending the ClientHello message, the client waits for a ServerHello message. Any other handshake message returned by the server, except for a HelloRequest, is treated as a fatal error. Notes - A ServerHello received after a ClientHello should not be treated as a fatal error. Paul Wouters (AD): TLS 1.2 has been obsoleted by TLS 1.3 RFC8446. The language in that RFC does not contain the same issue (see https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.2). As such, this is marked as Verified. -- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date: August 2008 Author(s) : T. Dierks, 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 Verified] RFC5054 (4546)
The following errata report has been verified for RFC5054, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid4546 -- Status: Verified Type: Technical Reported by: Rick van Rein Date Reported: 2015-11-30 Verified by: Paul Wouters (IESG) Section: 2.6 Original Text - B = k*v + g^b % N Corrected Text -- B = ( k*v + g^b ) % N Notes - The customary binding is that + has lower priority than % and so the default reading of the expression would be B = k*v + ( g^b % N ) That is inconsistent with the existence of PAD(B) and the size of B in the test vectors, so the context hints at proper brackets, but this may still lead to implementation errors (of which I actually ran into an example). Paul Wouters (AD): This errata is correct, but note that this RFC is applicable only for TLS < 1.3. For TLS 1.3, one needs to use a PAKE as replacement, such as those defined in RFC8492. As such, this errata is left as Verified as there won't be a document update for this document. -- RFC5054 (draft-ietf-tls-srp-14) -- Title : Using the Secure Remote Password (SRP) Protocol for TLS Authentication Publication Date: November 2007 Author(s) : D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin Category: INFORMATIONAL 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] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?
> > 2. I think it's good that both of the X25519 public keys are included > > where some hybrid constructions would include just one (labeled as > > ciphertext). > And it is required for the IND-CCA robustness: without it, it's not. Well, that depends on _which_ X25519 key is included in the hash. If the recipient's KEM public key is an X25519 public key, and the sender's KEM ciphertext is an X25519 public key, and the KEM session key is the X25519 shared secret, then the KEM obviously isn't IND-CCA2: it has what https://www.shoup.net/iso/ calls "benign malleability". The normal way to upgrade from benign malleability to IND-CCA2 is to also hash the ciphertext---i.e., the sender's X25519 public key---into the session key. If the goal is maximum streamlining for IND-CCA2 then one shouldn't include the _recipient's_ X25519 public key in the hash, so why exactly does X-Wing include it? I don't think the goal here should be maximum streamlining for IND-CCA2. The point of hybrids is to do a bit more work to reduce the damage from screwups; I think the scope of screwups under consideration should go beyond mathematical breaks and also include implementation issues. In particular, what happens if protocol designers confuse the two X25519 public keys here, and hash the _recipient's_ public key instead of the _sender's_ public key? The upgrade to IND-CCA2 doesn't work. Hopefully the protocol is okay with benign malleability, but there has been so much emphasis on IND-CCA2 that it's hard to blame a protocol designer for assuming that KEMs have that property. So, as I said, I'm happy with a combiner hashing both of the X25519 public keys (along with the shared secret, obviously). But the same perspective also makes me ask what happens when people replace Kyber with a different post-quantum KEM. The combiner H = SHA3-256, hybridpk = (receiverpkECDH,receiverpkKEM), hybridct = (senderpkECDH,senderctKEM), hybridss = H(ssECDH,ssKEM,H(hybridct),H(hybridpk),context) is then safer than X-Wing. Even for people using Kyber, this KEM makes security review easier than X-Wing does. This combiner also satisfies requests (see my first message for references) to include KEM public keys (or at least prefixes of those) in the hash for other reasons. I don't see how the cost of hashing hybridct can be an issue next to the cost of communicating it. Same for hybridpk (and obviously the hash can be saved whenever the public key is saved). I worry about complicating KEM analyses since they're already complicated and error-prone in the first place---we've seen many breaks of KEM proposals---but this combiner is a separate module, and the IND-CCA2 property that it's requesting from the input KEM is what we're asking a KEM to do anyway. I think that the potential review benefit of _omitting_ hybridct and/or hybridpk will be outweighed by the review complication of ending up with more combiners than necessary. ---D. J. Bernstein ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
