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

From: Eric Rescorla <[email-masked]>
Date: Sun, 03 Jun 2007 08:01:54 -0700

http://www3.tools.ietf.org/wg/tls/trac/ticket/30

Nelson Bolyard writes:
	Some time ago, mozilla was modified to detect and reject RSA
	keys with public exponents equal to 1.  Presumably, the
	readers of this list need no explanation of the implications
	of such keys.

	Now, mozilla users are encountering web sites whose certs have
	such keys.  At least one public CA has apparently issued one
	or more such certs.
	
	I'm reporting this here to alert the readers of this list who
	may wish to ensure that their implementations detect such
	keys, and to suggest that perhaps the TLS RFC should
	explicitly forbid the use of any public keys (RSA or
	otherwise) that facilitate such weak encryption and/or
	authentication by requiring implentations to detect and reject
	them.

My general feeling is that there are a broad category of "good crypto
practices" issues that don't apply specifically to TLS. I'd love to
see an RFC on them, but would rather not see them in TLS proper
since they need to be duplicated in every crypto-using RFC.

Proposed resolution: do nothing.

-Ekr

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

---

From: "Ben Laurie" <[email-masked]>
Date: Mon, 4 Jun 2007 23:39:29 -0700

> Proposed resolution: do nothing.

I'm wondering what the threat model is here? So, the guy who makes the
key gets you to transmit your data in the plain. But, regardless of
exponent value, if he wants to reveal your data all he need do is
decrypt it and reveal it.

Now, I'm sure you can construct some James Bond scenario where its a
good idea to reveal your victim's credit card number to a local
sniffer instead of the central server, but hey, we've got Tor and
anonymous remailers, anyone can hide their identity, so why bother?

---

From: <[email-masked]>
Date: Tue, 5 Jun 2007 09:59:14 +0300

Ben Laurie wrote:

> I'm wondering what the threat model is here? So, the guy who makes
> the key gets you to transmit your data in the plain. But, regardless
> of exponent value, if he wants to reveal your data all he need do is

Based on Nelson's original email, it seems the threat model was not 
an actively malicious attacker, but implementation and operational
mistakes: some key generation tool (mistakenly) generated keypairs
with public exponent 1, and some CA (mistakenly) issued valid certs
for them.

A TLS implementation could (and IMHO should) detect this mistake, 
as Mozilla NSS now does... but the question is whether this check
should be mentioned in the TLS spec or not. 

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). 

Best regards,
Pasi

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 05 Jun 2007 19:36:10 +1200

<[email-masked]> 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.

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 05 Jun 2007 07:17:08 -0700

At Tue, 05 Jun 2007 19:36:10 +1200,
> 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