Re: [TLS] Unifying tickets and sessions

[Richard Fussenegger <[e-mail]>]

On 10/23/2014 9:35 PM, Stephen Checkoway wrote:
> This seems perfectly reasonable (both for general N and for specific N = 2 or N = 3). But does it make any difference from a protocol perspective? The only way a client could tell if a server is doing something wrong is if the client knows the upper limit on the ticket's validity  NT and sends a ticket after that time which the server accepts.
>
> I'm probably missing something but it seems like there's no real way to detect if the server has followed any particular policy for a ticket so the details (such as key rotation and symmetric algorithm strength) should be left entirely up to the server. (Or resumption should be dropped from 1.3.)
>
> Giving guidance seems reasonable. Setting unenforceable limits does not.

Some parties think that only giving recommendations isn't enough 
(example quoted below), so why not give some rules then? Of course 
there's no way for a client to validate anything, but at least people 
can perform code reviews to check open or their own closed source 
projects to see if they are implemented correctly according to the RFC.

> The RFC doesn’t describe how key management should be performed and 
> merely emits recommendations. This has been found to be problematic in 
> OpenSSL’s case […]
> —Florent Daigniere: “TLS “Secrets””, p. 7, online: 
> https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-WP.pdf

I know, I'm using that reference too much, still …

Richard