Re: something something certificate --- boiling a small lake

Brian Campbell <bcampbell@pingidentity.com> Thu, 25 June 2020 21:34 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 408663A102F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Jun 2020 14:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Level:
X-Spam-Status: No, score=-2.748 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.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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 3DSlxyuQTgyr for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Jun 2020 14:34:46 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 3AFB53A102E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 25 Jun 2020 14:34:45 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1joZTN-0007bv-Ly for ietf-http-wg-dist@listhub.w3.org; Thu, 25 Jun 2020 21:31:53 +0000
Resent-Date: Thu, 25 Jun 2020 21:31:53 +0000
Resent-Message-Id: <E1joZTN-0007bv-Ly@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <bcampbell@pingidentity.com>) id 1joZTK-0007b3-SF for ietf-http-wg@listhub.w3.org; Thu, 25 Jun 2020 21:31:50 +0000
Received: from mail-lj1-x22d.google.com ([2a00:1450:4864:20::22d]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <bcampbell@pingidentity.com>) id 1joZTI-0000GH-HT for ietf-http-wg@w3.org; Thu, 25 Jun 2020 21:31:50 +0000
Received: by mail-lj1-x22d.google.com with SMTP id 9so8166362ljv.5 for <ietf-http-wg@w3.org>; Thu, 25 Jun 2020 14:31:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M0c83yt8DuUJ8so7neCORgW723l3VAUAqtDAMPeYyBw=; b=RYihjtN3lYsJPSkK3MbSyYtoElWyQQYrl8UlwvG3mMNS0cdVxWFkW7E0Cmx09GVLfE /lfEmf7v1uMedNnqwNP2LVmZ3NY4z5EuBQA5MU+JMMwsbzxbxREO1rX8jZDRo9/SKZ1+ KpGT0COHDQhFbpCeYTZ3qlNtX0MHDzkNNeGVHLHxbYOH+UzdmSQwDwC+ky0lUyDhBjw9 WhfoulMw91gUl39Xa/9d4s251E6C3kevNnfWcB1xyuGNtNuAISTrcxmtLk+APUdQ+pxF joZ7TySxZ1mxMpzqQvEWg1P/4xB/bpFox7kYmNW8ycquUdubZz7S+hnZQhEykqb2ap5A 0s5g==
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=M0c83yt8DuUJ8so7neCORgW723l3VAUAqtDAMPeYyBw=; b=isr3kHK3d8KxdNTK9UZ9PO1CnKeJhkxxVcjgjBFG9VOG6DnMUwE/nsLgoCZzldMSyP aTPqzESAAB138+mntvsnXYQXocY7E+EOj2OlV3qJDeaPKZKLK9gZLAIZO+yxJSY87sI2 Wv1LplQZ9Jl2dx3OLwbnhU4rTBhCUF/pHlFucdro+ZgE21EKYDanT3iJW3KbsGIBJhNi JsFZOitQ3TzqvfILlK4L044zgC41A6MPZh3T3Ojkd81NRjhG+gTWib8j6lE8+NgaANew 3bHx0AEgdCfJ7+kIfhYfj0/FFCgwoKX0jx4COJnJklMrcu17qgKT5y1GwJdMLg7+vYXL TqKw==
X-Gm-Message-State: AOAM533z87RH+vyy7FTPxsdxudSyrc6BWVt4LQ+ZjjiGYXhOEisR0bDN EauHdHTun/5vZE4/rZdN5nKf5VQwQBcNz3Ju4zPxvs9RSQW5qEgkA89tkegqQCPRIJ+2HTbQRAc RtkMPJ2+Hjb6AIL4TvVOhkWV6oQ==
X-Google-Smtp-Source: ABdhPJyQiRYHJ0EXRXEmNx1rTmK32ENiLJ5i452xMQAqNDvdjxHzHpiapnnpVHyS1GKJxd9g8DOQma+AiyoyV8g/Nio=
X-Received: by 2002:a2e:b8c2:: with SMTP id s2mr18830609ljp.368.1593120696496; Thu, 25 Jun 2020 14:31:36 -0700 (PDT)
MIME-Version: 1.0
References: <6663.1592585417@localhost>
In-Reply-To: <6663.1592585417@localhost>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 25 Jun 2020 15:31:10 -0600
Message-ID: <CA+k3eCTjgeXn9=woDXq5rCX+PHDwkSqD9H0=a8VnFemJheQEeA@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, tls@ietf.org
Content-Type: multipart/alternative; boundary="000000000000330abc05a8ef51af"
Received-SPF: pass client-ip=2a00:1450:4864:20::22d; envelope-from=bcampbell@pingidentity.com; helo=mail-lj1-x22d.google.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1joZTI-0000GH-HT 8a037a3183d8b0115e9c6b9fb5249a3a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: something something certificate --- boiling a small lake
Archived-At: <https://www.w3.org/mid/CA+k3eCTjgeXn9=woDXq5rCX+PHDwkSqD9H0=a8VnFemJheQEeA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37828
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>

