[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