[TLS] Security of OPAQUE in TLS

Hugo Krawczyk <hugokraw@gmail.com> Wed, 27 March 2019 02:58 UTC

Return-Path: <hugokraw@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 DB062120323 for <tls@ietfa.amsl.com>; Tue, 26 Mar 2019 19:58:17 -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 AWpn3e0odQ-1 for <tls@ietfa.amsl.com>; Tue, 26 Mar 2019 19:58:16 -0700 (PDT)
Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 D57121202ED for <tls@ietf.org>; Tue, 26 Mar 2019 19:58:15 -0700 (PDT)
Received: by mail-it1-x131.google.com with SMTP id m137so23139842ita.0 for <tls@ietf.org>; Tue, 26 Mar 2019 19:58:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UeOoYMsiWDytzFQboaFAfIIhfVI+gsnFj2ZgQRXAoBo=; b=V94spml55U2BT+f9jIRoAI9kuVNgXSwtLMoDulYpHRnkM3KkItWmHFb6tGAmbAKyxJ wVYZcf60w4MI0WVUP9KispfNTTKDx9dEXRAdQUknWA3jroycmuwUnRCg933gCGcFOV4S sVTOWL8KlEzbqECpSdiad4rl6T7J8p+r4KRTpOdy5sfE76YVsW4A/sogY1+iLTGXBV4i GoP2pvslKK0MF0JI39wXcXELJDVKTTrQ/7YBXZKVipCSsTeXViHpyb5fw9FsYQoVtu1J 67GYezafWnCsZMX2WHj5x+53K5HC4auKn5Fk1LV/kJDTBWUYKVL7qTtQcvcqNs+UiTEC 6+0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UeOoYMsiWDytzFQboaFAfIIhfVI+gsnFj2ZgQRXAoBo=; b=JQc4PrVxSv1iLU+njNiTBgPhGszaTObzGJp6trQIxm28Mx9OlGaaW2lGTjiehGsXVf 5XLByCKpLL4Y9e+pECXWePdJPiYMOQhkfsVkDeK+uv5LZ0FkS91ZPpOykqrlBsOKzV71 6APfFTo9227z4t6qUjYA0dh2LZp6B8lLNIasbhF9xIgZoFPKzFyGa4MTSDlHGSKSM1Ht ippHEMCW9u/ZzMl2l48cdKBZXaam135UMWlS8RYEjTFXj8ia76sO7Fc6ZiuFyxqWxKyy xxM2QKZ8IBJ2H3CSc31SZ1kA5DuBCItsSotq7CEI01hb+8inxgVc1/xi7ldKWfSGB9Zu qjyw==
X-Gm-Message-State: APjAAAUWHVMFbZ9ld0xMabSOD2Rq7gVIRZxkkADktkdz5Sf/BDb8lgl6 NBeDBHhb2s836nqh/ytnIsLGGJ/GiVBwdM80l46Gt2Kx
X-Google-Smtp-Source: APXvYqxnkLEltovThZnAbMusRNTplddlgEHa7fslT4+N2iPugMuJUi0XYz0K+RlzNdkN6qGP/PqcR3N/j6JzhomVtBc=
X-Received: by 2002:a05:660c:1282:: with SMTP id s2mr1803176ita.47.1553655494808; Tue, 26 Mar 2019 19:58:14 -0700 (PDT)
MIME-Version: 1.0
From: Hugo Krawczyk <hugokraw@gmail.com>
Date: Tue, 26 Mar 2019 22:57:32 -0400
Message-ID: <CADi0yUOuMDk7sY-XE6-SVisG=5a7eJHPZnzwMmLWiNa+N+E4Vg@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000df18e605850a9bb3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/noDzS4Nze0hk9k6QAmWtR9jC5rg>
Subject: [TLS] Security of OPAQUE in TLS
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: Wed, 27 Mar 2019 02:58:18 -0000

In the TLS meeting on Tuesday, Kenny asked about the analysis of OPAQUE in
the context of TLS. One important property of OPAQUE is that its design and
analysis is modular. It applies to the composition of *any* OPRF with *any*
(KCI-secure) key exchange. This is why we can integrate OPAQUE with
different KE protocols including TLS 1.3 and get a combined proof of
security. Of course, these high level analyses do not take into account all
the details in a complex protocol like TLS 1.3 so any more specific
analysis, including those using automated tools (Tamarin, Everest, etc)
would be more than welcome.  However, if there is interest in defining an
asymmetric PAKE for TLS to replace old designs such as SRP then we can
start moving towards that goal with the draft Nick presented.  This will
also motivate more analysts (including those based on tools like the above)
to look into this question  more seriously.

Hugo