Re: [Uta] TLS BCP Review

Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 22 July 2014 12:00 UTC

Return-Path: <yaronf.ietf@gmail.com>
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 702B21A01A9 for <uta@ietfa.amsl.com>; Tue, 22 Jul 2014 05:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level:
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no
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 ImSbBudlE2o9 for <uta@ietfa.amsl.com>; Tue, 22 Jul 2014 05:00:21 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5301A00DE for <uta@ietf.org>; Tue, 22 Jul 2014 05:00:20 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id hi2so5812272wib.10 for <uta@ietf.org>; Tue, 22 Jul 2014 05:00:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=H5BT5unAWL7M7LmMsarLwEdNLDS2FE8yJgLJ/mzPn+8=; b=jyABBW0eqCoTKrYtP6kcxiuRw6Cmg+5h6efZnyLCzGNH/MykdB8TtaQcKDYnXZ3u/i mGI0gcna76bxsrT3AO8kud1wJM9tJnGI8a2UHixcCsIpl6LGfkN0mhnBUglayYavE4cm V9PI4z/X+bX2vhuN7XMBN5Sk+++K2iiLnaychU7iV4fz4EIRKX0u5ojHU+GO7fn4fnae LvwQLOMB1A+eW2LMuKiEURfFNv30OL9gqauZKarptVXz1i91AQDUvXqX7RNdhtGlAE1O sZAG0kgtxUkAl+u8otwe712NVoB0zpdWJGhV1thvxSGbOLt0w2KD/pPjALwvQ0pOreIE CvAg==
X-Received: by 10.180.89.34 with SMTP id bl2mr14089295wib.41.1406030418580; Tue, 22 Jul 2014 05:00:18 -0700 (PDT)
Received: from [192.168.0.8] ([89.138.231.48]) by mx.google.com with ESMTPSA id q11sm1980217wib.14.2014.07.22.05.00.17 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 05:00:18 -0700 (PDT)
Message-ID: <53CE5251.8000106@gmail.com>
Date: Tue, 22 Jul 2014 15:00:17 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Aaron Zauner <azet@azet.org>, "uta@ietf.org" <uta@ietf.org>
References: <53CD8C01.4050808@azet.org>
In-Reply-To: <53CD8C01.4050808@azet.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/uta/RIyiPcU24YaG-8WgZgDyIAk-CVw
Subject: Re: [Uta] TLS BCP Review
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: Tue, 22 Jul 2014 12:00:22 -0000

Hi Aaron,

Thanks for your review. Please see some responses below. Unfortunately 
your review came too late to include your points in the presentation 
today, feel free to raise them during the discussion.

Best,
	Yaron

On 07/22/2014 12:54 AM, Aaron Zauner wrote:
> Hi *,
>
> I'm in the process of reviewing the BCP currently and do have a couple
> of open questions and remarks before submitting a patch. Please excuse
> me if some of them have already been asked before on the mailing list,
> although I tried to go through most of the mails, I might have missed some.
>
>     * the document on github seems to be out of sync with the document
>       that is currently available on the IETF website.

Yes, sorry about that. As Leif mentioned, the main discussion needs to 
be on this list.

>
>     * I've found some typos, rhetorical flaws w.r.t phrasing throughout
>       the document as well as missing information in reasoning parts. I
>       would be willing to submit a patch and a related message
>       explaining changes (if need be) to this list. is that acceptable?
>
>     * the document effectively states in 1. that TLS 1.3 will obsolete
>       this document. UTA should still give recommendations for legacy
>       protocols that will be widely deployed on the internet. although
>       faster than it used to be - TLS adoption is still very slow.

Yes, but the situation will change once 1.3 is out. An implementor will 
need to make a choice whether to spend time/money implementing this BCP, 
or spend time/money moving to 1.3, or maybe deploy 1.3 and use this 
draft to close any remaining issues.

>
>     * 3.1. states that SSLv2 has "serious security vulnerabilities"
>       while this is true, it does not emphasize how broken SSLv2
>       actually is. how about changing the wording to "considered to be
>       insecure"?

OK.

>
>     * as for the deployment of "3%", mentioned in 3.2. - previous
>       posters have pointed to the scans by j.vehent and sslpulse/qualys.
>       there's also a monthly scan being conducted by h.kario of
>       redhat [0].

As you point out, there are several scans (and the numbers vary between 
them...). We might remove the reference altogether.

>
>     * in 3.6 disabling compression is a SHOULD. with the issues currently
>       raised by attacks this has to be a MUST in my opinion. and:
>
>     * the document does not mention issues with compression in underlying
>       applications when using TLS (e.g. BREACH for HTTP).

Good point, we may need to do that.

>
>     * 4.2: once accepted (and everything looks this way) the draft by DKG
>       will obsolete parts of this section [2].

This is a point-in-time document. The DHE draft, as well as fallback 
SCSV, CT and pinning are important changes. When any of them is 
standardized and deployed at scale, some sections here will need to 
change. But we are not there yet.

>
>     * currently the document provides for no reasoning as to why no ECDSA
>       ciphersuites have been included. while I agree that they should be
>       excluded, one should include a sentence or two on the matter. I'm
>       not an expert with DSA/DSS so I can just refer to [1] and the
>       sources mentioned therein.

Because VERY few servers use ECDSA certs.

>
>     * the document currently does not mention any views for
>       standardization bodies and implementors on key pinning (TACK,
>       HTKP).

See above.

>
>     * the document currently does not mention any views for
>       standardization bodies and implementors on certificate
>       transparency.

Ditto.

>
> That's all for now, I'm pretty sure I'll come up with more.
>
> Thanks for your time,
> Aaron
>
> Sources:
> [0] - http://securitypitfalls.wordpress.com
> [1] - http://blog.cr.yp.to/20140323-ecdsa.html
> [2] - http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe
>
>
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>