Re: [TLS] draft-ietf-tls-exported-authenticator

Nick Sullivan <nick@cloudflare.com> Mon, 11 December 2017 22:36 UTC

Return-Path: <nick@cloudflare.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 0F1BE124234 for <tls@ietfa.amsl.com>; Mon, 11 Dec 2017 14:36:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 Z0-mrwa6HVJ8 for <tls@ietfa.amsl.com>; Mon, 11 Dec 2017 14:36:03 -0800 (PST)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 8CBFA128B91 for <tls@ietf.org>; Mon, 11 Dec 2017 14:35:59 -0800 (PST)
Received: by mail-qt0-x230.google.com with SMTP id g10so42680810qtj.12 for <tls@ietf.org>; Mon, 11 Dec 2017 14:35:59 -0800 (PST)
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=1MYcZoG0Sfi6ryF8QNH9Ina67ghyiR13KSzipSqj/xA=; b=QYIzZlRJfqkz+TX8tVbgVnvywRrMm8rel2o1Gqt1OknpzxkiuC5cXjf+nvbY+Gd2gG P+ndNk9/DYbyR4BJ/CrwUSkXHDNUVGqHTnFWtSNsJ8H9gAx6jdl7EnA2hl8HHUDx+Hvq X071vaUgQlPmtl/66ZvUWD4x50RrzWrQQE8Lg=
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=1MYcZoG0Sfi6ryF8QNH9Ina67ghyiR13KSzipSqj/xA=; b=pIYUz7KqMgrlHzRtaT9SrCfiZrIsOHUdZlXj75wkJVaiCGGEoLZEurBRsXXBMQZ2jO BigHgaOaZMOxPsH947LIfBt6v9HJA4x69hvhQWHt7WgJFqx1+05jrT+60dqDwVlFcWEb dAOvEs3UgwhNgq1I5JWRS+HlPMfZiYzsxPm+5dLteAk/xY/GCJ2yRc/2mtO4yUjExPgL oarjSiQhFVLKU9fpspbvFC20Uh3I9FpmFcDvAhDr4rtPUmR1/1UDHEVyUALQU5lyyJV6 vp/BZsvesQ7YTvE3QsypFfqt8Wo6oGTg2BvZOnz6Xt4KhGEGrhOeX1wwb6bnJHzCU0gi bcDw==
X-Gm-Message-State: AKGB3mICKkeXTAU+pAQtyl12E+CqPmV+TD8TKHCwq6dW6n5+SkyPVzus fCPCy9b+6Udcje2TbfH6jPrsPJqknqdFe4ksyHB3dQ==
X-Google-Smtp-Source: ACJfBov1lNagXn2dNKbxud5QgFohpX0ZTv59e0/1uL8onb18dcderwMx4fDtfZfp9KuEozTiTBlLB9y31kOEEyDHL04=
X-Received: by 10.200.50.61 with SMTP id x58mr2963159qta.117.1513031758600; Mon, 11 Dec 2017 14:35:58 -0800 (PST)
MIME-Version: 1.0
References: <20171116031327.GJ82825@kduck.kaduk.org>
In-Reply-To: <20171116031327.GJ82825@kduck.kaduk.org>
From: Nick Sullivan <nick@cloudflare.com>
Date: Mon, 11 Dec 2017 22:35:47 +0000
Message-ID: <CAFDDyk-9+6Q9tQpTf8rOB2mtTwut=8txq_=ifthxh=3O0wPq1A@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: tls@ietf.org
Content-Type: multipart/alternative; boundary="001a114045748173430560182823"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/v82QK6_01M2VT4iyrcA7WV1Ozqc>
Subject: Re: [TLS] draft-ietf-tls-exported-authenticator
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, 11 Dec 2017 22:36:05 -0000

Ben,

Putting the authenticator in an encrypted tunnel is not necessary for
binding, but it is necessary for keeping the certificate itself
confidential. I'll add text to that effect.

Nick

On Wed, Nov 15, 2017 at 7:13 PM Benjamin Kaduk <kaduk@mit.edu>; wrote:

> In the exported authenticators draft we claim that "The
> application layer protocol used to send the authenticator SHOULD
> use TLS as its underlying transport."  This is of course natural --
> why would you be using TLS authenticators if you were not using TLS
> -- but it seems that we would also benefit from saying what
> properties are actually *required* of the channel used to transport
> the authenticator.  (Confidentiality?  Binding to the key material
> of the TLS connection?)
>
> -Ben
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>