Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2
Daniel Migault <daniel.migault@ericsson.com> Tue, 14 May 2019 18:09 UTC
Return-Path: <mglt.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D45120155 for <tls@ietfa.amsl.com>; Tue, 14 May 2019 11:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idd_hkudU3gX for <tls@ietfa.amsl.com>; Tue, 14 May 2019 11:09:48 -0700 (PDT)
Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) (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 A06CC120137 for <tls@ietf.org>; Tue, 14 May 2019 11:09:48 -0700 (PDT)
Received: by mail-qt1-f194.google.com with SMTP id a39so132736qtk.2 for <tls@ietf.org>; Tue, 14 May 2019 11:09:48 -0700 (PDT)
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=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: <CAOp4FwRNxx2+MdSqHcrqgA0KkNMaQ29H8K4WBFDAw2AhL+3NKA@mail.gmail.com> <528b8748-6f99-4167-9075-891286b8bc26@www.fastmail.com> <CAOp4FwTNiTg+g2utyst330bc14-Q-_A2z1QEHi_FEMv14wa=iA@mail.gmail.com> <2977635.mFCBgFvPmQ@pintsize.usersys.redhat.com>
In-Reply-To: <2977635.mFCBgFvPmQ@pintsize.usersys.redhat.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 14 May 2019 14:09:36 -0400
Message-ID: <CADZyTk=oQ+nA6pfrKJB8y15vAogakUu8vB=rnLr5m6z_hDa2Lg@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: tls <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000032110f0588dcf01c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PwAKYYGxr0OnFyiBI_WygIM_VcE>
Subject: Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 May 2019 18:09:50 -0000
Hi, Please find some comments. Yours, Daniel Introduction I would suggest a reference to rfc6194 for sha1 digest as well as for hmac-sha1. 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 receiver. 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] Yours, Daniel On Tue, May 14, 2019 at 7:25 AM Hubert Kario <hkario@redhat.com> wrote: > On Tuesday, 14 May 2019 08:34:38 CEST Loganaden Velvindron wrote: > > Latest draft is here: > > https://www.ietf.org/id/draft-lvelvindron-tls-md5-sha1-deprecate-04.txt > > 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: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech > Republic_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] Proposal to deprecate sha1 and md5 for digi… Loganaden Velvindron
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Martin Thomson
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Loganaden Velvindron
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Hubert Kario
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Daniel Migault
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Loganaden Velvindron
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Hubert Kario
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Hubert Kario
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Daniel Migault
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Loganaden Velvindron