Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

David Benjamin <> Mon, 06 May 2019 19:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 302691200EF for <>; Mon, 6 May 2019 12:02:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.508
X-Spam-Status: No, score=-9.508 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mHqxQOhb61gb for <>; Mon, 6 May 2019 12:02:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D55AF1201D3 for <>; Mon, 6 May 2019 12:02:36 -0700 (PDT)
Received: by with SMTP id a17so1948522qth.3 for <>; Mon, 06 May 2019 12:02:36 -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; bh=dF7ATGstTE0nmOi7ZDEoep0QltzEvI5uEBAOsic7Wj4=; b=YAnw5wrDHsDQB2reHuo23AXsKNm1pR7jI9N8bp2o6HLVCBG/Gmn1sco+4uxdyLVbuG XL6VGhpTHxUi0doayWPDsC9xpKveycR/TJbuk0QIQKgzFo77YlKKg/EiPDt7F+DnuSTD /fPM0XfiWc7YosBSCdkoD65RNGUcj/Jw38rbs=
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; bh=dF7ATGstTE0nmOi7ZDEoep0QltzEvI5uEBAOsic7Wj4=; b=tn0ldtWl0lIANqILiwr3ALzCKiEQaCJohSrR/7AGkS3xqyxzktCAZ9odvYL3ku+a3W Qpmem7mdYhRHC+mklIaWj8zcIBMxu/eVpVOyUU+qEAO0Ml/l3DB4L0+We9JhL4/Aq9Ux tGuIU1qMjSYqxYgO+XkOcUpDyqe3lliKUc19r0lsUO/TX65w3Y30NL6VQvLLAjYpEfkG iq1IrIQVJkhF50OTrC4tR/gcoOUVlHms/ShnUAm54jbv4rzriGTrL4B0aKLIL/DtR1wO h1AlWuZKXeSUCE7kZd5JVma8VGYOF/YheVtnb87ao1oog8IhnAc0m7mlk9OdZgoKE/eF DNfw==
X-Gm-Message-State: APjAAAVkz1AJVjs9vu/JzYFcVKxyncY8QDcaNYChLQKiSla2kjI+M71Z fvVX4D4UORqEJVQZQlon0uLS3OH4PMH8lE1tID5daZQ=
X-Google-Smtp-Source: APXvYqy1dscDmCeSOS5Afh8PSB/X+L6Bu3zNa2mp6W3bT9NtjrQBqog2cmb8dT0+w092iQt+Lbgs8ncEmcQ9CWc7mwc=
X-Received: by 2002:ac8:2df9:: with SMTP id q54mr22687678qta.10.1557169355631; Mon, 06 May 2019 12:02:35 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Mon, 6 May 2019 14:02:18 -0500
Message-ID: <>
To: "<>" <>
Content-Type: multipart/alternative; boundary="0000000000004c9a2905883cbe1d"
Archived-At: <>
Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"
X-Mailman-Version: 2.1.29
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, 06 May 2019 19:02:49 -0000

On Mon, May 6, 2019 at 1:43 PM Viktor Dukhovni <>

> On Mon, May 06, 2019 at 01:50:42PM -0400, Kathleen Moriarty wrote:
> > Is this better suited for another (short) draft?
> SHA-1 certificates are history now.  If we're raising the floor,
> it should IMHO be safe to deprecate the MD5 and SHA-1 signature
> algorithms from TLS 1.2.
> Does anyone have evidence of medium to long-term requirements for
> continued SHA-1 sigalg support?

I've been following this one for some time now. Sadly, we still see quite a
lot of SHA-1 sigalg usage with RSA, even more than we see TLS 1.0 and 1.1.
(We already removed SHA-1 with ECDSA a couple years ago.) Some of it is
because older Schannel will preferentially sign SHA-1 when offered, which
is not a problem for removal but confounds metrics. Some of it is a bug in
older OpenSSLs where, on connections with SNI, it loses track of the peer
signature algorithm preferences and then assumes SHA-1 by default. Some of
it is load balancers which implemented TLS 1.2 but failed to actually
implement sigalg negotiation, and thus only sign SHA-1.

This is a consequence of text in RFC 5246 which says, when the extension is
missing, the server should take SHA-1 as default. With the benefit of
hindsight, I think that was a mistake. It meant bugs like OpenSSL's get
papered over with SHA-1, and any implementors that chose to only sign one
algorithm would pick SHA-1.

(This is not to say there shouldn't be text in this document or another
that discourages those, or requires servers be able to sign some SHA-2
hash. But I don't expect those to be removable on the web until after TLS
1.0 and 1.1.)