Re: [TLS] Signature Algorithms

Hubert Kario <hkario@redhat.com> Mon, 16 March 2015 13:41 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE051A875A for <tls@ietfa.amsl.com>; Mon, 16 Mar 2015 06:41:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.013
X-Spam-Level:
X-Spam-Status: No, score=-5.013 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 qjUX1d5YX9jM for <tls@ietfa.amsl.com>; Mon, 16 Mar 2015 06:41:00 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78E991A8759 for <tls@ietf.org>; Mon, 16 Mar 2015 06:41:00 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id EF0AFC1F94; Mon, 16 Mar 2015 13:40:59 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-213.brq.redhat.com [10.34.0.213]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2GDewJA031127 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2015 09:40:59 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 16 Mar 2015 14:40:51 +0100
Message-ID: <2126970.G8GsdsskoZ@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.4 (Linux/3.18.7-100.fc20.x86_64; KDE/4.14.4; x86_64; ; )
In-Reply-To: <19075EB00EA7FE49AFF87E5818D673D41145FB0C@PRODEXMB01W.eagle.usaa.com>
References: <19075EB00EA7FE49AFF87E5818D673D41145FB0C@PRODEXMB01W.eagle.usaa.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3652554.BkmTUHDRYH"; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/UnzRL_3nxJNN3aXqJFC7Wkd2uRc>
Subject: Re: [TLS] Signature Algorithms
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 16 Mar 2015 13:41:02 -0000

On Sunday 15 March 2015 03:40:38 Mehner, Carl wrote:
> >I believe we are going to remove this entire field and its associated
> >code points because it is redundant with the signature algorithms.
> 
> sounds good.
> 
> Speaking of Signature Algorithms, what do you think of this?
> 
> 
> Since root certificates are trusted by their identity rather than the
> signature I think that amendments to the text in the Server Certificates
> and Certificate Request sections are necessary.
> 
> As we move into a world that lacks trusted SHA-1 signatures, a change in the
> text would be necessary in order for clients that drop SHA-1 from the
> supported hash algorithms to continue to connect to servers that send a
> certificate_list that includes roots signed with SHA-1.

server that provides a self signed certificate is misconfigured in the first 
place...

a change that would reflect better the real world deployments would be to 
change the MUST to SHOULD - significant portion of servers ignore 
signature_algorithms when selecting server certificate (i.e. send sha-1 signed 
certs even when client didn't advertise SHA-1 in sig_algs)

and its the client's duty anyway to decide if it trusts a chain or not, the 
server should just provide one that is most likely to be trusted, not second-
guess client's intentions
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic