Re: [TLS] FFDHE and SHOULDs on usage

mrex@sap.com (Martin Rex) Sat, 18 April 2015 03:10 UTC

Return-Path: <mrex@sap.com>
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 C69CD1A88DA for <tls@ietfa.amsl.com>; Fri, 17 Apr 2015 20:10:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.652
X-Spam-Level:
X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 JaOjN5BHizxi for <tls@ietfa.amsl.com>; Fri, 17 Apr 2015 20:10:54 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17F81A8883 for <tls@ietf.org>; Fri, 17 Apr 2015 20:10:54 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 53A8144865; Sat, 18 Apr 2015 05:10:52 +0200 (CEST)
X-purgate-ID: 152705::1429326652-0000765A-A95EA3BC/0/0
X-purgate-size: 1080
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 309DD460A9; Sat, 18 Apr 2015 05:10:52 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 221221B2A1; Sat, 18 Apr 2015 05:10:52 +0200 (CEST)
In-Reply-To: <87fv80nnev.fsf@alice.fifthhorseman.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Sat, 18 Apr 2015 05:10:52 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150418031052.221221B2A1@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Ekrr9eTR9vP2TBSTgYTbbE4f2yc>
Cc: tls@ietf.org
Subject: Re: [TLS] FFDHE and SHOULDs on usage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Sat, 18 Apr 2015 03:10:56 -0000

Daniel Kahn Gillmor wrote:
>>
>> Groups are ordered based on client preference, noting the additional
>> ordering considerations in Section 6.1.
> 
> Also, this rewrite says "ordered based on client preferences" but
> doesn't indicate which order based on client preferences: most preferred
> to least preferred or the other way around.  It may be pedantic, but
> this is exactly the sort of pedantry that RFCs should include.


Could we just scrap the "based on xxx preference" nonsense entirely?

The sender of the list sends whatever it sees fit, and the receiver
of the list has the privilege to pick what ever the receiver believes
is most appropriate from the receivers point of view.

I never understood why (a) such a silly suggestion was made for
the ordering of cipher suites in ClientHello and (b) why any TLS server
implementaion would care for the client's ordering rather than enforcing
the server preference.  If the client does not want something, it must
not offer it.  If the server does not want something, it must not pick it.

-Martin