[TLS] Another way to reduce signature computational cost

"Bingzheng Wu" <bingzheng.wbz@alibaba-inc.com> Mon, 20 July 2015 04:20 UTC

Return-Path: <bingzheng.wbz@alibaba-inc.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id B350A1B2F65 for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 21:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DzOXMgPdSARd for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 21:20:26 -0700 (PDT)
Received: from out4133-82.mail.aliyun.com (out4133-82.mail.aliyun.com []) by ietfa.amsl.com (Postfix) with ESMTP id C43211B2F51 for <tls@ietf.org>; Sun, 19 Jul 2015 21:20:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1437366023; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=NjXZeny5oUiXvjTmqpnXbfqSvXaNWU7hsktsR/U4+lA=; b=Unz/GdJZq1JH8LZLAN1I7XwZM1MGyiAQ9LLtJqjbkfS+1ipqe2qm0TDJQ1tx17LSD9cav7uHc2fEXWLuw/bCCHJBRvE29XZ8nGuqJotUjRipuG9uGBShG/6l7nRI54FzOfgaZ+NQLIjZBSLxtbKn8DWy4DU8PQyfr5eN4sYGj6c=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R561e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03282; MF=bingzheng.wbz@alibaba-inc.com; NM=1; PH=DW; RN=1; SR=0;
Received: from WS-web (bingzheng.wbz@alibaba-inc.com[]) by e02c03312.eu6 at Mon, 20 Jul 2015 12:20:21 +0800
Date: Mon, 20 Jul 2015 12:20:21 +0800
From: "Bingzheng Wu" <bingzheng.wbz@alibaba-inc.com>
To: "tls" <tls@ietf.org>
Message-ID: <----3-------MPf3-$01951b4c-26a0-42fa-aeb1-dfa6894711a8@alibaba-inc.com>
X-Mailer: Alimail-Mailagent revision 2700061
MIME-Version: 1.0
x-aliyun-mail-creator: W4_2700516_hLSTW96aWxsYS81LjAgKFdpbmRvd3MgTlQgNi4xOyBXT1c2NCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzQzLjAuMjM1Ny4xMzQgU2FmYXJpLzUzNy4zNg==2I
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/3pVubigQY6xco9kH9De3hlL-ZUQ>
Subject: [TLS] =?utf-8?q?Another_way_to_reduce_signature_computational_cos?= =?utf-8?q?t?=
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bingzheng Wu <bingzheng.wbz@alibaba-inc.com>
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, 20 Jul 2015 04:20:27 -0000

Hi all,

In TLS 1.3 draft-07, server provides a ServerConfiguration message containing a long-term DH share.
If used on future connections:

(1) server reduces the computational cost for cipher suites where signatures are slower than key agreement;
(2) server omits both the Certificate or CertificateVerify message;
(3) and client encrypts zero-rtt data.

Here I'd like to give another way to reach (1), to reduce server's computational
cost for CertificateVerify message for RSA type certificate.

In normal way, the CertificateVerify is computed as:
    CA ==> CA2 ==> srv_cert_RSA --> session
where "==>" means reusing signature, and "-->" means signature for each session which is computation sensitive.

Maybe the server can generate a temparary ECC certificate, so the CertificateVerify is computed as:
    CA ==> CA2 ==> srv_cert_RSA ==> tmp_cert_ECC --> session
and the structure of CertificateVerify message becomes:

      struct {
           ECParam tmp_cert_public;
           time    tmp_cert_not_before;
           time    tmp_cert_not_after;
           digitally-signed struct {
              opaque handshake_hash[hash_length];
      } CertificateVerify;

Compared to ServerConfiguration, this tmp_cert_ECC has some advantages:

* The tmp_cert only modify the CertificateVerify message.
  While the ServerConfiguration brings MS and SS concepts.

* The tmp_cert need not to be global.
  If there are multiple machines or processes behind one service,
  they must synchronize the key share for ServerConfiguration.
  In practice the key share is always configured in server's configure
  file and need rotated periodically manually, like the ticket key in Nginx.
  While the tmp_cert can be generated randomly and independently.

* The tmp_cert's lifetime could be short.
  It could be re-new after used for only 100 times, or 10 minutes.

* The tmp_cert works even for the first connection.

So could we use this tmp_cert to replace ServerConfiguration's "reducing computation" function?

The "omitting Certificate message" could be reached by cached-info extension.
Then the ServerConfiguration can be used for zero-rtt data exclusively.