Subject: draft-thomson-http-encryption-00 - Logjam

From: Amos Jeffries <[email-masked]>
Date: Fri, 22 May 2015 20:48:58 +1200

The end of Section 4.2 states:

"
   Specifications that rely on an Diffie-Hellman exchange for
   determining input keying material MUST either specify the parameters
   for Diffie-Hellman (group parameters, or curves and point format)
   that are used, or describe how those parameters are negotiated
   between sender and receiver.
"

As has been seen with IKEv1. Having a specification determine explicit
parameters leads directly to it becoming vulnerable when that parameter
group is broken. see <https://weakdh.org/>

I believe that should be changed to remove the requirement to specify an
exact group.
New text:
"
   Specifications that rely on an Diffie-Hellman exchange for
   determining input keying material MUST specify how the parameters
   for Diffie-Hellman (group parameters, or curves and point format)
   that are negotiated between sender and receiver.
"

Security Considerations should probably also be updated to mention the
possibility of Logjam attack against weak parameter groups.

Amos

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 May 2015 10:11:29 +0100

Hiya,

I'm not so sure we have IETF consensus on the right way to
balance between widely used named fields vs. individually
crafted fields for integer DH. (Just for clarity: for ECDH
I think the former approach is fairly clearly where we're
at and is fine.)

The downside of the latter approach is that if one doesn't
check the offered values, then one can be open to attack,
and the checks needed can be onerous (e.g. checking primality).
Personally, I think the paper goes too far towards
recommending site-specific primes be used as we do have a
real history of that causing issues in some implementations
that omit checks on received values and other implementations
that send bad values. (Don't have a reference to hand sorry.)

Anyway, I think this'll be fully discussed as part of the
TLS1.3 work, and the topic is being discussed on the TLS WG
list now, so by the time  draft-thomson-http-encryption is
baked, I think we'll know what to say in that.

Cheers,
S.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 22 May 2015 12:14:44 +0300

> I believe that should be changed to remove the requirement to specify an

It would make more sense to me if group parameters/curves and point
formats were properties of the key.

It seems to me that using the same key with multiple parameters/curves
is asking for trouble.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 22 May 2015 12:45:03 +0300

> that send bad values. (Don't have a reference to hand sorry.)

It matters if the parameters:
- Are negotiated or a part of the key.
- Are used for asymmetric encryption or key exchange.

This specification only uses parameters for asymmetric
encryption. 

If parameters are part of the key (which pretty much only
makes sense for asymmetric encryption), then bad parameters
mean bad key, and one can't really expect any security in
the face of bad key.

Negotiation of parameters to use with given key seems like
a bad idea. Point formats are their own case, as those do not
affect security at higher level (but might at lower level).

With elliptic curves, things are a bit different due to two
factors:
- Supporting arbitrary elliptic curves (especially over arbitrary
  primes) is nasty to implement.
- Precomputation (logjam-style) doesn't usually work very
  well.
 
> baked, I think we'll know what to say in that.

Well, TLS 1.3 uses key exchange, not asymmetric encryption, so
things are different there.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 May 2015 09:52:14 -0700

> that send bad values. (Don't have a reference to hand sorry.)

I agree.  Apparently reference [43] in the paper explains how to
construct prime groups that have hard-to-detect small subgroups.

[43] I. A. Semaev. Special prime numbers and discrete logs in finite
prime fields.
Math. Comp., 71(237):363–377,Jan. 2002.