Re: New Version Notification for draft-jjmb-httpbis-trusted-traffic-00.txt

Hi Ben (et al) -

Just an update.  Still working on getting our test up and running, just 
need to fight through some issues we ran into with our proxy as an alt 
service.  Browser and origin seem to be doing what we need.

While we have a punch list of things to check, the main one is whether 
our transparent proxy (alt service) needs to host a certificate for the 
origin.  I suspect we will be able to get the proxy to forward one from 
the origin, if necessary, but need to be sure.

The reason for my concern about the alt service having an origin cert is 
that RFC 7838 says:
>     Importantly, this includes its security context; in particular, when
>     TLS [RFC5246 <https://tools.ietf.org/html/rfc5246>] is used to authenticate, the alternative service will
>     need to present a certificate for the origin's host name, not that of
>     the alternative.
Assuming we make this work, we will have another use-case for SNI alt 
services.  Should know soon.

/lou


On 5/23/2018 7:59 PM, Lou Steinberg wrote:
> Got it on both...makes sense. Let me see how we can spin up a test 
> like this.
>
> Best
> Lou
>
> On May 23, 2018 4:25:15 PM EDT, Ben Schwartz <bemasc@google.com> wrote:
>
>     On Wed, May 23, 2018 at 3:24 PM Lou Steinberg <lou@ctminsights.com
>     <mailto:lou@ctminsights.com>> wrote:
>
>         Hi Ben
>
>         Thanks for the comments. A couple of thoughts, though I am by
>         no means an expert in Alt-Svc-SNI so please correct me if I
>         get this wrong.
>
>         I think the biggest concern was that the alt service may need
>         to present a certificate for the origin (with TLS). We had
>         explicitly tried to avoid having to manage certificates on the
>         validator. Maybe that's worth reconsidering if this simplifies
>         the process.
>
>
>     I think you can do this without managing any certificates on the
>     validator.  The validator can simply inspect the SNI, and then
>     either forward the entire TCP stream to the origin or drop it.
>
>         Additionally, as I understand it, the client woukd still need
>         to manage the expiration of Trust Tokens, but the client
>         generally doesn't have access or visibility into the fact that
>         alt services are in use. There is a freshness setting that
>         allows an alt svc to expire, but I think the client is still
>         permitted to continue to use the alt service after expiration.
>
>
>     I think this may be based on a misreading of RFC 7838:
>
>        Clients with existing connections to an alternative service do not
>        need to stop using it when its freshness lifetime ends; the caching
>        mechanism is intended for limiting how long an alternative service
>        can be used for establishing new connections, not limiting the
>     use of
>        existing ones.
>
>     This means that client does not have to tear down its open
>     sockets, but it cannot use an expired Alt-Svc value for
>     establishing new connections.
>
>         Can the validator send a misdirected request should this happen?
>
>
>     I don't think you need to worry about clients using expired
>     Alt-Svc values, but if you want to fail gracefully, you could have
>     the validator forward connections with expired Assertion Tokens to
>     the "public" origin servers that handle untrusted traffic. The
>     client will then get a new Alt-Svc value, which will override
>     their present value.
>
>
>
>         Appreciate your help!
>         Lou
>
>
[snip]

-- 
---
Lou Steinberg
Managing Partner
CTM Insights, llc