[TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication?
Cas Cremers <cas.cremers@cs.ox.ac.uk> Fri, 03 November 2017 13:43 UTC
Return-Path: <cas.cremers@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 7CAC513FC4D for <tls@ietfa.amsl.com>; Fri, 3 Nov 2017 06:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 JuBI5tyCFYJv for <tls@ietfa.amsl.com>; Fri, 3 Nov 2017 06:42:56 -0700 (PDT)
Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 ADFEC13FD34 for <tls@ietf.org>; Fri, 3 Nov 2017 06:42:55 -0700 (PDT)
Received: by mail-ua0-x22d.google.com with SMTP id f46so1949814uae.1 for <tls@ietf.org>; Fri, 03 Nov 2017 06:42:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=Sqc5huYppxPkPVVVrZSvlK1i+y2cC+bpmMtU04g1Yxg=; b=Q2oPuepohIQeECwYxX7IZLPzaQ7KUtdSGF0Mjya2EjHrEC8VmjKjWcgltOmGJrgItN xZFJb2qOp9egwZ1gdGT2yRl1mUPJcib9JhCzxZazaGvRrGe1i7mCNs2NddHzFmhXzVmm 4XpIY0y+oEREmZvxsXzUs+BhQySKhYcXYndpXDHx/hj1HTnlOoLuc2hst9VNLa+SjUZo 8IFrNr7q2zRHaaaOD6tWzbqv300bliyK3wGaLU4Dr8VgeXarJOxNk5M6Q+uP7x5JSfac XTvo7FdCA5NnfGDoZVPynNflGdhUlBovKLUn/GHeYOKYxakazAH1P38TXgZtuIBFXBv1 zbww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Sqc5huYppxPkPVVVrZSvlK1i+y2cC+bpmMtU04g1Yxg=; b=J+Xtdt3pCIOQLefA/Tz4O7LyGJeIGrN+k8puvizMh+kJJC19f20wBoQVhR5POwRyu0 HOQ/72QOBtwhVou6ytcTDkZTbVLIi8HbuL8cBD+CuxAYQ7B1j/HOOk1ZnM2k9onEFEEE tVb+qVpAXuHFbD4z9ItGgvDocFTnLqj2Q2iPAFR/qwSGYsl0zKod1vKW0c2Z9JG56c3T zMc9QKvB9CtEv9yLxDw9P6C+lZ5dqr7/M9VvkD2PHv5R8gXllviohMT2M7AX/dqTMD4Y FXndyHJcfWq/6w+DDF2wKi0gBjeRzs44egICODsfedGwq35QiW3xkRUrZ+35hLpQKLaS QvgQ==
X-Gm-Message-State: AMCzsaWm1Mf3RBH1QPFRCxffXIJ+ggRyXuKuCxKoiLHXTzrJciqy+ybX /7eWTSw/XxC+MgoXDBKSAQHrJn4vbScH+zCrlllQ7CRS
X-Google-Smtp-Source: ABhQp+Rc81bZ0R5vpCQ9OTp7A1y1VYimSSofUXf0ELLDC12nqMnAndgOzXTfs588QFQvMySfPPb14TCdwLYJeQelLTs=
X-Received: by 10.159.32.133 with SMTP id 5mr6042763uaa.61.1509716574415; Fri, 03 Nov 2017 06:42:54 -0700 (PDT)
MIME-Version: 1.0
Sender: cas.cremers@gmail.com
Received: by 10.176.1.108 with HTTP; Fri, 3 Nov 2017 06:42:33 -0700 (PDT)
From: Cas Cremers <cas.cremers@cs.ox.ac.uk>
Date: Fri, 03 Nov 2017 13:42:33 +0000
X-Google-Sender-Auth: Gf3DmBtcm5BRdLDGjqql-_AXFcA
Message-ID: <CABdrxL4ZX5GbUhdqmVrhVqwM-MqMsgLL6ow9ksQ8NYBCPvgnfA@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0b6202212f66055d144854"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Xdj2CDBXAOMA57N1mPHjLm1soys>
Subject: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication?
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: Fri, 03 Nov 2017 13:43:00 -0000
Dear all, Disclaimer: I am not a proponent of the idea behind draft visibility/green/rhrd; I think such a mechanism should not be part of the TLS 1.3 standard. I have a technical problem with the current design, whose goal is to allow eavesdropping for inspection, i.e., selectively decreasing confidentiality. However, the design in the draft also enables arbitrary traffic modification/insertion, additionally breaking all authentication and integrity guarantees. Once someone has the session keys, they can not only eavesdrop but can also start to insert/modify traffic. This additional decrease in security is entirely unmotivated by the cited use cases. It is possible to offer authentication and integrity, while selectively giving up confidentiality. For example, one could replace the AEAD by (i) a mechanism for authentication and (ii) a separate mechanism for confidentiality, and then possibly reveal the keys used for (ii), but make sure only the real endpoint has the keys for (i). That seems more rational to me, and may retain the authentication/integrity guarantees. However, it would require a much more invasive change. Best, Cas
- [TLS] Technical comment on design draft-rhrd-tls-… Cas Cremers
- Re: [TLS] Technical comment on design draft-rhrd-… Richard Barnes
- Re: [TLS] Technical comment on design draft-rhrd-… Cas Cremers
- Re: [TLS] Technical comment on design draft-rhrd-… Joseph Salowey
- Re: [TLS] Technical comment on design draft-rhrd-… Stephen Farrell
- Re: [TLS] Technical comment on design draft-rhrd-… Richard Barnes
- Re: [TLS] Technical comment on design draft-rhrd-… Joseph Salowey
- Re: [TLS] Technical comment on design draft-rhrd-… Karthikeyan Bhargavan
- Re: [TLS] Technical comment on design draft-rhrd-… Cas Cremers