Re: [TLS] HTTP, Certificates, and TLS

mrex@sap.com (Martin Rex) Thu, 21 July 2016 15:57 UTC

Return-Path: <mrex@sap.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 4A37412D66A for <tls@ietfa.amsl.com>; Thu, 21 Jul 2016 08:57:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level:
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 L6C67U2uTlIs for <tls@ietfa.amsl.com>; Thu, 21 Jul 2016 08:57:16 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C1B120727 for <tls@ietf.org>; Thu, 21 Jul 2016 08:57:15 -0700 (PDT)
Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3rwJLx6430z25QZ; Thu, 21 Jul 2016 17:57:13 +0200 (CEST)
X-purgate-ID: 152705::1469116633-00000827-3B10B377/0/0
X-purgate-size: 699
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3rwJLx3k6Szkw0G; Thu, 21 Jul 2016 17:57:13 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 795ED1A504; Thu, 21 Jul 2016 17:57:13 +0200 (CEST)
In-Reply-To: <BLUPR03MB1330AB57841AE0A68F460A9987090@BLUPR03MB1330.namprd03.prod.outlook.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Date: Thu, 21 Jul 2016 17:57:13 +0200 (CEST)
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: <20160721155713.795ED1A504@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UtUpksO9JUGb3ZHzy7ic1FQ-rhY>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] HTTP, Certificates, and TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <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: Thu, 21 Jul 2016 15:57:18 -0000

Mike Bishop wrote:
> 
> That means we now have a proposal for carrying both client and server
> certificates above TLS, found at
> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs.
> 
> We have also discussed that it might be preferable to pull part of this
> capability back into TLS,

You are facing a MUST NOT in rfc6066 for this particularly bad idea.

I'm currently wondering what kind of (weird) TLS session caching strategy
would actually allow you to create such client or server behaviour.
You're definitely in severe conflict with the "principle of least surprise"
in respect to deterministic behaviour of your TLS clients and TLS servers.

-Martin