Re: [Uta] Richard Barnes' Discuss on draft-ietf-uta-tls-bcp-09: (with DISCUSS and COMMENT)
Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 19 February 2015 10:17 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250A71A8A63; Thu, 19 Feb 2015 02:17:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 9gcEV-rBFT8g; Thu, 19 Feb 2015 02:17:54 -0800 (PST)
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 74DE11A8A44; Thu, 19 Feb 2015 02:17:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 41EF1BEC4; Thu, 19 Feb 2015 10:17:53 +0000 (GMT)
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 4Ehhc4yUtgTu; Thu, 19 Feb 2015 10:17:51 +0000 (GMT)
Received: from [10.10.5.195] (unknown [216.127.117.11]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 41F17BE8E; Thu, 19 Feb 2015 10:17:50 +0000 (GMT)
Message-ID: <54E5B84C.9040400@cs.tcd.ie>
Date: Thu, 19 Feb 2015 10:17:48 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Richard Barnes <rlb@ipv.sx>, Peter Saint-Andre - &yet <peter@andyet.net>
References: <20150219033433.10815.25308.idtracker@ietfa.amsl.com> <54E56454.7080307@andyet.net> <CAL02cgS+h2jkOChJkoCy7gHvFQEe22SRRAg5om00ZpiHCOi_2g@mail.gmail.com>
In-Reply-To: <CAL02cgS+h2jkOChJkoCy7gHvFQEe22SRRAg5om00ZpiHCOi_2g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/S0X6uhwwRAbYNYBRm-7YXQivJwM>
Cc: "uta@ietf.org" <uta@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [Uta] Richard Barnes' Discuss on draft-ietf-uta-tls-bcp-09: (with DISCUSS and COMMENT)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2015 10:17:57 -0000
On 19/02/15 04:57, Richard Barnes wrote: > On Wed, Feb 18, 2015 at 11:19 PM, Peter Saint-Andre - &yet <peter@andyet.net >> wrote: > >> Hi Richard, thanks for the thoughtful review. Comments inline. >> >> On 2/18/15 8:34 PM, Richard Barnes wrote: >> >>> Richard Barnes has entered the following ballot position for >>> draft-ietf-uta-tls-bcp-09: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> I really can't abide by the abdication in Section 5.2. >>> >> >> Abdication is an awfully strong word. >> > > And deliberately so. Maybe it's just late here, but the current text reads > to me as incredibly weak. > > > >> Getting a cert is >>> hard. Running reasonably recent software and configuring it properly is >>> not. The possibility that a connection will not be authenticated is no >>> excuse for using bad versions of TLS or using insecure ciphersuites. >>> >>> I appreciate that normally deference to WG consensus is appropriate, but >>> this is a recommendation that could be actively harmful to the Internet >>> by encouraging the continued use of broken code. >>> >> >> I think the document, then, does not provide clear enough text. >> >> I do not think we intended to actively recommend that anyone run broken >> code, use outdated versions of TLS, use insecure ciphersuites, etc. > > > Good. I'm glad we agree on this. > > Could I ask the opposite question? Which recommendations in the document > did people think *could* be violated in an unauthenticated context? > > > >> However, we are saying that this document was not written specifically to >> cover unauthenticated TLS usages because that was a point of strong >> contention in the WG and we were not able to reach consensus. The thread >> beginning here is illustrative: >> >> http://www.ietf.org/mail-archive/web/uta/current/msg00625.html >> > > Thanks for the link. That adds some helpful context. > > It also seems to me to illustrate that there's not much clarity in the > group about what problem this section is trying to solve. > > Part of the source of my confusion here is that from the pure perspective > of TLS, the server is *always* authenticated (and the client, Factually incorrect. Anon-DH has been present in TLS since the beginning. If your DISCUSS is based on that misapprehension then you need to re-consider. S. > if mutual > auth is used) -- you always know what key you're talking to. Any binding > of that key to an identity is exogenous to TLS. > > Everything in the document besides Section 5 gets this right. There's no > mention of requirements on PKIX, or PGP certs, etc, except for some > indirect mentions in the Security Considerations. > > So it seems to me that this section is pure harm. It takes a document that > got the layering right, introduces semantic confusion, and thereby arrives > at a giant loophole. > > Can we just delete it? > > > > If you are insisting that this document be remanded to the WG with >> instructions that it reach consensus one way or the other, then please let >> us know. >> >> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> These COMMENTs are right on the edge of being DISCUSS points, because I >>> think there are some pretty critical references missing. Please consider >>> this a COMMENT of Unusual Strength. >>> >>> Section 1. "which together are the most widely deployed ciphers" >>> >>> Actually, at least in the web context, this isn't totally true. >>> According to Firefox telemetry, AES-GCM has been the most widely deployed >>> cipher since at least 3Q14, and is currently used in the majority of TLS >>> handshakes that Firefox does (52%) [1]. >>> >> >> As a result of addressing a comment from another IESG member, we will be >> changing "are" to "have been" in the quoted text. >> > > Great. "among the most" would have been fine too :) > > > >> Section 3.1.1. Implementations MUST NOT negotiate SSL version 3 >>> >>> A reference to draft-ietf-tls-sslv3-diediedie seems in order here. >>> >> >> Are you thinking that would be a normative reference or an informative >> reference? >> > > Informative will be fine. It just provides more background for this > requirement, and FWIW, duplicates it: > https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-00#section-2 > > > >> Section 3.1. >>> >>> It would be good for this section to mention that servers MUST implement >>> TLS version negotiation. That is, they MUST NOT abort the handshake if >>> the version offered by the client is higher than the version the server >>> supports. This is, after all, the root cause of fallback. >>> >> >> Good point. >> >> Section 3.1.3. >>> >>> I'm surprised that there's not even a SHOULD CONSIDER [RFC6919] for SCSV >>> here. Did the WG discuss having any requirement for SCSV? >>> >> >> As I recall, the (brief) discussion concluded that a normative dependency >> on draft-ietf-tls-downgrade-scsv was not yet appropriate because it is too >> new to yet be a best *current* practice. >> >> On a more general note, the WG considered a number of recent proposals for >> TLS hardening, but concluded as well that they were too new to recommend >> quite yet. There is breaking news (pun intended) every week about TLS and >> there's no way that a document like this can reflect the very latest ideas >> and suggestions - we tried to balance practices that are (or might be >> considered) "best" against practices that are implemented and can be >> deployed today. IMHO the most we can do is get this BCP published and, as >> needed, update or replace it with improved recommendations on a regular >> basis (say, every year or two). This document was supposed to be published >> quickly after IETF 88 and is already late. >> > > Fair enough. Thanks for the background. > > > >> Also, if you want a cite for the 3% number, it's in the proceedings of >>> IETF 91 [2]. >>> >> >> Thanks. >> >> Section 3.3. >>> >>> You might point out HPACK [3] as an example of compression that is >>> sensitive to things like CRIME. >>> >> >> I see no harm in an informative reference. >> >> Section 3.5. >>> >>> Shouldn't this refer more specifically to draft-ietf-tls-session-hash >>> [4]? As it is, the recommendations in this section are kind of vacuous; >>> e.g., TLS without session-hash provides no way to "bind the master secret >>> to the full handshake". >>> >> >> Yes, that's what [triple-handshake] cites as well, and I agree that a >> pointer to it would be helpful. >> > > Yes, please make this direct. > > > >> Section 4.4. "Modular vs. Elliptic Curve" >>> >>> I think that "finite field" or "modp" are more common than "modular". >>> >> >> I have been told that elliptic curves are also finite fields, but I am not >> a cryptographer. >> > > /me dusts off his math degree... > > To get very technical, elliptic curves are finite *groups* (they're not > fields; they have no multiplication operation), whereas a modp group is the > multiplicative group of a finite field. > > --Richard > > > >> >> Peter >> >> >> >
- [Uta] Richard Barnes' Discuss on draft-ietf-uta-t… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Pete Resnick
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Peter Saint-Andre - &yet
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Pete Resnick
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Brian Smith
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Brian Smith
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Leif Johansson
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Stephen Farrell
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Viktor Dukhovni
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Ralph Holz
- Re: [Uta] Modular vs. modp Peter Saint-Andre - &yet
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Peter Saint-Andre - &yet
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Eric Rescorla
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Peter Saint-Andre - &yet
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Stephen Farrell
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Pete Resnick
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Peter Saint-Andre - &yet
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Peter Saint-Andre - &yet
- [Uta] Modular vs. modp (was: Richard Barnes' Disc… Viktor Dukhovni
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Stephen Farrell
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Richard Barnes
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Leif Johansson
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Daniel Kahn Gillmor
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Leif Johansson
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Peter Saint-Andre - &yet
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Pete Resnick
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… t.p.
- Re: [Uta] Richard Barnes' Discuss on draft-ietf-u… Pete Resnick