Re: [TLS] [UNVERIFIED SENDER] Re: Comments on draft-celi-wiggers-tls-authkem-00.txt

"Kampanakis, Panos" <kpanos@amazon.com> Thu, 22 July 2021 04:26 UTC

Return-Path: <prvs=8302bfa12=kpanos@amazon.com>
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 89B983A3718 for <tls@ietfa.amsl.com>; Wed, 21 Jul 2021 21:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.047
X-Spam-Level:
X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8U28AMxX4GT for <tls@ietfa.amsl.com>; Wed, 21 Jul 2021 21:26:05 -0700 (PDT)
Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86683A3713 for <tls@ietf.org>; Wed, 21 Jul 2021 21:26:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1626927965; x=1658463965; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=pSp7B79tGqM9Wm/Ond8NKImQEQ2r1DSZ6GNKF3wgEos=; b=lpQX2vxwK3QvviLMayONZkXUJu9Ua/jy0M2nTx/eJ9KoxDkYLb0hU5Nk SE4UETPukNTfkB8XARuR/QkFTsaa0I3eggX9DBGhUk9nhSa5FppMdkAnD fQMHNv3iXCHgN1czO1WHRg71ZLPCzFOo7dI58fMXZssY7JYFUO/3tNB+Q g=;
X-IronPort-AV: E=Sophos;i="5.84,259,1620691200"; d="scan'208,217";a="124106258"
Thread-Topic: [UNVERIFIED SENDER] Re: [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt
Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1d-38ae4ad2.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-2101.iad2.amazon.com with ESMTP; 22 Jul 2021 04:25:55 +0000
Received: from EX13MTAUWB001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1d-38ae4ad2.us-east-1.amazon.com (Postfix) with ESMTPS id 926B1A1D5D; Thu, 22 Jul 2021 04:25:54 +0000 (UTC)
Received: from EX13D01ANC003.ant.amazon.com (10.43.157.68) by EX13MTAUWB001.ant.amazon.com (10.43.161.207) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Thu, 22 Jul 2021 04:25:53 +0000
Received: from EX13D01ANC003.ant.amazon.com (10.43.157.68) by EX13D01ANC003.ant.amazon.com (10.43.157.68) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Thu, 22 Jul 2021 04:25:52 +0000
Received: from EX13D01ANC003.ant.amazon.com ([10.43.157.68]) by EX13D01ANC003.ant.amazon.com ([10.43.157.68]) with mapi id 15.00.1497.023; Thu, 22 Jul 2021 04:25:52 +0000
From: "Kampanakis, Panos" <kpanos@amazon.com>
To: Watson Ladd <watsonbladd@gmail.com>
CC: Eric Rescorla <ekr@rtfm.com>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Index: AQHXeGp0uhWfD5/oG0GXYuZ0ZLsv7KtOa+vA
Date: Thu, 22 Jul 2021 04:25:52 +0000
Message-ID: <797d22be046b42a3839850da2b9a1f3e@EX13D01ANC003.ant.amazon.com>
References: <CABcZeBN4y40o7T3hx4RH3LogbMDEScxGY4SVuCWuQ67oW+XZ3w@mail.gmail.com> <DF9C8D2D-4B2A-414D-AD7A-0ED424CD98FE@gmail.com> <CABcZeBNH4Hg5v99+MmsgTNKD54jvxLRzrj55fCM+m8drxajQKA@mail.gmail.com> <76bf3aa9e18c475590b6fab7c050b851@EX13D01ANC003.ant.amazon.com> <CACsn0c=9uTybFw4Uj4o-xxN4WjtwJcCrH5MUSEyXVHkMmAsOkw@mail.gmail.com>
In-Reply-To: <CACsn0c=9uTybFw4Uj4o-xxN4WjtwJcCrH5MUSEyXVHkMmAsOkw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.156.236]
Content-Type: multipart/alternative; boundary="_000_797d22be046b42a3839850da2b9a1f3eEX13D01ANC003antamazonc_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UoyuwVDJ3bH5zKkVH07y7_WtO3s>
Subject: Re: [TLS] [UNVERIFIED SENDER] Re: Comments on draft-celi-wiggers-tls-authkem-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jul 2021 04:26:11 -0000

> SQISign is short! It's just slow to sign, which KEMTLS avoids. Also with a known set of intermediates the public keys do not need transmission, and the tradeoffs between signature, public key, verification, and signing speed further shift. One could conceivably use XMSS roots to sign SQISign intermediates of moderate duration signing FALCON or Dilthium KEM keys, balancing security and performance at each level. I think this fits in 14KB with realistic conditions. We shouldn't assume that NIST candidate signature schemes are the last word here.

My argument is that suppressing ICA certs and not doing KEMTLS will be immaterially slower than using KEMTLS and suppressing ICA certs. Or alternatively I am arguing that using Dilithium without KEMTLS will be immaterially slower than using KEMTLS. It was shown in  ia.cr/2020/071<https://ia.cr/2020/071> , dl.acm.org/<https://dl.acm.org/doi/10.1145/3386367.3431305>doi<https://dl.acm.org/doi/10.1145/3386367.3431305>/10.1145/3386367.3431305<https://dl.acm.org/doi/10.1145/3386367.3431305> , ia.cr/2019/1447<https://ia.cr/2019/1447> that a couple of KB do not slow down the handshake even in lossy (not too lossy) conditions

