[TLS] Comments on draft-salowey-tls-rfc4507bis-01.txt

["Wan-Teh Chang" <[e-mail]>]

I am helping Nagendra Modadugu implement the TLS SessionTicket extension
in NSS.  I have some comments and questions on the current Internet-Draft
draft-salowey-tls-rfc4507bis-01.txt.

I. Page 5 and page 6 jump back and forth between abbreviated handshakes
(session resumption) and full handshakes, so it was hard to follow the
description at first.  I suggest a better order of presentation below.

Page 5, third paragraph:

"If the server cannot or does not want to honor the ticket, then it
can initiate a full handshake with the client."

I suggest adding "in one of two ways" at the end of this sentence,
to announce to the readers that the next two paragraphs describe the
two ways of performing a full handshake after a server rejects a ticket.

Page 6, first paragraph:

The first sentence of this paragraph says:
"It is also permissible to have an exchange similar to Figure 3 using
the abbreviated handshake defined in Figure 2 of RFC 4346 ..."

Should "Figure 3" be changed to "Figure 2"?

This paragraph is in the wrong place.  It describes an abbreviated
handshake.  It should be moved right after Figure 2.

It would be nice to add a message flow for this paragraph.

Page 6, second paragraph:

Change "Client Hello" to "ClientHello".

Note: If you reorder the paragraphs as I suggested, you need to rework
the text to make the transition smooth.  Please let me know if you don't
understand my suggestion.

II. Page 8, first paragraph:

"....  If the ticket is accepted by the server
but the handshake fails, the client SHOULD delete the ticket."

I assume the client should also delete the cached master secret?

III. Page 8, last paragraph:

I assume the ticket_lifetime_hint field contains a relative time
(time interval) rather than an absolute time (time instant), right?
(Nagendra also asked about this in his comments.)

IV. Issues with the recommended ticket construction.

There are two issues: the 128-bit security level, and the need to have
the master secret in plaintext form.

Page 10, second paragraph:

"The server uses two different keys: one 128-bit key for AES [AES] in
CBC mode [CBC] encryption and one 256-bit key for HMAC-SHA-256
[RFC4634]."

Can we use a 128-bit key for HMAC-SHA-256?  Even FIPS 198 requires only
a 128-bit key for HMAC-SHA-256 (see FIPS 198, Sec. 3, p. 3).

A 128-bit AES key provides a security level of 128 bits, so it could
be weaker than the AES-256 cipher suites, especially those used with
NSA Suite B 384-bit elliptic curves, which are designed to operate at
the 192-bit security level (see Sec. 3 of draft-rescorla-tls-suiteb-01.txt).
It would be nice to point out that the security strength of the 128-bit
AES key may not be sufficient for all cipher suites, and mention this
issue again in Section 5.5 "Ticket Protection Key Management".

Page 10, last paragraph:

Should the length of the encrypted_state field (2 octets) be encoded
in network byte order?

Page 11, definition of the StatePlaintext structure:

The timestamp field is a uint32.  Should a 64-bit timestamp be used?
Contrary to the ticket_lifetime_hint field of the NewSessionTicket,
this timestamp is an absolute time (time instant), not a relative time
(time interval), so an unsigned 32-bit value will overflow in 136 years
from the chosen epoch.

It is implied that the master_secret field is in plaintext form.
Some crypto modules only allow the master secret to be extracted
in wrapped (encrypted) form.  If an SSL implementation uses such
a crypto module, it can't use the recommended ticket construction
as is.

A ticket construction using AES-GCM would also work, right?

V. Appendix A. Detecting RFC 4507 implementations

Page 17, last paragraph:

I hope the authors will take a stronger stance on discouraging
RFC 4507 implementations by deleting this paragraph.  But if
you'd like to keep it, it is incomplete, as described below.

In RFC 4507, the second paragraph of Sec. 3.2 (p. 6) says:

    If the client does not have a ticket and is
    prepared to receive one in the NewSessionTicket handshake message,
    then it MUST include a zero-length ticket in the SessionTicket
    extension.

So an RFC 4507 client would encode the extension as follows:

    00 23      Ticket Extension type 35
    00 02      Length of extension contents
    00 00      Length of ticket

whereas a client conforming to this document would do:

    00 23      Ticket Extension type 35
    00 00      Length of extension contents (ticket)

RFC 4507 says in the next paragraph:

    The server uses an zero length SessionTicket extension to indicate to
    the client that it will send a new session ticket using the
    NewSessionTicket handshake message described in Section 3.3.

It's not clear how an RFC 4507 server encodes "an zero length
SessionTicket extension".  It is reasonable to assume that an
RFC 4507 client would expect it to be 00 23 00 02 00 00 because
that's what the client sends.

Therefore, a complete discussion on implementing a server that
detects an RFC 4507 implementation should start by describing
how to detect "a zero-length ticket in the SessionTicket extension"
from an RFC 4507 client.  If detected, the server probably should
respond with 00 23 00 02 00 00 rather than 00 23 00 00 (unless the
RFC 4507 client blindly ignores the extension_data field of the
server's SessionTicket extension).

Wan-Teh Chang
NSS developer


_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls