Re: [TLS] Issue 30: Reject RSA public exponent 1
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TLS] Issue 30: Reject RSA public exponent 1



At Tue, 05 Jun 2007 19:36:10 +1200,
Peter Gutmann wrote:
> 
> <Pasi.Eronen at nokia.com> writes:
> 
> >Perhaps the advice about this check could be combined with other advice: e.g.
> >the TLS implementation should (or even must) check that DH group parameters
> >are "good enough" (and reject attempts to use e.g. 256-bit groups, unless
> >this is really allowed by the local policy).
> 
> A problem with this is that it's almost impossible to get any consensus as to
> what should and shouldn't be checked.  I played with this a few years ago and
> showed it to a few crypto people and everyone had a different, generally
> incompatible, checklist of things that needed to be checked.  In the end you
> either end up with a huge shopping-list of often questionably-useful checks
> (all of my checks are useful, everyone else's are superfluous and a waste of
> implementation effort), or a more concise list that represents only one
> person's idea of what's worth checking (all of my checks are useful, I'll
> ignore everyone else's suggestions because they're superfluous and a waste of
> implementation effort).
> 
> Overall I think (based on an attempt at doing it) that this is such an
> incredible can of worms that you really, really don't want to open it.  If
> anyone really wants to build a checklist, put up a web page or create a wiki
> and see how the market reacts first.

I think this is probably about right. 

I would argue that 95% of these checks are generic to most COMSEC
protocols. If someone were to draft generic guidance I'd be happy
for TLS to reference it informationally :) I just don't think it
makes a lot of sense in the TLS standard

-Ekr

  

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.