IETF Logo Mail Archive

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

Nick Sullivan <nicholas.sullivan@gmail.com> Tue, 23 May 2017 20:07 UTC

Return-Path: <nicholas.sullivan@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 0516712EAFA for <tls@ietfa.amsl.com>; Tue, 23 May 2017 13:07:14 -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 lriW1WGYDIyH for <tls@ietfa.amsl.com>; Tue, 23 May 2017 13:07:12 -0700 (PDT)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 DB78412EAC4 for <tls@ietf.org>; Tue, 23 May 2017 13:07:11 -0700 (PDT)
Received: by mail-ua0-x22f.google.com with SMTP id u10so85070098uaf.1 for <tls@ietf.org>; Tue, 23 May 2017 13:07:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=spCIE85vSBkHOsJHerAlox1neYlZC9DcB2H4PB/9GsM=; b=e82NbcX3iyA26hPirSVMTw+0Yp2RFal5V3rniM64Aaup7voiUD/trdykvrtgHaB6b4 jpZBU6j/B+AXQTGwjVdR9K9jwG4wi/qMHlBu3pANo7F3bRkp6usXoaUMPrUzfIMgfzhR JTVJx2wOcPUdn38F3hCvF1STSE5Zx4Yib54OEvZzksSHnrvOFp0Q3qbhW0stv+5uzwPD zJSKmdYzxwroQqJIZpipKO9JCPHSjBSxSi398vFGM7/qqdW6SNmk6D/9EtAKNo6Ou053 IL25L9UrDKGaMcnnet3NCSSOGv/243SjeMFsfaApDrRQD5FGMiG0fHrayxYrBULyJWKp AeEA==
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; bh=spCIE85vSBkHOsJHerAlox1neYlZC9DcB2H4PB/9GsM=; b=gsB391il0c3nSOcQ7njrXbpIlC94NfiEsHM3Z/EfUXaTQ6AVMjB9y/I24gkXNziL0l D3umM6dNn4dTNSdH/tTSJvXbiRLx9dKyH9AR0REUvnFS1R1vqCmEFr4oRNrjSUHSiL8G z8Kb9eLhGOfLfxaJu2Fuks8dC6voukBqkC4dZvN61tEv5r/NcbAHNFdQQdp4sS0YGj7b E+ZjCnN/gQ/XZmHQFgWMWi51kS1xaASgwDKLvbYoBQItOmujVMaPFEg7uKf8G6GudsWz U38XcrnPSXQGgpfbZgyohx4ewSHktpttfPNhggfM9uAxUAaNBQxnu6PP4oggSu/oBV+P F20Q==
X-Gm-Message-State: AODbwcDRsmWBrOiV2+aFwwZYNNh5c0WHb+zn9r1FyVIKxmxtjJ4Xwswc aAfVmTPDxR3fB5p321k7JNwRL5OiQQ==
X-Received: by 10.176.7.198 with SMTP id d6mr15737066uaf.61.1495570030920; Tue, 23 May 2017 13:07:10 -0700 (PDT)
MIME-Version: 1.0
References: <CAN2QdAHByU1kxgit9J2KqOp1ujz4xWG8QEgAsZQCZWjfoZ2S=A@mail.gmail.com>
In-Reply-To: <CAN2QdAHByU1kxgit9J2KqOp1ujz4xWG8QEgAsZQCZWjfoZ2S=A@mail.gmail.com>
From: Nick Sullivan <nicholas.sullivan@gmail.com>
Date: Tue, 23 May 2017 20:07:00 +0000
Message-ID: <CAOjisRziY8KhF163V=VhQGGyXJVkgsQ9QGsqVSpzJMbkvXYO4w@mail.gmail.com>
To: Watson Ladd <watson@cloudflare.com>, tls@ietf.org
Content-Type: multipart/alternative; boundary="f403045f7fe86e0ae305503688ec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fD5RanBiv24iRmo5jt9DD-g78RA>
Subject: Re: [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 20:07:14 -0000

Hi Watson,

Some points that should help clarify your questions:
1) The certificate used in the construction is no the plain certificate
chain, it's the TLS 1.3 certificate message which could contain extensions.
2) The finished message is used to bind the certificate+certificateverify
to the connection state. It mirrors TLS 1.3 post-handshake authentication.
3) In TLS 1.3 post-handshake authentication, each successive certificate
added to the connection is incorporated into the handshake state. The last
certificate in a sequence of authentications would result in a connection
in which the party could say they were jointly authoritative a over
multiple identities. In exported authenticators, the only state that is
signed comes from the original handshake, so there's no way to order them.
Each exported authenticator is tied to the connection, but not tied
directly to another authenticator, and therefore there is no proof that the
party is "jointly authoritative". I welcome text changes to make this more
clear.
4) We can add the prefix in the next draft, thanks for the note.

On Tue, May 23, 2017 at 12:40 PM Watson Ladd <watson@cloudflare.com> wrote:

> 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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email