My aim with something-something-
<https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/>
certificate
<https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/>
is/was to address a narrow but existing need by documenting current
practice while introducing enough commonality to the header name and its
content/encoding so as to facilitate relatively simple interoperability
between independently developed systems. I see where you are going with
this boiling of a small lake but it's well beyond the scope of the kind of
solution I'd envisioned or think would be practically deployed and useful
in any meaningful numbers.

On Fri, Jun 19, 2020 at 10:50 AM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Brian,
> {I have been on the httpbis list, but I'm not right now, and I know that
> w3 and IETF do not share their whitelists, so this might not work}
>
> I was thinking about something-something-certificate yesterday while
> cleaning/swimming
> my pool.  (A long thankless task, as the pool is not heated, we've been
> getting very a-seasonal *snow*, and nobody in my family but me will swim
> in it
> until it's "perfect".  Also we have many many trees, which we won't cut
> down.
> You can see how my mind might wander)
>
> [This discussion would be better done with beer and napkins.]
>
> So I am thinking that we need to create a "digital twin" in the back-end
> server for the front-end TLS state machine.  It needs to reflect the
> current
> state at a level of detail appropriate for the application.
>
> Thus, a single header isn't enough, although there could be some
> degeneration
> that results in a single header.  We need a few variables to update.
>
> I think we have a choice between:
>
> 1) sending the state (possibly a few kb) on every transaction, which keeps
>    the protocol stateless.  We could explore ways to encode it: CDDL+CBOR
>    seems like a good thing.  TLS structures are another obvious choice, but
>    that's a detail.
>
> 2) assuming that state will be maintained by both ends, and simply updating
>    the state appropriately.   When it comes to this, I think of the
>    HTTP PATCH methods, but I'm not sure I mean this literally.
>
> It's the model of having a few objects per-connection that the TLS
> front-end
> might update on the backend, and making the management of the TLS
> connections explicit.
>
> Alternately, the TLS front-end could maintain a RESTful interface on a
> per-connection basis that the back-end could interrogate.  The header
> would just provide the right reference to that.  The RESTful interface
> could even be pushed/updated into some other CPU on the TLS terminator.
>
> This is cleaner, but this has read-latency round trip issues, while pushing
> the state out on each HTTP request (or uwsgi, fastcgi, ...) seems a lot
> more
> pipelined.  Or MQTT :-)
>
> To this, I think we'd have to look at the RFC8446 Appendix A.2 state
> machine
> and figure out how to express this.   I don't really see re-auth in that
> diagram.  Maybe I'm overthinking here, but given the opportunities in TLS
> 1.2 and 1.3 for newer states, and the review from TLS experts on the
> header,
> this might be cleaner and less of a hack to get the additional things in.
>
> This data model mechanism also better accomodates the split between those
> who
> need the entire certificate chain (w/ and w/o trust anchor used), and those
> that just care about the EE involved.
>
> ---
>
> I don't know, in a HTTP/3(QUIC) world, what the TLS front-end/backend
> connection looks like.  I haven't entered such a world personally.
>
> TLS front-end systems *are* collecting/storing state on a per-client
> connection basis, whether the transport is QUIC or not.  I don't think it
> scales well to try to spread that state across load balancers, you want to
> split the traffic before the TLS terminators in order to horizontally scale
> them.
>
> A thought that I have is that with a move to HTTP/3, that the need for
> something-something-certificate declines.
> A model that I could see in such a situation is that since the bulk of the
> transport is via QUIC, it could be that it makes less sense to have TLS
> hardware terminators; by careful use of port numbers to demux upon, and/or
> IPv6 addresses, it might be easier to load balance directly to application
> servers, and just horizontally scale them wider.
>
> The hardware TLS offload box then is only important for adapting HTTP 1
> and HTTP/2 connections to HTTP/3.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT
> architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
>
>
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._