Re: [Lurk] [TLS] TLS 1.2 and sha256
David Benjamin <davidben@chromium.org> Mon, 11 June 2018 21:53 UTC
Return-Path: <davidben@google.com>
X-Original-To: lurk@ietfa.amsl.com
Delivered-To: lurk@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85831131073 for <lurk@ietfa.amsl.com>; Mon, 11 Jun 2018 14:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.251
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 6Qc0_zIolXdB for <lurk@ietfa.amsl.com>; Mon, 11 Jun 2018 14:53:08 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 83826131091 for <lurk@ietf.org>; Mon, 11 Jun 2018 14:53:08 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id h5-v6so21816252qtm.13 for <lurk@ietf.org>; Mon, 11 Jun 2018 14:53:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; 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; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rVSvYgk+NRmQuNuecIqLE0ky0olpVdah8AQMy5FzZMM=; b=o8fZ1aKCpMCWWngeL9SRwon4P1cyCFPbAWUvXSvLkA44PFr1KojsGjc8zpNVBVD7LU O3Koqo/xqf3Uk09pnJIbti6eqcl5bxpZYsNhBguIVmZ5qf3APSs4y5BexYSPSFkq1PH8 qQle1xA3hKxW6mubc8YmoEVEV8i+UdkhCoXNrND8wwKahFxYiHZwtKPcg7flXb1rHFr3 CFJvJwvCg5m3C05arLw5GTt2EFG/f/ZdPu3Z/bA6Xl0vD+d3vBU3SaFVRHVfv+pYNvM6 ehs+ONLD0cIrGEzopOa3wW6j3JYORKBfiGe+EnOxpKRK37ubWyP5hW3CUTNJaoqCiJog A3bg==
X-Gm-Message-State: APt69E325IUCKUzMgTRqq/1raaoaat0b2al3SQ3uBeo0IEw7ddL90cnr LJm/BUwG5z+y7m/ScaChZD5vk5g+UpKrlNb8l9hVf+Y=
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: <CADZyTknFe8Da948kOJRZcPkKkwnaVQUOseMfyZa_A4TckuY3gw@mail.gmail.com>
In-Reply-To: <CADZyTknFe8Da948kOJRZcPkKkwnaVQUOseMfyZa_A4TckuY3gw@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Mon, 11 Jun 2018 17:52:55 -0400
Message-ID: <CAF8qwaCFEwz_D5PtSAYKifvisKbGK6yVJma=7uSDd=UOWkG=gw@mail.gmail.com>
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: tls <tls@ietf.org>, LURK BoF <lurk@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005f7082056e64c6bf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lurk/SHlF1iLZbGTCauBhmgQzCPlsfVg>
Subject: Re: [Lurk] [TLS] TLS 1.2 and sha256
X-BeenThere: lurk@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Limited Use of Remote Keys <lurk.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lurk>, <mailto:lurk-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lurk/>
List-Post: <mailto:lurk@ietf.org>
List-Help: <mailto:lurk-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lurk>, <mailto:lurk-request@ietf.org?subject=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 then). 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. David On Mon, Jun 11, 2018 at 5:25 PM Daniel Migault <daniel.migault@ericsson.com> wrote: > 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- Re: [Lurk] [TLS] TLS 1.2 and sha256 Hubert Kario
- Re: [Lurk] [TLS] TLS 1.2 and sha256 David Benjamin
- [Lurk] TLS 1.2 and sha256 Daniel Migault
- Re: [Lurk] [TLS] TLS 1.2 and sha256 Colm MacCárthaigh