Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication?
Richard Barnes <rlb@ipv.sx> Fri, 03 November 2017 14:00 UTC
Return-Path: <rlb@ipv.sx>
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 8A69413FAC5 for <tls@ietfa.amsl.com>; Fri, 3 Nov 2017 07:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 jAPU6XwIqYQo for <tls@ietfa.amsl.com>; Fri, 3 Nov 2017 07:00:22 -0700 (PDT)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 531F013FB6C for <tls@ietf.org>; Fri, 3 Nov 2017 07:00:22 -0700 (PDT)
Received: by mail-wr0-x233.google.com with SMTP id w105so2603258wrc.0 for <tls@ietf.org>; Fri, 03 Nov 2017 07:00:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6dwvIL9Fs3qhDOinDBLLHzZf2dOdcJJ51QoldKWUNfQ=; b=PXy7vGDvDGbcE35opF7g4nEN1GGu/3OetN7QSP1zG0LeZInWigDMjGgpmy+jfdEV5N tOuAx35X8fOGkjdlNtMIC/qJ5kZ+uLhw3/WrE8YiETovjL4fn8cqCoVyAYXJsVsyKFSx GLF5hZ/iu22QmqoqGZnotCx0xlRnScHZWVPfsxY1IUgxbi6WsLVgi5hXafJxyroWZHtr NC81Ppg5qwTn96R2zTqfBxt2tsyP1iSPLsOxXpMiwHsGFbkcdX8WklOW/6o31ueEtWfc 5fzf5lHK6VtBSTlO5X99JhrhPE4DdBEmH5G8aTZAC+d2i8WI5wlv6+HCfTSmj3x0ulvN kUkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6dwvIL9Fs3qhDOinDBLLHzZf2dOdcJJ51QoldKWUNfQ=; b=PHsFvCAUlFMIvc2A3EZafm0ZQXzdf4rBpeNI1iZt2NfSbDXQsz0P4piL3oBs3in9li HQwJLJije4/XQfiDyrLC1G8SdEO2MdaNoM2xhKcf7E7Xzy/uQhIwG+qg3MUzVyJ1m+MC Iu5Iwqt5roFET3UzzWEXsMDvtzRTkIVEiEKDRqmSULtZVi3Y0HXspU+BLtjRvA+64GaT ZANNnJL2d2F966BfV0ny+J3TcHmCqIH+7LPyixzl5usx3MxuDlH00EAOTjYTr5dJXQtk TaFVdi6wwX+XsLB3An+kbY23JcvuXpbhypY4rN32tYCNpS8HlLf6/bNPDcOLKWh6wAv7 qL/Q==
X-Gm-Message-State: AMCzsaVHLcmEnLTMelfC85LoEx+UwGupg13LNUuclxVtfO0VE0c8CK1X 5fHRAHXNrivM/RgAGztI9yXE43gm3ZPfUXvwpkBOXA==
X-Google-Smtp-Source: ABhQp+Qg4Yw4as3BVQgCqRam4kr7A7vZLSqUpPh7XFica34MAgI6X+nMSVRCbKVicmpAqrHG+3Bc8PVRVSrWr7G2eCg=
X-Received: by 10.223.196.156 with SMTP id m28mr6461506wrf.67.1509717620480; Fri, 03 Nov 2017 07:00:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.174.81 with HTTP; Fri, 3 Nov 2017 07:00:19 -0700 (PDT)
Received: by 10.28.174.81 with HTTP; Fri, 3 Nov 2017 07:00:19 -0700 (PDT)
In-Reply-To: <CABdrxL4ZX5GbUhdqmVrhVqwM-MqMsgLL6ow9ksQ8NYBCPvgnfA@mail.gmail.com>
References: <CABdrxL4ZX5GbUhdqmVrhVqwM-MqMsgLL6ow9ksQ8NYBCPvgnfA@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Fri, 03 Nov 2017 10:00:19 -0400
Message-ID: <CAL02cgQMeJAqTtrVBzv254arGQU-88NTJJWgZdoRQguPn14TkQ@mail.gmail.com>
To: Cas Cremers <cas.cremers@cs.ox.ac.uk>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="f403045f54867aef7c055d14860c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8Tlv9RlHIUucujUvKAzjyTckEGk>
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:00:24 -0000
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
- [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