Re: [TLS] Initial draft of DH-based key exchange

The theme of simplification applies to your concerns below too.
The simpler the protocol the closer it stays to its underlying
cryptographic core hence the closer it stays to the cryptographic semantics.
Actually, the issue of simplifying semantics is of utmost importance.

For example, the hierarchical key derivation scheme in TLS 1.3/OPTLS bind
terminal keys (those used for data protection either inside the handshake
or output for record protection) to a unique context encompassing a label
defining the key's functionality and information that ties the key to
particular handshake session (including nonces, negotiated parameters,
identities, etc.). That defines the semantics and provenance of keys which
should be the only thing that consumers of the TLS handshake need to know
about these keys.

One thing to double check when specifying the handshake protocol is that
context and intended semantics match indeed.
(I wonder, for example, if we should label keys derived with PFS from those
derived without PFS.)

Hugo

On Fri, Mar 27, 2015 at 12:17 PM, Ilari Liusvaara <
ilari.liusvaara@elisanet.fi> wrote:

> On Fri, Mar 27, 2015 at 03:27:54PM +0000, Paterson, Kenny wrote:
> >
> > The limitation of scope does not mean the papers are useless. As you
> write
> > above, one just needs to be wary of over-interpreting what they say.
>
> Well, not useless, but...
>
> There are different kinds of problems arising for over-interpreting
> security proofs:
>
> Take some protocol X that is designed to use TLS feature Y for purpose
> Z (e.g. SPDY used TLS-Extractor for channel binding).
>
> This can be outright broken (like the example is in TLS 1.2 without
> extensions).
>
> This calls for documenting limiations of various TLS features. And
> preferably not provoding "attractive nuisances". But that doesn't
> mean the features provoded won't be used in strange ways.
>
>
> More nasty case is if there is a security proof that some strengthening
> A is unnecressary given assumptions B (which seems quite broadly
> applicable).
> Then TLS removes A as "unnecressary". Except that using Y for Z breaks B
> and relies on A, so now X is insecure. This is obviously highly attractive
> for crypto sabotage projects.
>
> E.g. suppose TLS had renego-fix-like fix for resumption. Now remove
> session-hash because it is unnecressary given proper certificate
> authentication. Except now TLS-Extractor for channel binding is broken.
>
> This calls for being conservative with strengthening.
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>