Re: [TLS] Fwd: I-D Action:draft-bmoeller-tls-falsestart-00.txt

[Adam Langley <[e-mail]>]

On Wed, Jun 2, 2010 at 2:55 PM, Marsh Ray <[e-mail]> wrote:
> 1. This proposal scares me. Wasn't the Finished message added in
> response to vulnerabilities in SSLv2? Doesn't this sort of, umm, undo
> that for initial data from the client? It bears repeating that in TLS
> usage for a secure web application that first transmission from the
> client to the server would be expected to contain the session cookie,
> perhaps even the full plaintext credentials for a form-based login. The
> entire security model of web apps is based on the inability of the
> attacker to decrypt this.

Agreed that the first request from the client to the server is very
sensitive. If someone finds a way to decrypt this because of False
Start then that's a fatal flaw.

> 2. Couldn't a similar optimization be achieved without protocol changes
> by simply implementing session resumption more robustly? Session
> resumption also takes things like cert chain validation and revocation
> checking out of the critical path of the handshake but this proposal
> still depends on it.

Can you expand on 'robustly'? We cannot store session information on
disk which limits its applicability. Although we'll always try
resumption when we can.

It's true that cert chain revocation is still in play here. OCSP
multi-stapling will hopefully address that.

> Last I checked this included IE, Chrome, and everyone else that used
> Schannel on MS Windows.

Chrome no longer uses SChannel on Windows in the latest development
channel builds (and False Start is enabled in these development
releases).

> But the server's Finished message will not have been validated by the
> client, so the security analysis for the RI fix must start over with the
> expectation that the client cannot trust the presence or absence of an
> RI extension. If the client didn't ever have to trust it, then why did
> we send it in the server-to-client direction anyway?
>
> AFAICT, RI is the only TLS extension that's presence is mandatory for
> security purposes. But other extensions affect the handshake somehow or
> else they wouldn't be sent, and how much of TLS really doesn't affect
> security somehow? E.g. SNI? Seems like everything must be re-analyzed
> from scratch if we are to be safe sending confidential data before fully
> validating the server.

I agree that careful thought is required for this change. At this
point several people have considered it and not found any issues save
for the ones enumerated in the draft.



Cheers

AGL