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

On Thu, May 31, 2018 at 10:13 AM Lou Steinberg <lou@ctminsights.com> wrote:

> 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.
>

Great.  Feel free to contact me directly if you have non-standards-relevant
issues, to avoid unnecessary traffic on the working group list.

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.
>
> Yes, this is correct.  However, if your transparent proxy acts as a TCP
bytestream forwarder, which seems consistent with your design goals, it
doesn't need to host any certificate at all.

(The SNI Alt-Svc proposal does relax this requirement somewhat: if the
client doesn't get the origin's certificate immediately, it can try again
using Secondary Certificate Authentication.  I think this is not relevant
to your use case.)


> 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>
> <bemasc@google.com> wrote:
>>
>> On Wed, May 23, 2018 at 3:24 PM Lou Steinberg <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
>
>