Re: Key Opacity/Identification Issue - Web Cryptography Charter Updated

Hi Tom,

On 12/11/2011 04:37 AM, Tom Ritter wrote:
> On 9 December 2011 11:41, Stephen Farrell<stephen.farrell@cs.tcd.ie>  wrote:
>> [1] http://tools.ietf.org/html/rfc5705
>
> I thought I was on board with you Stephen, but after looking over that
> RFC I'm just not getting it.  I'm a bit tired, but even after
> re-reading it a few times... It seems to just provide a RNG accessible
> on the client and server which uses the master secret as a partial
> input seed.  Which is useful, but not what I was thinking of a priori.
>   How far off am I with that?

That's about it. The point though is that the master secret is
already securely (for whatever value of secure you associate with
TLS) on the other side. There's no need to develop a new key
transport/agreement protocol. That's a major plus, if the TLS
endpoints are already at the right places for doing application
layer crypto.

> Thoughts I had which it definitely isn't:
>
>   - A way to operate on things using the master secret of the
> underlying TLS connection

Right. The API constructed here would have to build on 5705 to
provide an interface for using the TLS derived key to provide
confid. & integ. for an application layer plaintext. Something
like:

    TLSDerivedWrap(appstring, plain, cipher) for the sender
    TLSDerivedUnWrap(appstring, cipher, plain) for the receiver

The appstring would map to the 5705 label input. (Which might
or might not be an identity mapping, dunno.) Thought would be
needed on whether or how to try separate different applications
using the same TLS session. (Probably need to do that in any
case.) Note that if using the TLS extracted key I don't see
there'd be any need to define ways to separately use confid.
& integ. but that'd be one to discuss I guess.

If TLS key extraction isn't suitable for an application then
it does need the usual pkcs#11-like functions and probably
needs to reinvent key transport, but I'd really like if we could
encourage the pattern above.

>   - A way to operate on things using certificates (server and/or
> client) in the underlying connection
>   - A way to expose parameters about the underlying connection to a
> higher-level protocol (e.g. certificates and chain in javascript
> parameters)

The last one there also sounds reasonable. Not sure I get what
"operate on" might mean for the 2nd last one.

Cheers,
S.

>
> The last bullet point I mentioned is something I've been pushing for a
> bit.  Especially coupled w/ signing and verifying javascript libraries
> - you can implement key pinning and a number of interesting CA
> auditing and verification tools if you can read the supplied
> certificate parameters.
>
> -tom
>

Received on Sunday, 11 December 2011 15:26:21 UTC