IETF Logo Mail Archive

[TLS] Re: ML-KEM failures

Phillip Hallam-Baker <ietf@hallambaker.com> Tue, 07 October 2025 14:29 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 1E16B6EA986E for <tls@mail2.ietf.org>; Tue, 7 Oct 2025 07:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.877
X-Spam-Level:
X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.017, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWAyw2qUarMC for <tls@mail2.ietf.org>; Tue, 7 Oct 2025 07:29:46 -0700 (PDT)
Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 8AEC06EA97A1 for <tls@ietf.org>; Tue, 7 Oct 2025 07:29:44 -0700 (PDT)
Received: by mail-qv1-f47.google.com with SMTP id 6a1803df08f44-7970e8d1cfeso78392646d6.1 for <tls@ietf.org>; Tue, 07 Oct 2025 07:29:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759847378; x=1760452178; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pu1a1cvW1PJ/195uQeVtR25rx8Nyzmn7mLiiTMTt4Sg=; b=h+0Ovpp/Nh1r3suBG+GC0UjgzChSdjPHJ6w44wTt8q5wyqKrlbs+OFEc8SG+Djl/Kd fg2rnNIpMS7V/osbH9ZLyx8NMz4Hrx0rWjpf5YfuKrn1+VyVDz+F9tAnBzk+rXVQElHS 9FqpKe9DSl73nH29Xg3gEc7J9SdF4SikMcDXwvz9kaMxtJN4Vvduaj3dc1eUpda8PLf8 Rh4qHtzGkrvw1waFwpq1wfj9awkt6TR9OHqQwQ5UCpJHnSMFtvR7ano1qIKzFzMirn9d BxxOUclh9t52boC7HdW9rovFSnvUVK4Ny0k8UoawZB+KM2NLmlgZjCbOfYMONRKL6Zwf /L1Q==
X-Gm-Message-State: AOJu0Yyg7pUApU1RBlYSlOkUVso4ZMZ3qhxbHRgyz19o5s3A+fvF/yJk J/uV3syhSCBeulc9kyPN3NoZI6AhmfKpd+LmKSm69oErMSzLA+a2muSNKZUufBS+DQvIY+bWIZG +cCH9uP8dtgofYE5C3baqislF1heEZa+uZxM6
X-Gm-Gg: ASbGncsqOjn9ktEgLgZ4J7tOjA8RMNhnilUaEfpw2QAri2kW9oB5vGNes4zxA8FA/Qm sJlU3bKzqkVnmY06M+BaOI/r8FTuZdYj4Wp7UKpM5II5ePFWAmCki1wnbiPRqjWAYzDcRdPvFOu 6JSJSsiTktHZSMekBrJtDBodH5Gg5KL+JtEvlhT/LyW7xW4xE/mfA2GScEM3hKCr4QXjfyBSRBe Q5fRG7U/mWUwXRR+FHPuMwmuIHAA7leuSVvk4u6GAwXw5dYZr8xG1uKgTK7khiq1BExPwqBsVWD O5R+NVEhsvnkkllmyP0fyvw9HFGI9oz9eqHnnzy/XKSJLQ==
X-Google-Smtp-Source: AGHT+IFgGeS7gvB4K3MiGkrR04+S37JNDvrdsuEsQjxk4vErhohoDlIC2uXHVjLGVGpc9leUxlzSBsQJl79OObTnvSc=
X-Received: by 2002:a05:6214:765:b0:7b4:4dea:2a9d with SMTP id 6a1803df08f44-879dc85287amr218411246d6.53.1759847377993; Tue, 07 Oct 2025 07:29:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAHBU6iv0ztRg8ESC-ipftJzsJjTewKMxmMMWc3TXut_Rdxbz+A@mail.gmail.com> <20250925184030.290092.qmail@cr.yp.to> <CABcZeBOafQCFJVGE1TN92BpC2rJQ5b5d7tdDXuaa_vgu5TMr=Q@mail.gmail.com> <CAEEbLAZhxcxCCoVz-vPGjDCacFa9ZP+VmdX-Z1yGL3EemhVy5A@mail.gmail.com> <2c83d8ff-d429-90c3-f776-c04627cb8ac2@nohats.ca> <02fd876f-8fb8-4d56-aabf-61044b3060c5@gmail.com> <IA3PR11MB9133A4A4B338E3066E6FF8CDC11BA@IA3PR11MB9133.namprd11.prod.outlook.com> <70cf0b8b-ffb5-4ad6-b663-89fbaacffec4@gmail.com>
In-Reply-To: <70cf0b8b-ffb5-4ad6-b663-89fbaacffec4@gmail.com>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
Date: Tue, 07 Oct 2025 10:29:24 -0400
X-Gm-Features: AS18NWDUFqCvVNTgTkI3-Nal32dsz3_KjnCnCrbZkNSED3btdmYf3ri549HDcss
Message-ID: <CAMm+LwiHBekxV2F-6n9435axOb04va38WBNUMTEvRq1sSt1uDA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d30d7a06409265bc"
Message-ID-Hash: 5ZW3QKDK7DOXZTKBZ5OKKVBAEVSLXSNX
X-Message-ID-Hash: 5ZW3QKDK7DOXZTKBZ5OKKVBAEVSLXSNX
X-MailFrom: hallam@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: ML-KEM failures
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9E2BtGvBC1p2pQaO4XNS-zaZKYY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

This whole problem goes away when considering the TLS negotiation from a
systems perspective.

Consider the fact that the initiator and responder in a TLS negotiation are
connected via a transmission medium with a finite probability of an
undetected transmission error. There is only a one bit checksum on the
individual octets and the QUIC/TCP packet checksum is only 16 bits.

[There is also the possibility of a CPU issue as people mentioned but that
is a game over issue while recovering from transmission failures is
something much more in scope]

A responder attempting to do a key agreement against a corrupted ephemeral
is going to occur far more often than algorithmic decaps failures and this
condition should be indistinguishable as far as the initiator is concerned.
Even if there is a way for the responder to distinguish the conditions, it
shouldn't.

v2.34.0 | Report a Bug | By Email | System Status