[TLS] Thoughts on draft-rescorla-tls13-semistatic-dh-00
Watson Ladd <watson@cloudflare.com> Wed, 05 December 2018 01:36 UTC
Return-Path: <watson@cloudflare.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 C725F130DD2 for <tls@ietfa.amsl.com>; Tue, 4 Dec 2018 17:36:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.461
X-Spam-Level:
X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 1XXAOCo723Ya for <tls@ietfa.amsl.com>; Tue, 4 Dec 2018 17:36:21 -0800 (PST)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 F2454130DC2 for <tls@ietf.org>; Tue, 4 Dec 2018 17:36:20 -0800 (PST)
Received: by mail-qt1-x82a.google.com with SMTP id d18so20516131qto.8 for <tls@ietf.org>; Tue, 04 Dec 2018 17:36:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=m/qOXOiC2yYhKphTnVfP3l1jMQIWtiqOH0sBMUNSFm0=; b=ww/LKVsH0C/BQZkSCla9qNIuKhCmuR2wti2sVjKCv++YjLLqK4Osa4c32w6Ks1GD/c KXNcYJKxKsmyZSHx8Tagbod5tLZvyWPKjTULSBGHmsYBSIWyGrbX09nP29mj1MchzX91 Iqu3Jh1PhB4z6w5dU/73whQtT9ZQUcZQ5+4GM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=m/qOXOiC2yYhKphTnVfP3l1jMQIWtiqOH0sBMUNSFm0=; b=eLOcuyu1RJo5R3y2FK0uMEXcgH+v1DLTEA8vPrItyAxOQBuWTlDR+LCo+v9Xfy3iub /ahcZiY+SBqimmuiaiUTzKQn1bnyKINUzVrUDqoBH3bGyJmeN/CC5CYhPELkhfHP+D8t RKVtzGocNHLQCYtgj7IY33S7rE79/GhX12vL+HR74EiVpwHh+r2xh7PqKv8ChOcSMs6x UX5gGpd8wYQZH01E/u43Q7DIh6KeKJ7AUe/ba9C2EEYQaUprjHOa97D5WuhPki1PTTYt +pKXnSoAew4krjEqZv2ka8RK6m7OldQoN7gyKqJNHuukxHz37ANVr0cThA17hXN2c6wy 2xlg==
X-Gm-Message-State: AA+aEWac9QAdGoN2UcPVdP0CdfW6ItNfgidL7z1nRT2L9eSi7Llr0A0S cab59CFkVX2kG6QGVyiztv6pkt9hkKdRpES91aOTR35f
X-Google-Smtp-Source: AFSGD/VtaY8Jh401pfBq8gR/PrIRajC7if9QlrRCg4DGKpRKdgme304acf+dLVywPh7oeW7VbuP41+HDmBCFqaqcSVE=
X-Received: by 2002:a0c:8936:: with SMTP id 51mr22310040qvp.220.1543973779870; Tue, 04 Dec 2018 17:36:19 -0800 (PST)
MIME-Version: 1.0
From: Watson Ladd <watson@cloudflare.com>
Date: Tue, 04 Dec 2018 17:36:09 -0800
Message-ID: <CAN2QdAEKSKzkZmZ_k7joZcx35MY=LYKzDLK5Xh6_3rYy6aq7RQ@mail.gmail.com>
To: tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/oruBZX2DhXG0PGdhm3iVgh_S26g>
Subject: [TLS] Thoughts on draft-rescorla-tls13-semistatic-dh-00
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: Wed, 05 Dec 2018 01:36:23 -0000
Dear all, I read the draft and have a few comments. First off it seems like OPTLS used an HKDF extracted key to feed into the content keys, instead of reusing the shared secret. I'm pretty sure that will end up not mattering, but I'm by no means an expert in how much some change like that will affect the analysis. Secondly there is the question of performance. A fixed based exponentiation can almost always be done faster then a variable base exponentiation because it offers precomputation. As specified a server does one fixed based exponentiation and two variable based exponentiations, while with signatures a server does two fixed based exponentiations and one variable base exponentiation. The performance gains possible from OPTLS come from reuse of the ephemeral, resulting in just two variable base exponentiations for most clients, unless there is a very fast choice of group that doesn't support signatures out there. The given example of x25519 vs. P256 could be solved with issuing an Ed25519 delegated credential for instance. Clients will see a performance gain if the total number of signature verifications goes down as two variable base exponentiations are cheaper then a verification plus variable base exponentiation, but that depends on not using delegated credentials. Perhaps more interesting is the question of postquantum schemes that don't support signatures. But there a classical signature usually outperforms a postquantum key exchange, and so it is not very interesting to do two postquantum key exchanges instead of one and a classical signature. As for client authentication I think the server ephemeral+client static producing a key they use to MAC works out: it's no worse for mixing the client secret in then the signature based client authentication is in TLS. Sincerely, Watson Ladd