Re: [TLS] Contemplated major revision to draft-ietf-negotiated-ff-dhe

[Ilari Liusvaara <[e-mail]>]

On Fri, Sep 19, 2014 at 03:05:36PM -0700, Martin Thomson wrote:
> On 19 September 2014 12:52, Daniel Kahn Gillmor <[e-mail]> wrote:
> > == Advantages ==
> 
> Great.  This is much nicer as a rule.

Yeah, I think this proposal sounds good.

Process question: Does this need to update 4492 (it repurposes extensions
defined there)?

> I think that the issues Ilari points are entirely orthogonal to this
> proposal, those are largely existing problems with the existing stuff.
> I do have one suggestion below that might help alleviate concerns like
> those though.

I actually figured out solutions to those issues, without impacting this
specification (and I consider those less radical than this spec).

> > This proposal suggests carving out a small space of that registry for
> > finite field groups.
> 
> I would rather you add a parameter to the registry so that entities
> that understand the code point can identify if the group is FF or EC.
> It would be informative only, scoping the registration appropriately.

Yeah, I think it should be done that way.

> I'm not sure that that helps on the ServerHello end of things though.

Talking about TLS 1.0-1.2 or 1.3?

If 1.0-1.2, I don't see how ServerHello is involved (you don't have to
signal the DH group used in elliptic_curves). 

If 1.3, where the group used is signaled anyway? I can't find it it
in either SH or SKE.


Regarding server key misinterpretation problems (only affects TLS
1.0-1.2), the notation differences between 1.2 and 4492 make
seeing what is actually signed hard. So I can't say about
possiblity of misinterpretting SKE.

Also, regarding TLS libs not accepting <9 bit DHE, I have seen certain
infamous TLS library accept some ridiculously short DHE prime (I
think it was 16 bits or something like that)... But such problems
should be fixed.


-Ilari