Re: [TLS] ID Tracker State Update Notice: <draft-ietf-tls-negotiated-ff-dhe-08.txt>

Andrey Jivsov <> Fri, 24 April 2015 07:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B4D471B354E for <>; Fri, 24 Apr 2015 00:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V8zhqog4O45U for <>; Fri, 24 Apr 2015 00:34:08 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 002171B356B for <>; Fri, 24 Apr 2015 00:32:50 -0700 (PDT)
Received: from ([]) by with comcast id KjYg1q001516pyw01jYqhU; Fri, 24 Apr 2015 07:32:50 +0000
Received: from [] ([]) by with comcast id KjYp1q0024uhcbK01jYpar; Fri, 24 Apr 2015 07:32:50 +0000
Message-ID: <>
Date: Fri, 24 Apr 2015 00:32:49 -0700
From: Andrey Jivsov <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1429860770; bh=SPfcN4mJIlJORhLONc3VWkSQaomhQUZ2UC35RFPZhoM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HCeQpsABa+WCVzH83jBH6M4cYO28rvGBpOlrPVr2nDJfejRo9eXEBIMTpFG0ylAtj tjsa5BFiLjgdGjKSLWvTfRpwV3aEPKUzfoChwdrBnSpSbI8hq0fJmhQvwqHrRm92Hq ENGsQEUo1KkiA96+h3WsBdzWUv/eSpx4SdR/LRGrVNlhzJRy1CgxvtCtrcfxjNPr/b sNh487VC9t4lIMDUfWa4AKUWfraOsqLkZKenbZfETrKFSKqLRNTNe3/UiqCS+W0txg QeR1bR/VkjJxbuURxsSY6c4AENwecmTCrpjDi4Dab6burRre8nWaYpmcz/r3LVxpAL 6C/SnIO82qZsw==
Archived-At: <>
Subject: Re: [TLS] ID Tracker State Update Notice: <draft-ietf-tls-negotiated-ff-dhe-08.txt>
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Apr 2015 07:34:11 -0000

I have a mostly editorial comment for sec 1.

The document calls the composite group with p-1 elements a "group" in 
sec 5. The document calls the the 2-element group in sec 5.1 a "small 
subgroup". The document calls the prime group with q=(p-1)/2 elements a 
"group" in sec. A.

Let's say we continue to call the q-element subset of p-1-element group 
a group, and continue to call the 2-element subset of p-1-element group 
a subgroup.

My concern is that the sec. 1 may be interpreted as that by virtue of 
using groups from this document a client avoids the issue of small 
subgroups. In reality, the main benefit of groups in this document is 
that they give us the minimal small subgroup and there is an efficient 
check for the membership in the large (sub)group. This check is 
correctly specified in sec 5.1, but it should not be skipped.

1. The sentences with two first occurrences of "subgroup", both in 
section 1, should be reworded to not suggest that this document avoids 
small subgroups.

2. One can go further and try to clear the terminology about the group 
by assuming that the
- _group_ has p-1
- _prime group_ has q
- _small subgroup_ has 2 elements.

i.e. insert "prime" in front of some "group", where appropriate.

BTW, I like the ability for the client to indicate the support for the 
DH group size.