[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
- [TLS] psk_key_exchange_mode question Daiki Ueno
- Re: [TLS] psk_key_exchange_mode question Benjamin Kaduk
- Re: [TLS] psk_key_exchange_mode question Eric Rescorla