Subject: Re: [TLS] Another IRINA bug in TLS

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 01 Jun 2015 17:20:14 -0400

On Sun 2015-05-24 03:12:00 -0400, Peter Gutmann wrote:
> Jeffrey Walton <[email-masked]> writes:
>
>>GnuTLS with its Lim-Lee primes causes me a lot of problems because they
>>cannot be validated.
>
> Actually the problem isn't GnuTLS (hey, I use Lim-Lee primes as well!), it's
> the fact that TLS uses the PKCS #3 format rather than the DSA format, so
> you've got nice verifiable values for which you have to throw away the
> parameter used to verify them and send them in an unverifiable format.  Having
> said that, there's a pretty simple fix, define an extension that acts like the
> existing propose/accept extensions that signals a change in DH values to the
> DSA form (p, q, g) rather than PKCS #3 form (p, g).  And for TLS 1.3, use the
> DSA form by default, not the PKCS #3 form.

If we're still shipping arbitrary groups across the wire, then adding
(q) to the data over the wire not only increases the size of the
handshake (by the size of q) but now the receiving peer has to verify
that:

 (a) p is prime

 (b) q itself is prime

 (c) p is actually a Lim-Lee prime

either that, or they can skip the checks and cross their fingers.

Standardizing on known safe prime moduli seems simpler and easier and
less likely to include some steps that people will be tempted to skip
for speed.

        --dkg

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 1 Jun 2015 17:34:00 -0400

> less likely to include some steps that people will be tempted to skip
Yeah, agreed.

The little voice in the back of my mind is saying the NSA would love
to see standard groups so they can build those big tables and store
them in Utah in its new data center with shiny new floors. But I'll
resist the urge (until Karthikeyan's next paper)....

Jeff

---

From: Andrei Popov <[email-masked]>
Date: Mon, 1 Jun 2015 22:27:23 +0000

> Standardizing on known safe prime moduli seems simpler and easier and less likely to include some steps that people will be tempted to skip for speed.

Using known safe DH parameters makes sense to me. Besides, if we want clients to validate arbitrary DH parameters, then we have to standardize the exact verification steps, otherwise we'll get interop issues.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Daniel Kahn Gillmor
Sent: Monday, June 1, 2015 2:20 PM
To: Peter Gutmann; [email-masked]
Cc: <[email-masked]>
Subject: Re: [TLS] Another IRINA bug in TLS

On Sun 2015-05-24 03:12:00 -0400, Peter Gutmann wrote:
>>GnuTLS with its Lim-Lee primes causes me a lot of problems because 
>>they cannot be validated.
>
> Actually the problem isn't GnuTLS (hey, I use Lim-Lee primes as 
> well!), it's the fact that TLS uses the PKCS #3 format rather than the 
> DSA format, so you've got nice verifiable values for which you have to 
> throw away the parameter used to verify them and send them in an 
> unverifiable format.  Having said that, there's a pretty simple fix, 
> define an extension that acts like the existing propose/accept 
> extensions that signals a change in DH values to the DSA form (p, q, 
> g) rather than PKCS #3 form (p, g).  And for TLS 1.3, use the DSA form by default, not the PKCS #3 form.

If we're still shipping arbitrary groups across the wire, then adding
(q) to the data over the wire not only increases the size of the handshake (by the size of q) but now the receiving peer has to verify
that:

 (a) p is prime

 (b) q itself is prime

Standardizing on known safe prime moduli seems simpler and easier and less likely to include some steps that people will be tempted to skip for speed.

        --dkg

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Nico Williams <[email-masked]>
Date: Mon, 1 Jun 2015 18:03:29 -0500

> less likely to include some steps that people will be tempted to skip

+1.  Pick standard groups large enough to put DLP out of reach of all
adversaries, with Moore's law in mind, with groups having a not-after
date.  As time passes these not-after dates should be revised, perhaps
periodically, to account for any improvements in DLP technology, or
slight deviations from [Moore's law's] predictions of chip transistor
count doubling times.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 1 Jun 2015 18:40:16 -0500

On Sat, May 23, 2015 at 01:12:53PM +0000, Santiago Zanella-Beguelin wrote:
> > From: TLS <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
> > 
> > On 23/05/15 07:21, Karthikeyan Bhargavan wrote:
> > > The “avoid fixed groups” recommendation applies to 1024 bits (and any
> > > other group-size for which precomputation becomes feasible.)
> > 
> > It's a really good paper, but if you have the chance I
> > think adding the above clarification would be very good.
> 
> Thanks! 
> We're working on that.

This is important.  It would be easier to have standard groups large
enough and don't require run-time validation (being standard...) than to
use arbitrary groups that require run-time validation.

Don't thow the baby out with the bath water and all that.

Nico
--