Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2

[Tero Kivinen <[e-mail]>]

Peter Gutmann writes:
> Tero Kivinen <[e-mail]> writes:
> 
> >I did verify the RFC 2409 primes (768, 1024, and 1536 bit groups) when I 
> >generated the RFC3526. I do not know if anybody else has verified the 
> >RFC3526 primes.
> 
> Wow.  So the 2409 values took five years to be independently
> verified and

Earlier than that. First version of the
draft-ietf-ipsec-ike-modp-groups-00.txt was published october 2000,
and that already include primality proofs for 1536, 2048, 3072 and
4096 bit groups. And I did had verified 1024 and 768 bit groups before
publishing that draft. 

It then took 3 years to publish that draft as RFC3526, and it took
several months of that was just to do the primality proofs for bigger
groups. The 16384 bit group (which we decided not to include in
RFC3526) took more than 36 days to generate the primality proof, and I
had to restart it 3-4 times, as machine doing it crashed or lost power
during the process several times. Getting windows machine to stay up
and stable for 36 days was bit challenging.

So yes, there was two year lag from the RFC2409 publication to after
the first draft providing independent proofs for them was published.
Or three years if we use the draft-ietf-ipsec-isakmp-oakley-04 as
baseline for RFC2409, as that was first one that included 1024-bit
group. 

> nineteen years before this became known, the 3526 values took twelve
> years to be independently verified. If we do publish new groups, we
> need to address this problem with some urgency. I'm not saying I
> don't trust you :-) but the point of publishing the details is to
> gain confidence in everything being correct once multiple people
> have verified things.

Sure, it would be good thing for other people to run the verifications
too. How about you verifying both IKE and TLS groups and make sure
they are actually generated as explained, and that they are first
primes matching the process...

Primality proofs are something that you do not need to rerun, you can
just take the proofs and verify that they verifiers the prime.

> >Actually breaking SSH is much more useful than breaking IKE or TLS. The 
> >first time the adminstrator types sudo and his root password inside his 
> >ssh connection, the stored SSH stream comes very valuable for the 
> >attacker... 
> 
> Only if they want to compromise someone's Linux box or something.  If you
> target IKE you get to vaccuum up a ton of VPN traffic, and with SSL you
> get not only all web browsing but a ton of other stuff that uses it as the
> universal secure transport mechanism for network traffic.

Note, that with IKE there is typically 8 hour rekey timer or similar,
so they need to do the second part of the DH breaking again for each 8
hour data capture and also again for each different client. Most of
the VPN traffic is not that high value than something like root
password of the mail server... 

> For example if you're targetting VoIP then you'd want it for the
> tiny fraction of SIP that isn't just sent in the clear. It'd also
> give you ToR traffic, and endless other material. The pretty clear
> lesson here is, don't use the same DH parameters as SSL/TLS.

No the lesson here is that you do not want to use too short
Diffie-Hellman groups. As the [1] says:

	Our analysis suggests that 1024-bit discrete log may be within
	reach for state-level actors. As such, 1024-bit DHE (and
	1024-bit RSA) must be phased out in the near term. NIST has
	recommended such a transition since 2010 [4]. We recommend
	that clients raise the minimum DHE group size to 2048 bits as
	soon as server configurations allow. Server operators should
	move to 2048-bit or larger groups to facilitate this
	transition. Precomputation for a 2048-bit non-trapdoored group
	is around 10^9 times harder than for a 1024-bit group, so
	2048-bit Diffie-Hellman will remain secure barring a major
	algorithmic improvement.

[1] https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

> So in terms of target groups if I was a government-level attacker, I'd go
> for SSL, then IKE, and then I'd think about what to do next, given that it
> could take years to break each parameter set.

If you are scared about that then just go to the 4096 bit
Diffie-Hellman. If it will take years to break 1024-bit DH, and
billion years (10^9) more to break 2048-bit DH, then 4096-bit DH
should be safe... :-)

Even if we assume that they have much more cpu power than people think
they have, and that they can do pre-calculation for the 1024-bit DH in
one day (meaning it does not matter if people will create their own
1024-bit DH groups as they can easily break them quickly), then doing
pre-calculation on one 2048-bit DH group will take more than 2 million
years, so we should be quite safe even if we just use one group. And
if they go and attack TLS group first then IKE is still safe for 4
million years, so you can safely use IKE numbers for next few
decades... :-)
-- 
[e-mail]