But I am willing to change my mind if you have experimental proof.

I am also arguing that KEMTLS introduces significant changes to TLS 1.3. And that in order to avoid an extra round-trip it requires the client to get the server identity public key some out-of-band way. OK ECH does that for an encryption public key, but doing it for the identity public key is an extra complication.



From: Watson Ladd <watsonbladd@gmail.com>
Sent: Wednesday, July 14, 2021 12:39 AM
To: Kampanakis, Panos <kpanos@amazon.com>
Cc: Eric Rescorla <ekr@rtfm.com>; <tls@ietf.org> <tls@ietf.org>
Subject: [EXTERNAL] [UNVERIFIED SENDER] Re: [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.




On Mon, Jul 12, 2021 at 9:10 PM Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org<mailto:40amazon.com@dmarc.ietf.org>> wrote:

> So, while I'm not that enthusiastic about paying a few K, I think on balance it's a better than doing this kind of major rearchitecture of TLS.

+1. KEMTLS is a great scheme but significantly changes the TLS state machine. It introduces implicit and explicit auth concepts which do not exist in TLS 1.3 and would need further security proofs and study. Also, it may save ~1-2KB of data (Falcon, Dilithium assumed), but still uses PQ Sigs in the PKI which means we go to 10+ KB for the cert chain. So we alleviate 1-2KB, but still have to deal with 10+. Also note ia.cr/2019/1447<https://ia.cr/2019/1447> which makes the argument that the more the data the more the slowdown in lossy environments (which intuitively makes sense as the loss probability (1-(1-p)n) increases with more packets). Imo the draft-celi-wiggers-tls-authkem should be considered for future versions of TLS as the drastic changes do not justify the marginal benefit.

Part of what came out of the work on TLS 1.3 is a reusable formal model of TLS, and at least some of the work in KEMTLS has repeated this formal analysis.


And a couple of comments regarding Ekr’s points:

> - If you are doing TLS over TCP, then the server can use IW10 as specified in RFC 6928. This will allow the server's first flight to be about 14 KB, which should be large enough.

That is not completely accurate. The smallest Dilithium parameters will fit in 10MSS only when doing plain TLS (no SCTs, no OCSP staples) with up to 2 ICAs. Anything else will go beyond 14KB. Now if we talk web (include SCTs), then only 1 ICA would fit with Dilithium-II.

Having said that, if we talk about the other lattice based NIST PQ Sig Finalist, Falcon-512, then there are more TLS cases (up to 3 ICAs) where the data would fit in an TCP initcwnd.  For Falcon-1024 that is not the case either.

> - If you are doing QUIC, then the server is restricted to 3x the client's initial message, which is potentially a problem with very large server first flights, but the client can add extra bytes to its Initial messages to increase the limit [0]

Padding to the client initial message to 1200B would mean the QUIC amplification attack protection would kick in for any PQ KEM Round 3 Finalist and any PQ Sig Finalist, even Falcon-512 which is the smallest one. The smallest PQ Sig will still be >3x when used with X25519+the biggest PQ KEM Finalists. I am not sure what dummy key exchange data and how much of it someone could put in the client message in order to reach 2.5KB in the request in order for the response to fit in the 3x2.5 window necessary (assuming 2 ICAs).


SQISign is short! It's just slow to sign, which KEMTLS avoids. Also with a known set of intermediates the public keys do not need transmission, and the tradeoffs between signature, public key, verification, and signing speed further shift. One could conceivably use XMSS roots to sign SQISign intermediates of moderate duration signing FALCON or Dilthium KEM keys, balancing security and performance at each level. I think this fits in 14KB with realistic conditions. We shouldn't assume that NIST candidate signature schemes are the last word here.

I think the best answer to the extra round-trip problems which are inevitable for PQ Sigs (as shown in ia.cr/2020/071<https://ia.cr/2020/071> , dl.acm.org/<https://dl.acm.org/doi/10.1145/3386367.3431305>doi<https://dl.acm.org/doi/10.1145/3386367.3431305>/10.1145/3386367.3431305<https://dl.acm.org/doi/10.1145/3386367.3431305>) is Martin’s draft-<https://datatracker.ietf.org/doc/html/draft-thomson-tls-sic>thomson<https://datatracker.ietf.org/doc/html/draft-thomson-tls-sic>-<https://datatracker.ietf.org/doc/html/draft-thomson-tls-sic>tls<https://datatracker.ietf.org/doc/html/draft-thomson-tls-sic>-sic<https://datatracker.ietf.org/doc/html/draft-thomson-tls-sic> which should be revived imo.

Cert compression will not help as these big certs mostly consist of big keys or sigs which are random sequences and thus do not benefit from compression.

In some sense draft-thompson-tls-sic is compression with a dictionary of known intermediates.

Rgs,
Panos

Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim