Re: [TLS] TLS 1.3 draft-07 sneak peek

[Jeffrey Walton <[e-mail]>]

On Tue, Jun 30, 2015 at 6:23 PM, Eric Rescorla <[e-mail]> wrote:
> Folks,
>
> Yesterday, I posted the -06 draft which snapshots the consensus changes
> made since -05, specifically:
>
> - Prohibit RC4 negotiation for backwards compatibility.
> - Freeze & deprecate record layer version field.
> - Update format of signatures with context.
> - Remove explicit IV.
>
I think the record layer parameters need to be cryptographically bound
in the protocol. Without a binding, a bad guy can tamper with the
initial stages of the exchange an make it appear another party is
responsible for the failure. For example, a bad guy can make it
appears a particular protocol version is unsupported by a server. At
minimum, I believe it causes a hard failure in auditing.

In Krawczyk's Cryptographic Extraction and Key Derivation: The HKDF
Scheme (https://eprint.iacr.org/2010/264.pdf), here's what he says
about contextual information like record layer versions (from page 2):

    the latter is an important parameter for the KDF intended to
    include key-related information that needs to be uniquely and
    cryptographically bound to the produced key material (e.g., a
    protocol identi er, identities of principals, timestamps, etc.).

And going back to Wagner and Schneier's Analysis of the SSL 3.0
Protocol (https://www.schneier.com/paper-ssl-revised.pdf), omitting
the record layer versions violates semantic authentication (from page
):

    ... call this the Horton principle" (with apologies to Dr. Seuss)
of semantic
    authentication: roughly speaking

        "we want SSL to authenticate what was meant, not what
        was said."

    To phrase it another way,

        Eschew unauthenticated security-critical context

I know the protocol wants to avoid a hard coupling of the record layer
from the data it carries, but its a security parameter and it needs to
be tended to.

Jeff