Re: [TLS] More clarity on resumption and session hash

I poked a bit more and I was mistaken about OpenSSL's d2i_SSL_SESSION
behavior: Although it does ignore the structure version, it will fail the
parse if it sees elements at the end of the structure it doesn't
understand. Presuming any EMS implementation adds an optional boolean to
the end of the serialized session, pre-EMS servers derived from OpenSSL
should simply not recognize any sessions created by post-EMS servers in any
shared session cache + rolling upgrade situation. So, at least against
those servers, having the client abort when the peer resumes an EMS-full
server without EMS should not cause issues. I don't know about other
implementations though.

If we do specify that the client MUST or even SHOULD abort in that case, I
think we should also explicitly call out that servers without EMS support
MUST NOT resume sessions created with EMS support. This is slightly weird
because EMS-less servers will necessarily predate this specification.

A client has no option to fall back to a full handshake at ServerHello, so
any cases where we want clients to abort, we need to be sure are illegal
for the server to produce. (E.g. EMS-ful resume of EMS-less session is okay
to abort because we can reasonably require that servers fall back to a full
handshake.)

David

On Thu, May 28, 2015 at 7:24 PM Eric Rescorla <ekr@rtfm.com> wrote:

> I'd like to close the loop on this, since I think it would be better if
> implementations
> behaved identically.
>
> It seems to me that there are two cases here:
>
> - Interoperating with non-EMS-enabled devices, in which case we want to
>   encourage refusal to resume, but we know we can't require it (hence
>   SHOULD.
>
> - Mid-flight reconfigurations/changes, etc. in which case we should be able
>   to come down on one definite interpretation.
>
> Since this second case should rarely happen, but people seem sad about
> abort, I would suggest that we say MUST NOT resume and SHOULD
> do a new full handshake.
>
> -Ekr
>
>
>
>
>
>
>
>
> On Wed, May 27, 2015 at 10:43 AM, Martin Thomson <martin.thomson@gmail.com
> > wrote:
>
>> On 27 May 2015 at 10:23, Nico Williams <nico@cryptonector.com> wrote:
>> > Is a mid-flight reconfiguration of the client while reusing an old
>> > session cache likely?
>>
>> Some clients persist session caches to disk.  That means completely
>> new software could load old sessions.
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>