Re: [TLS] comments & clarifications for rfc4507bis

>>>> The description would be unabiguous if 
>>>> the text included a struct along the lines of:
>>>>
>>>>   struct {
>>>>     opaque NewSessionTicket.ticket<1..2^16-1>
>>>>   } SessionTicket;
>>>
>>> The new struct actually reintroduces an issue with encoding that we 
>>> trying to correct with this revision.
>>
>> I'm afraid that l/
or server operators don't understand this stuff to the level
required to make all the right choices.

>> Another issue I've been meaning to bring up is that
>> if you want forward secrecy, you need to use Diffie-
>> Hellman; however, there is no way to tell the server
>> the size of the parameter p you want.  Increasing the
>> size of p has significant performance implications,
>> so servers will typically use 1024 bits.
>> [...] It would be better if those
>> who want to use 4096 bits could ask for it.
> 
> Again, please present some evidence that this is a real
> practical issue outside of a very small population of 
> keylength fetishists.

RSA key exchange provides up to 368 bits of security, but
doesn't provide forward secrecy.  If I want forward secrecy,
then I need to use Diffie-Hellman.  A server that has 1024-
bit Diffie-Hellman parameters only provides me with some-
where in the neighborhood of 70-80 bits of security
(extrapolated from the data in RFC 3526).  You are saying
that I am a "keylength fetishist" because I want better
than 70-80 bits of security?  So I'm allowed either lots
of "strength" *or* forward secrecy, but not both?  That's
irresponsible.

Mike

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls