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
>>
>>
>>
>