[TLS] psk_key_exchange_mode question

Daiki Ueno <dueno@redhat.com> Mon, 23 April 2018 11:45 UTC

Return-Path: <dueno@redhat.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 DF042126CC4 for <tls@ietfa.amsl.com>; Mon, 23 Apr 2018 04:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 9fQutmxrlTJD for <tls@ietfa.amsl.com>; Mon, 23 Apr 2018 04:45:38 -0700 (PDT)
Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BE2124D6C for <tls@ietf.org>; Mon, 23 Apr 2018 04:45:38 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7AF92406C791 for <tls@ietf.org>; Mon, 23 Apr 2018 11:45:37 +0000 (UTC)
Received: from localhost.localdomain (unknown [10.43.21.161]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1C8FC2026DFD for <tls@ietf.org>; Mon, 23 Apr 2018 11:45:34 +0000 (UTC)
Message-ID: <od14lk2b0yp.fsf-dueno@redhat.com>
From: Daiki Ueno <dueno@redhat.com>
To: tls@ietf.org
Date: Mon, 23 Apr 2018 13:45:34 +0200
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Mon, 23 Apr 2018 11:45:37 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Mon, 23 Apr 2018 11:45:37 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'dueno@redhat.com' RCPT:''
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qNQibGvRsBv55KlpFuUkDWZUcIs>
Subject: [TLS] psk_key_exchange_mode question
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 23 Apr 2018 11:45:40 -0000

Hello,

I have a question about handling the psk_key_exchange_mode extension.

4.2.9. Pre-Shared Key Exchange Modes says:

  This extension also restricts the modes for use with PSK resumption;
  servers SHOULD NOT send NewSessionTicket with tickets that are not
  compatible with the advertised modes

Is this compatibility defined externally to the protocol, or does it
depend on the initial handshake?

To take an example, suppose the server uses the ticket construction
mechanism described in RFC 5077.

If the former is the case, the server requires PSK with (EC)DHE when the
ticket encryption key is required to be forward secret.  From the
implementation point of view, that would be provided as an option in the
server configuration.

On the other hand, if the latter is the case, the server requires PSK
with (EC)DHE when the initial handshake chose (EC)DHE key exchange,
because the ticket is tied to resumption_master_secret derived from the
(EC)DHE secret.

Since the above paragraph is followed by:

  however, if a server does so, the impact will just be that the
  client’s attempts at resumption fail.

I thought the latter is more plausible; however, in that case psk_ke
would only be meaningful when the initial handshake is PSK-only.

Regards,
-- 
Daiki Ueno