Re: FW: New Version Notification for draft-bishop-httpbis-http2-additional-certs-05.txt
Nick Sullivan <nicholas.sullivan@gmail.com> Mon, 13 November 2017 09:35 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DA6128BC8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 13 Nov 2017 01:35:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.998
X-Spam-Level:
X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 n1FamkUo9gth for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 13 Nov 2017 01:35:53 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78C8126CC4 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 13 Nov 2017 01:35:53 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1eEB46-00065X-N2 for ietf-http-wg-dist@listhub.w3.org; Mon, 13 Nov 2017 09:30:02 +0000
Resent-Date: Mon, 13 Nov 2017 09:30:02 +0000
Resent-Message-Id: <E1eEB46-00065X-N2@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <nicholas.sullivan@gmail.com>) id 1eEB3x-0005gk-Qy for ietf-http-wg@listhub.w3.org; Mon, 13 Nov 2017 09:29:53 +0000
Received: from mail-wm0-f51.google.com ([74.125.82.51]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <nicholas.sullivan@gmail.com>) id 1eEB3v-0002Vz-D0 for ietf-http-wg@w3.org; Mon, 13 Nov 2017 09:29:53 +0000
Received: by mail-wm0-f51.google.com with SMTP id v186so4858653wma.2 for <ietf-http-wg@w3.org>; Mon, 13 Nov 2017 01:29:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UKPBJHi8NMkP+6gGXKloqn8PkvgsKbj0ezOX84ln8nU=; b=uQ7ByFIYZY/A01rtw+C4U/hzU3oevC4ANRy2LPAFkVj71SRHgY0K/iwUhn8j1KMEZR AEwQ4dAb1040hWV13u/Lw4qr3ZujhRwcA0QxIMekdFqoRbOLwdHR7T9JQ3QMqFXpEda6 w+d83Joh+nZfD0MbxmvIvVeja4qP/hEaj31h46y6LHUqZRbhe2adFahuAIbpdXyovI4L sNB4bvaB6IcopMQPiL/KBNnVZvzFduuQkcoYyk3qGC+KOPJ0LTALmDWD3l3qOZpqMSSf lVXSAUm02DPKeQ3Jxm/ZwyYRn7+MD+MRmJozQwgVwaWxSxkRGQWVpqhhr7I87FEv1qmH Js+Q==
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=UKPBJHi8NMkP+6gGXKloqn8PkvgsKbj0ezOX84ln8nU=; b=DAknxsXEI1/g38Qv3w78UxFOBb+e2bgcO+MvBMAo5zGdAIi6WRaXrSNDdZ1oxiqPxk nQVqRuxAAxcaSqISA5rkWHRIYEkkW5caQrgw56Rdcb9P5MBDV/pH0OC8TImprPg8FNvF uj4fUuuXzPkUYfulS/8K+EKgFnSC//1g2ZhuSaesbUmo0rc3TOPSXstlw+QmdgSroCQH XcvQ1U4AxPkcF0w6Lz7YMRSyKfT29iwK7KBsE/1VKTlW9QCmLgyh/rtN+numbZbYkdQE otbhgyzfWKlvV022feSaz1BZHzmJ8h9q6c6FFX/MtmflPyZfUW0krsFl9ewXAsd/klCf KzZg==
X-Gm-Message-State: AJaThX6z7jjtwFn7QdoBlP9IvFxTVAZndwZeIicAKQrI1C2iLb1SfLeu 0eLBtfnAVtnLfmcddGBvHHjHV5dfc+Cu+2uNvj8=
X-Google-Smtp-Source: AGs4zMZPIXSIuxZ2uTFN3mjKEGeKdDEP03aEmKhq3xBXRwLPXDkiXVvtP9gY1f4ZjP6v6Iet9NwwRWbDe3bR415foQs=
X-Received: by 10.28.73.196 with SMTP id w187mr5646895wma.17.1510565369752; Mon, 13 Nov 2017 01:29:29 -0800 (PST)
MIME-Version: 1.0
References: <150939960176.7740.5723475746682417243.idtracker@ietfa.amsl.com> <MWHPR08MB347212B6F2F9DDD092728354DA5E0@MWHPR08MB3472.namprd08.prod.outlook.com> <CANatvzzO0gsuvjBjCuGuvxenubnVt4G==qw1huzjSd57V+8A9Q@mail.gmail.com>
In-Reply-To: <CANatvzzO0gsuvjBjCuGuvxenubnVt4G==qw1huzjSd57V+8A9Q@mail.gmail.com>
From: Nick Sullivan <nicholas.sullivan@gmail.com>
Date: Mon, 13 Nov 2017 09:29:19 +0000
Message-ID: <CAOjisRyTn4UR0oV7si93da2G4gbzZZXU4LO-NW2PZWSLosFOLg@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Mike Bishop <mbishop@evequefou.be>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001a114b3092463306055dd9e809"
Received-SPF: pass client-ip=74.125.82.51; envelope-from=nicholas.sullivan@gmail.com; helo=mail-wm0-f51.google.com
X-W3C-Hub-Spam-Status: No, score=-4.0
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1eEB3v-0002Vz-D0 b09fb38b6cccfce3dffcfe13a762a134
X-Original-To: ietf-http-wg@w3.org
Subject: Re: FW: New Version Notification for draft-bishop-httpbis-http2-additional-certs-05.txt
Archived-At: <https://www.w3.org/mid/CAOjisRyTn4UR0oV7si93da2G4gbzZZXU4LO-NW2PZWSLosFOLg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/34782
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Hi Kazuho, Thanks for this. I think you found an issue that we did not consider: the fact that server support for setting AUTOMATIC_USE in client certificates may not be desirable for all servers. The CGI case you describe would work find as long as the client doesn't use AUTOMATIC_USE. Here's a possible solution to this: Let the server advertise support for AUTOMATIC_USE in the CERTIFICATE_REQUEST message as a flag. If the client receives a CERTIFICATE_REQUEST without AUTOMATIC_USE set, then it should not be able to reply with a CERTIFICATE with AUTOMATIC_USE set. Nick On Mon, Nov 13, 2017 at 3:18 PM Kazuho Oku <kazuhooku@gmail.com> wrote: > Hi, Mike, Nick, Martin, > > I have briefly asked this in the IETF meeting, but let me question if > it sounds logical to adjust the approach so that the client will be > required to proactively specify the certificate that is associated to > each HTTP request. > > I ask this due to the following reason. > > In HTTP/1, it was always clear from the server’s viewpoint which > certificate is associated to a HTTP request. This is because the > underlying connection allowed only one client certificate at maximum > to be used. CGI is designed after that model. A CGI gateway is > expected to designate _at most one_ certificate that has been > associated to the request by using a set of environment variables > (e.g., `SSL_CLIENT_S_DN` [1]). I would assume that it is the same for > other de-facto standards that have evolved from CGI (e.g., FastCGI, > Rack). > > The secondary certificates draft changes the model. Under the model > proposed by the draft, the server is expected to choose from one of > the certificates that it has received with AUTOMATIC_USE flag set, or > to request the client to send a new certificate. > > However, to me (as a HTTP server developer that acts as a CGI gateway) > it is unclear how a server can make such choice. Applications that are > run using the CGI protocol _might_ have sufficient information to make > such choice, but that is not the case for a CGI gateway. > > That means that unless the draft (in the following revisions) specify > the guess logic that I should implement, I would be forced into > sending CERTIFICATE_NEEDED for every HTTP request I receive. Doing so > would introduce one extra roundtrip. > > Considering that, I wonder if you could adjust the approach proposed > in the draft to require the client to proactively clarify the > certificate that is associated to each HTTP request. > > For example, I believe that the draft could specify that: > * If the client does not specify a certificate that is associated to a > request, a server MAY request the client to specify the certificate. > * The client can specify the certificate that is associated to a > request proactively, instead of sending USE_CERTIFICATE frame in > response to a CERTIFICATE_NEEDED frame. > > By changing the approach as such, the only case in which two > roundtrips are required for processing a request could become when the > client is required to send a new certificate. Also, AUTOMATIC_USE flag > becomes unnecessary. > > One downside caused by such change is that the bandwidth slightly > increases due to the fact that the client would be required to specify > the certificate that is associated to every HTTP request. However that > is just sending Cert-ID per every HTTP request; I believe that the > increase of bandwidth is negligible. > > To summarize, I am suggesting to push the responsibility of choosing > the certificate back to the client. Note that in the current draft the > client is still required to make such choice if the server sends a > CERTIFICATE_NEEDED frame; so I think requiring the client to _always_ > make the choice does not increase the complexity on the client side. > > [1] https://httpd.apache.org/docs/2.4/mod/mod_ssl.html > > 2017-10-31 8:14 GMT+08:00 Mike Bishop <mbishop@evequefou.be>: > > In preparation for Singapore, we've updated the Additional Certs draft > to track changes in TLS 1.3 and the Exported Authenticators TLS draft. > There's been substantial interest here, and we'll be discussing the draft > during the WG meeting. > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Monday, October 30, 2017 2:40 PM > > To: Martin Thomson <martin.thomson@gmail.com>; Mike Bishop < > mbishop@evequefou.be>; Nick Sullivan <nick@cloudflare.com> > > Subject: New Version Notification for > draft-bishop-httpbis-http2-additional-certs-05.txt > > > > > > A new version of I-D, draft-bishop-httpbis-http2-additional-certs-05.txt > > has been successfully submitted by Mike Bishop and posted to the IETF > repository. > > > > Name: draft-bishop-httpbis-http2-additional-certs > > Revision: 05 > > Title: Secondary Certificate Authentication in HTTP/2 > > Document date: 2017-10-30 > > Group: Individual Submission > > Pages: 21 > > URL: > https://www.ietf.org/internet-drafts/draft-bishop-httpbis-http2-additional-certs-05.txt > > Status: > https://datatracker.ietf.org/doc/draft-bishop-httpbis-http2-additional-certs/ > > Htmlized: > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-05 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-bishop-httpbis-http2-additional-certs-05 > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-bishop-httpbis-http2-additional-certs-05 > > > > Abstract: > > TLS provides fundamental mutual authentication services for HTTP, > > supporting up to one server certificate and up to one client > > certificate associated to the session to prove client and server > > identities as necessary. This draft provides mechanisms for > > providing additional such certificates at the HTTP layer when these > > constraints are not sufficient. > > > > Many HTTP servers host content from several origins. HTTP/2 > > [RFC7540] permits clients to reuse an existing HTTP connection to a > > server provided that the secondary origin is also in the certificate > > provided during the TLS [I-D.ietf-tls-tls13] handshake. > > > > In many cases, servers will wish to maintain separate certificates > > for different origins but still desire the benefits of a shared HTTP > > connection. Similarly, servers may require clients to present > > authentication, but have different requirements based on the content > > the client is attempting to access. > > > > This document describes how TLS exported authenticators > > [I-D.ietf-tls-exported-authenticator] can be used to provide proof of > > ownership of additional certificates to the HTTP layer to support > > both scenarios. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > The IETF Secretariat > > > > > > > > -- > Kazuho Oku > >
- FW: New Version Notification for draft-bishop-htt… Mike Bishop
- Re: FW: New Version Notification for draft-bishop… Patrick McManus
- Re: FW: New Version Notification for draft-bishop… Kazuho Oku
- Re: FW: New Version Notification for draft-bishop… Nick Sullivan
- Re: FW: New Version Notification for draft-bishop… Ilari Liusvaara
- Re: FW: New Version Notification for draft-bishop… Ilari Liusvaara
- RE: FW: New Version Notification for draft-bishop… Mike Bishop
- Re: FW: New Version Notification for draft-bishop… Kazuho Oku
- RE: FW: New Version Notification for draft-bishop… Mike Bishop
- Re: FW: New Version Notification for draft-bishop… Kazuho Oku
- RE: FW: New Version Notification for draft-bishop… Mike Bishop
- RE: FW: New Version Notification for draft-bishop… Mike Bishop