Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

Manuel Pégourié-Gonnard <mpg@polarssl.org> Mon, 20 October 2014 12:30 UTC

Return-Path: <mpg@polarssl.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9901A86E5 for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 05:30:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level:
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, 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 kd2VLTFE7Vay for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 05:30:35 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B401A8028 for <tls@ietf.org>; Mon, 20 Oct 2014 05:30:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=iNYDtIvCmu0aA8zn7BHR6MTs1A416OIh2OSCypidp/M=; b=dIdmOcIPHZh2OkSA9KdWRC1/tZYyeNJHUv9L4NWVoSfqO3z2JSLfYs6ilhjRMWVfN2OnxKLsfvk5AzwyazxR509s+4hCzkQJKn/m3mU1CTk7gfIqeQ36LnH2JDgVoMfhhwp9KKeeLAqPksi+8gxJYEZo1dR4rnjdFTUzt7qwoX8=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1XgC6W-0003T6-TH; Mon, 20 Oct 2014 14:30:29 +0200
Message-ID: <54450068.5020101@polarssl.org>
Date: Mon, 20 Oct 2014 14:30:32 +0200
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, "<tls@ietf.org>" <tls@ietf.org>
References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>
In-Reply-To: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5xhQy9xntnTBDqeoi94ly4UNH60
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 20 Oct 2014 12:30:37 -0000

On 26/09/2014 06:00, Joseph Salowey (jsalowey) wrote:
> This is an announcement for the working group last call for
> draft-ietf-tls-downgrade-scsv-00.  Please review the document and send your
> comments to the list by Friday, October 17, 2014.
> 
Just to mention that I just implemented this. As expected (since it's one of the
design goals of the draft), it was very easy.

The only problem I ran into was an interop issue with OpenSSL, which apparently
does not like it if the SCSV appears before the actual ciphersuites in the
ciphersuite list. If the intention of the draft was that the SCSV MUST be placed
after the actual ciphersuites, it would be good to state so using normative
language, rather than the current one which doesn't look normative:

                                     (Since the cipher suite list in the
      ClientHello is ordered by preference, with the client's favorite
      choice first, signaling cipher suite values will generally appear
      after all cipher suites that the client actually intends to
      negotiate.)

Otherwise, it should probably be clarified that servers MUST recognize the SCSV
at any position in the ciphersuite list, which is my preferred option. (It can
be combined with a "clients SHOULD place it after actual ciphersuites", I have
no opinion on that one).

Manuel.