Re: [Cfrg] [Ntp] Last minute annoying discovery about NTS

Dan Brown <danibrown@blackberry.com> Thu, 21 March 2019 16:58 UTC

Return-Path: <danibrown@blackberry.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB62131457 for <cfrg@ietfa.amsl.com>; Thu, 21 Mar 2019 09:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 qmXoltKyYbCU for <cfrg@ietfa.amsl.com>; Thu, 21 Mar 2019 09:58:29 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12272131453 for <cfrg@irtf.org>; Thu, 21 Mar 2019 09:58:28 -0700 (PDT)
Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs210cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Mar 2019 12:58:27 -0400
Received: from XCT198YKF.rim.net (10.2.25.6) by XCT101CNC.rim.net (10.65.161.201) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 21 Mar 2019 12:58:26 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT198YKF.rim.net ([fe80::59f9:6b62:c489:7f43%13]) with mapi id 14.03.0415.000; Thu, 21 Mar 2019 12:58:26 -0400
From: Dan Brown <danibrown@blackberry.com>
To: Daniel Franke <dfoxfranke@gmail.com>, Watson Ladd <watsonbladd@gmail.com>
CC: "ntp@ietf.org" <ntp@ietf.org>, "cfrg@irtf.org" <cfrg@irtf.org>, Watson Ladd <watson=40cloudflare.com@dmarc.ietf.org>
Thread-Topic: [Cfrg] [Ntp] Last minute annoying discovery about NTS
Thread-Index: AQHU31uqP3lPeAbYmU6SSimAmwqoK6YVO/YAgABHTICAAN/LAP//5rNQ
Date: Thu, 21 Mar 2019 16:58:25 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF501DA67DF@XMB116CNC.rim.net>
References: <CAN2QdAH3f58FsfPoLquUh-ZgQe-X4EoCgiJAF7zf5X1M_r+zEA@mail.gmail.com> <CAJm83bDnyHx+wA21xsodL+tZkXSjDceFtyqPVNAnVOLJZVgmJA@mail.gmail.com> <CAN2QdAG8szTQyCw41XkioW7de3WxF59UaWmLazk3ak4wX8ps4Q@mail.gmail.com> <CAMbs7ktP_pmC5x256U38L0f_MXTWh9=Xy0KZ79AH=PtROxA5pQ@mail.gmail.com> <CACsn0cmedxYQoQSoCFLj3xWoSNPKSzy6RaCPC6P+L98ShEwLBA@mail.gmail.com> <CAJm83bBWCY6tSWaRDPyfomR+ZKsvTwvuaju=GSLSvLWEN-NywQ@mail.gmail.com>
In-Reply-To: <CAJm83bBWCY6tSWaRDPyfomR+ZKsvTwvuaju=GSLSvLWEN-NywQ@mail.gmail.com>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.252]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"; boundary="----=_NextPart_000_00D9_01D4DFE5.C483E4F0"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/bkszBpm59ZgkQ_j_8jRi8fheGKY>
Subject: Re: [Cfrg] [Ntp] Last minute annoying discovery about NTS
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2019 16:58:33 -0000

What's the added value of key-dependency in E_K1(E_K2(K1)) over, say,
Hash(K1+K2), or E_K1(1)+E_K2(2), or some other kind of key confirmation,
etc.?  

Also, should there be messages, as in E_K1(M1+E_K2(K1+M2)) to limit the
scope of replay attack to a particular message? 

For weak enough E, the value E_K1(E_K2(K1)) seems weak.  For example, if
e.g. E_K(M) = K xor M, then E_K1(E_K2(K1))=K2, which is probably bad if K2
is necessary for any other purpose, etc.  If there is no E_K2 oracle for the
adversary, then very weak E meets Shannon's theorem about one-time pads, so
E_K2(K1) and E_K2(R) are indistinguishable. So, any security proof (of what
goal?) would need more than this indistinguishability, either some extra
property E (not held by E_K(M) = K xor M).

> -----Original Message-----
> From: Cfrg <cfrg-bounces@irtf.org> On Behalf Of Daniel Franke
> Subject: Re: [Cfrg] [Ntp] Last minute annoying discovery about NTS
> 
> I think I might nonetheless spend my flight to Prague formalizing a
security
> proof, mostly as an exercise to improve my proficiency working in the
standard
> model. My intuition here is mostly that, even if the adversary is given
K1, it still
> can't distinguish E_{K2}(K1) from E{K2}(R) for random R; there therefore
> shouldn't be anything "special" about using E_{K2}(K1) as an input to
E_{K1}(.).
> A colleague has sketched out a plausible hybrid argument which sort of
> matches this intuition. I'm going to take that argument and see if I can
run with
> it.
> 
> On Wed, Mar 20, 2019 at 8:46 PM Watson Ladd <watsonbladd@gmail.com>
> wrote:
> >
> > I've managed to convince myself Daniel is right and there is no problem.
> >