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

David Benjamin <> Fri, 29 May 2015 18:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0AB571ACEA0 for <>; Fri, 29 May 2015 11:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pEoyy30LeH7X for <>; Fri, 29 May 2015 11:06:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 234C21ACE8E for <>; Fri, 29 May 2015 11:06:49 -0700 (PDT)
Received: by igbsb11 with SMTP id sb11so20638021igb.0 for <>; Fri, 29 May 2015 11:06:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=Z1ANcV4N12sAL8dPIHcztAASeVxpwpK5bmaluRwmAU8=; b=mW7lzbfKmXkSdhOFFpV1IDrLH3x21KOBq+2mPS24UIHSgU+vRO3WQYbF5hlTT0zoBD muZ08YQ/VQzcgirt55RZRAnKMrcRGEAPXBPI086xK3hdPYIN3VDopheKnjn87kVWfKI1 upUjunsTyaygIi6heg+NXWkZRKAgk1h29e83Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=Z1ANcV4N12sAL8dPIHcztAASeVxpwpK5bmaluRwmAU8=; b=j6yE4ijvEE3FISgMEc2GwZBgajJVwycy/3yo4tldEn9BpCam5vBmQTTYFL7Sw3ZQ2e ea5mxG7peentFV5hpnF6/48VuvMR09R7+sIcFRyiOG+Dkc6LyA1XY13uK3ropoYqj/Ba e+RLIgqyXeoqc7XW3rAcXgpJPDN9WD+eZc/LnJqKdHo6UZqAUQOMn8u53cgpY2TNgn/g +VCIxDBhODVIS64pc7iAqW+P97q3yMiZVmfyv/zW6Dh92x6UFy7hK7uffcnsZ47PJDGt nChJCO5h3rqk5Eq2d7BTtQriRRwByIrGJdsiPNVoAhcS/aOX98o1egeCkg342YC6uP+p wIvA==
X-Gm-Message-State: ALoCoQkR70/FUoi4kPKFDBkzadQSB/Sa88MMsNWwiP+gewNwxFMR0DhJ4z+Pl15DJje4EXuueeOP
X-Received: by with SMTP id a10mr16575187ict.49.1432922809424; Fri, 29 May 2015 11:06:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <20150527172329.GI27628@localhost> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Fri, 29 May 2015 18:06:38 +0000
Message-ID: <>
To: Eric Rescorla <>, Martin Thomson <>
Content-Type: multipart/alternative; boundary=bcaec55237800bfcd205173c576a
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] More clarity on resumption and session hash
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 May 2015 18:06:52 -0000

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


On Thu, May 28, 2015 at 7:24 PM Eric Rescorla <> 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
> - 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 <
> > wrote:
>> On 27 May 2015 at 10:23, Nico Williams <> 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