Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4710C1D5C5A for ; Wed, 27 Nov 2024 23:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbzEQMk2fkoP for ; Wed, 27 Nov 2024 23:35:03 -0800 (PST) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 2A867C1D4CD2 for ; Wed, 27 Nov 2024 23:35:03 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-aa5366d3b47so70948766b.0 for ; Wed, 27 Nov 2024 23:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732779302; x=1733384102; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=37R9ypD55XNA4O9jwwjUZq3bxi7vH7HgRS6tWCm15QA=; b=hSgRaqy+EwkCP7IaZ3I+ccL3QViC6av4k04FSP6EfVG83eTdSHgOOZLF3QtKpPsoed j9DNWRyl8pOog5JsnaWIrcv5Xts7PbDZ6Yc0EOBMWAAOgHPVSw9Qs3VLi5+ZxuoGFw2N gcI7sjNSO5CwdBm2k1/a4fGp+LukueSIy6ncRSYhVzHDWAZtxAxR+FWc49PhDOYNk8PG xNaRe5JwON17Wv4A+UX11Bx6FWf7fe+9dD+dJtmva/y015SySkjA3y+4HE3aAfQdpz4w A+2WcY8A/VmHVsY9rEG7WrcYsh9dqelAJ4Ru6fjY/INC0ps8xCjm059pKgoc+7osFp/z HSsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732779302; x=1733384102; h=cc: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=37R9ypD55XNA4O9jwwjUZq3bxi7vH7HgRS6tWCm15QA=; b=FyRP5+Iockpv5xlUyV47TmpuyibQRWSWxbEE0Eml5Fx3Xt2FAd4dCJE7mhZela3fav o9y/qjXtp5paSOJ/i4sV6iUcwyM0XEO8dQVUECXZVMDi0edBZy3f/Q4jqiO2DFcT+IW9 g3uqXWmRA92jJZuDpleY11dLqH34TZQepMKuikMNOuuAGXfl6ib8Gh94uxFhh6Ofc5/H hRmnpX5wc4arzJQYSHb3Z2yPUQbjjs5BUFMCKNrKUSNwm8OOjqbgYK+cC0aSXHZ/X+e8 hm6wVYhjYjU+8HcC20ZHvDXtU3LP2mlxEJ8tKC+iHkGeJIJMNamTSXAKepXlZlDOOrku gRAw== X-Forwarded-Encrypted: i=1; AJvYcCWXzTR6MOz1muyaOXlwM49prk1fi2O7VaXKaxRy0DoNWQqEm/+cD2e8s1wtOxwVcfI8PUQ=@ietf.org X-Gm-Message-State: AOJu0YyCirjoKZ7h2QG8A+exbWcsDUoNv5zETrmHKRE87lbfneOdDVoq RS86zVl+o1v6TtopLfpSdV4wF/2OkMoefElMjYGgOmyW2Y9MCc18H/4c4buRs15zXL2kTt45kL1 QVvs9Uw52/e/W8VpPzyMWZZ5x5XThfTYovCU= X-Gm-Gg: ASbGncubOOEprvFaATfw0Vt7R+TfmRyqXSGE5F5MhM7IPPGCkr+LOIWtYfTCY/+8zSe hIvPn2jjGujIy4ameDbW0Zd3xBmeufM97 X-Google-Smtp-Source: AGHT+IH08NolBZcaLVZty7RhkSl8kY8iGFuOdwCi+rjRzP9N7wbwU5wKsZmUo/2TxsThvFv4ihOmbc54tXRO4uWPwFw= X-Received: by 2002:a17:906:30cf:b0:a9f:4f7:f064 with SMTP id a640c23a62f3a-aa580edf616mr442376766b.3.1732779301516; Wed, 27 Nov 2024 23:35:01 -0800 (PST) MIME-Version: 1.0 References: <20241124184822.743413.qmail@cr.yp.to> In-Reply-To: From: tirumal reddy Date: Thu, 28 Nov 2024 13:04:24 +0530 Message-ID: To: "Blumenthal, Uri - 0553 - MITLL" Content-Type: multipart/alternative; boundary="000000000000bdbd010627f41e97" Message-ID-Hash: UPF5T5UPXWUEHAA5UZUORUEMYM5TMUKK X-Message-ID-Hash: UPF5T5UPXWUEHAA5UZUORUEMYM5TMUKK X-MailFrom: kondtir@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 CC: "D. J. Bernstein" , "tls@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?b?W1RMU10gUmU6IFtFWFRdIFJlOiBNTC1EU0EgaW4gVExT?= List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000bdbd010627f41e97 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 25 Nov 2024 at 06:55, Blumenthal, Uri - 0553 - MITLL wrote: > > To clarify, are you continuing to claim that there's "no damage possibl= e > > (at least, in the TLS context) caused by PQ DSA break", despite the > > facts that (1) upgrades often take a long time and (2) attackers aren't > > going to announce their secret attacks? > > For (1) I call it not an =E2=80=9Cupgrade=E2=80=9D (i.e., to something ne= w and often > untested yet), but a =E2=80=9Cdowngrade=E2=80=9D =E2=80=93 reverting to t= he =E2=80=9Cold mature and > well-tested ECC code=E2=80=9D. Shouldn=E2=80=99t take long at all. > > For (2) =E2=80=93 why do you assume there are no secret attacks against E= CC? > Merely because you couldn=E2=80=99t find one, and nobody announced it yet= ? > > > >> then don=E2=80=99t move to PQ DSA until either CRQC is announced > > > > That would be too late. It completely fails to address the large risk o= f > > quantum attacks happening before the first public attack demos, plus it > > leaves users vulnerable during the upgrade period. > > You don=E2=80=99t really need PQ DSA until CRQC is here. At this point, e= verybody > seems to agree that there is time before CRQC arrives. So, keep > studying/exploring/attacking PQ DSA, and prepare code and infrastructure = to > deploy it =E2=80=93 but use ECC for now. It will also > The deployment timeline for new algorithms and standards is lengthy. For instance, once an IETF specification is standardized, it typically takes around 1.5 years for 3GPP to incorporate it into their release cycle. After that, product teams require several months for development and testing. Additionally, operators often adopt these updates gradually, which extends the timeline further. Moreover, it may not always be feasible to easily tweak configurations to enable/disable algorithms dynamically when CRQCs become publicly known. We would like to also consider the potential impact of zero-day vulnerabilities, where exploits are discovered and used before vulnerabilities are publicly disclosed. Proactive preparation and deployment of hybrid signature schemes reduces the risk of being caught unprepared in such deployments. -Tiru > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-leave@ietf.org > --000000000000bdbd010627f41e97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 25 Nov 2024 at 06:55, Blumenthal,= Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:

