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

On Tue, Nov 19, 2013 at 5:33 PM, Roberto Peon <grmocg@gmail.com> wrote:
> More of a nightmare than a challenge, but such is UI, and I thank my lucky
> stars to not have to deal with it right now!
>

That's why I'm definitely *not* a UI developer ;-)

> Being able to run a handshake in parallel with whatever else can only happen
> when one doesn't need or want the integrity handshake, which is necessary
> for detecting a malicious filtering MITM (and yes one can never *prevent*
> such, but detection is quite important).

One of the key design goals for this draft was to allow for
experimentation with a variety of approaches. One could, for instance,
perform an initial "quick" negotiation for integrity to get the ball
rolling, then later on (in parallel to less-important activity)
perform much more expensive negotiation for the more important stuff.
This approach also makes it possible to protect individual streams at
different levels, depending on need and sensitivity. If you wanted to
get fancy, you could even separately protect each direction of a
stream (i.e. each direction using a different negotiated key).

Also, keep in the mind the CONNECT tunnel option. One could negotiate
an agreement and use that along with a CONNECT tunnel. Once that's
done, any traffic that passes back and forth within that tunnel would
be protected, limiting potential leakage. If we add incremental
integrity checking to the picture, this becomes more reliable (albeit
more complex as well).

The bottom line is that there are a ton of possibilities with this
approach. Unfortunately, there are also likely quite a few drawbacks
and a potentially high amount of additional complexity. If we decide
to trudge down this path, it's going to require a significant amount
of research and verification.

- James


> -=R
>
>
> On Tue, Nov 19, 2013 at 5:23 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>
> wrote:
>>
>> In message
>> <CAP+FsNcNtdo9amaboDDDWbMGz47DgCed6q-BS_zLB275Y_MN4w@mail.gmail.com>
>> , Roberto Peon writes:
>>
>> >Exposing the framing/length of things that would be in an
>> >encrypted-by-TLS bytestream today, however, does worry me--
>> >it makes BEAST/CRIME-like attacks significantly more difficult
>> >to protect against.
>>
>> Absolutely.
>>
>> And there is no doubt either that there is an UI challenge in
>> communicating the security situation, if the various elements you
>> see are protected to different levels and degrees.
>>
>> But there are also many benefits, for instance being able to
>> run the crypto-handshake in parallel with delivery of the first
>> unprotected page elements, rather than stall everything until TLS
>> has gotten its bits sorted out.
>>
>>
>> --
>> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>> phk@FreeBSD.ORG         | TCP/IP since RFC 956
>> FreeBSD committer       | BSD since 4.3-tahoe
>> Never attribute to malice what can adequately be explained by
>> incompetence.
>
>

Received on Wednesday, 20 November 2013 01:53:45 UTC