TLS 1.2 server

Simon Josefsson simon at josefsson.org
Wed Sep 30 14:08:59 CEST 2009


Daiki Ueno <ueno at unixuser.org> writes:

>>>>>> In <87r5tp56c4.fsf at mocca.josefsson.org> 
>>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
>> What do you think we should do about the CertificateRequest
>> supported_signature_algorithms field?  I think the application may want
>> to look at the server preference when deciding which certificate to use,
>> and GnuTLS may want to use this information internally too, when it is
>> selecting the certificate.
>
> I have thought of something like:
>
> * Provide the following default ordering of algorithms:
>
>   RSA_SHA512(*)
>   RSA_SHA384(*)
>   RSA_SHA256(*)
>   RSA_SHA1(+)
>   DSA_SHA1(+)
>
>   * is only available if RSA certificate is given
>   + is only available if DSA certificate is given

The approach seems OK, but I think the ordering should depend on the
NORMAL vs SECURE vs PERFORMANCE.  For similar reasons GnuTLS prefer
AES-128 over AES-256 (i.e., because of no known attacks and it is
faster), RSA_SHA256 should probably be the default in the NORMAL mode.

Thus NORMAL:

   RSA_SHA256(*)
   RSA_SHA384(*)
   RSA_SHA512(*)
   RSA_SHA1(+)
   DSA_SHA1(+)

And PERFORMANCE:

   RSA_SHA1(+)
   DSA_SHA1(+)
   RSA_SHA256(*)
   RSA_SHA384(*)
   RSA_SHA512(*)

And SECURE:

   RSA_SHA512(*)
   RSA_SHA384(*)
   RSA_SHA256(*)
   RSA_SHA1(+)
   DSA_SHA1(+)

Possibly SHA-1 should not be mentioned in the SECURE mode at all?  The
hash is considered broken even though no practical attacks are known.

> * The application may supply the preference through a priority string
>   like this: "+SIGN_RSA_SHA256:-SIGN_RSA_SHA384:!SIGN_RSA_SHA1", where
>   "+" moves the given algorithm to the top, "-" moves it to the bottom,
>   and "!"  disables it.

Sounds good.  Today ! and - have the same meaning for priority strings
(i.e., remove), but I like your model better.

Clients will probably want to be able to inspect the server's preference
list when it is in the certificate selection callback function.  I think
a new API function is needed to extract the algorithm identifiers.

Implementing the first part (i.e., sending a server side preference
list) is probably the easiest to start with.  Would you like to work on
it?  Once that is working, it will be easier to add the API to return
the algorithm list for clients.  And finally, make GnuTLS automatically
pick the most appropriate client certificate by default if the
application supplied more than one (depending on server side
preference).

/Simon





More information about the Gnutls-devel mailing list