Re: [Cfrg] I-D Action: draft-irtf-cfrg-spake2-08.txt

Greg Hudson <ghudson@mit.edu> Wed, 13 March 2019 04:39 UTC

Return-Path: <ghudson@mit.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D876F12AF7D for <cfrg@ietfa.amsl.com>; Tue, 12 Mar 2019 21:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 XkKg5AteF0bE for <cfrg@ietfa.amsl.com>; Tue, 12 Mar 2019 21:39:19 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8BB1277DB for <cfrg@ietf.org>; Tue, 12 Mar 2019 21:39:18 -0700 (PDT)
Received: from [18.101.8.186] (VPN-18-101-8-186.MIT.EDU [18.101.8.186]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2D4dDMg010223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Mar 2019 00:39:15 -0400
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: cfrg@ietf.org, cawood@apple.com
References: <155232379553.23186.8764563590660883823@ietfa.amsl.com> <884f593b-0753-16ff-e68c-990acd0e8d68@mit.edu> <20190313034352.GE8182@kduck.mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Openpgp: preference=signencrypt
Autocrypt: addr=ghudson@mit.edu; keydata= xsFNBFLMQYIBEADZLNv8Jpeo2d4XSLE+k6m1VD2iOyX66wErZKaQpYrGB/leWKfz8l6c3pWd iVUnCoyxKlhRuGVArszdh2wUSRgHnMl86JC/vIdawdOdbnlTVfOJTiP3EfycsMUUDG6GckLY e+xxo7sM/bpXpGkbIWc0Ec/vbQt67eeW2En1AqL+ezJdVN9XL8icH2Hu6HlqxGgleC5H0yAi kM4yvNjo5z2M/Dr/x63bLcIdKkSRPzd0OaBg2g0Yh651eYpPu0e1Gi6785ZBjV4bnv3K5oLo 5XsiHIZ60maHWTEyMO/byw4aS2cCWIovXurvz699KSF83B296+xhsFhhz4+kbQgXvJt4kIoI pdpX6xbIkeVlc+FuUbyE8MUGveA3TFHXZ4+0f2tvTekey/62FOeXnrqc4NsBViir3zGTXAqC 7PQTNnX/86jyW+9SnJo9XbSBB3NV0K5I2o1cDzqRPqy/4fsoq8SxQwRga0CSId1PzE9PUEUY V0FCldo9LvPsUK9YE7AuwC+bcQiVLah5TF+5Kk7yLSaRxzQ3fI5lcqk5UPUqMLa87cRBdnal niuHVg0u3W22RMPkWe2iPIYYdr4TQDzCkD2JXpXNaZ3KipVT5aqowwfPEt7b6ti0vjrOInij YzFmVNMGKYabwh2zxKWQQ8GO5mUVu09CSe33H4EW7pDP+zHr2wARAQABzR1HcmVnIEh1ZHNv biA8Z2h1ZHNvbkBtaXQuZWR1PsLBeAQTAQIAIgUCUsxBggIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AACgkQDLoIV1+Dct8dZBAA1Mtoq1RPuUQg6hL2qFjwTEXeonWq8czkQ1fNNzO9 x8I3VLn5L6CmWeAmxRU1DD0qZ5HL24+Mwnvy/eazp4/CSgiPC52KfbNsnQtg/E+8ruFQVHA/ 3HZXuCT/Nz4s06N3fMZrJLCGNEHRD0S43kb2GGboVY3ykO3FbPJB/DxDqtIMqt6B1SZ87UAR CVsRc296X3TsF9BgoQ/n54XfYAzrACkuIH9biHmH6wB1eykCeuhkCsu5Zf/tlSXJCFiuhvS+ CX2EbNKF+0MLcGAavSzbjTnQw3kv8unSgecbEQ7A8ibGx6Jwgnvy0gzu6w4prhR40pVYDcL+ sKsmQg6jo/uPvGdEqHISFSK8FxGGAonaAwg0014bXLaPo2MckcZ+szcHA/z4vpTdB1vChexL omM5ZTeSJaFfeYsspv8sq6EL1x21c7A+ngCmB70/OZR6dcgf9/ILmcjBiYfJHYukXTIvGT6y QJbok19So8RJKUYjzzHDKBweg8x6HdIrdy7HTcLzsqY9PFGg7/YlbLlGQwYXhK1b4uBmWyE7 I/402+57I1YpMYND7vsTmJuE13Gv5ZGhYn5pSzX9ZTWY13LgGymkWBXPxfefkHKTV9ROCGEL t7SV3Nf7ZsCGLRGmDT6oqLz75/IrhKEcHIfD4ct+QvIm6pvPNvikQMwPWSd52GazILLOwU0E UsxBggEQAKaz/wX8nsSUaivmwW4NVlbmTsErHUt9iNHm9CmieuoDv1o8qUqEV6RiONIs0q5Y +dcooazhHRNpjAST2rbQFBZebfpVRKYAGzHoZEQ6OV8Eao+NjAGazS8RuwIxpeZ36r3AyVhe TAIvIzwpQFDNKTIUNbXctHrZ157TlxDuKwZ3+Yw/bhQE5YGrSLm17wIMcY3UHiE1mO5X0ohR dDeTf93PignUUvWvRRQLyxRGsBLz/CCwmCJZeu/FjnDk8HkEbAlmFAJ+YZu9rQ40vU6Z40KY L5U9PIn0FdSxviK7mys+VbFYV6mXWXZN8dOkHuG6zSdmobE90G6ZzAPcI4cyql63N+kUOb3b hGI/Wvn6tUbWeIc8UvQGpYb0+eOKHQBNKUOq5RV98hZorZRCu2W2RzZSxiufyONvtonbUtYs BMdw+gqUpK0ir782lc3cKbj+X5iiyg3ZGvBmTU6FN/MiX6MnTyEwOScFboKe6vB8ZgwII85K n9qlSI3xH56JBXamMP0yqJf57q0WfP8V7lFtm8SmhU2NQyP3wRYDm2+bLTNCmRPJN2ZUgkTx c/Qjov8TeeiTfX9S3ea/GJOdgA1mQfSkmUoOWROnwDBbKGBXNzkkoJna8j/zWgo/mQ5gNdIu HXcIdDKbyyhVH3+DwxXYWyYP/pnIk3AVCss75dXcdStfABEBAAHCwV8EGAECAAkFAlLMQYIC GwwACgkQDLoIV1+Dct+oSA/9HyTkr+UQbaucXE9pP87yasObKCBxYhoeRjzBhgtYUtSDuH2o xl5M3wmTNOooQSa8R1ljhax9v02pqspIA9hyGjGjvZ6jPydDsANNcohdbMjCzXNdrCF5149w gbGQ07rkc5JNyajzxH4GE/BXclTzwTYAaHvYM5PEQLDhmubK3M/kBvjWpZxLAJAobMi/jVwQ cmai+N56X9Ht/FVIQlmCuXoMAE9ScVWFaq8JnCo9VZ0G045NcxdEoQXVUXb3E5cmZ0Ld9sUm SKSJKjYWjfE4c/8oylZuo9LDTwozBEp/jsASjL0g8F3QJsQUkFkKROd45xHcIkFulshS3xkG gMu6UduV2ypPz987f+0wdVwx+KYnmnUB83gxqVucFRxfZZXiUHUml4rJ7Ww2+//H9FFPfw9f aPMg7nLFm2T0to3pwgyisLH/aThzW3TY7CZ7gkvMDtbo9EHrN4Nl3onuOtOKQpIMbFVqX4YZ m6znSLuUiWDUd8rvQfz+4ndZKIFOG1YIKwQBV8tN1RYBGY9bhv2Wtt5X6SKIzkUhDdgeyzci MC1M3N0Pqoqrms7FdBKAd0BE7puhQ24U42APss+Ur6WyRZMQTKc41SZWfrWV30agytUVdtRu gxERw74qeGAz6o3if42vI6u30SR6OCLMMSobqKc7HQvJ2qv3Z6j9kt1zXiE=
Message-ID: <7fa7713b-94da-da7b-bf9e-465627a8f030@mit.edu>
Date: Wed, 13 Mar 2019 00:39:13 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <20190313034352.GE8182@kduck.mit.edu>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/mjBcr1lq695zjNsBd3DxHQ7pEv8>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-spake2-08.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2019 04:39:21 -0000

On 3/12/19 11:43 PM, Benjamin Kaduk wrote:
> Perhaps the most drastic change is the switch from multiplying by the
> cofactor before transmission and recipients verifying that points are on
> the curve (but in essence trusting the peer on prime subgroup membership),

In the old draft, each side chooses a multiple of the cofactor as its
private coefficient, and multiplies that coefficient by the unmasked
point, points of order greater than p (p times a divisor of h) will
become points of order p.  This is the same strategy as X25519 uses.

Points of small order (after unmasking) become I after multiplication by
the scaled coefficient.  I recall some debate around whether X25519
should require a check for whether the result is the identity point,
with the conclusion that it is not necessary.  I believe the same
applies here.

> This should probably be (3) in my list above.  I think when I was merging
> Chris's PR, I had convinced myself that only order-p and order-h subgroups
> were possible (or factors of h), so that (e.g.) 2p would not be possible.
> But I can't back that up right now -- Chris, can you say more?

https://safecurves.cr.yp.to/twist.html lists the possible orders of
group points.  It includes p times divisors of h.  There is also some
discussion of small-subgroup attacks and why scaled coefficients are
useful against them.

>> * This revision includes allowances for omitting one or the other
>> identity from key derivation.  I think this departs from the SPAKE2
>> security proof, and I don't recall discussion here about relaxing that
>> requirement.
> 
> I also don't recall discussion, though the text is attempting to indicate
> that this can only happen in cases where the identity in question is
> implicit in the containing protocol.

That doesn't seem like a helpful property.  One concern is that a
message (or a derivative of a message) might be taken from one session
and used in another.  If different sessions have different implicit
identities, omitting an identity from key derivation definitely seems to
potentially compromise the security proof.

>> * scrypt seems like an outdated choice of memory-hard hash function.
> 
> That's fair.  I assume you're thinking of draft-irtf-cfrg-argon2?

Yes.

> I did not get to think about this question particularly hard, but the main
> barrier here seemed to be the change in cofactor multiplication; a lot of
> the other changes could be wrapped into a specific "ciphersuite" for the
> kerberos usage, if needed.  (Since that protocol does do the transcripting,
> key derivation, and key confirmation steps that are needed, just with a
> somewhat tighter integration with the containing kerberos context.)

Rather than put a lot of Kerberos-specific stuff in the CFRG document, I
think it will make more sense to fully describe the SPAKE math in the
Kerberos document.