IETF Logo Mail Archive

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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 02 October 2017 21:23 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 C58D01348D1 for <tls@ietfa.amsl.com>; Mon, 2 Oct 2017 14:23:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 sVb1onR-9mku for <tls@ietfa.amsl.com>; Mon, 2 Oct 2017 14:23:10 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 511CF133187 for <tls@ietf.org>; Mon, 2 Oct 2017 14:23:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 88171BF6B; Mon, 2 Oct 2017 22:23:08 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S39r_MU5HokJ; Mon, 2 Oct 2017 22:23:07 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DAA19BF66; Mon, 2 Oct 2017 22:23:06 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1506979387; bh=OAWisZrXCEg4Q2Ajd6ufbzzpdy/vsh6S5cSJDs+QVo8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=bJKDq9TBQAqVLCaZcuBlLJyPD5HI/cwfXPJbEzIARQUIiMQ+Y7+9HMoXvh0+IKoJ/ HaqpRsS++XPz0GsIqYw3x+KxZn0PzEav8MKthqEUwpY11+mVzvPReTyKUIt/iVE5as vE//1N8K/Tw6V4uUwUvN/f5y0Ve0AnKeZN2H2fiA=
To: Ralph Droms <rdroms.ietf@gmail.com>, tls@ietf.org
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <49d914cf-7b33-9379-5659-30ffb18244da@cs.tcd.ie>
Date: Mon, 02 Oct 2017 22:23:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="h2FWh2AFckpf84pu0sPtIpDj67HWIhkHM"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OTqSrelsaj9N0f9ODOEqy75Ssls>
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: Mon, 02 Oct 2017 21:23:13 -0000

Sigh:-(

IMO the WG shouldn't touch this terrible proposal with a
bargepole.

And it remains outside the WG's charter I think. (It would be
a good idea if the chairs would clarify that a re-charter would
be needed were the WG to go bonkers and adopt a terrible idea
like this.)

I guess I'll need to update [1] too. I'll get back when I've
had a chance to do that but will happily accept PRs as before
and will keep an eye on the list.

For starters, though, I'd be interested answers from the authors
to two quick questions, though I suspect I can guess 'em:

1. TLS1.3 has had significant formal analysis. Did the authors
or other proponents here do any such work and if so can you send
a pointer to your results? If not, then I believe the onus is on
the folks who want to break TLS to do that work themselves if they
want to make a serious proposal and it is not ok IMO to try put
that work onto the community who have been working hard for years
to make TLS stronger.

2. Which of the hundreds of applications making use of TLS did
you analyse before proposing this? If only a handful, then same
comment wrt where the onus ought lie.

S.

[1] https://github.com/sftcd/tinfoil#latest


On 02/10/17 21:31, Ralph Droms wrote:
> We are about to publish draft-rhrd-tls-tls13-visibility-00.  The TLS extension defined in this I-D takes into account what we heard from the discussion regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 in Prague. Specifically, it provides an opt-in capability for both the TLS client and server and makes it clear on the wire that visibility will be enabled for the session.  The new mechanism does not depend on static handshake or session keys.  
> 
> - Ralph and Russ
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email