Re: Please don't re-write TLS (Was: HTTP/2.0 -04 candidate)

I should add that this RFC I mentioned is problematic as there are IPR claims. 

Yoav

On Jul 3, 2013, at 5:43 PM, "Ludin, Stephen" <sludin@akamai.com> wrote:

> Zero intention of doing so. The "rewrite TLS" comment was there simply to
> point out how far afield the idea was going.  For the record, I am open to
> most any ideas but my goal was not to suggest we tweak TLS but more to
> point out a potential direction to spur more conversation.  Will and
> Roberto handily redirected the conversation to the experimental SPDY world.
> 
> Thanks for the pointer to the RFC and the other suggestions!
> 
> -stephen  
> 
> On 7/3/13 12:33 AM, "Yoav Nir" <ynir@checkpoint.com> wrote:
> 
>> 
>> On Jul 3, 2013, at 3:02 AM, "Ludin, Stephen" <sludin@akamai.com> wrote:
>> 
>>> Here is an idea to chew on.  It has been discussed before, but if there
>>> was a concept of returning multiple certs in the ServerHello which
>>> indicate other common names the origin is authorized to serve I tight
>>> provide a path forward to serving related content from those domains.
>>> For
>>> example, if the origin serves an html response on domain1.com which has
>>> references to objects on otherdomain.com AND the origin has a valid
>>> certificate for otherdomain.com it has a mechanism to 'prove' to the
>>> client that it is authorized to push that content.
>>> 
>>> At this point I am rewriting TLS as well as getting far from the
>>> original
>>> subject.  Probably best to continue in a fresh thread if there is
>>> interest.
>> 
>> Hi Stephen.
>> 
>> This is authorization at the HTTP level. I don't think this should go in
>> TLS just because TLS has a mechanism for showing certificates. Also if
>> you do want it to go in TLS, there's an RFC for that:
>> http://tools.ietf.org/html/rfc5878 . This allows for sending arbitrary
>> authorization information.
>> 
>> Alternatively, you could add this in HTTP as a header or as a new frame
>> type.
>> 
>> Yoav

Received on Wednesday, 3 July 2013 20:50:53 UTC