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

Eric Rescorla <ekr@rtfm.com> Thu, 28 May 2015 23:24 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12ADB1A8BAF for <tls@ietfa.amsl.com>; Thu, 28 May 2015 16:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT2nETcWfcAl for <tls@ietfa.amsl.com>; Thu, 28 May 2015 16:24:29 -0700 (PDT)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C02A1A893A for <tls@ietf.org>; Thu, 28 May 2015 16:24:29 -0700 (PDT)
Received: by wifw1 with SMTP id w1so2590367wif.0 for <tls@ietf.org>; Thu, 28 May 2015 16:24:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=POB3sqtds/WboNyR6IJJoxwWvfnc62FBa72a3dKBwqU=; b=ggFsalxJ/tyJYySR//t4DvCYZPJUE4tkeXArAliDWuRB0SlLzWZ/KQWTqW7L/YccU1 psrEMBA6IXLTNS22tYrC5YBIkoQ5BkiXUwgQrxcDKtwXc4HUVGLBAiy3ccHAruOeXyXc IrshC4NDfJMan4F4lTzp7Lw2pVpoZ7cjFXWhIwNb/beMBoN9zMoo0Lw07WhCpZWGgrs7 /JnfEC/QVZ4OlNTmNyOEN23VPmjORhpqB+uupqmQQO4xPnX/u0nZapPz6GhE/R59d0CZ xfwX62yVaraOALczKn8mjy/hFBSUjRwwqFqdaaEa9kcJ4G9h6/q7T/aHV7NvijgqsOT2 5BYA==
X-Gm-Message-State: ALoCoQm11lKT4fVEWJLf8Fp17Bo9gaZbpBP8IVJZqoySwb9SRs/djO1sSh1euuGkROLuGvIuQ8n8
X-Received: by 10.180.73.176 with SMTP id m16mr728696wiv.68.1432855468193; Thu, 28 May 2015 16:24:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.225.14 with HTTP; Thu, 28 May 2015 16:23:47 -0700 (PDT)
In-Reply-To: <CABkgnnUb5jDMMchxDxun_Kp9hYJ8_YFK_URrE=bXE8oej=zYCA@mail.gmail.com>
References: <CABcZeBM9UGZoifzDZZ3METMJJHa1ueX9CdHiccYTDW5UVC3RrA@mail.gmail.com> <20150527172329.GI27628@localhost> <CABkgnnUb5jDMMchxDxun_Kp9hYJ8_YFK_URrE=bXE8oej=zYCA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 28 May 2015 16:23:47 -0700
Message-ID: <CABcZeBO6=V8HFTnr82_tt63HQiwSjeSJ-o-hS3sr_tUnO-Jy5g@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=f46d043c7e58324ae805172ca9fa
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/4LYT-pLlOAZHS_ooFp5ecudmRI4>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] More clarity on resumption and session hash
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2015 23:24:31 -0000

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