[TLS] Comments on draft-ietf-tls-exported-authenticator-00

Watson Ladd <watson@cloudflare.com> Tue, 23 May 2017 19:40 UTC

Return-Path: <watson@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 E25FD12EA95 for <tls@ietfa.amsl.com>; Tue, 23 May 2017 12:40:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.801
X-Spam-Level:
X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 qc2M4UsPAe7H for <tls@ietfa.amsl.com>; Tue, 23 May 2017 12:40:18 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 5CB17129B60 for <tls@ietf.org>; Tue, 23 May 2017 12:40:18 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id e127so44029796wmg.1 for <tls@ietf.org>; Tue, 23 May 2017 12:40:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=FLHu4IzJBckQjzTAhbVZFS5y+v6YVO2sZUfian1LTNg=; b=QMAIZVOcnnVq6c4tIfYmMYO7idGJskIc/dibac5zBlhbZy96uAoDKEVXTYhVGIFoo/ hluX0zQfxgtEYAOObusUWojHGiOft+EV4plTVKcE6RCulDYU9cr3keYeiUu4OyE8ZXs4 mxSiP4EIQ+szn+9ADs+B2MGkRTvDaYSVOHxTQ=
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=FLHu4IzJBckQjzTAhbVZFS5y+v6YVO2sZUfian1LTNg=; b=cu2pkzCZjONEt97Eq8u/k0iJLiMzSM2I9/hVPVzEpDDg4Kc7T6Gk/Myvj8ujszqZrr AuEDvFxhpgxXSYspmOb6CB1Fq9UB8WAcTM2RPmcgd4Mde0krflh0BC7bSd/EhVdWmNvF uJ2q3IYUXCMLkHp34Uy6+Naf3uLjmUf0cmbm/reo9+muOnMgXAoOkIhbet35vTiKNDoB nE89E62B1XAr2+EtdmAqEWjWDgpRtX/jfwr3MicuIyUYMqoB7wCV8QXqfPv5LGpPfXQw UWsbQ6aGL7IgX8JhiuOKQAAnrUsLQ9pKdm8YNGVJHLj6MLFPQ6C7CP+pOvyuVo6e5SaX 90cQ==
X-Gm-Message-State: AODbwcDYgsumDZGdUPkfuOzaIEv2YRWFkKpkmUlePvn5fchyOduMdZjT dihS5F2vOUB+zf8Of74I+pAdz2YRu8K6bYM=
X-Received: by 10.28.156.197 with SMTP id f188mr3579280wme.76.1495568416588; Tue, 23 May 2017 12:40:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.152.148 with HTTP; Tue, 23 May 2017 12:40:16 -0700 (PDT)
From: Watson Ladd <watson@cloudflare.com>
Date: Tue, 23 May 2017 12:40:16 -0700
Message-ID: <CAN2QdAHByU1kxgit9J2KqOp1ujz4xWG8QEgAsZQCZWjfoZ2S=A@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="001a114b316835635d0550362810"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KB3HkCdle1JUr1pcS4K6JHQt8P4>
Subject: [TLS] Comments on draft-ietf-tls-exported-authenticator-00
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: Tue, 23 May 2017 19:40:20 -0000

Dear all,

I don't think this design needs to be as complex as it is. Why isn't
signing a party-dependent (server or client) exporter with the key of the
certificate, and then appending the certificate chain, enough? I am fairly
certain this gets the properties we need.  Further, the language around
jointly authoritative remains very opaque to me.

My other (much more minor) comment is that exporters labels should start
with "EXPORTER" in RFC 5705, and I don't see why this draft shouldn't do
it.

Sincerely,
Watson Ladd