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

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.

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.  Can the validator send a misdirected request should this happen?  

Appreciate your help!
Lou



On May 23, 2018 9:54:44 AM EDT, Ben Schwartz <bemasc@google.com> wrote:
>On Tue, May 22, 2018 at 3:10 PM Brzozowski, John Jason <jjmb@jjmb.com>
>wrote:
>>
>> A small group with members who work at Akamai, Bloomberg, Comcast,
>CTM,
>Google, NS1,and  Squarespace self-formed about a year ago to work on a
>solution to high-volume DDoS traffic from IoT devices.  From this
>emerged
>an idea to use tokens, like cookies, that an internet destination could
>issue to change how traffic flows to it from trusted sources (e.g.
>bypassing scrubbing centers, creating a deterministic mechanism and
>eliminating potential delays or loss during attacks).  The mechanism
>selected was designed to work with https traffic over IPv4/6  without
>having to distribute certificates to decrypt.  A variant of the
>mechanism
>for any IPv6 application was defined that leverages SRH, but the
>consensus
>was to prototype our solution for http/s traffic using browser cookies.
> A
>working POC was implemented and tested for both performance and
>resiliency
>at scale.  The group would like to share our work as a potential BCP.
>>
>>
>>
>> We believe that broader input from the community would help to
>produce a
>better solution.  For example, we included an optional ability to use
>IP
>addresses to inhibit replay attacks, though we understand that it
>likely
>won't be desired in dual stack environments with long-lived
>authorization.
>We considered
>https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-01 to
>eliminate
>the need for our redirect mechanism, but were concerned about needing
>certificates to decrypt the contents for intermediate validation and
>didnt
>see a place to assert that a session was authorized for different
>treatment.
>
>I don't claim to have fully understood the draft's logic, but could you
>expand on why Alt-Svc-SNI doesn't work in this case?  It seems to me
>that
>the server could compute an Assertion Token and pass it to the client
>as a
>replacement SNI, and the client would then display that token in the
>SNI,
>labeling its connections until expiration and achieving the intended
>effect.  I don't see why any decryption would be required.
>
>>  We considered TLS client_hello extensions to to not overload the
>SNI/hostname field but were unsure if the browser would have access to
>this
>layer.  While our approach has been demonstrated to work, we are open
>to
>discussing and revisiting any of these.
>>
>>
>>
>> John
>>
>> +1-484-962-0060
>>
>>
>>
>> -----Original Message-----
>>
>> From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
>>
>> Subject: New Version Notification for
>draft-jjmb-httpbis-trusted-traffic-00.txt
>>
>>
>>
>>
>>
>>     A new version of I-D, draft-jjmb-httpbis-trusted-traffic-00.txt
>>
>>     has been successfully submitted by John Jason Brzozowski and
>posted
>to the
>>
>>     IETF repository.
>>
>>
>>
>>     Name:               draft-jjmb-httpbis-trusted-traffic
>>
>>     Revision: 00
>>
>>     Title:                 Trusted Traffic
>>
>>     Document date:  2018-05-22
>>
>>     Group:               Individual Submission
>>
>>     Pages:               12
>>
>>     URL:
>https://www.ietf.org/internet-drafts/draft-jjmb-httpbis-trusted-traffic-00.txt
>>
>>     Status:
>https://datatracker.ietf.org/doc/draft-jjmb-httpbis-trusted-traffic/
>>
>>     Htmlized:
>https://tools.ietf.org/html/draft-jjmb-httpbis-trusted-traffic-00
>>
>>     Htmlized:
>https://datatracker.ietf.org/doc/html/draft-jjmb-httpbis-trusted-traffic
>>
>>
>>
>>
>>
>>     Abstract:
>>
>>        Current methods for managing traffic through content
>inspection
>tend
>>
>>        to process all sessions similarly.  Internet traffic examples
>like
>>
>>        DDoS mitigation require all data to pass through one of a
>limited
>>
>>        number of scrubbing centers, which create both natural choke
>points
>>
>>        and the potential for widespread collateral damage should a
>center
>>
>>        become overloaded.  Similar issues exist with email SPAM and
>malware
>>
>>        filtering, traffic shaping, etc.  We propose a method to
>utilize
>>
>>        existing HTTP and HTTPS protocols that enables destinations to
>>
>>        temporarily confer trust on sources, and for trusted traffic
>to be
>>
>>        routed and processed differently from untrusted traffic.
>>
>>
>>
>>
>
>>
>>
>>
>>
>>
>>     Please note that it may take a couple of minutes from the time of
>submission
>>
>>     until the htmlized version and diff are available at
>tools.ietf.org.
>>
>>
>>
>>     The IETF Secretariat
>>
>>
>>
>>

-- 
Lou Steinberg 
Managing Partner 
CTM Insights, llc

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