Re: [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 14:41 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 73BB613FD6C for <tls@ietfa.amsl.com>; Fri, 3 Nov 2017 07:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 bT8yVwmtx6wr for <tls@ietfa.amsl.com>; Fri, 3 Nov 2017 07:41:39 -0700 (PDT)
Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 8EB5013FB55 for <tls@ietf.org>; Fri, 3 Nov 2017 07:41:24 -0700 (PDT)
Received: by mail-vk0-x22e.google.com with SMTP id n70so1877982vkf.11 for <tls@ietf.org>; Fri, 03 Nov 2017 07:41:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6m7rAXcaPsTlkQO53Fd0WQuJJMh4z9WJYsNPxSLxmCE=; b=gbOZMKF++8Zq4cZqPgDYxAxR3YEjgzVvl/dYK7+D5IpeUH4Ou9ho3HnLNW86nc6uYA 7CWD//MfHTILt/XViHAqGNOyPDkAiOYBsknM/DC9HhURBGWkEu3uXCr9x3iQJfg9laPP qSkjm8mdzpEU+1xg7YJDsvUqoX4z9IRqaLe6ZDmETNIWhYxzznxR3kzF0eTVmry/m8Yx d35gqy2y9LajJx5OloGP3/FAlAxs/uX4ue8XFPtZzr3N8xWKjtHKYps7Tg5HPDjuCzj5 Pw65HhgaWdjuNc3JSgs/TmaHHHmRmki0L25NJEGg/m9o5habWlpW4R7o2k1RM0YNJblZ UFDQ==
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:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6m7rAXcaPsTlkQO53Fd0WQuJJMh4z9WJYsNPxSLxmCE=; b=fR2Y+RvDO5JJNJhLxe3oVrCCQjWB+/4M9QDcwPSXm2GmO0Jb+n0M83grBzGjCLtTxw vXMqj6tv/fe4CoqzqwKWOyhOWxOTcw+XGWKbIT+3yXiatu88EUniOrxzqCTplbcjY8mX 6SlvE77gS76mAycCmFCubeKzD27q2g1wqt7Qbnw0tsxt41FuqHbGllAzlYUgvaOmrcin B57Lh5RFvI9W1oF80ERGsh3XsQtlZw+UiwJoP9O67WjIU1plkL1BdD2Us5ZUFOKexp7V mtNdC9IOJo9OFwOaHhZeDGhZ6T5nKPHfJKaQL4cQHyi0PVmeUVNLRZOB3sN7hQWG8aK1 vpqQ==
X-Gm-Message-State: AMCzsaU691WrGn+/CM7TAtyjX2GiWjkAsKGrhn50M5l6NYPMkGk8u+Dr olSbr9SBf3cLVcY7co+ijysSK3fiajLfsbCLg8Qn3g==
X-Google-Smtp-Source: ABhQp+T5va6ljCTBy+bixP2c72cfaO5Jx8NSTK+gkUq8aYbKPNSy8yXatgPfInEXW+k9mtaTDJgFbi+LPfX5vnDugLU=
X-Received: by 10.31.234.131 with SMTP id i125mr5529910vkh.149.1509720083582; Fri, 03 Nov 2017 07:41:23 -0700 (PDT)
MIME-Version: 1.0
Sender: cas.cremers@gmail.com
Received: by 10.176.1.108 with HTTP; Fri, 3 Nov 2017 07:41:02 -0700 (PDT)
In-Reply-To: <CAL02cgQMeJAqTtrVBzv254arGQU-88NTJJWgZdoRQguPn14TkQ@mail.gmail.com>
References: <CABdrxL4ZX5GbUhdqmVrhVqwM-MqMsgLL6ow9ksQ8NYBCPvgnfA@mail.gmail.com> <CAL02cgQMeJAqTtrVBzv254arGQU-88NTJJWgZdoRQguPn14TkQ@mail.gmail.com>
From: Cas Cremers <cas.cremers@cs.ox.ac.uk>
Date: Fri, 3 Nov 2017 14:41:02 +0000
X-Google-Sender-Auth: YzuHnfq2wbBOCnZXXp47rsV6Y3E
Message-ID: <CABdrxL7eE1rND6b-q-La7gwzgZmt2VEo3CKUcEfGMoiMWZ71wQ@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0916904ad349055d151911"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Z0cRFtcSURb9MvAE7aRjXpa9TJY>
Subject: Re: [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 14:41:41 -0000

Hi Richard,

Thanks for the pointer, I had missed your earlier observation of
essentially the same thing in the large mail threads.

Personally, I think it is a substantial and unmotivated loss in security to
also give up authentication/integrity.

Note that any changes towards PERC would require some significant changes
in the security analyses; for mctls, I expect it would be a completely new
analysis. (I haven't seen any analyses of rhrd, but of the three, it is of
course closest to the current setup.)

Best,

Cas


On Fri, Nov 3, 2017 at 2:00 PM, Richard Barnes <rlb@ipv.sx>; wrote:

> Hey Cas,
>
> This question is a good one.  Earlier I brought up mcTLS, which some folks
> have been working on to provide even more granular separations than you
> suggest:
>
> https://mctls.org/
>
> I think the authors of draft-rhrd are trying for a more lightweight change
> to TLS.  That said, there might be some intermediate points on the spectrum
> here.  For example, you could define a TLS ciphersuite akin to what we
> defined in PERC when we wanted to break integrity partly and
> confidentiality not at all.
>
> https://tools.ietf.org/html/draft-ietf-perc-double-07
>
> That would be less invasive than mcTLS, while still getting the properties
> you describe.
>
> --Richard
>
>
> On Nov 3, 2017 09:43, "Cas Cremers" <cas.cremers@cs.ox.ac.uk>; wrote:
>
> 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 mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>