Subject: support for sni-altsvc deadt

From: Lou Steinberg <[email-masked]>
Date: Sat, 7 Jul 2018 19:34:20 -0400

Hi Folks-

We want to offer a quick update and note of support for SNI alt services 
in advance of the Montreal meeting.

A group of tech leaders from Akamai, Bloomberg, Comcast, CTM (formerly 
TD Ameritrade), Google, NS1, and Squarespace have been working on a 
method to create short-lived, pairwise trust relationships between 
clients and destinations.  A number of us have dealt with large-scale 
DDoS attacks, and we believe that this approach has significant benefits 
in mitigating their impact.  We built a proof of concept and tested the 
effectiveness, performance and resiliency of our ideas.  We then 
documented and submitted draft-jjmb-httpbis-trusted-traffic-00.txt​ to 
share with the broader community.

Some of the feedback received pointed us to SNI Alternative Services 
(draft-bishop-httpbis-sni-altsvc-02) as another way to implement the 
distribution and assertion of our tokens.  We have since successfully 
tested Alternative Services (RFC7838) as a mechanism to distribute a 
token from an origin and to redirect the client to a transparent proxy 
in front of the origin that serves as one of our edge "validators". We 
intend to publish an implementation report draft describing our experiences.

We believe that the "SNI" parameter in sni-altsvc provides a good 
mechanism in our model for a client to assert to a validator that it is 
trusted, and would like to offer our support for continued consideration 
and advancement of that draft.

We assume this group is interested in real-world use cases and 
expressions of support for in-flight drafts.

Thanks!

Lou Steinberg
John Brzozowski

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

---

From: Erik Nygren <[email-masked]>
Date: Sun, 15 Jul 2018 17:11:56 -0400

Closely related and worth looking at is the ESNI draft:

    https://tools.ietf.org/html/draft-rescorla-tls-esni-00

which is in an early stage of its life.  While the current draft proposes
putting the public key
in the DNS, one could also see putting it in an Alt-Svc record attribute.
It also alludes to being able to encrypt additional attributes, and the
Trust Token
would be a great thing to include under that encrypted cover from a privacy
perspective.

It's "Split Mode Topology" is very much inline with what you're considering
for the trusted traffic forwarder.

Best, Erik

On Sat, Jul 7, 2018 at 7:34 PM, Lou Steinberg <[email-masked]> wrote:

> A group of tech leaders from Akamai, Bloomberg, Comcast, CTM (formerly TD
> Ameritrade), Google, NS1, and Squarespace have been working on a method to
> create short-lived, pairwise trust relationships between clients and
> destinations.  A number of us have dealt with large-scale DDoS attacks, and
> we believe that this approach has significant benefits in mitigating their
> impact.  We built a proof of concept and tested the effectiveness,
> performance and resiliency of our ideas.  We then documented and submitted
> draft-jjmb-httpbis-trusted-traffic-00.txt​ to share with the broader
> community.
>
> tested Alternative Services (RFC7838) as a mechanism to distribute a token
> from an origin and to redirect the client to a transparent proxy in front
> of the origin that serves as one of our edge "validators". We intend to
> publish an implementation report draft describing our experiences.
>
> We assume this group is interested in real-world use cases and expressions
> of support for in-flight drafts.
>
> Thanks!
>
> Lou Steinberg
> John Brzozowski
>
> --
> ---
> Lou Steinberg
> Managing Partner
> CTM Insights, llc
>
>
>

---

From: Lou Steinberg <[email-masked]>
Date: Sun, 15 Jul 2018 21:13:36 -0400

Thanks, Erik.  We've had a little discussion about ESNI as well.  I need to understand it better to see how this works without burdening the validator with managing decryption keys

Best
Lou

On July 15, 2018 5:11:56 PM EDT, Erik Nygren <[email-masked]> wrote:
>token

-- 
Lou Steinberg 
Managing Partner 
CTM Insights, llc

Sent from my phone while not driving. Please excuse typos and brevity.