IETF Logo Mail Archive

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Richard Barnes <rlb@ipv.sx> Wed, 25 October 2017 22:37 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 1980513F4A8 for <tls@ietfa.amsl.com>; Wed, 25 Oct 2017 15:37:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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] 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 e8Ghm-G1VPGP for <tls@ietfa.amsl.com>; Wed, 25 Oct 2017 15:37:45 -0700 (PDT)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 F234713F49F for <tls@ietf.org>; Wed, 25 Oct 2017 15:37:44 -0700 (PDT)
Received: by mail-wr0-x22b.google.com with SMTP id o44so1418637wrf.11 for <tls@ietf.org>; Wed, 25 Oct 2017 15:37:44 -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=XsOlocoLySwCmj0Vq+bo0+DsmBb0WdZwQrMeZ3eOBOg=; b=cGZ6iMR/aIJ7R5DQhJkEHuWv4CaNHYHg/GTw4JBRtoaZRfT2Y5Z4UzB4BdwSsxom8b YYsl8B8v8Rei7UHM1P2bDb/GAKlwTZtagYxf51caX9AsfM5gOI44btF+KmZVLgmTAM1S +ZJIfsfK5SOnT/9KBATK67b9fN/PjxbH86mI6FENdnXgDhdL87elyUyMf1eLZC2VGuMI 9KJOGCdPM61HhUU4f/bOP5qLho0W2O0bNtFnpAIMWH9sNNPhZZ9pv1qGQIQl6Hc9HeTI Dgd2bx8ma3wtqNL5dF9LcCg4ZEVLxFZu+XFwPytfZgZPl+2Gj2Z/cXiDQaZDB2cWDPUQ RY1w==
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=XsOlocoLySwCmj0Vq+bo0+DsmBb0WdZwQrMeZ3eOBOg=; b=YeAGEOm2JCZTQg+bZKkp2wQ9vsfym5RA40f0o60DzwrMMpcJG9pJ3W13uEjWuQR4eI opiGR4E6NPU0BG1dVmRLYZRVTtIKFlDiRweSCCN/1k8Vlo/gqNoKtBh/Wd9hnPlhtafX 5rJYJ1esjo8NDMPxyyWb2BOXA9fbFQNuzoRBtcvKsKFv6S4CS1DM/jrBF6hh530bfcZL rhuEqEDMol4JQa9e1IgrXbwpOlj/lUxwwybAsyyY8ywEE0SY3aRb5iKJnBIehiWOXz1z HOY9pTF/0F5+9rXUEfn7fjQmiMwlyLqFyqKCMSssiu7z7LfbvQo5XQicjeo16H5lOEBU KW1A==
X-Gm-Message-State: AMCzsaVXkAJ4f3ZYRzkvvUep/h7O7Eb6TH9fb5lUspLHlS69XFJWokDl glNKVDDknUpsYzlyI0FMZRM3LGcjjGQcdHi5m/13Xw==
X-Google-Smtp-Source: ABhQp+RK8O6k0f+a3bLJikjsrp8G1ctgIa8xAFbEyvDqxHRM3hlTi35YDH5+Pp631/M6t/5vYbbQHjzJLoDl5FExWVQ=
X-Received: by 10.223.196.156 with SMTP id m28mr3772778wrf.67.1508971063104; Wed, 25 Oct 2017 15:37:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.174.81 with HTTP; Wed, 25 Oct 2017 15:37:41 -0700 (PDT)
Received: by 10.28.174.81 with HTTP; Wed, 25 Oct 2017 15:37:41 -0700 (PDT)
In-Reply-To: <CAL02cgRWogUJUaQVCUbiDqihMC8e3bdf_H9TqkMz4r-TvoNq=g@mail.gmail.com>
References: <cde0e322-797c-56e8-8c8d-655248ed7974@nist.gov> <FB95CAC8-C967-4724-90FB-B7E609DADF45@akamai.com> <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <10a00f17-37e9-622d-1d48-8febdc6a5d5b@cs.tcd.ie> <CAL02cgQ86jVMZK+hXF3Ugkepe4K1+1kLgqVMbVZRBHyito+LKQ@mail.gmail.com> <CAL02cgRWogUJUaQVCUbiDqihMC8e3bdf_H9TqkMz4r-TvoNq=g@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 25 Oct 2017 23:37:41 +0100
Message-ID: <CAL02cgSS54ATHO0wqRoRhLhFcJbwtxf=8jZwBNE7arFHYxayvQ@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="f403045f548631943d055c66b423"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wYXBuQxmaiblFmuw7GcEb3GeCi8>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-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: Wed, 25 Oct 2017 22:37:47 -0000

On Oct 25, 2017 22:34, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:


Replying to just a couple of bits...

On 25/10/17 15:23, David A. Cooper wrote:
> Similarly, the best that TLS can offer in terms of privacy is that the
> contents of the communication between the two endpoints is not seen by
> anyone else *unless* at least one of the two endpoints (client or
> server) chooses to provide the contents of the communication to some
> other entity. draft-rhrd-tls-tls13-visibility doesn't change that.

The above is nonsense. The draft in question clearly proposes
fundamentally changing the feature set of TLS to include snooping
as a standard, supported feature.


Sorry, what?  The current draft proposes an extension, literally the
opposite of a standard, supported feature.  It's explicitly optional.

I don't really have a dog in this fight, but let's please be accurate.

--Richard


> But, I'm tired of the abusive
> and false suggestions that draft-rhrd-tls-tls13-visibility is a
> "wiretapping" draft or that it is defining a "please-screw-me
> extension."

Abusive of what/whom? The truth or falsity of the wiretapping
description is a matter for debate. (Russ' argument that these
are not witetapping features is one I find to be lawyerly nit
picking based on a partial reading of 2804, but I believe he
does believe that.) I'm fine that you ignore that there are
other opinions.

I also don't really care if the proponents of snooping as a
standard feature get tired to their ideas being criticised to
be honest. I am, and will remain, available to offer such
criticism.

And FWIW, I consider the use of euphemisms like "passive" or
"visibility" here to be deceptive. Perhaps not deliberately
deceptive, (I'm not saying the authors of the draft are trying
to deceive), but nonetheless I find such abuses of language
far more irritating than the occasional bit of robustness in
debate. Such euphemisms are also more long-term damaging IMO.

This draft and the one before it are proposing supporting an
active attacker in the middle of TLS sessions and that is how
we ought be discussing this, not as some pretend passive
good-natured observer capability.

S.


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email