Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?

Bill Cox <> Tue, 12 July 2016 15:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D7AB12D0ED for <>; Tue, 12 Jul 2016 08:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.987
X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Kogzp69ooCTJ for <>; Tue, 12 Jul 2016 08:43:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2FB8512D9DD for <>; Tue, 12 Jul 2016 08:34:34 -0700 (PDT)
Received: by with SMTP id x130so27106374vkc.0 for <>; Tue, 12 Jul 2016 08:34:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MCaHradSXSTh4/pk6yWYNH2LPr/NRcZ3maR6JSfldUU=; b=dP8F/DvJLsHXGf0N8UYFYoNsOvomgqveS9Lsm+0qPugcmE9YrZASDEpTroGvKYzNNa Q55R/JhnBc15D7U2vod5LqnA1wmU0FEAWYzwqnLQF2MwaXAC7xpxZMUXQGIaClaswL5U KUVhNjq4XiUkknfIxJgjQIy80Eqoaz8/lq16cE7ovIiWM/EsRzzSV5kCg8+ZaYHaGX5J ttRSCV0u+h7H5rZCDfwJWZnrKUsX9KnJfxGjk+nfgdQZF7lXGLU5D6nh4Xm7ayLCcnv2 0izk4OkqJXEPsA9O0gB+7r3/myD/1L9odlaCe4hZuCP2OBhfR5N1QoptmtfmbIx5d2Fs n5Uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MCaHradSXSTh4/pk6yWYNH2LPr/NRcZ3maR6JSfldUU=; b=Q7YeQU6zaacSkDVQ7ZLa9Xisiylp7t54rCUM7OZ1LqCjJAHA9wmCDkLhOSf0XVv+z4 rM0gd8Yr5oVipaKnyjNRF6oUsKEDlIm2hqvFSjTKARy4U+WW7j4jbdwaom9QBwYLJd4/ ghVfduFuDKhDm04QCK/uvq3EwKe3H+W/Z7y+SQzz/gnj+KE78ONjEOIf4WhwxNq1vEJN YQw/OcdtvlOxDXhfAtcBnJbAQRwmQa9BAgTI+hIjc4zAFQF6gszy3Sy3k1RADDxp9rMl MlYskksW5P5HjnInkKXwNFsf7CCptjrkdmJeCoI0xd/CUNT4N5YSLx4sVwTsdfCmcU8/ Nztg==
X-Received: by with SMTP id 53mr1478924uai.113.1468337673093; Tue, 12 Jul 2016 08:34:33 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 12 Jul 2016 08:34:32 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Bill Cox <>
Date: Tue, 12 Jul 2016 08:34:32 -0700
Message-ID: <>
To: Douglas Stebila <>
Content-Type: multipart/alternative; boundary="001a113db6da6a84ee05377201eb"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?
X-Mailman-Version: 2.1.17
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: Tue, 12 Jul 2016 15:43:16 -0000

IIRC, in TLS 1.2 the same keys are used after resumption, and EKM values do
not change.  I think most applications currently using EKM will break if
the EKM values change after a PSK resume.

However, forcing TLS 1.3 to remember a 256-bit EKM seed will bloat tickets
by 32 bytes, and complicate the state machine.  I think this could
partially be addressed by enhancing the custom extension APIs found in
popular TLS libraries to enable custom extensions to specify state that
needs to be remembered on a resume.  That, in combination with requiring
extensions to be sent and processed in order of extension number, could
enable a lot of this complexity to be taken out of the main TLS code, and
only connections that actually need such extensions would see the increase
in ticket size.

Could something like this could work well for channel binding?