Re: [TLS] TLS Next Proto negotiation

[Adam Langley <[e-mail]>]

On Thu, Jul 21, 2011 at 6:06 PM, Marsh Ray <[e-mail]> wrote:
> The server needs to see the client's NextProtocol message to know what
> protocol will be in use. But when a session is resumed, the server sends the
> Finished message before the client. Some app protocols have the server send
> the first application data, e.g., "username: ". If such an app protocol is a
> possibility, doesn't the use of NPN introduce an extra round-trip delay in
> case of session resumption?

Yes, NPN precludes the possibility of a server-side False Start.

> Also, since the semantics of NPN apply explicitly to the connection (rather
> than the session or connection state), perhaps the use of NPN ought to be
> contingent on the successful negotiation of RFC 5746 Renegotiation
> Indication. Multiplexing multiple protocols from same server port are likely
> to provide additional opportunities for an attacker to put the server in a
> state where it is willing to accept a renegotiating ClientHello. It will
> also provide more ways for an attacker to have the server echo back chosen
> plaintext to be interpreted as HTTP response headers (or other protocols
> could be attacked).

That sounds quite sensible to me. I'm happy to include such a requirement.


Cheers

AGL