Re: [TLS] Unifying tickets and sessions

[Joseph Salowey <[e-mail]>]

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).

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.

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.

I want to make sure we have a clear understanding of 1 and 2.

--
> Regards,
> Hubert Kario
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>