[STDS-802-11-TGAI] TDS-802-11-TGAI] A suggestion to clean up the list of IANA groups that 802.11ai should consider -- i.e., ditch roughly 40% of those as inadequate (was: Re: [STDS-802-11-TGAI] modp group question)

[Tero Kivinen <kivinen@xxxxxx>]

Rene Struik writes:
> Dear Tero:
> 
> Thanks for your response regarding the expression of my concern re
> a) security of Sophie-Germain groups;
> b) security aspects of using "2" as a generator;
> c) computational complexity.
> 
> While I do appreciate your informal assessments, I am not sure whether 
> those would have sufficient merit to sway 802.11ai into using those groups.

No. I would not agree on that. Those groups are used in almost all
security protocols standardized in the IETF. If there is any problems
with the group that is much bigger issue than just this issue with
802.11ai...

> Wouldn't you agree that avoiding those groups altogether, at least for 
> 802.11, would make for less navigation of potentially very choppy waters?

Lets put it this way, that I trust those groups more than the MODP
groups defined in the RFC5114 (which is the other option), as for
those there is at least the primality proofs available, and they are
also generated using known method. If I remember right the other modp
groups were generated by NIST, and they said they did use the method
specified in their documents, but I think they didn't store the
initial values used for generating those groups, so nobody can really
verify they were correctly generated.

>  From your note I get the impression that it is fine to use 
> Sophie-Germain groups since
> a) while cutting corners in truncating ephemeral private keys 
> (presumably to make performance acceptable) may create strong biases, 
> these might be compensated for by
> opening a vast arsenal of tricks;

Regardless what kind of groups you use, it is not safe to truncate the
output of Diffie-Hellman. You need to use proper key derivation
function to extract the keys out from the secret. I.e. you cannot "cut
corners" there, you need to use proper KDF.

> b) while tricks may seriously impact performance (and may land us into 
> "nontechnical" minefields), there are ways to cut corners here as well, 
> seemingly without impact;

I do not understand what you are meaning here. 

> c) while performance may be quite poor, one could do computations 
> offline and reuse ephemerals to fair somewhat better. And, there is 
> always hardware...

I do not think there is that big difference in the computation cost
between the group 14 and group 23 or 24, except that with groups 23
and 24 you need to check against the small subgroup attack, which
means you do not gain anything for reusing them private key values for
those groups 21-24, as you need to do computation that is about as
expensive as generating new private key.

See section 2.2 of
http://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks/ for more
information. 

> Let us assume that one accepts those arguments on face value. Wouldn't 
> there then still be an issue using Sophie-Germain groups with 802.11ai 
> in the "non-TTP case"? After all, there one needs DSS signature, where 
> if one were to use the Sophie-Germain arsenal of tricks, one would 
> essentially use private keys where roughly 80-90% of the private key 
> bits are known? Again, the literature is full of examples where knowing 
> just 1-2% (e.g., 3-4 out of 256 bits) has disastrous ripple effect.

I have not checked what is specified in the 802.11ai, but usually
those groups are only used in the Diffie-Hellman key agreement, not in
the DSS signature. I do not think any of the IETF standards uses any
of the groups defined in the IKE or IKEv2 group registries in the DSS
signatures, so if you need groups that are suitable for that, I have
no idea if any of them are suitable for that.

Normally the DSS signature private keys needs to be generated
specifically and the parameters (which include the group) must be
generated using the rules set by the NIST in their publication. If you
do not follow those rules when generating those parameters, it is not
really DSS, which means for that you cannot use those IKE groups.

Even then the groups 21-23 claims to be generated using the NIST
rules, there is no way to verify that, so I am not sure whether those
are enough.

On the other hand there is no reason why the Diffie-Hellman group
should be same than the group used for the DSS signature. Is there any
benefits for that? I do not think there is any computational benefits
from that, as you still need to do anonymous Diffie-Hellman
calculation and the signature generation / verification both, even if
you use the same groups.

> Rather than trying and finding strong technical evidence that supports 
> informal "gut-feel" (no better how appealing this sounds), wouldn't it 
> be much better to just avoid going that route altogether (at least for 
> 802.11 purposes) and simply use Diffie-Hellman groups for which safe use 
> seems to involve less "navigation of treacherous waters".

There is nothiong wrong using those groups in the uses they are meant
for, i.e. for Diffie-Hellman. Using them for any other purposes might
or might not be safe.

I just only now understood that you really want to use those same
groups as DSS FFC Domain parameters, i.e. trying to use them in uses
which they are not meant to be used (none of IKE groups are meant to
be used for that purpose). I.e. even when the groups 21-23 are
believed to be generated using the algorithms in the appedix A of the
FIPS PUB 186-3 Digital Signature Standard (DSS), I do not think the
any of the information needed to verify it is available anywhere, so
you cannot really verify them.

> Thus, unless one can dig up all the strong technical evidence, it seems 
> that foregoing more or less 40% of the IANA curves, at least for 802.11 
> use, seems the "wiser" approach? The remaining roughly 60% of IANA 
> curves would still work and often much better, with less security 
> headaches, more in line with the directions practice-based crypto is 
> moving in the world, and with quite reasonable and sometimes even 
> (almost) great performance.

I would say forget 100% of the IANA IKE curves when you are talking
about the DSS. And for Diffie-Hellman you can use any of the IANA IKE
curves. The groups are not meant for DSS, thus there is no guarantees
that any of them are suitable for that use (some of them might be,
some might not, but as they are not meant to be used for those, nobody
has verified that fact). 

> Would you agree? (at least for 802.11's purposes)?

Yes, for DSS use 802.11ai needs to generate their own groups that are
generated to be suitable for DSS use, i.e do not use any of the IANA
IKE groups for uses other than what they are intended for.
-- 
kivinen@xxxxxx

_______________________________________________________________________________

IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this
CLOSED reflector. We use this valuable tool to communicate on the issues at hand.

SELF SERVICE OPTION:
Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI and
then amend your subscription on the form provided.  If you require removal from the reflector
press the LEAVE button.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________