[PATCH] session ticket support

[Simon Josefsson]

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On Tue, Aug 4, 2009 at 3:15 PM, Simon Josefsson<simon at josefsson.org> wrote:
>
>> Also the above API hard-codes the use of AES-128 + HMAC-SHA-256 which
>> won't be good choices forever.  How about changing the randomize
>> function into:
>>
>>  int gnutls_session_ticket_key_randomize (gnutls_session_ticket_key_t,
>>                                          gnutls_cipher_algorithm_t cipher,
>>                                          gnutls_mac_algorithm_t mac);
>
> Indeed the rename will make things more clear. However
> this might not be proper place to make the algorithms flexible since
> the allocation has been done before and had
> no knowledge of the required key sizes. Those options could have been
> in the allocation part.

Good point.  Let's ignore my suggestion.  We can always add new APIs to
generate particular keys later on if there is a need.

>> I see that some struct sizes in the RFC (like IV and MAC size) are hard
>> coded, so it may not be worth time to extrapolate that part to support
>> non-AES-128/HMAC-SHA-256 options.  So
>> gnutls_session_ticket_key_randomize could return an error if other
>> choices than AES-128/HMAC-SHA-256 are used.  This means the API is ready
>> if RFC 5077bis defines support for HMAC-SHA-3 or similar.
>
> I am not really sure about the flexibility here. If a new rfc mandates
> some different algorithms would we
> expect the application need the change those? I would expect gnutls
> should have done it implicitely. Anyway I
> don't think is bad since many people would want to use AES-256 and
> hmac with 512 etc etc... If we add it we could do
> it with a different function that accepts additional parameters such
> as gnutls_session_ticket_key_allocate2(z,x,y ) and leave a simple
> allocate(x) that will set the defaults?

I agree.

/Simon