Re: [TLS] A la carte handshake negotiation

Kyle Rose <> Wed, 22 July 2015 11:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EDECB1B2BCF for <>; Wed, 22 Jul 2015 04:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Tdnbprgm6je for <>; Wed, 22 Jul 2015 04:09:30 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 653111B2A68 for <>; Wed, 22 Jul 2015 04:09:26 -0700 (PDT)
Received: by wibxm9 with SMTP id xm9so158180265wib.0 for <>; Wed, 22 Jul 2015 04:09:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PxzIABgYf/VtaPDUW6ujjhThK+aLGkyX7xXx/MC+ufM=; b=D8UZNsEnIdiZXSFqY9KJwYdbHvrjmQhS/izp4RyJE1I+JKuvGDNIVEFelKcJezCk24 5Ipol8RAp1MVWmxnDtEsjgPeGyQTq2K7+ZPh3Aa4nxRF62zxpBmy5hMcgnbEbn1McrFK Rr687YJXCgsvh3SoGAUJ6EUvN/ilF1K0gceKk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PxzIABgYf/VtaPDUW6ujjhThK+aLGkyX7xXx/MC+ufM=; b=L6WcEJOZ5aYYvbAowfn90FgAjEFVCqbmmMjzSb/EsAFAcR2P4bJiEPuOc84SCTHvwH +kD6XZ265YQahmEAViyu7PZil8xmZZ5E9iaA1DDAShbvnsndU0drdCD4+S6Uyj3WYcHn JKYR6gy1PUoooenHW5QzqISw699Z60RFy5XB4+L7nwUhs1yxjDrZ9tycr3DwUBI6QFKS yqdjJhTH1e0KIc3/UPM0d0vxaU+bMvXDPPMMS8Z3sIVVQ6qlczV560aoI9gyhX4nRCfw ube9hU70roH+2/sL50dZij3nzDhkojPhD0uX/igxos5gs1roClgfInuFO13An8BuUCN8 ALOQ==
X-Gm-Message-State: ALoCoQkmJ6BD09o/4uH/Sc1lU6Znb5a1oJD06ubADzdafXF93nsWHYhLfwBwxv5he/Mv2XCHZBx2
MIME-Version: 1.0
X-Received: by with SMTP id md18mr40964694wic.31.1437563365131; Wed, 22 Jul 2015 04:09:25 -0700 (PDT)
Received: by with HTTP; Wed, 22 Jul 2015 04:09:24 -0700 (PDT)
X-Originating-IP: [2001:67c:370:176:40f1:60c1:3ca2:aeab]
In-Reply-To: <>
References: <> <> <> <> <> <> <20150722093143.GA7186@LK-Perkele-VII> <>
Date: Wed, 22 Jul 2015 07:09:24 -0400
Message-ID: <>
From: Kyle Rose <>
To: Peter Gutmann <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] A la carte handshake negotiation
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jul 2015 11:09:32 -0000

>>Furthermore, comparing the strengths of kex, auth, ciphering and PRF seems
>>like comparing apples, orangles, pears and kumquants.
>>Even if the nominal strengths are the same, the scaling of strengths is going
>>to be different (e.g. the quadric vs. linear sub-treshold scaling for ECDH vs.
> +1.  It's just more numerology:

In that case, we should dispense with any larger key sizes and
recommend exactly one per algorithm, and vary only on algorithm.
Adopting this would simplify things even further by reducing the
cipher set list by an order of magnitude.

Sadly, I'm guessing there are numerological requirements in various
standards and regulations that make it necessary to keep both AES-128
and AES-256 around, for example. There are also a ton of existing
2048-bit RSA keys that aren't going anywhere for a while.

I'm also skeptical of statements like "Using any known technology it's
unlikely that humans can ever get beyond about 2^^100 operations",
because that's true exactly up until it isn't. An open question is
whether the innovation that undoes this will also subsume much larger