Re: [TLS] Triple Handshake Fix.

On Wed, Apr 30, 2014 at 2:15 PM, Bodo Moeller <bmoeller@acm.org> wrote
>
>  <http://www.ietf.org/id/draft-bhargavan-tls-session-hash-00.txt>
>>
> Thanks, but haven't we seen that this alone doesn't actually fix the
> problem?  I think we'll need a requirement for clients and servers
> implementing this spec to do one of the following, because an attacker
> can't be expected to opt in to extended master secrets in its handshakes:
>
> (1) If the current session does not use an extended master secret, don't
> allow renegotiation.
>
> (2) If a session does not use an extended master secret, don't allow it to
> be resumed.
>

I agree that the first approach is probably more palatable for legacy
applications. We should require no-renegotiation, and strongly recommend
that application not use channel bindings or exported TLS keys (or PRFs) in
this case.

>
> Approach 2 arguably is cleaner, but since it would entirely prevent
> session resumption between updated implementations and legacy
> implementations, it's probably not viable to roll out immediately.  Maybe
> for servers you'd initially want to pick either approach 1 or approach 2
> depending on the particular needs (whether renegotiation is needed at all),
> while clients initially could allow *both* renegotiation and resumption for
> new sessions, where whichever comes first for a given session would
> disallow the other.  Eventually, once support for extended master secrets
> is reasonably widespread, everyone should switch to approach 2.
>
> Bodo
>
>
>
>
>
>
> I think this is still missing a requirement for clients and servers that
> implement the fixed
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>