Re: Fwd: New Version Notification for draft-snell-httpbis-keynego-01.txt

[James M Snell <[e-mail]>]

On Sat, Nov 23, 2013 at 1:50 PM, Stephen Farrell
<[e-mail]> wrote:
>
> So I finally had a chance to read this draft.
>

Appreciate you taking a look...

> I think the ideas are interesting, and it'd be good if HTTP/2.0
> was extensible so that future work in this direction could be
> explored. Perhaps if the WG do work on supporting proxies, then
> room for this as an extension to that could be found.
>
> However, today, this is nowhere near ready to be put up as an
> alternative to TLS in any respect. Its not even in the ballpark.
>

To be certain, providing a replacement for TLS is certainly not the
intent this early in the game. At this point, this is an experiment
only.

> I figure by the time this got properly worked out, (in maybe a
> year or more) it'd be very like GSS-API without the API, but
> probably as complex. Now that might be interesting actually and
> maybe we could do GSS-API context token handling better this
> time around. Or maybe we wouldn't.
>
> I'm also quite unsure how the server side of this would work.
> With whom would the browser be negotiating? The web server or
> some web application? That wasn't clear to me and might make
> a big difference in terms of trust models, how the web-origin
> plays into the game and in terms of the liklihood of server
> side deployment happening.
>

The negotiation is with the origin... whatever that means. Typically,
that would imply that it's handled by the web server.

> The "algorithm" header field seems to have the same benefits
> and pitfalls as TLS ciphersuites, but goes beyond that to also
> codify the handshake protocol and the security framing. I think
> I kinda like that, and would go further and let that also
> determine if some header-field values are also input to the
> security framing. (E.g. the web-origin could be input to any
> MAC calculation for some "algorithm" header field values.)
> There's fun to be had there.
>

Yes, indeed. There are quite a few possibilities. The more exotic we
get, here, however, the more unanswered questions there are. Fun yes,
but could be quite complicated.

> The security properties of the framing are not even defined yet.
> I guess it'd be something like ESP or the TLS application data
> protocol, but the algorithm thing above means that those can
> vary by algorithm. I'm not sure if that's a good plan since it'd
> mean that you have to understand each algorithm to understand
> the security properties of payloads. In other words, there could
> be value in flexibility in terms of how you negotiate a session
> key, but not in the security framing for payloads. One to
>

The more I look at it, I think I agree. Having a defined structure for
secured DATA frame payloads would be the best approach. The one
drawback is that DATA frames used for HTTP traffic are limited to a
particular size... I want to try avoiding using too much of that up on
security overhead.

- James

> Anyway, I do think this might be an interesting near-term
> research thing to try play with and if the WG's solution for
> better proxy support looked a bit like this, then that would
> be good since it'd allow future experimentation along these
> lines.
>
> But this just ain't a replacement for TLS.
>
> IMO the WG should do what folks in Vancouver said: get more TLS
> used in HTTP/2.0. I'd prefer that be done via the http:// URI
> sent on top of opportunistic TLS plan with no new user i/f, but
> would also be ok (while a bit skeptical) with the plan Mark
> proposed last week to get more server-auth TLS. I do think
> either would be better done as an integral part of the spec.
>
> Cheers,
> S.
>
> PS: I hope I don't re-ignite the browser/proxy/tls battle
> again. Maybe if I say "VP8 or H.264?" that'll distract those
> who like such arguments;-)
>
> On 11/19/2013 09:13 PM, James M Snell wrote:
>> At Mark's urging, I've posted a significantly updated draft of the
>> "in-session key negotiation" draft that I had published last year.
>> Please treat this as purely experimental at this point. I am not
>> pushing this as a proposal just yet, just offering it up as one
>> possible approach to providing message-level security as opposed to
>> transport-level security. What this proposal does, in effect, is make
>> it possible to negotiate and use cryptographic keys from *inside* an
>> HTTP/2 connection as opposed to the TLS approach. A key benefit of
>> this approach is that it allows peers to establish secure
>> communication even over potentially insecure transports. Of course,
>> it's not a perfect solution.
>>
>> As always, feedback is welcomed and requested.
>>
>> - James
>>
>>
>> ---------- Forwarded message ----------
>> From:  <[e-mail]>
>> Date: Tue, Nov 19, 2013 at 1:08 PM
>> Subject: New Version Notification for draft-snell-httpbis-keynego-01.txt
>> To: "James M. Snell" <[e-mail]>
>>
>>
>>
>> A new version of I-D, draft-snell-httpbis-keynego-01.txt
>> has been successfully submitted by James M Snell and posted to the
>> IETF repository.
>>
>> Filename:        draft-snell-httpbis-keynego
>> Revision:        01
>> Title:           HTTP/2.0 Intra-Connection Negotiation
>> Creation date:   2013-11-19
>> Group:           Individual Submission
>> Number of pages: 6
>> URL:
>> http://www.ietf.org/internet-drafts/draft-snell-httpbis-keynego-01.txt
>> Status:          http://datatracker.ietf.org/doc/draft-snell-httpbis-keynego
>> Htmlized:        http://tools.ietf.org/html/draft-snell-httpbis-keynego-01
>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-snell-httpbis-keynego-01
>>
>> Abstract:
>>    This memo describes a proposed modification to HTTP/2.0 that
>>    introduces the concepts of Intra-Connection Negotiation and Secure
>>    Framing.
>>
>>
>>
>>
>> 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
>>
>>