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

Eric Rescorla <ekr@rtfm.com> Sat, 07 April 2018 14:20 UTC

Return-Path: <ekr@rtfm.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 24C77124217 for <curdle@ietfa.amsl.com>; Sat, 7 Apr 2018 07:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 9eG0zM7nP1H3 for <curdle@ietfa.amsl.com>; Sat, 7 Apr 2018 07:20:04 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 87C24120726 for <curdle@ietf.org>; Sat, 7 Apr 2018 07:20:04 -0700 (PDT)
Received: by mail-oi0-x22f.google.com with SMTP id t16-v6so3668820oih.3 for <curdle@ietf.org>; Sat, 07 Apr 2018 07:20:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xdbS2YwXCitL/+dqWUoxqBFHYkQBucDvketdpeHFYgc=; b=eoXIgPX+35mI/YS4lkG0jq9xhOaXHdLiMdW6o8vF2M/nOs/TiHrq9oJw6vRYJsenvK lvGvL07O5xF7k0ikeerMUE83OyV0oSLnEwWlKZHh0po7EsGP2iTPYXVkj1Mjm/gaThpW L7DnwSMQmAcedI5K84Yefn6XSW9PPkMHQn1d7Ach9DiiNMEIrR99DYnCP7U2X75/YOk8 nYZLP8NVEORhIF/CGKQbepCgh0KLbQ8cq5vZecdoMMxf7k66B0VhfOKC/q0q3qHpzRBu qyWR/ox78IYJDlMeQoT5g9pVbmT/3B54Da59mFci9AJ69uWel6LnSgCzW8MhXG+jtikY iOMQ==
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=xdbS2YwXCitL/+dqWUoxqBFHYkQBucDvketdpeHFYgc=; b=S4GFxGCe3DOxvMSNzMrdLjhX+jcIQCZ5ivofXvs/+5H4Zr3gz81VmwzGidhjahaSI8 SkSKXwUEuJaDOLfp8In03SX8Wtw0NXuaKomh3hIX8oVI0iEYFqnLpRrHCi2VJMYymAg6 rpGeRsemXlzjLjsyGu/DP1T9bvgO0ZaiVFTKuvwrVaplTIeAiUW4f0p2ds7ZtCPJf1gi BjBACGoN2wTO6fGkGqHc2NvaaQkV/YiocP07HTval1waxoyFu9aEIf4oSIlg6IM/21em 4fqqaVG6CfP8wJoeMiuP2M0g2CrXeYmm93dP4uLjyvEwOJE13nQLenND7U/HtFR8Mv4u B4hw==
X-Gm-Message-State: ALQs6tBSxk73jF8lrzw7ukaEbl/QivNMG9grIMLkiJN3FzyOUmzNiF7x QEvQ+zMCgJ2bwTA2C0+bJ2Wf2HIDWP4zptlC5DBKRg==
X-Google-Smtp-Source: AIpwx49WQL5l3KmviiXYHQ7mKTHZCxTbbQ4OtQsjYICO4Er4Boo1dEXultn7rI6WhygQVzEGpTqC9cmJbHrkxtR51As=
X-Received: by 2002:aca:4f46:: with SMTP id d67-v6mr16929341oib.138.1523110803751; Sat, 07 Apr 2018 07:20:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.138.18.130 with HTTP; Sat, 7 Apr 2018 07:19:23 -0700 (PDT)
In-Reply-To: <CADPMZDAe0HVz8NKCEPthV6AfZHJPuvk_S7-vMmVZQpyy_0F+vw@mail.gmail.com>
References: <CABcZeBNCUSpGihHz6bPBSALS4-34Tm7W36BCZ_Ev8OQz3KtVag@mail.gmail.com> <CADPMZDDjFghyj=1L+kq_XAXiea1W2LNEG9d13YY+OSyyd61niA@mail.gmail.com> <CABcZeBN=aHSTGusNWaCDcyv5BtnCjTU9jaTcohY4L-PHYk8e2Q@mail.gmail.com> <CADPMZDAe0HVz8NKCEPthV6AfZHJPuvk_S7-vMmVZQpyy_0F+vw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 7 Apr 2018 07:19:23 -0700
Message-ID: <CABcZeBM-XKUjAWA7jX=ShnQaRdXmAChxNis_PCrqfMXd+yfRmg@mail.gmail.com>
To: denis bider <denisbider.ietf@gmail.com>
Cc: draft-ietf-curdle-gss-keyex-sha2@tools.ietf.org, curdle <curdle@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000695941056942de1c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/s0KOQZkWbfvtf5qojzumcfSzJsU>
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 14:20:08 -0000

On Fri, Apr 6, 2018 at 8:07 PM, denis bider <denisbider.ietf@gmail.com>
wrote:

> 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.
>

The value here would be allowing you to have a 4096-bit DH group without
having to also have a SHA-512 implementation.

I recognize that the NSA recommendations you point to say you should use
SHA-512, however

(a) NSA recommendations don't have any special authority in IETF
(b) they say you should use SHA-512 for *integrity* but assuming I
understand these documents correctly, here H is being used as a KDF, so
it's not clear that the same reasoning applies (especially given that the
document you cite doesn't provide much in the way of reasoning).

-Ekr

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
>>>
>>>
>>
>