> To clarify, are you continuing t= o claim that there's "no damage possible
> (at least, in the= TLS context) caused by PQ DSA break", despite the
> facts that = (1) upgrades often take a long time and (2) attackers aren't
> go= ing to announce their secret attacks?

For (1) I call it not an =E2=80=9Cu= pgrade=E2=80=9D (i.e., to something new and often untested yet), but a =E2= =80=9Cdowngrade=E2=80=9D =E2=80=93 reverting to the =E2=80=9Cold mature and= well-tested ECC code=E2=80=9D. Shouldn=E2=80=99t take long at all.<= u>

For (2) =E2= =80=93 why do you assume there are no secret attacks against ECC? Merely be= cause you couldn=E2=80=99t find one, and nobody announced it yet?=


>> then don=E2=80=99t move to PQ DSA until= either CRQC is announced
>
> That would be too late. It comple= tely fails to address the large risk of
> quantum attacks happening b= efore the first public attack demos, plus it
> leaves users vulnerabl= e during the upgrade period.

You don=E2=80=99t really need PQ DSA until CRQC is here. At this = point, everybody seems to agree that there is time before CRQC arrives. So,= keep studying/exploring/attacking PQ DSA, and prepare code and infrastruct= ure to deploy it =E2=80=93 but use ECC for now. It will also

The deployment time= line for new algorithms and standards is lengthy. For instance, once an IET= F specification is standardized, it typically takes around 1.5 years for 3G= PP to incorporate it into their release cycle. After that, product teams re= quire several months for development and testing. Additionally, operators o= ften adopt these updates gradually, which extends the timeline further.=C2= =A0Moreover, it may not always be feasible to easily tweak configurations t= o enable/disable algorithms dynamically when CRQCs become publicly known. W= e would like to also consider the potential impact of zero-day vulnerabilit= ies, where exploits are discovered and used before vulnerabilities are publ= icly disclosed. Proactive preparation and deployment of hybrid signature sc= hemes reduces the risk of being caught unprepared in such deployments.

-Tiru
=C2=A0<= /span>
_______________________________________________ TLS mailing list -- tls@i= etf.org
To unsubscribe send an email to tls-leave@ietf.org
--000000000000bdbd010627f41e97--