Re: [Curdle] AD Review of draft-ietf-curdle-gss-keyex-sha2-05
denis bider <denisbider.ietf@gmail.com> Sat, 07 April 2018 03:07 UTC
Return-Path: <denisbider.ietf@gmail.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B615A127333 for <curdle@ietfa.amsl.com>; Fri, 6 Apr 2018 20:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Jcwn3x_B0I7d for <curdle@ietfa.amsl.com>; Fri, 6 Apr 2018 20:07:25 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245691271DF for <curdle@ietf.org>; Fri, 6 Apr 2018 20:07:25 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id f8so3266248qtg.12 for <curdle@ietf.org>; Fri, 06 Apr 2018 20:07:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/VYor4QyZeJsABgM83m5170S7bstOgGq+R/E1m01uQU=; b=qGHVYVTyPi0pzN0RqFzCFqzVYN1FtOcyAjL2XD7Objnout+HcVozh/OIqsf7/tDynU Q/t5ApVK5cHumWTYL/Nw3yepGdw732VaZSf/7QvEkHIa49NrWz8pRIKRo7ckeHImpe6p qKzqTFHYfBm9nxbb5fSdNN/cAUQ9LiAg5GTHZUcr5hd/t2afn4v1eyYqz6yJeF+5OaSG OK9Lkxm2wXpAm5xEVhgqCLTP1pbmiNRBvTcB4FP8JEHC5W/kHPWCelK7YiOYXJN1N/47 CrZclMW79lbm3kTgWRm3hZoAEMwLwvWWJeQS0CeHeCN2eo4krgYoisY7aktXb1jPOr6Z Mh8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/VYor4QyZeJsABgM83m5170S7bstOgGq+R/E1m01uQU=; b=QLfZADjeNng9Q0VAysjZV6wZpr7Y8n/bsMLN2dblMxUNntVdjdSVVlx0Tf/GIeKq78 GiQW/sZuuEMKnRW34A3ZCe6sZYKyL9LY8Rmxss/euKDNCsGxJqvkaysEy0AfwTB0/hVB JBgokNg+XqEtGr8Ga0oB0I/SX750f/v10q85dR7VvQpUVSv3M/3HWzQ4gx8749QqoFMV sWket4yceKFuVgurt8IxCl9MPcwQRnFunNDjKJHNiXuXos2CGwiq2L9kmg7/PYkVSxVI bcFfKrXlZR7sqvBpQ27BlPJBhA2cz7sbHeERK5jcUYYdHhiRQ+oKVDmAR+X/hZfbINK+ c3qg==
X-Gm-Message-State: ALQs6tDnOYHTsAzaTfIbaGM0uaUG5T6rifY2Z3V16JhdSJl3SIXy/AXc E8wOiJWMbB3SBYgCSTEjnwfhFyc12vEEL4FGXQY=
X-Google-Smtp-Source: AIpwx4+tB9VC6v8Of0JCh9kC6u0Obawmoy+P9UugKl7dvCkJYvAQoPNSbS081P40uBH4UfkWWbN+tWVW8g7lAn14Vmg=
X-Received: by 10.200.112.214 with SMTP id g22mr41305387qtp.95.1523070444267; Fri, 06 Apr 2018 20:07:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.158.146 with HTTP; Fri, 6 Apr 2018 20:07:23 -0700 (PDT)
In-Reply-To: <CABcZeBN=aHSTGusNWaCDcyv5BtnCjTU9jaTcohY4L-PHYk8e2Q@mail.gmail.com>
References: <CABcZeBNCUSpGihHz6bPBSALS4-34Tm7W36BCZ_Ev8OQz3KtVag@mail.gmail.com> <CADPMZDDjFghyj=1L+kq_XAXiea1W2LNEG9d13YY+OSyyd61niA@mail.gmail.com> <CABcZeBN=aHSTGusNWaCDcyv5BtnCjTU9jaTcohY4L-PHYk8e2Q@mail.gmail.com>
From: denis bider <denisbider.ietf@gmail.com>
Date: Fri, 06 Apr 2018 22:07:23 -0500
Message-ID: <CADPMZDAe0HVz8NKCEPthV6AfZHJPuvk_S7-vMmVZQpyy_0F+vw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: draft-ietf-curdle-gss-keyex-sha2@tools.ietf.org, curdle <curdle@ietf.org>
Content-Type: multipart/alternative; boundary="883d24f3a364cc6dc9056939787e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/omHJyGReXFT2uIwscrvoxAFmiCk>
Subject: Re: [Curdle] AD Review of draft-ietf-curdle-gss-keyex-sha2-05
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Apr 2018 03:07:29 -0000
Well, to avoid algorithm spam. There exist objections to have as many algorithms as we do, to begin with. The added value of a SHA256 version when there already exists a SHA512 version for the same DH group appears particularly small. On Fri, Apr 6, 2018 at 10:03 PM, Eric Rescorla <ekr@rtfm.com> wrote: > > > On Fri, Apr 6, 2018 at 7:52 PM, denis bider <denisbider.ietf@gmail.com> > wrote: > >> Eric: >> >> 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." >> >> https://cryptome.org/2016/01/CNSA-Suite-and-Quantum-Computing-FAQ.pdf >> >> 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. >> > > My question is why these groups are only specified with SHA-512, and not > SHA-256. I think it's fine to specify them for SHA-512. > > > -Ekr > > >> On Fri, Apr 6, 2018 at 6:24 PM, Eric Rescorla <ekr@rtfm.com> wrote: >> >>> Rich version of this review at: >>> https://mozphab-ietf.devsvcdev.mozaws.net/D4544 >>> >>> This document has a huge amount of duplicated material which makes it >>> very hard to read. Please refactor so that the common material is in >>> one place. >>> >>> >>> >>> >>> COMMENTS >>> > Due to security concerns with SHA-1 [RFC6194] and with MODP groups >>> > with less than 2048 bits [NIST-SP-800-131Ar1] we propose the use >>> of >>> > the SHA-2 based hashes with DH group14, group15, group16, group17 >>> and >>> > group18 [RFC3526]. Additionally we add support for key exchange >>> > based on Elliptic Curve Diffie Hellman with NIST P-256, P-384 and >>> > P-521 as well as X25519 and X448 curves. Following the rationale >>> of >>> >>> "the X25519..." >>> >>> >>> > +--------------------------+--------------------------------+ >>> > | Key Exchange Method Name | Implementation Recommendations | >>> > +--------------------------+--------------------------------+ >>> > | 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? >>> >>> >>> > >>> > Each of these methods specifies GSS-API-authenticated >>> Diffie-Hellman >>> > key exchange as described in Section 2.1 of [RFC4462] with >>> SHA-256 >>> > as HASH, and the group defined in Section 8.2 of [RFC4253] The >>> method >>> > name for each method is the concatenation of the string "gss- >>> > group14-sha256-" with the Base64 encoding of the MD5 hash >>> [RFC1321] >>> >>> Why is this MD5? Is there some legacy reason for this? It's not >>> necessarily bad but it's odd to modern eyes. >>> >>> >>> > Each of these methods specifies GSS-API-authenticated >>> Diffie-Hellman >>> > key exchange as described in Section 2.1 of [RFC4462] with >>> SHA-512 >>> > as HASH, and the group defined in Section 7 of [RFC3526] The >>> method >>> > name for each method is the concatenation of the string "gss- >>> > group18-sha512-" with the Base64 encoding of the MD5 hash of the >>> > ASN.1 DER encoding of the underlying GSS-API mechanism's OID. >>> >>> These all seem to be boilerplate. is there a way to refactor into a >>> single paragraph with a table that describes the substitutions? >>> >>> >>> > ASN.1 DER encoding of the underlying GSS-API mechanism's OID. >>> > >>> > 5. New Elliptic Curve Diffie-Hellman Key Exchange methods >>> > >>> > In [RFC5656] new SSH key exchange algorithms based on Elliptic >>> Curve >>> > Cryptography are introduced. We reuse much of section 4 to >>> implement >>> >>> s/implement/define/ >>> >>> >>> > This section defers to [RFC7546] as the source of information on >>> GSS- >>> > API context establishment operations, Section 3 being the most >>> > relevant. All Security Considerations described in [RFC7546] >>> apply >>> > here too. >>> > >>> > The Client: >>> >>> This section should be refactored to put all the EC mechanics (which >>> are symmetrical) in one place. >>> >>> >>> > and then y coordinate. The coordinate coversion MUST >>> preserve >>> > leading zero octets. Thus for nistp521 curve the encoded x >>> > coordinate will always have a length of 66 octets while the >>> Q_C >>> > representation will be 133 octets long. This is the >>> > uncompressed representation specified in Section 4.3.6 of >>> > [ANSI-X9-62-2005]. >>> >>> I have two questions about this: 1. Why are you specifying the >>> detailed computation of the public key? This seems like you could >>> defer it to another spec. 2. Why are you specifying uncompressed >>> representations for NIST curves? We did this in TLS because people >>> already supported them, but in general they are worse. Is there a >>> reason here? >>> >>> >>> > by 31 zero octets for curve255519 and as an octect of value >>> > 0x05 followed by 55 zero octets. >>> > >>> > Calculating Q_C as the result of the call to X25519 or X448 >>> > function, respectively for curve25519 and curve448 key >>> > exchange, with parameters d_C and g. >>> >>> This material all seems to be in RFC 7748 S 6.1 and 6.2. >>> >>> >>> > >>> > For NIST curves, the server verifies that the q_C is not a >>> point >>> > at infinity, that both coordinates are in the interval [0, p - >>> 1], >>> > where p is the prime associated with the curve of the selected >>> key >>> > exchange and that the point lies on the curve (satisfies the >>> curve >>> > equation). >>> >>> You should probably cite to the X9.62 or SP-800 for this procedure. >>> >>> >>> > For curve25519, the server verifies that the the high-order >>> bit of >>> > the last octet is not set - this prevents distinguishing >>> attacks >>> > between implementations that use Montgomery ladder >>> implementation >>> > of the curve and ones that use generic elliptic-curve >>> libraries. >>> > If the bit is set, the key exchange SHOULD fail. For curve448 >>> any >>> > bit can be set. >>> >>> I'm not following what this is supposed to do. If you are worried >>> about this, why don't you just mask off the top bit. >>> >>> >>> > For NIST curves, the peers perform point multiplication >>> using >>> > d_U and q_V to get point P. >>> > >>> > For NIST curves, peers verify that P is not a point at >>> > infinity. If P is a point at infinity, the key exchange >>> MUST >>> > fail. >>> >>> Why is this text here? It describes the client's behavior. >>> >>> >>> > and q_V. The result of the function is the shared secret. >>> > >>> > For curve25519 and curve448, if all the octets of the shared >>> > secret are zero octets, the key exchange MUST fail. >>> > >>> > H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K). >>> >>> This kind of just comes out of nowhere. You probably want some >>> prefatory text. >>> >>> >>> > >>> > 7. C verifies that the key Q_S is valid the same way it is done >>> in >>> > step 3. If the key is not valid the key exchange MUST fail. >>> > >>> > 8. C computes the shared secret K and H and verifies that it is >>> > valid the same way it is done in step 5. It then calls >>> >>> This check only applies to CFRG curves. >>> >>> >>> > string server public host key and certificates (K_S) >>> > >>> > Since this key exchange method does not require the host key to be >>> > used for any encryption operations, this message is OPTIONAL. If >>> the >>> > "null" host key algorithm described in Section 5 of [RFC4462] is >>> > used, this message MUST NOT be sent. >>> >>> I am assuming in this situation there is some other form of >>> authentication? >>> >>> >>> > string I_C, payload of the client's SSH_MSG_KEXINIT >>> > string I_S, payload of the server's SSH_MSG_KEXINIT >>> > string K_S, server's public host key >>> > string Q_C, client's ephemeral public key octet string >>> > string Q_S, server's ephemeral public key octet string >>> > mpint K, shared secret >>> >>> The actual equation is way up above this in the document, which is >>> presumably not great. >>> >>> >>> > Each key exchange method is implicitly registered by this >>> document. >>> > The IESG is considered to be the owner of all these key exchange >>> > methods; this does NOT imply that the IESG is considered to be the >>> > owner of the underlying GSS-API mechanism. >>> > >>> > 5.2.1. gss-nistp256-sha256-* >>> >>> Again, can you refactor this section so it's not so duplicative. >>> >>> >>> > the target the user intended.. Some mechanisms implementations >>> (like >>> > commonly used krb5 libraries) may use insecure DNS resolution to >>> > canonicalize the target name; in these cases spoofing a DNS >>> response >>> > that points to an attacker-controlled machine may results in the >>> user >>> > silently delegating credentials to the attacker, who can then >>> > impersonate the user at will. >>> >>> Is this something new in this document? >>> >>> >>> _______________________________________________ >>> Curdle mailing list >>> Curdle@ietf.org >>> https://www.ietf.org/mailman/listinfo/curdle >>> >>> >> >
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Simo Sorce
- [Curdle] AD Review of draft-ietf-curdle-gss-keyex… Eric Rescorla
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… denis bider
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Eric Rescorla
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… denis bider
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Eric Rescorla
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Salz, Rich
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Russ Housley
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Mark Baushke
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Eric Rescorla
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… denis bider
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Eric Rescorla
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Simo Sorce
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… denis bider
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Simo Sorce
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Benjamin Kaduk
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Hubert Kario
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Eric Rescorla
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… denis bider
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Hubert Kario
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Eric Rescorla
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Hubert Kario
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Simo Sorce
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Eric Rescorla
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Eric Rescorla
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Simo Sorce
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Eric Rescorla
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Mark D. Baushke
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Daniel Migault
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Eric Rescorla
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Salz, Rich
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Eric Rescorla
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Hubert Kario
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Simo Sorce
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Eric Rescorla
- Re: [Curdle] AD Review of draft-ietf-curdle-gss-k… Simo Sorce