Re: [TLS] Review of PR #209

I should add: I do think this general line of consolidating all the client
auth modes is a good idea, assuming we can work out the details.

-Ekr

On Wed, Sep 16, 2015 at 11:18 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> I think the potential issue here is needing a way for the server to tell
> the
> client "don't bother sending me data until you've authenticated" (though,
> as MT says, you could argue that the client's signature retroactively
> authenticates, which does seem like the simplest way to think about
> things).
>
> One might imagine dealing with that by a simple signal in a ServerHello
> extension that said "authentication will be required, sit tight..."
>
> -Ekr
>
>
> On Wed, Sep 16, 2015 at 11:11 AM, Andrei Popov <Andrei.Popov@microsoft.com
> > wrote:
>
>> Martin's point makes sense to me: applications that need to do
>> authentication upfront can still do that immediately after the handshake.
>>
>> Cheers,
>>
>> Andrei
>>
>> -----Original Message-----
>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>> Sent: Wednesday, September 16, 2015 10:48 AM
>> To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
>> Cc: Andrei Popov <Andrei.Popov@microsoft.com>; tls@ietf.org
>> Subject: Re: [TLS] Review of PR #209
>>
>> On 16 September 2015 at 08:30, Ilari Liusvaara <
>> ilari.liusvaara@elisanet.fi> wrote:
>> > Problem with pulling client auth out of the handshake is that it
>> > complicates applications that can't change identities involved with
>> > active connection.
>>
>> Why would that be unsupported here?  The server can still send
>> CertificateRequest immediately after its Finished.  That looks exactly like
>> it does today, only the order has changed.
>>
>> > As then the application needs to ensure that the authentication occurs
>> > between TLS handshake and actually starting up the protocol.
>>
>> I'm not sure that is necessarily a problem.  If the claim is that the
>> authentication attests to everything prior to its appearance, then you have
>> no problem.  I think that claim is reasonable, but I'm happy to discuss it.
>>
>> >> 2. The client can send Certificate and CertificateVerify at any time
>> >> application data is permitted, regardless of whether the server had
>> >> previously sent CertificateRequest.
>> >
>> > CertificateRequest contains the permitted signature algorithms for the
>> > PoP signature, which TLS library needs to verify before dumping the
>> > certificate chain on application (which can then figure out things
>> > like trust anchors).
>> >
>> > Without CertificateRequest, one has little idea what algorithms are
>> > acceptable there.
>>
>> Arguably, signature_algorithms covers that adequately.  Though I'll grant
>> that certificate chain validation often happens in a separate component to
>> the TLS stuff.
>>
>> > Basically, one must clear the pipeline before changing identities, and
>> > with protocols like HTTP/2, this is extremely expensive (seemingly
>> > even more expensive than establishing a new connecion).
>>
>> There's been some confusion about this with HTTP/2.  I think that if you
>> adopt the position that authentication applies to the entire session - even
>> retroactively - then the only remaining concern is the correlation one.  If
>> you have three tabs to the site open where all of them are making requests
>> and you see a certificate request, which one do you pop the dialog on?
>>
>> > Also, it should sign the certificate, to avoid possible weirdness due
>> > to signatures not properly binding the key (some schemes do, most
>> > don't).
>>
>> I agree with this.
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>