Re: [Curdle] AD Review of draft-ietf-curdle-gss-keyex-sha2-05

Mark Baushke <> Sat, 07 April 2018 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A25E112D874 for <>; Sat, 7 Apr 2018 09:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Byb7tPMh4YG8 for <>; Sat, 7 Apr 2018 09:59:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C22921204DA for <>; Sat, 7 Apr 2018 09:59:13 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w37GxCxu000966; Sat, 7 Apr 2018 09:59:12 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=3QUAjwqcE5xiqu5KPhTCsvlJyToBv7ddU2X2rMlVHOA=; b=CMh63407idPHNp2SjjV056EeGveaJuAIqDbijDLM6k1jX4g00qBJ9Z1RbYJAvh2Aq6rq tsu2S0QmmaRJXZYHS72Iqw2BNN3pqGMQYr2k68tIk/qsJupIckJt9sO4rVHKsLgRAIBt z3gtDLtM4UYAbT99wquS7eki5L6+3yov2G67rnlPu4foqSlqwgh4lROz3/IljsuLJ0Xo z90rOeqAOkcxY6s2DpG7KFRy+UFKpcXN6PCsjTBufKYqmIP7rQj8gA2PYbVtxtZoyvgI SVH/FFDSV8GWevP3dPfkEpFu7ktGp3Kt5RtPoj+xzKOektygE4hs4mB+oJKwlLQ6aMGG Bg==
Received: from ( []) by with ESMTP id 2h6uxu0f3x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 07 Apr 2018 09:59:12 -0700
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.4; Sat, 7 Apr 2018 16:59:09 +0000
Received: from ([fe80::551:828b:247d:d070]) by ([fe80::551:828b:247d:d070%15]) with mapi id 15.20.0675.004; Sat, 7 Apr 2018 16:59:08 +0000
From: Mark Baushke <>
To: Russ Housley <>
CC: denis bider <>, Eric Rescorla <>, curdle <>, "" <>
Thread-Topic: [Curdle] AD Review of draft-ietf-curdle-gss-keyex-sha2-05
Thread-Index: AQHTzf6GjVWMYgFDtkKXKasroKm1JaP0mwsAgADOOICAAB47gA==
Date: Sat, 7 Apr 2018 16:59:08 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB403; 7:EgftQZXJdbyUZNh6yGzmOyM7Ydr7TVk+y5zI7maXB6+4I2Kti0QgQpBVKIlrI1dIzO7tOXb7cOp9XqigKGOJxYoXg3hU5ygGRiTmkp9jJnBSThdKbJrHVL6IFC9f6vzId0w1lMeeaVuCfhVS5AFvKghaytjFvOBVTLcFaHoeaWeXQ3EyTuBoxsfaMwnNPplI3ZFUifb3YQfcQOOUmVEwZsly7+sq4sEZQz6MerRE07ltVLdbhwDaWGhC8Wrknppk
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: c9b9d5f4-b9db-4d46-8e4a-08d59ca8e0c9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BLUPR05MB403;
x-ms-traffictypediagnostic: BLUPR05MB403:
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(131022147185803)(21532816269658);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231221)(944501327)(52105095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:BLUPR05MB403; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB403;
x-forefront-prvs: 0635D5275E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(39860400002)(39380400002)(396003)(199004)(189003)(966005)(8676002)(2900100001)(105586002)(66066001)(53936002)(36756003)(3660700001)(5250100002)(8936002)(6306002)(6436002)(6512007)(305945005)(486006)(3280700002)(99286004)(11346002)(59450400001)(83716003)(476003)(68736007)(6506007)(86362001)(54906003)(76176011)(33656002)(6246003)(7736002)(478600001)(6486002)(2616005)(25786009)(97736004)(5660300001)(14454004)(446003)(39060400002)(26005)(53546011)(316002)(4326008)(102836004)(186003)(81166006)(2906002)(82746002)(81156014)(6916009)(6116002)(106356001)(3846002)(229853002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB403;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: xbk+qIqUQcFlS3Sdb6VroGWGjReXtIw83ZY1+M7cRzIhEkfm6w11blJc559/TRqgWJW2Oq7oKIU4H1XIWGhSqgV8Y0yY3Mk4YSFR1If0PCcsdZo/dtuOTb7HRSENLpUKn8rqO4+uAZRCc2zXzEGIUZa0nzK58UZolF0TMyGKDc+2qYGo/7RFqgOnVCKJ1BCVZQb1+kdz7txagW49Cgx6uzc+e/k2JamPTsr14UqgriMZVKVKKVRQBBx7jfMUr8ttm9yDgjP1as/1lYWGALVu3SQnb7HTbKAwdQXbW3PEc0vZ/1brEzwtNRvQaLu8DyLPPOtq09I3wz/m8afUh0hP9+8lHLgE3XDtV83PPtAeAy+v7Txl6YXQfVvQrW43P5aOEyG0Fy/cz1YHSEaKIO/w7m0BuC5wN9r7brqDFvxU9Ic=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c9b9d5f4-b9db-4d46-8e4a-08d59ca8e0c9
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2018 16:59:08.0350 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB403
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-07_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804070186
Archived-At: <>
Subject: Re: [Curdle] AD Review of draft-ietf-curdle-gss-keyex-sha2-05
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 07 Apr 2018 16:59:16 -0000

> On Apr 7, 2018, at 8:10 AM, Russ Housley <> wrote:
> Denis:
>> I'm not an author of this draft, but I can respond with respect to the following:
>> > > | gss-group14-sha256-*     | SHOULD/RECOMMENDED
>> > > | gss-group15-sha512-*     | MAY/OPTIONAL
>> > > | gss-group16-sha512-*     | SHOULD/RECOMMENDED
>> >
>> > Why are you only specifying SHA-512 with 4096-bit groups.
>> > SHA-256 is still reasonable at that size?
>> There exist NSA recommendations aimed at "organizations that run classified or unclassified national security systems (NSS) and vendors that build products used in NSS."
>> These recommendations cover a usage case for software that implements the above algorithms. These recommendations call for the following minimums:
>> - Diffie Hellman: 3072-bit or larger
>> - Hashing: SHA-384 or larger
>> These recommendations are most effectively met by associating group15 and group16 with SHA-512.
>> Otherwise, products that wanted to meet these recommendations would have to use much larger and more expensive DH groups in order to meet the SHA-384-or-better requirement.
> I do not quite understand this response.  I can understand a desire to include a ciphersuite that aligns with the NSA guidance so that anyone that needs to follow it can easily do so, but that does not seem to be what you are suggesting.  Looking at page 2 of the document that you cite, a ciphersuite that uses the NIST P-384 curve, SHA-384, and AES-256 is needed.

The key exchange ECDH NISTP-384 with SHA-384 is already in RFC 5656 along with ECDSA NISTP-384 with SHA-384 as a public key algorithm.

AES256-CBC is OPTIONAL in RFC4250 and RFC4253 as a symmectric cipher.

AES256-CTR is RECOMMENDED in RFC4344 as a symmectric cipher.

RFC3526 groups are provided for SSH in RFC8268:

group14 with sha256 is SHOULD/RECOMMENDED in RFC8268

group15 with sha512 is OPTIONAL in RFC8268

group16 with sha512 is OPTIONAL in RFC8268

group17 with sha512 is OPTIONAL in RFC8268

group18 with sha512 is OPTIONAL in RFC8268

Should we have decomposed the group with the hash? Or, should we have used shorter key exchange algorithm names? 
Well, perhaps both would have been better, but that should have been done some years ago.

The negotation list is getting a bit long these days and the SSH implementors did not seem to fancy adding SHA256, SHA384, and SHA512 variations of each of the new diffie-hellman groups being added, so the longest one (SHA512) was chosen as it slightly faster to implement on 64-bit architecture machines.

I am given to understand that NIST SP 800-56A revision 3 and FIPS PUB 186-5 may address the use of Finite Field Cryptography safe primes for Diffie-Hellman key exchange sometime this year. (see also URL:
section 5.5.1 and Appendix E which allow RFC3526 and RFC7919 groups)

For myself, I tend to think that using 2048-bit prime P FFC Diffie-Hellman provable primes that are generated on a bi-weekly basis with Q as a large subgroup of approximately P/2 bits in length and G is a proper generator of q-ordered subgroups. If changed often enough, then there would be no big push to try to precalcualte the majority of the factors of such parameters. Even if we have sufficient sieves to help in factorization, there is still a lot of computation behind breaking a large subgroup. In a Post-Quantum Cryptography world, I tend to trust large FFC calculations over small ECC calculations. Although something better than either would be welcome... always allowing it is desirable to still be able to connect to small embedded devices too.

With RFC4419 and RFC8270 we get safe primes generated with P being a 2048-bits or larger prime. The only downside is that the example calcuation does not always choose a generator g which generates a q-ordered subgroup.

> I would be in favor os adding such a ciphersuite as MAY/OPTIONAL.

I think this may already be present, depending on what you are asking.

For myself, I see no problems with the GSS variations of diffie-hellman using the same groups and hashes as RFC8268.
For gss-group14-sha256-* I support RECOMMENDED to move away from the SHA1 variation. I am okay with
gss-group16-sha512-* as either OPTIONAL or RECOMMENDED.

        -- Mark