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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Thu, 22 July 2021 19:00 UTC

Return-Path: <prvs=68373189bb=uri@ll.mit.edu>
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 C12A03A0DFE for <tls@ietfa.amsl.com>; Thu, 22 Jul 2021 12:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 d-TBeBb3NCWq for <tls@ietfa.amsl.com>; Thu, 22 Jul 2021 11:59:59 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (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 641AE3A0DEE for <tls@ietf.org>; Thu, 22 Jul 2021 11:59:59 -0700 (PDT)
Received: from LLE2K16-HYBRD02.mitll.ad.local (LLE2K16-HYBRD02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 16MIxrYV013040; Thu, 22 Jul 2021 14:59:53 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=FTVqyK+tbyzZCPlhKddV0x6OkGLEAX5ik2xfJw6Qh/Hr3s6cpYjgi+cji4nNJTPKtqmo0PqgMK2QrTMnIBmtYbNa62TJ+1b9BY3v+3LKbCVGTLLgZkuXMYYuMUj49urHyd42K9jgnSbHqwuHbjjjWyii4t/cx8bc4tI8Si1T03s238tna7bo3CmjpLkm9e1YIWI0KWxnjm5Q0hphN6QHIzmv3md3fQ4RgDW638GYx3s01+j6CoZ0e0ME53yYn2XVFiHYjCKw4mbnxwBz6y5ueOMTZChXGOH2m+zsTG4LtYppnvJ/QxlliMaQTkIekizI+peYNEL3IEsYQvHqThnHhg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GzT4HYV7ZRiyGVea4RqPZiybYf9Kp9/PX8QE5Lr56tI=; b=S6Y/RiGLJMoc33T7iutyIuPEbpXHrOeGgxRZZ8VWq56443FSIQa6pLjPBoNgwt6hCb9zhZvMxWk2mpenLfwaG2KwIRWCwFqd9UFWf4vsm+VYKxiirUqhf/Oy+XEO9OYcjg82pHLZsD/7LAWn1pL+kgs6e+0R8XSrqehL2dg/BgreAADnV++k9vhNNDvFwm68EZQFsBAlM/UKxKuJi5lIqwlgWX720Q67QZvkREhVwwrOH6Ehki2z9K4nhQLuN6GF1Jgkp16ksWUIwXFdJK9wxGFIcnyKS87WnEZS1Z7y1+9P0vLdt+A0ugDyqXK1NuLghu+Hk88JZ62KwN3gcOBj+g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "Kampanakis, Panos" <kpanos@amazon.com>
CC: "tls@ietf.org" <tls@ietf.org>, Douglas Stebila <dstebila@gmail.com>, "Eric Rescorla" <ekr@rtfm.com>
Thread-Topic: [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt
Thread-Index: Add+tHdLT0JcZqpyTOWwQ+3dwbToQgAQ2naAAAm4oZD//9bkAA==
Date: Thu, 22 Jul 2021 18:59:47 +0000
Message-ID: <A156A2D5-6C6D-4EB3-90A9-07A119D29878@ll.mit.edu>
References: <8674700eb241430cb5d09d46ba331e1b@EX13D01ANC003.ant.amazon.com> <40F72451-DA9B-4E71-9A7F-5BE9A6EFDD67@ll.mit.edu> <f28703ef76304d9c97fda137fd5c2f34@EX13D01ANC003.ant.amazon.com>
In-Reply-To: <f28703ef76304d9c97fda137fd5c2f34@EX13D01ANC003.ant.amazon.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.50.21061301
authentication-results: amazon.com; dkim=none (message not signed) header.d=none;amazon.com; dmarc=none action=none header.from=ll.mit.edu;
x-originating-ip: [129.55.200.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f28c267d-3da8-4701-cb3f-08d94d42e076
x-ms-traffictypediagnostic: SN5P110MB0544:
x-microsoft-antispam-prvs: <SN5P110MB054417BA4AEE90F05C50DAE690E49@SN5P110MB0544.NAMP110.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: iT+AsLwWvW8R8klocn2clb6SyeRLLx796WrS+p37Nb75ffnX7mlFHbN0qSs0mkoaMBvvOrm/oSCZjzQwYxpz9cvvOY1TWOnHD5k/ic+yWTgRqErPA+FRTbGCq4H5HCc796WJcYgymYDTALxK6lKnhae1jrbHhjYEZIC2c0aXM6Xs16cWHGeyHsneeUtefAA+2DQV0iQD8pIpxxlclAh2ET46ei/ATJBKa94Cw26VsWs3QtbYVc+j4AUBWt8NDld+2qfNxUA9i0aQ5vsdBKz3LA31tqHI5G6T3cfIn/IT+i2mykEHxfIMTyPi+xjDZLVOHih1LasRJAJguX/4shyxXHNF4oPoAqyO2MBItd8+IyjZaZcTmZv9FmxH2xzUOegjxOfMg0SIkd3z+Frw8yNVFjDTAX2uWQUzcCDbktJGvytiE1tlWp3LJ3TefJFimpdZwJspdnCxaqPQFPkx/I5wKcR9i2zG1rY1HnUHXu7BuqGrXSlqSnQEFz6iTd/xPcIsSE/TnB4qKyxHiK3zQ3pJfNjBgepxzFlNU25wNosmXagGdv860g3uAlPc0oAzuyErfgIH1dq9wiAglA2ko9jdPWAAwW06qQDUWuQAWPFBLqAvZyN0gqADN7yaN/7Uq0zv7ZwTYSr7JzOIaziFDdqZTZ1lBpzpsc+J/JXKdGK1U3A=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN5P110MB0560.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(5660300002)(26005)(66616009)(966005)(66476007)(66556008)(33656002)(122000001)(86362001)(54906003)(8936002)(75432002)(6486002)(316002)(71200400001)(8676002)(6512007)(508600001)(2616005)(38100700002)(76116006)(6916009)(186003)(66946007)(6506007)(4326008)(99936003)(53546011)(64756008)(83380400001)(66446008)(45980500001)(38070700004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 6aWDiwWtqA3EWyR4gdbF8E1MM829nAwC5c1sCTkpTZaTdcPmRKntX2FSJoQKqV6kCfXZcKXfHUb5fCrXzppF7wax/cT9THJfDBW87G197/HM1njCJocSMNhdy5JIj9pIvuCC1N5Wn95scepIE0wMgp+/yNC+mE9wM8ttZNYPtQ+fB9e7Lk+vb0cWd2pWT8KrZZnyRV2mwj2bll0BL6LTsy5rS2QupfyUlDdfN93Cry5ZTlHhw+dueCfDeo+968L2jwcKMC2o3xwnoWKbMW8WFFqrb/bXXDjhTBzPX4aoldC/JDoohuACF6N+9OvY4B4VHAckfcoZskqO5tZujKidbPcW1vLRkJls5aDQZ1bT9Dc4FjCw9corml4mcdZ6pQ9WXovTlrzy0Vc8hRx56xw23b8k+1Wqf7fda14+qBujQjSIl7DqQMnZfNAwojl20n6xi+0MbafyXY0iLExFFDRhEkxZ8BV35w2AgwETa8Vk2LDIT0QWUphn6kytCvl8SvaAxKEYtF9ysPwKH0PYgZHKYvIP+qjecqKeQRa6pGsZTRScx6eCQUY9BRecajZGoxUWstG9z7lBRPgjHu7rRYTieHHjznXRZXpVCBmEPL+X27sEMv0XfK+c2gcTeurhFkvw6E//pbiwZaEApzhj7eyWP+/k11znsLf9+JYfs43Zd8Sqde/Xf3VcpS2nKCqqKDTaMdPntRzrkrmKRrwZinObZg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3709810787_1096455040"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN5P110MB0560.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: f28c267d-3da8-4701-cb3f-08d94d42e076
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2021 18:59:47.7698 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN5P110MB0544
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-22_12:2021-07-22, 2021-07-22 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2103310000 definitions=main-2107220124
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/v_HFXp8gHIWNh7_MO9CAcjtLGAg>
Subject: Re: [TLS] 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 19:00:04 -0000

>    >> - can cache or fetch the peer public keys in order to do KEMTLS
>    > I did not say that. As far as I can tell now, there's no way to fetch (outside/OOB of this protocol) peer's pub keys or certs.
>
>    draft-ietf-tls-esni does it with DNS HTTPS RRs, but indeed it would require new efforts to make it happen with additional operational challenges.

Most likely it won't work in my environment, but need to check.

>    If caching the peer public key is an option for your use case, then cache management could be an operational challenge for clients that talk to many peers.

Exactly! 

Open question for now.

>    If caching peer public keys is not an option either, then you will have to pay the price of an extra round-trip to get the peer KEM public key. 

Yes, and this is what we've been planning for. In general, one extra round-trip is not a "pain point" for my use case, as long as one round-trip fits into the link constraints.

Now that you mentioned the possibility of caching keys, and paying that extra round-trip price only once - we'll evaluate the implementation costs of doing that.

Thanks!

    -----Original Message-----
    From: Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> 
    Sent: Thursday, July 22, 2021 8:49 AM
    To: Kampanakis, Panos <kpanos@amazon.com>
    Cc: tls@ietf.org; Douglas Stebila <dstebila@gmail.com>om>; Eric Rescorla <ekr@rtfm.com>
    Subject: RE: [EXTERNAL] [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt

    On Jul 22, 2021, at 00:46, Kampanakis, Panos <kpanos@amazon.com> wrote:
    > 
    > Hi Uri,
    > 
    > Thank you for the clarifications. 
    > 
    > So you have a usecase that 
    > - want to use PQ algorithms
    > - is significantly affected by an extra 1-2 or 4-5KB on the link
    > - does not send a cert chain, only leaf certs

    Yes. 

    > - can cache or fetch the peer public keys in order to do KEMTLS

    I did not say that. As far as I can tell now, there's no way to fetch (outside/OOB of this protocol) peer's pub keys or certs. 

    Caching received and validated keys to ease the reconnects is an interesting idea. I'll need to figure whether the comm savings outweigh the extra complexity and branching of the protocol. 

    > Although I don't consider it the general usecase, maybe KEMTLS is the way to go there. 

    I'm 99.9% sure it is.

    > Other good options imo for it would be draft-ietf-tls-ctls and rfc7924 to save even more on data put on the link.

    Thank you! Seems applicable - let me check. 

    Thanks

    > -----Original Message-----
    > From: Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> 
    > Sent: Tuesday, July 13, 2021 1:17 AM
    > To: Kampanakis, Panos <kpanos@amazon.com>
    > Cc: <tls@ietf.org> <tls@ietf.org>rg>; Douglas Stebila <dstebila@gmail.com>om>; Eric Rescorla <ekr@rtfm.com>
    > Subject: RE: [EXTERNAL] [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt
    > 
    >> If we are talking NIST Level 5 (and I am assuming you are
    >> discussing mTLS), 
    > 
    > Yes. ;-)
    > 
    >> ...have you calculated the total CertVerify+cert chain sizes
    >> there assuming 2 ICAs let's say? 
    > 
    > More or less. ;-)
    > 
    > My use case has all the ICAs pre-loaded - the transmitted chain contains only one entity cert. I'm sacrificing flexibility for performance under constraints. Size is the real enemy here.
    > 
    > 
    >> And would constrained devices or mediums that sweat about 5KB
    >> really be able to support PQ KEMs and Sigs at NIST Level 5?
    > 
    > My tests showed that they *do* support PQ KEMs (NTRU and Kyber - haven't tried McEliece ;) and Sigs (Falcon and Dilithium - haven't tried Rainbow ;) at Level 5. Caveat - they do only Sig *verification* (which suits me fine).
    > 
    > (I posted benchmarks from Intel Core i9, but they work acceptably well on the "smaller" chips.)
    > 
    > Also, sorry if I did not make it clear - it's not the *devices* themselves that sweat 5KB, it's their austere links.
    > 
    > 
    > 
    >    -----Original Message-----
    >    From: TLS <tls-bounces@ietf.org> On Behalf Of Blumenthal, Uri - 0553 - MITLL
    >    Sent: Monday, July 12, 2021 11:39 PM
    >    To: Douglas Stebila <dstebila@gmail.com>om>; Eric Rescorla <ekr@rtfm.com>
    >    Cc: <tls@ietf.org> <tls@ietf.org>
    >    Subject: RE: [EXTERNAL] [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.
    > 
    > 
    > 
    >    Let me emphasize the reasons Douglas brought up. Note that I need to use NIST Sec Level 5 algorithms. So, Kyber-1024 and Dilithium5 (other algorithms show even worse ratio between KEM and signature!).
    > 
    >    Communications costs:
    >    - Difference in public key sizes: 1568 bytes of Kyber vs. 2592 bytes of Dilithium => 1024 extra bytes to carry over channel each way;
    >    - Signature: extra 4595 bytes each way, because in addition to exchanging certs (aka "signed public keys", which is inevitable) you need to sign the exchange and communicate that signature across;
    >    - Total: 5619 extra bytes each way. For peer-to-peer broadband connections, you can say "so what?". But my links are *very* austere.
    > 
    >    Computation costs (ballpark, on a powerful CPU):
    >    - KEM: keygen 15us, encap 18us, decap 14us (say, double encap and decap for PFS-providing exchange);
    >    - Signature: sign 113us, verify 55us;
    >    - Comparison: 134us for signature-less KEM vs. 215us for TLS-like exchange => almost twice as long;
    >    - Difference may be negligible for Intel Xeon, but for my much weaker hardware it matters.
    > 
    >    So, for constrained environments with austere comm links, signature-less "authkem" is God-sent.
    >    Big servers that need to support many clients (so they care how much CPU cycles and comm bytes they spend on every connection) would appreciate these savings too.
    > 
    >    @ekr,I hope this provides convincing explanation why "authkem" is needed.
    > 
    >    P.S. I know that Falcon has much more favorable sizes - but (a) it takes three times as long to sign, and (b) it uses FP calculations, which isn't great to implement in my environment.
    >    --
    >    Regards,
    >    Uri
    > 
    >    There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.
    >    The other is to make it so complex there are no obvious deficiencies.
    >                                                                                                                                         -  C. A. R. Hoare
    > 
    > 
    >    On 7/12/21, 20:59, "TLS on behalf of Douglas Stebila" <tls-bounces@ietf.org on behalf of dstebila@gmail.com> wrote:
    > 
    >        Hi Eric,
    > 
    >        The main motivation is that, in some cases, post-quantum signatures are larger in terms of communication size compared to a post-quantum KEM, under the same cryptographic assumption.
    > 
    >        For example, the KEM Kyber (based on module LWE) at the 128-bit security level has 800-byte public keys and 768-byte ciphertexts.  The matching signature scheme Dilithium (also based on module LWE) has 1312-byte public keys and 2420-byte signatures.  Doing KEM-based server authentication rather than signature-based server authentication would thus save 2164 bytes per handshake.
    > 
    >        We would still need digital signatures for a PKI (i.e., the root and intermediate CAs would sign certificates using PQ digital signature schemes), but the public key of the endpoint server can be a KEM public key, not a digital signature public key.
    > 
    >        Douglas
    > 
    > 
    >> On Jul 12, 2021, at 20:30, Eric Rescorla <ekr@rtfm.com> wrote:
    >> 
    >> Hi folks,
    >> 
    >> I have just given draft-celi-wiggers-tls-authkem-00.txt a quick
    >> read. I'm struggling a bit with the rationale, which I take to be
    >> these paragraphs:
    >> 
    >>   In this proposal we use the DH-based KEMs from [I-D.irtf-cfrg-hpke].
    >>   We believe KEMs are especially worth discussing in the context of the
    >>   TLS protocol because NIST is in the process of standardizing post-
    >>   quantum KEM algorithms to replace "classic" key exchange (based on
    >>   elliptic curve or finite-field Diffie-Hellman [NISTPQC]).
    >> 
    >>   This proposal draws inspiration from [I-D.ietf-tls-semistatic-dh],
    >>   which is in turn based on the OPTLS proposal for TLS 1.3 [KW16].
    >>   However, these proposals require a non-interactive key exchange: they
    >>   combine the client's public key with the server's long-term key.
    >>   This imposes a requirement that the ephemeral and static keys use the
    >>   same algorithm, which this proposal does not require.  Additionally,
    >>   there are no post-quantum proposals for a non-interactive key
    >>   exchange currently considered for standardization, while several KEMs
    >>   are on the way.
    >> 
    >> I see why this motivates using a KEM for key establishment, but I'm
    >> not sure it motivates this design, which seems like a fairly radical
    >> change to TLS. As I understand the situation, in the post-quantum
    >> world we're going to have:
    >> 
    >> - non-interactive KEMs (as you indicate above)
    >> - some sort of signature system (otherwise we won't have certificates).
    >> 
    >> This certainly argues that we need a KEM for key establishment, but
    >> not for authentication. Instead, why can't we use signatures for
    >> authentication, as TLS does today? I.e., the certificates would have a
    >> (potentially post-quantum) signing key in them and you then use the
    >> KEM for key establishment and the signing key for authentication.
    >> That would give us a design much closer to the present TLS 1.3
    >> (effectively just defining a new group for the KEM).
    >> 
    >> What am I missing?
    >> 
    >> -Ekr
    >> 
    >> 
    >> _______________________________________________
    >> 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