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 19:13 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 AC62A1200D7 for <tls@ietfa.amsl.com>; Tue, 14 May 2019 12:13:28 -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 E6iKHXGXLNBy for <tls@ietfa.amsl.com>; Tue, 14 May 2019 12:13:26 -0700 (PDT)
Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (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 CD25E1200DE for <tls@ietf.org>; Tue, 14 May 2019 12:13:25 -0700 (PDT)
Received: by mail-qt1-f174.google.com with SMTP id m32so400860qtf.0 for <tls@ietf.org>; Tue, 14 May 2019 12:13:25 -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=oP8POdvj3g2sLIPqiRVAV78OgMl2iZ/JhkzJ0wfNOQM=; b=gYVUQlaj8uxiW6TbF1hZSguVZ38xpa+TIil0bQfi8UgeBauI7BqE9TFT89VpsGR7D9 wFsqqq0SkW01y2IJZTtaWv2k4y287rKDo3L0KWjN8Xh8lggpO+1R+cbuZncVyQ3rxzBX gG9ysHWnAvK4pV5fJpG1lhw0/gh+3nt3klT3m7NDicwCNA+jz0Mnx8VMrxVMeqYDI7zA Pk8za0yb5f4XbBY0aaa6xT1n9U+F5RglpPG1+Nkt8HZp8SYsZy1NK86wlX6D9NxoB9du FfR1D7J5TPws/jadV05zW2JpqaCWtElwM3lI06NXV37D9WtGJuOTDkgr18j38Oz3Cu1A JqTA==
X-Gm-Message-State: APjAAAXqoORsrn95aWrO+YRTPv88sGnfNxR6AwFFkdX9/9qGY/g3i3ln bhqTB7MWyk5T2H6B14CZ+pQKddkc4rO+XOBQ7+8=
X-Google-Smtp-Source: APXvYqxuWzKEZfSMfJxA+WnHyQgocS1ecyYzmZuWSS7QduJSFpXuWtigdg5dvNCm61EEeapd6Io7sdVGm6Su7qJ9nXc=
X-Received: by 2002:ac8:1082:: with SMTP id a2mr31099673qtj.231.1557861204709; Tue, 14 May 2019 12:13:24 -0700 (PDT)
MIME-Version: 1.0
References: <CAOp4FwRNxx2+MdSqHcrqgA0KkNMaQ29H8K4WBFDAw2AhL+3NKA@mail.gmail.com> <2977635.mFCBgFvPmQ@pintsize.usersys.redhat.com> <CADZyTk=oQ+nA6pfrKJB8y15vAogakUu8vB=rnLr5m6z_hDa2Lg@mail.gmail.com> <2162072.cel6DGkFtN@pintsize.usersys.redhat.com>
In-Reply-To: <2162072.cel6DGkFtN@pintsize.usersys.redhat.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 14 May 2019 15:13:13 -0400
Message-ID: <CADZyTkngMp6rg=uru0HHy7TYLBdJunbQ+xQ05d77Ja7A7u3Brg@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: tls <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b7565e0588ddd391"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tIwR-0vPBfc84YBxetSLLH3EDPU>
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 19:13:29 -0000

On Tue, May 14, 2019 at 2:27 PM Hubert Kario <hkario@redhat.com> wrote:

> On Tuesday, 14 May 2019 20:09:36 CEST Daniel Migault wrote:
> > 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.
>
> that was the intention behind my suggestion for SHOULD NOT - i.e. the
> server
> MUST be able to handle ClientHello that does advertise them, but in
> practice
> ignore them based on required handling for SKE and CV
>
>
got it, then the text needs to be explicit in each case we should not hide
ourselves behind a vague SHOULD.


> > 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.
>
> same as above
>
> > 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.
>
> no, sha-1 is the default in case the extension is omitted, but then we
> also
> specify that if the extension is omitted now, the negotiation MUST fail
> the recommendation for sha256 is that it in practice has to be included in
> the
> extension as some servers use the extension to select server certificate,
> so
> omitting sha256 there will cause the connection to fail
>
> Works for me. I believe the reasoning worth being mentioning. In addition,
the section update of 5246 coudl also emphasis changes are not limited to
the NEW text.


> this is also partially the reason for a SHOULD NOT instead of MUST NOT for
> section 2 and 3 – I do not know how those servers handle interaction
> between
> SHA-1 missing in the extension and root CA (self-signed certificate) being
> signed by SHA-1
>
> I had the same question ;-) and of course not the response.  I believe
that we should clarify this and document the choice for MUST/SHOULD.

> --
> 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
>