- From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Date: Fri, 22 May 2015 12:45:03 +0300
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Fri, May 22, 2015 at 10:11:29AM +0100, Stephen Farrell wrote: > > 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.) 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. > 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. Well, TLS 1.3 uses key exchange, not asymmetric encryption, so things are different there. -Ilari
Received on Friday, 22 May 2015 09:45:32 UTC