Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication?

Cas Cremers <> Fri, 03 November 2017 14:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73BB613FD6C for <>; Fri, 3 Nov 2017 07:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.398
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bT8yVwmtx6wr for <>; Fri, 3 Nov 2017 07:41:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8EB5013FB55 for <>; Fri, 3 Nov 2017 07:41:24 -0700 (PDT)
Received: by with SMTP id n70so1877982vkf.11 for <>; Fri, 03 Nov 2017 07:41:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id i125mr5529910vkh.149.1509720083582; Fri, 03 Nov 2017 07:41:23 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 3 Nov 2017 07:41:02 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Cas Cremers <>
Date: Fri, 3 Nov 2017 14:41:02 +0000
X-Google-Sender-Auth: YzuHnfq2wbBOCnZXXp47rsV6Y3E
Message-ID: <>
To: Richard Barnes <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="94eb2c0916904ad349055d151911"
Archived-At: <>
Subject: Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.)



On Fri, Nov 3, 2017 at 2:00 PM, Richard Barnes <>; 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:
> 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.
> That would be less invasive than mcTLS, while still getting the properties
> you describe.
> --Richard
> On Nov 3, 2017 09:43, "Cas Cremers" <>; 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