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

Watson Ladd <watson@cloudflare.com> Wed, 20 March 2019 20:29 UTC

Return-Path: <watson@cloudflare.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 1CACC1310E5 for <cfrg@ietfa.amsl.com>; Wed, 20 Mar 2019 13:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 lwaiNlWWUX52 for <cfrg@ietfa.amsl.com>; Wed, 20 Mar 2019 13:29:20 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 BA5C81310FE for <cfrg@irtf.org>; Wed, 20 Mar 2019 13:29:17 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id t28so4182819qte.6 for <cfrg@irtf.org>; Wed, 20 Mar 2019 13:29:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qLm3LDjhvnuvPlrmZG5Ly4UV/uJ4dHwcVTtVmbNsPOs=; b=ObPUZMnWEubm8x/zEKIQHsi9dAb2CEE1IQizZgIKXz9f9hhneegu9GBbFilUxLOaq5 aXq2eCT8gQUeII09fa915kxdyQ5v9VWguoQ61p7RrDhKDdbzU5vz56s2Nao4dqyppuBJ imid7txWdS6M/cC/IyYgtO/5Z6vop/Mz8GUmM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qLm3LDjhvnuvPlrmZG5Ly4UV/uJ4dHwcVTtVmbNsPOs=; b=gutMy/YpWiEVI5HYsb1K5LnLwsGhRXmAGLrIeLtqx58iwwPoNIDY7qFdR3LaX/Ul5X 8pHRAda4WtygZSOG3akZB6ygfOSh11bk982v0GZ+qAq/16wMlKqCwPPrJLB5r9XJ4xYA TO7t/Fedg/6Zgo2+Gq51PjmVvWBZysqKV6/zAJkf+Z9fCLZGOAsHh/FCVeW7OvyxmxVb Qrp0dqrktJgeFC6fboK98bJF8rfJSiNgDh7i2giAWbkbYGHXE5/HM2o7NS4LV+gFlZjG EMJl6xFeITjO5lwPYIXLOIY+trUYzVD5vOZztcGcdoassG3qP3I/rflwoP30L3cOESi4 UL+w==
X-Gm-Message-State: APjAAAUUid8SgNjnowY5/ame7gT/CyGVXMqyjYidEuPiRjI9bgYmtKIb mWIM/8gLAarJWgXuoVzlfbRWCPSahV1M/zUbzQt/QA==
X-Google-Smtp-Source: APXvYqz6j69H3oiDPM3KO7rFguoU5ORIKg9w951EIUBoAiNVOHiCpMIjcmjkOQ9wpWFMqkbjcN4b2nigu+ZqFbb3D6s=
X-Received: by 2002:ac8:22d1:: with SMTP id g17mr8674115qta.30.1553113756310; Wed, 20 Mar 2019 13:29:16 -0700 (PDT)
MIME-Version: 1.0
References: <CAN2QdAH3f58FsfPoLquUh-ZgQe-X4EoCgiJAF7zf5X1M_r+zEA@mail.gmail.com> <CAJm83bDnyHx+wA21xsodL+tZkXSjDceFtyqPVNAnVOLJZVgmJA@mail.gmail.com>
In-Reply-To: <CAJm83bDnyHx+wA21xsodL+tZkXSjDceFtyqPVNAnVOLJZVgmJA@mail.gmail.com>
From: Watson Ladd <watson@cloudflare.com>
Date: Wed, 20 Mar 2019 13:29:05 -0700
Message-ID: <CAN2QdAG8szTQyCw41XkioW7de3WxF59UaWmLazk3ak4wX8ps4Q@mail.gmail.com>
To: Daniel Franke <dfoxfranke@gmail.com>
Cc: ntp@ietf.org, cfrg@irtf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/tPRDLn-OaiSTjuq-0WYOhca5DUs>
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: Wed, 20 Mar 2019 20:29:23 -0000

On Wed, Mar 20, 2019 at 1:18 PM Daniel Franke <dfoxfranke@gmail.com> wrote:
>
> Are you certain the standard security definitions don't suffice? If
> the S2C key were directly being encrypted under itself, then a
> circular-secure cipher would be needed. Ditto if you were to encrypt
> the S2C key under the master key and also encrypted the master key
> under the S2C key. We're producing the cookie by encrypting the S2C
> key under the master key, and then for transmission we're encrypting
> the resulting ciphertext under the S2C key. But at no point does the
> master key ever get encrypted under the S2C key; the master key never
> leaves the server even as ciphertext. So I don't think we actually
> have a loop here.

Any sort of encryption of a function of the key is a call the experts
situation. So the question for the experts: if E_K(M) is an AEAD
scheme, and K1, K2 keys
is E_{K1}(E_{K2}(K1)) a sane thing to do, or is it a problem from a
proof perspective? What if I am allowed to change the inner or outer
schemes to any AEAD scheme?

>
> On Wed, Mar 20, 2019 at 3:34 PM Watson Ladd
> <watson=40cloudflare.com@dmarc.ietf.org> wrote:
> >
> > Dear all,
> >
> > I really apologize for sending this message so late in the process,
> > but there is a problem with NTS in draft-17.
> >
> > The cookie encrypts S2C and C2S under a key known to the server, but
> > then the response encrypts the cookie under S2C. This creates a
> > situation where we are encrypting plaintext that depends on the key,
> > which complicates the security analysis. (And by complicates I mean
> > there are contrived ciphers meeting the ordinary security notion that
> > would be completely insecure in such a protocol: one has to not use
> > generic analysis: it's a pain to deal with. see
> > https://eprint.iacr.org/2010/144.pdf)
> >
> > One solution would be for the cookie to contain the new keys which the
> > server picks at random (and of course the client strips them out
> > before sending the rest of the cookie to the server). Again, I
> > apologize for only just noticing this detail.
> >
> > Sincerely,
> > Watson Ladd
> >
> > _______________________________________________
> > ntp mailing list
> > ntp@ietf.org
> > https://www.ietf.org/mailman/listinfo/ntp