Re: [TLS] Summary of discussion regarding spontaneuous authentication

[Martin Thomson <[e-mail]>]

On 22 October 2014 07:31, Watson Ladd <[e-mail]> wrote:
>> The primary concern was that the properties of the connection were
>> considered to change with respect to authentication.  Any data
>> received before the authentication, or messages that appear partially
>> before and partially after would have ambiguous properties.
>
> Why is the proposal worse than fixed renegotiation in this regard? I
> agree, it's possible to simplify a lot by forcing reconnection to
> authenticate, but it isn't necessary to do so.

The concern wasn't that it was worse than renegotiation: the opposite
in fact because fewer things change.

The concern was that it wasn't appreciably better with respect to the
state of authentication.  And it was more complicated.


>> I noted that the use case that renegotiation provides was not going to
>> be supported with the proposed Update message, since there was no
>> analogue for the HelloRequest message.
>
> As far as I can tell, not true with regard to HTTP. I believe (but may
> be wrong) that when a client is informed by a server it needs to
> authenticate to make a request, that this is done by an error code,
> not sending a HelloRequest message.

That is only a proposal (my -cant thing).  The way this works in
servers today, in TLS 1.2 and earlier is that servers see the request,
identify the need for client authentication and send a HelloRequest.
Once the renegotiation handshake completes and the client has provided
valid credentials, the server sends the response.  In effect, the
authentication is invisible at the HTTP layer, where -cant proposes to
make this explicit.