Re: Call for Adoption: Secondary Certificate Authentication in HTTP/2

Patrick McManus <mcmanus@ducksong.com> Fri, 15 July 2016 18:14 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 6A1E812D0AA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 Jul 2016 11:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.207
X-Spam-Level:
X-Spam-Status: No, score=-8.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sendgrid.me
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 hPYT8JEcsK_h for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 Jul 2016 11:14:19 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2C212B04F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 15 Jul 2016 11:14:18 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bO7Z4-0002XJ-Im for ietf-http-wg-dist@listhub.w3.org; Fri, 15 Jul 2016 18:10:18 +0000
Resent-Date: Fri, 15 Jul 2016 18:10:18 +0000
Resent-Message-Id: <E1bO7Z4-0002XJ-Im@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net>) id 1bO7Yx-0002VM-5o for ietf-http-wg@listhub.w3.org; Fri, 15 Jul 2016 18:10:11 +0000
Received: from o1678955x65.outbound-mail.sendgrid.net ([167.89.55.65]) by lisa.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA256:128) (Exim 4.80) (envelope-from <bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net>) id 1bO7Yu-0005CC-FX for ietf-http-wg@w3.org; Fri, 15 Jul 2016 18:10:10 +0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=mime-version:in-reply-to:references:from:subject:to:cc:content-type; s=smtpapi; bh=9AyuhK4vPUjbexKqmZ3lU68tAU8=; b=zRDcw1xO//bYlY361L wuKIVpSGMPNb90kZqtEqt6IiMzNUT3Woo8kVxBO316GOK2kzO6zuMBS4WYMCSXEl lKIJ7qREVW/eRQS18wtv/XJmTeeZZwM6wOnXtEjskx3y1CvJEQ1gCX3fi4u2pu4p 81+3JI7NpcSgznAVpAN/5A3rU=
Received: by filter0691p1mdw1.sendgrid.net with SMTP id filter0691p1mdw1.28644.578926D741 2016-07-15 18:09:27.842609054 +0000 UTC
Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com [209.85.213.47]) by ismtpd0003p1iad1.sendgrid.net (SG) with ESMTP id IaZVFU76R6K-1jm9uqNb_A for <ietf-http-wg@w3.org>; Fri, 15 Jul 2016 18:09:27.773 +0000 (UTC)
Received: by mail-vk0-f47.google.com with SMTP id j126so111841533vkg.3 for <ietf-http-wg@w3.org>; Fri, 15 Jul 2016 11:09:27 -0700 (PDT)
X-Gm-Message-State: ALyK8tK2gYDbDZYwhDSOMaXnjJnvDIc2pIBO/FSlYDTI1sHv5knTxvAHzoDlanv+oFt5EWJGSlZyijugECdR4A==
X-Received: by 10.31.225.70 with SMTP id y67mr9702652vkg.80.1468606167488; Fri, 15 Jul 2016 11:09:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.4.79 with HTTP; Fri, 15 Jul 2016 11:09:26 -0700 (PDT)
In-Reply-To: <CABkgnnXL-hS-raH5cC3c0nzpTHWP8speLbOhFNppv4p5LB5nQQ@mail.gmail.com>
References: <F9D2CFF3-57C2-41BD-ACB1-FA6C991458D7@mnot.net> <CABcZeBPTYgcfecKErhacR=jfXkoRPESgUQ=1pzPEWg092fqZvw@mail.gmail.com> <BL2PR03MB1905D20659B406937EA7C021873B0@BL2PR03MB1905.namprd03.prod.outlook.com> <CABcZeBOuf0k5VwSO1nMp-P0YXF-j8pZ7ZVF1h-_pMU54LnwpJQ@mail.gmail.com> <CABkgnnXL-hS-raH5cC3c0nzpTHWP8speLbOhFNppv4p5LB5nQQ@mail.gmail.com>
From: Patrick McManus <mcmanus@ducksong.com>
Date: Fri, 15 Jul 2016 14:09:26 -0400
X-Gmail-Original-Message-ID: <CAOdDvNoVYPojUzqTgZBv=bqKFDPy8pg-w78s37Aa1WYQ0=g3GA@mail.gmail.com>
Message-ID: <CAOdDvNoVYPojUzqTgZBv=bqKFDPy8pg-w78s37Aa1WYQ0=g3GA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Eric Rescorla <ekr@rtfm.com>, Mike Bishop <Michael.Bishop@microsoft.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001a114e0046eda1af0537b0841b"
X-SG-EID: YLWet4rakcOTMHWvPPwWbcsiUJbN1FCn0PHYd/Uujh71I1h38u+vPGz35iWgzKQ8OCIb93deEpmWpP D1OWUJ70H5hL6N66qdTkA8lbSLcWQL+yOOffmMOH1ODmDVIwtHbS3DgfnWhlLophV1FqdtYrGGOUw7 CQFzQisZlFrEnSPIkQO4bwAJ9Bp877L2vr4CvrlZqbr+e1t/+uBelDrbEn/EkUDfcDr4Ak9A2QVPoU g=
Received-SPF: pass client-ip=167.89.55.65; envelope-from=bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net; helo=o1678955x65.outbound-mail.sendgrid.net
X-W3C-Hub-Spam-Status: No, score=-6.0
X-W3C-Hub-Spam-Report: AWL=-0.268, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, URIBL_GREY=0.424, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1bO7Yu-0005CC-FX 730f56f2c79306ae65fafa5310006abc
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Call for Adoption: Secondary Certificate Authentication in HTTP/2
Archived-At: <http://www.w3.org/mid/CAOdDvNoVYPojUzqTgZBv=bqKFDPy8pg-w78s37Aa1WYQ0=g3GA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31978
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: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Mike - thanks for this draft. As I noted at the mic in BA I strongly
support its adoption.

