Re: [TLS] Unifying tickets and sessions

[Hubert Kario <[e-mail]>]

On Friday 24 October 2014 09:58:54 Joseph Salowey wrote:
> On Fri, Oct 24, 2014 at 3:50 AM, Hubert Kario <[e-mail]> wrote:
> > On Thursday 23 October 2014 19:21:08 Richard Fussenegger wrote:
> > > On 10/23/2014 4:03 PM, Hubert Kario wrote:
> > > > While it may negotiate AES-256 (because it wants to interoperate with
> > > > clients that are configured to not to present weaker ciphers), doesn't
> > > > mean that it as a whole is configured to the 256 bit level of
> > > > security. With TLS1.2 it may sign the (EC)DHE parameters using SHA-1,
> > > > it may use RSA key exchange using only 2048 bit keys, it may be just a
> > > > local proxy server that is hard coded to connect using AES-128 with
> > > > the backed servers over open Internet. Yes, server should encrypt the
> > > > tickets with as strong algorithm as its most secure cipher, but there
> > > > are many situations where it's not necessary. "MUST" is certainly not
> > > > applicable.
> > > 
> > > Those are good and valid arguments for a RECOMMENDED regarding session
> > > ticket/token key algorithms or simply dropping one word and uppercasing
> > 
> > > another does the trick (?):
> > yes, I agree.
> > 
> > > https://tools.ietf.org/html/rfc5077#section-5.5
> > > 
> > > >    o  The keys and cryptographic protection algorithms should be at
> > > >    
> > > >       least 128 bits in strength.  Some ciphersuites and applications
> > > > 
> > > > -     may require cryptographic protection greater than 128 bits in
> > > > +     REQUIRE cryptographic protection greater than 128 bits in
> > > > 
> > > >       strength.
> > > 
> > > But the MUST regarding key rotation, key discarding, and key count hard
> > > limits is still appropriate in my opinion because PFS is a MUST in TLS
> > > 1.3 (unless this has changed and I didn't read about it).
> > 
> > Yes, while a large key size is recommended ("SHOULD"), a frequent key
> > rotation
> > (in order of days) is a "MUST" with shorter time scales recommended, given
> > other parts of TLS 1.3.
> 
> [Joe] Personally, I don't think that PFS is a MUST for session resumption.
>   I think an implementation can attempt to provide PFS like behavior, but
> if one is really interested in PFS I think the full handshake is the way to
> go.
> 
> I'm a bit concerned that we're going down the path of trying to mandate a
> particular implementation.  I think we have the following areas under
> discussion:
> 
> 1.  Hard RFC 2119 requirements for things that are verifiable.  For
> example, perhaps you would want to make sure that the client could request
> the server issue a new ticket (the client can actually verify that the
> ticket is different).

We already have ticket lifetime hints and basically nobody sets them higher 
than 48h (>99%), vast majority limit to 24h(>96%)[1]. That's including servers 
that don't use tickets at all! Of servers that do enable tickets, over 70% 
leave them at a 300s default. Nearly half of servers don't enable them at all.

That clearly means that server administrators don't consider renegotiation of 
clients that connect less often than once a day to be a burden on servers...

> 2.  Strong guidelines for the ticket and key management.  RFC 5077 has some
> of these, they can be improved upon.  These would not necessarily be RFC
> 2119 language.

...so if the actual use agrees with theory, nearly no one will be negatively 
impacted if all the frameworks actually started to enforce those limits (not 
that I think this should, let alone will happen). As such, I don't see why we 
shouldn't use the RFC 2119 language.
 
> 3.  Implementation guidance for ticket and key management.  Again RFC 5077
> has some of this, but it can be improved upon.
> 
> I think we should be focusing first on 1 because it is normative and
> affects interop.  2 is also important, but it should not force a particular
> implementation.   3 is useful, but I do not think it should be normative
> and I think it may be difficult to come to consensus on what the guidance
> should be.  A discussion on 3 may help us with 1 and 2, but I think its a
> secondary part of the discussion.

As it was pointed out, proper key management of server is non-verifiable by 
client, it may only be verified by auditing. Definite language there does 
help.

 1 - https://securitypitfalls.wordpress.com/2014/09/29/scan-results-for-september-2014/

-- 
Regards,
Hubert Kario