Re: [TLS] Advancing draft-ietf-tls-hybrid-design

Douglas Stebila <dstebila@gmail.com> Mon, 09 August 2021 20:44 UTC

Return-Path: <dstebila@gmail.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 CAD9E3A16A8 for <tls@ietfa.amsl.com>; Mon, 9 Aug 2021 13:44:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFqGBrRdomgn for <tls@ietfa.amsl.com>; Mon, 9 Aug 2021 13:44:45 -0700 (PDT)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF7B3A16A6 for <tls@ietf.org>; Mon, 9 Aug 2021 13:44:45 -0700 (PDT)
Received: by mail-qk1-x731.google.com with SMTP id y130so7252262qkb.6 for <tls@ietf.org>; Mon, 09 Aug 2021 13:44:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d1pdMGhG25ulakRccJqJ7mB+xq0cvJG16LgsUYppw4k=; b=bwZvvRXk+wfoIOAWV/G1M+K8jyTaOv5ueiw9VEDMPMPesC5DymZ6g6kLfsxiKJdLtP DWPGXJBxulxqnGcK8rq/x4k9Xh9CWrKLpFiWx9vqBWRKChnJYhdRBDNy5oNjs3azqcCa 8ykSBq8clqB8bTimudaZONc+Y9pE5PFHwC0GMp2CVzd+u4LLMs1ifd5nfHFjcoGzswVr bsuWRltjxKIlvx05+WsFPRBWyZVkIW9PxYgJbpalaK74oxs2IchH0GTaHLZdPg08kA/8 33ziqKhHEVlC3QlXwmSnX79MHwQk65Qb/pH2+zjO8XbIQZ2LdTRWQKms099E0ZXDJ87Y VQ0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d1pdMGhG25ulakRccJqJ7mB+xq0cvJG16LgsUYppw4k=; b=GnETNpI+DA8G52fgAkuAMSgmGYPfpthTXOS7L/1xc9/KhRxT7Pj6yGVoM58Sw5ZPxL lNi5ock7D4Dm+6sJqFXD/FcxJx5+RNP7PQhcQtxgnH5JBKoSLBnN9sbdnc8Pvq5uVMwE Fd/7jLPmLr1Dv1qzC+ie1a/0NN7XzAcVToQqEqa5DR9sgqVAmL4NeGmCsZtO3AUH13RU 7bnUlm/BVAaEwrweF1Du1A19QBgUyxAYB/4avvGHFfjQ3UkHfxDfaGAavhOt6HKXqfZa vDTSuRYYx8E53zfr50wksn4Jm9EoHNI3Yj6Qp0X88DzFfGrw/vfjn/5zJ6RKxIHyQOPN X2cw==
X-Gm-Message-State: AOAM530p4vdzccszVtth1x5uv1zKtkfPOrBztwU1EKONUiBR6QOP/LKq mUL1ECUmL6hILZblIqZFjOI=
X-Google-Smtp-Source: ABdhPJyVgnZ/vjTAx6op1aNxJLJidvt1YOGKoU6RtV8viKS0sgE/+4ZrDecZdwYCl3S/bbUCp0MHJg==
X-Received: by 2002:ae9:eb8b:: with SMTP id b133mr24894625qkg.344.1628541882891; Mon, 09 Aug 2021 13:44:42 -0700 (PDT)
Received: from smtpclient.apple (cpe881fa12cf37b-cma84e3fc93e50.cpe.net.cable.rogers.com. [99.250.203.26]) by smtp.gmail.com with ESMTPSA id l17sm1793775qtq.44.2021.08.09.13.44.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Aug 2021 13:44:42 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Douglas Stebila <dstebila@gmail.com>
In-Reply-To: <dfcf9b0c26eb49cd899638afaa2ec886@blackberry.com>
Date: Mon, 9 Aug 2021 16:44:40 -0400
Cc: "tls@ietf.org" <tls@ietf.org>, Shay Gueron <gueron@amazon.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2647CCAB-2588-45D1-8CF2-A1B493FD5ECD@gmail.com>
References: <1DCCB8D8-F987-4A30-8084-06CE6FBCD507@gmail.com> <dfcf9b0c26eb49cd899638afaa2ec886@blackberry.com>
To: Dan Brown <danibrown@blackberry.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WvRzNGdAIUoSqb5K4QOzFQsbQnA>
Subject: Re: [TLS] Advancing draft-ietf-tls-hybrid-design
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: Mon, 09 Aug 2021 20:44:51 -0000

Hi Dan,

If memory serves, this came via discussion on the list in July 2021 after my presentation at IETF 105.  At the time we presented a choice between two main approaches: one where each part of the combination was fully negotiated with corresponding data structures for everything, and a simpler approach where all combinations were fixed in code points with concatenated data structures.  Stronger support came for the latter.  There were some voices advocating for supporting more than 2 algorithms, and some advocating for only 2.  I don't believe there was a vote taken, just the sense that there was stronger support for only 2.  

Looking at the document as it stands, since it uses new named group code points for each combination and simply concatenates key shares (for transmission) and shared secrets (in the key schedule), it would be straightforward to let it specify that you concatenate *all* the key shares / shared secrets in the appropriate order, rather than just 2.  As this document doesn't specify particular combinations, it would be up to later documents to actually put forward the case for a particular set of 3 or more algorithms being a worthwhile combination.

Douglas



> On Aug 5, 2021, at 15:22, Dan Brown <danibrown@blackberry.com> wrote:
> 
>> -----Original Message-----
>> From: TLS <tls-bounces@ietf.org> On Behalf Of Douglas Stebila
>> We wanted to see if there is any further feedback on our draft "Hybrid key
>> exchange in TLS 1.3" ...  We have not received any new feedback from the
> working group
>> since we posted our last non-trivial update in October 2020.
> 
> Allowing 3 or more key exchange methods in a hybrid combination should
> somehow be an option, for a user who can afford the extra cost and is
> risk-averse and has high-value data to protect.
> 
> I was told this issue (2 versus 2+) was already discussed on the list, but I
> must have forgotten (or missed) that conversation.
> 
> A workaround is to nest TLS into TLS, to get more types of key exchange, or
> to apply the extra key exchanges at the application layer, on top of TLS,
> for those (few) who want the extra security.  These workarounds imply
> applying symmetric crypto twice, which does not help against the quantum
> threat.
> 
> 
> 
> 
> ----------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.