I have some feedback, some editorial some not.




*HTTP clients need to know that the content they receive on aconnection
comes from the origin that they intended to retrieve infrom.*
Something went awry there.. maybe s/in/it ?

B*ecause the TLS SNI extension is exchanged in the clear, clients
   might also prefer to retrieve certificates inside the encrypted
   context.*

not just clients who might prefer that.. perhaps "implementations" or
"peers"

c
*iphersuite at the TLS layer, while acquiring the "real" certificatein HTTP
after the connection is established.*

I know what you're going for - but saying scare quotes real makes me wonder
what the fake (i.e. not valid PKI) certificate is. Perhaps "final"?



*1.2.1 and 1.2.2*
Those sections about h1 are pretty long, detailed, and don't have a lot to
do with the mechanism being defined here other than as motivation. I think
they're targets for cutting and perhaps replacing with a short graf on the
challenges of auth of a transport stream when it is muxed between multiple
transactions. fwiw.

* defined in [RFC7540 <https://tools.ietf.org/html/rfc7540>], when a
client finds that a https:// origin
   (or Alternative Service [I-D.ietf-httpbis-alt-svc
<https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01#ref-I-D.ietf-httpbis-alt-svc>])
to which it needs
   to make a request has the same IP address as a server to which it is
   already connected, it MAY check whether the TLS certificate provided
   contains the new origin as well, and if so, reuse the connection.*

alt-svc never changes an origin so I don't think you need the parenthetical
and by calling it out it kinda adds to that general confusion. You might
just change all of

*https:// origin
   (or Alternative Service [I-D.ietf-httpbis-alt-svc
<https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01#ref-I-D.ietf-httpbis-alt-svc>])*

to be "server".

*   A server MAY push resources from an origin for which it is
   authoritative but for which the client has not yet received the
   certificate.  In this case, the client MUST verify the server's
   possession of an appropriate certificate by sending a
   "CERTIFICATE_REQUIRED" frame on the pushed stream to inform the
   server that progress is blocked until the request is satisfied.  The
   client MUST NOT use the pushed resource until an appropriate
   certificate has been received and validated.*

I think this might worry me the most. in practicality that means
certificate required is going to be sent on a closed stream a lot of the
time. The extension probably needs to work harder to say this is OK, given
that it is overriding 7540 - but in practice it seems like a hard
requirement to make work. And worse, you're adding a 1 RTT delay into push
when push is really only a 1 RTT mechanism anyhow. What if we could push
the certificate_required bit on the non-zero stream as some kind of
extension to push_promise?

   *This could also increase the impact of a key compromise.  Rather than
   needing to subvert DNS or IP routing in order to use a compromised
   certificate, a malicious server now only needs a client to connect to
   _some_ HTTPS site under its control.  Clients SHOULD continue to
   validate that destination IP addresses are valid for the origin
   either by direct DNS resolution or resolution of a validated
   Alternative Service.  (Future work could include a mechanism for a
   server to offer proofs.)*

I certainly think some text is needed here - but I have a fundamental
objection. Routing - whether that be IP routing, DNS routing, Alt-Svc
Routing, Proxy use or lookup, tcp hijack via inline proxy, or origin frames
is simply not part of the security model of https. The model is all about
the cert and the origin - not about how you got the bytes. The fact that
many of these are (ab)used pervasively on the Internet and https is
distinctly more secure in practice (not just theory) than http:// is
basically because of that. IP addresses don't even play a role in some of
those mechanisms (proxies?) and creating SHOULD language around validating
them over constrains us for no real gain. I would suggest some
non-normative text describing how certificates are the real security model
here and as we scrape away the compromised detritus that surrounds them
that becomes clearer.

Lastly, I liked how the general text called out the security benefit of
being able to hide SNI especially from passive attacks. The security
considerations mentions how this is still subject to active probing but it
might be worth re-iterating the passive benefit explicitly in the security
considerations.

Thanks again for this - this is an important draft with a lot of hard work
in it.

-P