Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis

mrex@sap.com (Martin Rex) Fri, 19 December 2014 17:10 UTC

Return-Path: <mrex@sap.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 1CB641A8A7C for <tls@ietfa.amsl.com>; Fri, 19 Dec 2014 09:10:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.652
X-Spam-Level:
X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 8ST9NjwAZn0S for <tls@ietfa.amsl.com>; Fri, 19 Dec 2014 09:10:51 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51891A8A6C for <tls@ietf.org>; Fri, 19 Dec 2014 09:10:50 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id E25833AB2A; Fri, 19 Dec 2014 18:10:48 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 8DA8442B84; Fri, 19 Dec 2014 18:10:48 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 83D341B097; Fri, 19 Dec 2014 18:10:48 +0100 (CET)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9F9C96@uxcn10-tdc05.UoA.auckland.ac.nz>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Date: Fri, 19 Dec 2014 18:10:48 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20141219171048.83D341B097@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DyTYvslM7kqPtpLTKC3Xi26Yud4
Cc: tls@ietf.org
Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 19 Dec 2014 17:10:59 -0000

Peter Gutmann wrote:
> Stephen Checkoway <s@pahtak.org>; writes:
> 
> >That seems wrong. In practice, a client connects and says I'm willing to
> >communicate using protocol parameters X, Y, and Z. If the server can't
> >accommodate the client, it closes the connection. How is the signature
> >algorithm any different from the cipher suite in this respect?
> 
> TLS conflates the algorithms used with TLS with the algorithms used for
> certificates.  As others have pointed out, a server has control over the
> algorithms used for TLS, but no control over what's used in certificates.
> Those are dictated by the CA.  So it's OK for the client to say "I would like
> one of the above for TLS", but it has no business saying "I expect your CA,
> and every CA above it up to the root, to also use the algorithm(s) I've asked
> for".

I hadn't previously realized that the TLS WG has _already_ retroactively
deprecated the relevant paragraph about the algorithm that was used to
sign the server certificate from rfc4492 (rfc5246,Appendix A.7,3rd paragraph)

https://tools.ietf.org/html/rfc5246#appendix-A.7

   A.7.  Changes to RFC 4492

 [...]

   As described in Sections 7.4.2 and 7.4.6, the restrictions on the
   signature algorithms used to sign certificates are no longer tied to
   the cipher suite (when used by the server) or the
   ClientCertificateType (when used by the client).  Thus, the
   restrictions on the algorithm used to sign certificates specified in
   Sections 2 and 3 of RFC 4492 are also relaxed.  As in this document,
   the restrictions on the keys in the end-entity certificate remain.


-Martin