Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

Daniel Migault <> Tue, 14 May 2019 18:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75D45120155 for <>; Tue, 14 May 2019 11:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id idd_hkudU3gX for <>; Tue, 14 May 2019 11:09:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A06CC120137 for <>; Tue, 14 May 2019 11:09:48 -0700 (PDT)
Received: by with SMTP id a39so132736qtk.2 for <>; Tue, 14 May 2019 11:09:48 -0700 (PDT)
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=kQYCteSKARGhY/AgzlcPOezQJjnM87/2HYwJ3iaBrzg=; b=Wdl2g2CXCG6454EdVKpNrXtLgAhtGSMGNpx8jeEbX5ZxRtMH1nsstcAMotNoDJOBSa Jq3ncJlwzouewwKXzUnGN4i7ss58Qw/ZOnARfvj2+/52x/EhFQJFms7el1HPtFNAZWXt NX54fl1Fl5TkMIJeJjRIHkIAi6V14F55pKThvwTziwRBKPtJXiezZCgURjsONcaw8CKO AfC/q2tUgUfqHSsRgUvHilT6JLFsV2wpdkgxkeTjmhXUbL4ilhWgfeay5ZVkaD0izNac XHZOdO4wuj9dCtMAC4gKc8cGoQhZtDRvnmSNpSv2DYsKXexkD3tixDOVTgZgQDedLKuU VIEQ==
X-Gm-Message-State: APjAAAW/OKLJDuehCIb898AYirkb8sfSQJx5fIckBAb9BS0wHOj5LOAT hQ3KMaU+B8iEAPwn7EC1mzYxbH1xa88APxZDNiY=
X-Google-Smtp-Source: APXvYqzET514Spl/xB6BajKWlHwQ0T03As2ZlPJ9rYMd/+hzoStcQ57J8cTfRyS86HSP+5RnrUf1S5NZMUSb2wL5dOI=
X-Received: by 2002:a0c:929a:: with SMTP id b26mr29391971qvb.148.1557857387547; Tue, 14 May 2019 11:09:47 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Daniel Migault <>
Date: Tue, 14 May 2019 14:09:36 -0400
Message-ID: <>
To: Hubert Kario <>
Cc: tls <>
Content-Type: multipart/alternative; boundary="00000000000032110f0588dcf01c"
Archived-At: <>
Subject: Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2
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: Tue, 14 May 2019 18:09:50 -0000


Please find some comments.



I would suggest a reference to rfc6194 for sha1 digest as well as for

I believe more text in the introduction may be needed to expose how the
document impacts TLS 1.2.

Typically, the impacted structure is HashAlgorithm, This structure is used
by SignatureAndHashAlgorithm which defines the Signature Algorithms
extension and is included in messages such as CertificateRequest  In
addition a number of messages rely on this extension (, ServerKeyExchange,
CertificateVerify) and they will be impacted by the current document.

Updating the HashAlgorithm registry was caught in the previous version by
updating the enum. While this is not the standard procedure to deprecate a
registry entry, I believe the intention was there. I would rather suggest
to do that in the IANA section..

section 2:

I am wondering whether SHOULD NOT could be replaced by  MUST NOT. On the
one hand, deprecation should be smooth, but on the other hand I am reading
that rfc6194 and rfc6151 already started the deprecation. I would rather
favour MUST NOT.

Maybe we need to also indicate that MD5 or SHA-1 are ignored by the

section 3:

The title section maybe should be Certificate Request (without 's').
Similarly to the previous section I would suggest MUST NOT and specifying
how the client would behave upon receiving MD5 or SHA-1 as hash.

I believe SHA-1 has been dropped in section 4 and 5.

section 6:

The current rfc5246 rely on default sha-1 and md5. To ease interoperability
I am wondering if we strongly recommend to provide the signature algorithm
extension in addition to the default sha256.

section 7:

The new text is missing a capital letter: s/severs/Servers.

Unless i am missing something, I would limit the update to the scope of the
draft and leave the sentence discussing the group unchanged. .

In the following paragraph and s/MUST not/MUST NOT/.

I believe the IANA section is missing:

TLS HashAlgorithm should have the values

1 md5 Y [RFCTBD]
2 sha1 Y [RFCTBD]


On Tue, May 14, 2019 at 7:25 AM Hubert Kario <> wrote:

> On Tuesday, 14 May 2019 08:34:38 CEST Loganaden Velvindron wrote:
> > Latest draft is here:
> >
> why did you drop SHA-1 from Section 4 and 5?
> the note about SHA-1 in HMAC applies to ciphersuites, to state explicitly
> that
> ciphersuites like TLS_DHE_RSA_WITH_AES_128_CBC_SHA are _not_ deprecated by
> it
> SKE and CV don't use HMAC
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web:
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech
> Republic_______________________________________________
> TLS mailing list