Re: [TLS] TLS 1.2 and sha256

David Benjamin <> Mon, 11 June 2018 21:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DB10131057 for <>; Mon, 11 Jun 2018 14:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.251
X-Spam-Status: No, score=-9.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 71vvbRpfRFmF for <>; Mon, 11 Jun 2018 14:53:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 838691310BA for <>; Mon, 11 Jun 2018 14:53:08 -0700 (PDT)
Received: by with SMTP id p23-v6so21866761qtn.6 for <>; Mon, 11 Jun 2018 14:53:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rVSvYgk+NRmQuNuecIqLE0ky0olpVdah8AQMy5FzZMM=; b=CYtrjVhwNzjVMWSxXsn3OzHVLkB6ihIXKLfabgObJaUnrJdMDiZu+mfadokvnDrwRx EkP+2JFrGk825mzbP58JcxeqKdyxDauQqY3DtWU2KU+B6wPvk7B8SZABbfTTl6nhEsZN Bajcb6XrMan+P6EbfHZ3O147/1xVXH+1fFSuM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rVSvYgk+NRmQuNuecIqLE0ky0olpVdah8AQMy5FzZMM=; b=fvhEsQRGcKw0UwXVGSJ9j2O7tfZ68DUETjIbSxZKXBe3gDAEifCIMEm5tdtfnR7pPj bZV122QEgstJTw9Ib+PPgA/TzelmkgRPYIugfVWAIeJs4TIZumJ1lwz+6qGfsgImeONK i/8QV2BA6R/MRg8G3TNfUP40kc01uwU87/0mpMZ7WiB7tIOals6QvI1cFJKk0jVIwxzp G7gbF6gg3v7f8RdMWeOPnvutA6cBq8eEob+dUkKjtUdjZA3oyQLzpLjKrUT33npEtMzF PNSxhCzyyRfAWuDiHNjTRLc+RzEQzQLLyIkheUVhmQYyN/b7VRaRZvOv1oMAsiIISGR0 Vw6A==
X-Gm-Message-State: APt69E3SHnlN+rr3tis7bY7WTwz5qOrMBnOPbeZLAFQ3DFkybomDlIcT WcfUVR97JaPLYy6hAqCacg0sll8Oy40ylfgQ6hHh
X-Google-Smtp-Source: ADUXVKLDfl5g/e1o7RZjw9mc9ld2UdI0mn+hC+O+bKVanyH1vA58/i4+s4AeuzstHeSzkFF6YBMhuNyuXpmbo1wt22k=
X-Received: by 2002:ac8:25a5:: with SMTP id e34-v6mr979860qte.318.1528753987433; Mon, 11 Jun 2018 14:53:07 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: David Benjamin <>
Date: Mon, 11 Jun 2018 17:52:55 -0400
Message-ID: <>
To: Daniel Migault <>
Cc: tls <>, LURK BoF <>
Content-Type: multipart/alternative; boundary="0000000000005f7082056e64c6bf"
Archived-At: <>
Subject: Re: [TLS] TLS 1.2 and sha256
X-Mailman-Version: 2.1.26
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: Mon, 11 Jun 2018 21:53:17 -0000

In both TLS 1.2 and TLS 1.3, SHA-256 isn't hardcoded per se. It's a
function of the cipher suite you negotiate (and also, separately, the
signature algorithm you negotiate). That said, in practice, both are pretty
solidly dependent on SHA-256. Most options involve it. AES-128-GCM and
ChaCha20-Poly1305 are currently paired with SHA-256 while only AES-256-GCM
is paired with SHA-384.

We could certainly define new cipher suites for either of TLS 1.2 and TLS
1.3 as needed. But defining a new cipher suite for TLS 1.2 doesn't
magically deploy it for all existing TLS 1.2 servers. Those servers must
deploy new code, at which point updating your TLS library to include it
would also pull in TLS 1.3 anyway (or whatever the latest TLS version is by

So I think there will likely be no point in bothering with TLS 1.2
allocations at that point. More options means more combinatorial complexity
for implementations, which means more our rather limited collective
resources in this space get even more thinly spread.


On Mon, Jun 11, 2018 at 5:25 PM Daniel Migault <>;

> Hi,
> TLS 1.2 uses sha256 as the prf hash function. When sha256 will not be
> considered secured, I am wondering if we can reasonably envision
> deprecating sha256 for TLS 1.2 or if TLS 1.2 will at that time be
> deprecated in favor of TLS 1.X X>= 3 ?
> In other words, I am wondering how much we can assume TLS 1.2 is
> associated to sha256.
> Yours,
> Daniel
> _______________________________________________
> TLS mailing list