Re: [TLS] CertficateRequest extension encoding

[Nick Sullivan <[e-mail]>]

Signature algorithm support is typically per-connection, not per
certificate request. If you're doing multiple post-handshake
authentications then (2) reduces the amount of redundant data sent on
subsequent authentications. Furthermore, it opens the door for unsolicited
post-handshake authentication in future extensions to the protocol.

Clients only need to stash a copy of it if they support client
authentication, which in my opinion should be optional. Perhaps support for
post-handshake authentication should be signaled with an extension. That
way the server SignatureSchemes could be carried in that extension, rather
than overloading the "signature_algorithms" extension.




On Fri, Sep 23, 2016 at 5:56 PM David Benjamin <[e-mail]>
wrote:

> (1) seems reasonable. I don't have strong views there. I even jokingly
> suggested it in the PR description.
>
> I do not like (2). This requires implementations stash a copy of the
> signature algorithms without known a priori whether it will be used or not.
> And it means when receiving a CertificateRequest, you have to go check that
> the extension was provided at all. I think that should stay bound to the
> CertificateRequest and as a required field.
>
> On Fri, Sep 23, 2016 at 8:35 PM Nick Sullivan <[e-mail]>
> wrote:
>
>> David,
>>
>> If we're changing this structure of CertificateRequest, I have two
>> suggestions.
>>
>> 1) Move DistinguishedName out of the structure and define it as a
>> TLS-style extension. It's not a required field.
>> 2) Remove SignatureScheme from structure, and instead change the behavior
>> of the the "signature_algorithms" extension to include all server-supported
>> SignatureSchemes in the ServerHello in descending order of preference.
>>
>> This will result in a much more compact message structure that can easily
>> be re-purposed for post-handshake server auth and other optional extensions
>> to TLS 1.3:
>>
>>      struct {
>>          opaque certificate_request_context<1..2^8-1>;
>>          CertificateRequestExtension certificate_extensions<0..2^16-1>;
>>      } CertificateRequest;
>>
>>
>> Nick
>>
>>
>> On Thu, Sep 22, 2016 at 6:26 PM David Benjamin <[e-mail]>
>> wrote:
>>
>>> On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov <[e-mail]>
>>> wrote:
>>>
>>>> > But it's OID-specific how the matching works, isn't it?
>>>> Correct, and initially we define matching for KU and EKU. These are the
>>>> OIDs I've got the most customer requests for. I expect that we will want to
>>>> define matching rules for other OIDs over time, in separate specs. This new
>>>> proposal allows multiple sets of matching rules for each OID, which
>>>> certainly increases flexibility.
>>>>
>>>> David, do you care enough to write your proposal down as a PR, so that
>>>> we can discuss the specifics?
>>>>
>>>
>>> Apologies for the delay. Been a busy few weeks. This is roughly what I
>>> was thinking:
>>> https://github.com/tlswg/tls13-spec/pull/656
>>>
>>> What do you think?
>>>
>>> Again, I don't actually care about this, so if you and others who would
>>> use this mechanism prefer it as it is, I have no qualms. This is a "pull
>>> suggestion", not a "pull request". :-)
>>>
>>> David
>>>
>>>
>>>> Thanks,
>>>>
>>>> Andrei
>>>>
>>>> -----Original Message-----
>>>> From: Anders Rundgren [mailto:[e-mail]]
>>>> Sent: Tuesday, September 6, 2016 8:36 AM
>>>> To: Peter Gutmann <[e-mail]>; David Benjamin <
>>>> [e-mail]>; Andrei Popov <[e-mail]>;
>>>> Ilari Liusvaara <[e-mail]>; [e-mail]
>>>> Subject: Re: [TLS] CertficateRequest extension encoding
>>>>
>>>> On 2016-09-06 16:15, Peter Gutmann wrote:
>>>> > David Benjamin <[e-mail]> writes:
>>>> >
>>>> >> Either way I imagine our stack will just keep on ignoring it, so I
>>>> >> don't feel about this all too strongly. But the topic came up so I
>>>> >> thought I'd suggest this.
>>>> >
>>>> > I ignore it too.  Client certs are so rare, and so painful to deploy,
>>>> > that I'm not going to make things harder on users by adding complex
>>>> > and opaque filtering to prevent them from working.  My approach is to
>>>> > specify as few constraints as possible, the client submits whatever
>>>> > certificate it has, and it's then decided based on a whitelist for
>>>> > which the server can very clearly report "not on the whitelist" when
>>>> > it rejects it.  The design seems to be based on the idea that each
>>>> > client has a smorgasbord of certs and the server can specify in
>>>> > precise detail in advance which one it wants, when in reality each
>>>> > client has approximately zero certs, and the few that do have one
>>>> just want the one they've got to work.
>>>>
>>>> May I add some nuances here?
>>>>
>>>> Client-certificates are *extensively* used for secure box-to-box
>>>> communication.
>>>> Existing selection methods suffice (there's usually none on the client
>>>> side).
>>>>
>>>> Client-certificates for user authentication on the Web through HTTPS is
>>>> a small and diminishing activity. The decision by the browser vendors
>>>> dropping support for on-line enrollment is likely to further limit this use
>>>> case which make improvements in selection/filtering pretty uninteresting.
>>>>
>>>> Client-certificates for user authentication on the Web through through
>>>> proprietary ("FIDO like") application level protocols is fairly big.  Half
>>>> of the Swedish population use such a scheme for e-government and bank
>>>> access.  It uses an ugly (and non-secure) OOB-method to make it "Web
>>>> compatible".  This use-case is (of course) not of an issue for the TLS WG
>>>> but may be of some interest for people currently using client certificates
>>>> for Web authentication.
>>>>
>>>> Anders
>>>>
>>>>
>>>> >
>>>> > Peter.
>>>> > _______________________________________________
>>>> > TLS mailing list
>>>> > [e-mail]
>>>> > https://www.ietf.org/mailman/listinfo/tls
>>>> >
>>>>
>>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>