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

[Stephen Farrell <[e-mail]>]

So I finally had a chance to read this draft.

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.

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

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

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