[TLS] Question regarding TLS 1.3 session resumption

<geyer.lukas@gmail.com> Sun, 05 May 2019 11:11 UTC

Return-Path: <geyer.lukas@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A9D120140 for <tls@ietfa.amsl.com>; Sun, 5 May 2019 04:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 9Bhl7l0jbdVU for <tls@ietfa.amsl.com>; Sun, 5 May 2019 04:11:39 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 C9298120126 for <tls@ietf.org>; Sun, 5 May 2019 04:11:38 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id e56so11843698ede.7 for <tls@ietf.org>; Sun, 05 May 2019 04:11:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=pwM/6GMBh4G3Wf5ip4khvugDQNsOS9Z9a2NS3fVB84Y=; b=AsSnKyUPVse/0Z5mM8znTLsyD3k4NkDeUUUWSc2RnxoREbeJLFL9pr/hD1p5+fRpbH YIFJvsnKc7YQ1K3v+RHC561A9x/W7t4uoQiUurWTNU+A1diO/71yH0tMG7Akc/wfmxLt zKDQ1M6Q9bi53ivuaNJcpfYZsj82ivbig0hV0/d0Lyk1wdNCd0gZf3o7dFpF0+fdJEd0 k+xe5ApEncfU0vXU3NzSAfHcTT3S6ubFcZRarMHmKAQsB7YQR+DDL5JWeeXovKITBZmh kwYGHM37WNBrRvI+9iIap3FGSM5IttJgecZbabXhUMpaVoWdJfncsvWHvjU5mN5oMPJi TOTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=pwM/6GMBh4G3Wf5ip4khvugDQNsOS9Z9a2NS3fVB84Y=; b=g/8NNgZsDlNnCCsF1yn9mICH415VqfTdjjCvD3vSs0wku6bi8aozWPqU7wHnEDodSc WJiGhh09OeTODD3sBFfP5dJBhPpcrt7cd0xsDs7U4zvpJbfUAp3WtphbVIRW2dWI9qSm dkiU7CXcZp7IgYqZtDVoWJZmtkwR6Jw34l1DTQdllMuPhzMhVr7XbtUyV7bcPxvf+qc8 AVOwbSPtoUILmWCgeRjyvq903SUiPtLsiVa3ElCHQ88jzngiVL4mFuBDpRjN5LF9gxfU LpeB0bzxoPSvhg8I8R6P8ZZI8PndOkQv6qyOhB2jAULk/sM4w7gEIyZvMAt0hkF2ZiGe Jobw==
X-Gm-Message-State: APjAAAUCovl0TYaBjL23NMmNOaSbtuJpBIWhheuU2ehkjnKM4ZSKO9gy coop76Zg1P5tZ4aIdXvhyRMQWCOS
X-Google-Smtp-Source: APXvYqwiUfvP6cPF1K8K3t2ACa+FHMyQdJl25SpiMTTlMK/5M5Nk+UwBqE4ZzSeMsyhR3gm9GFPNAg==
X-Received: by 2002:a05:6402:13cf:: with SMTP id a15mr19728590edx.70.1557054697206; Sun, 05 May 2019 04:11:37 -0700 (PDT)
Received: from zeropki ([31.10.159.222]) by smtp.gmail.com with ESMTPSA id s15sm2102938edm.6.2019.05.05.04.11.36 for <tls@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 May 2019 04:11:36 -0700 (PDT)
From: <geyer.lukas@gmail.com>
To: <tls@ietf.org>
Date: Sun, 5 May 2019 13:11:27 +0200
Message-ID: <00d601d50333$49253bd0$db6fb370$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D7_01D50344.0CAE59F0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdUDLZFEqb3m45urTxKWiK30IbrAiA==
Content-Language: en-ca
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qS8ww8q_xN7vfDYKCp_mn1MNoj8>
Subject: [TLS] Question regarding TLS 1.3 session resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 05 May 2019 11:11:41 -0000

Good afternoon all,

 

The RFC 8446 mentions key schedule, resumption_master_secret and new session
ticket and I am not quite sure if I understand the session resumption
behavior correctly.

 

My understanding is that both the client and server calculate all the
secrets of the key schedule therefore both the client and server know the
value of the resumption_master_secret, therefore both sides calculate,

 

PSK = HKDF-Expand-Label(resumption_master_secret,

                        "resumption", ticket_nonce, Hash.length)

 

and the server sends back to the client the PSK (unencrypted, which acts as
an input into the HKDF-Extract to calculate the 0-RTT encryption key) + new
session ticket (encrypted using the session ticket key). Upon resumption the
PSK is provided as an input into the key schedule together with new ECDHE
parameters to assure forward secrecy of the resumed session + the new
session ticket is sent to the server as a reminder it is a resumed session.

 

If the session ticket is opaque to the client then the client needs to store
session information of the initial session (cipher suite, key exchange,
etc..) + PSK and session ticket and the server needs to store only the
session encryption key to resume session. Correct?

 

My question is what key is encrypting the session ticket (is it a symmetric
key that is generated by the webserver/SSL library for each session? In my
Apache 2.4.39 and openssl 1.1.1b testing the TLS 1.3 resumption works
without specifying the SSLSessionTicketKeyFile directive) and what
information is stored in the ticket (is it cipher suite, key exchange?? The
full key schedule is executed anew for resumed session and new crypto.
material is generated so there is no need for the ticket to contain
master_secret or anything similar like in TLS 1.2, so what exactly does the
ticket contain?).

 

Thank you,

 

Lukáš Geyer