Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC

Martin Thomson <> Wed, 23 March 2016 00:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0404B12D5C9 for <>; Tue, 22 Mar 2016 17:46:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ob7Mq-40wy_s for <>; Tue, 22 Mar 2016 17:46:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2FC5912D5EC for <>; Tue, 22 Mar 2016 17:46:30 -0700 (PDT)
Received: by with SMTP id c63so7153979iof.0 for <>; Tue, 22 Mar 2016 17:46:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=FyksbPYtVblfc4nrJLBUJgHOCxwaE6hVZIFdC2ZUeoc=; b=Jpj9MVXtH2mCpsBERkXBXoYGeRwuuPRacGk93zIbs1kfWl/+ZUnpdFiVSQAq7VfmP8 gQpJ3uPNu2pXkQdUSj+ldv954CyzJVvuYsePtAdPMc4jZDY+1qIvwbswdMLKjHHNuckE S3rAVQxklf8Ee4tjxRXRRTQwecB3OU9SUphgMRnq1j9xycpbkEas7UUCmJ4saLZtLX8M A/YWEAWnj4K0xBpS/AwMUvVnvLJrvFq4fg+JM1QpRB6qwePO0xhTw7Gs/euoI/8Xpp3Y vh1jg30k9YZ6gL0C8FTxQxwvTOJEzTNHmyfykf2z97kKZPn1NAWRtgVasLvY7vkh11RC UFdA==
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; bh=FyksbPYtVblfc4nrJLBUJgHOCxwaE6hVZIFdC2ZUeoc=; b=dwnB0gLGOAXC1XI8aAiqUpBV6rOeSeUVZjobLptdvGcDY2cpgsTIiCASbN8Wbn8ngy V8iTkHdDgsw6qVZNE6ZWsOupCRXCKgEEhkFugk3jyOKiEpjrlaMTEaQt6W4f1K/lkCkT bE/40dIB9O14s0kcosrBzB/6bZB7Qx6FLYzAkhWBGAVOy7wCtBlGeUN4vT6KaLuBHAQI YzdyVV/iBpREWCQ8EHXPjOdj2UKUch+3rWqyONI8/0t+lS9008LdW2AD0qyOEDB9GWOc x/kAbx3OojD2c9zK1+wSpO3V6bg0qkUEYAdVg2j95qs0BP7qhi8ok31cfHFCRUkZ5i41 xMQA==
X-Gm-Message-State: AD7BkJKc64hFKwTjejN/tc309TCS1CjgSWY7uUby2u/j4+bLCSZONBQ9pZ6YO+fiZS6HZW2zAFVY2fQjJqYAOw==
MIME-Version: 1.0
X-Received: by with SMTP id l97mr556584iod.100.1458693989463; Tue, 22 Mar 2016 17:46:29 -0700 (PDT)
Received: by with HTTP; Tue, 22 Mar 2016 17:46:29 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 23 Mar 2016 11:46:29 +1100
Message-ID: <>
From: Martin Thomson <>
To: Timothy Jackson <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC
X-Mailman-Version: 2.1.17
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, 23 Mar 2016 00:46:32 -0000

On 23 March 2016 at 11:38, Timothy Jackson <> wrote:
> How would this group feel about a proposal to address this by specifying in
> the 1.3 specification that implementations must ensure that the strength of
> the certificate must be >= strength of ECDHE/DHE >= strength of the cipher?

There are good reasons to make certain parts of the suite stronger than others.

For example, record protection and ephemeral key exchange strength are
tied to the potential lifetime of the ciphertext.  If someone is
scooping up sessions, that could be a long time (lifetime might
actually need to be a lifetime).

On the other hand, authentication keys need only be strong enough to
resist a break until their expiration date.  To given an example, in
WebRTC, we used to use 1024-bit RSA keys; the lifetime of the keys was
a single session (and it was still too slow).