Subject: Re: [TLS] DSA support in TLS 1.3.

From: Hubert Kario <[email-masked]>
Date: Tue, 01 Sep 2015 13:09:14 +0200

On Friday 28 August 2015 20:17:11 Geoffrey Keating wrote:
> Jeffrey Walton <[email-masked]> writes:
> > > Also, if DSA was to be supported, one would need to specify how to
> > > determine the hash function (use of fixed SHA-1 doesn't fly). And
> > > 1024-bit prime is too small.
> > 
> > FIPS186-4
> > (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf)
> > partially remediates the issue. DSA now includes 2048 and 3072
> > sizes.

It still doesn't say exactly which hash should be used with which sizes.

and unlike RSA, the signature itself doesn't specify it either so hash 
truncation attacks are not impossible

> This is true, but if TLS 1.3 was to specify DSA, it should require the
> 2048 or 3072 sizes (since 1024 is last century's crypto), and
> existing implementations do not necessarily support those today.

those sizes are not really interoperable:
https://bugzilla.redhat.com/show_bug.cgi?id=1238369
because of the above (GnuTLS takes the conservative approach which is 
incompatible with NSS implementation)

> Which really highlights the question: who would actually use it?

Since 1024 bit is too weak and 2048 bit and 3072 bit is underspecified 
for TLS 1.2 it already isn't recommended for use (which means that the 
biggest deployment of DSA - US Gov - can't really use those bigger 
sizes, and in fact the Common Access Card already transitioned to RSA 
with the change to 2048 bit).

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 1 Sep 2015 11:24:59 -0400

> It still doesn't say exactly which hash should be used with which sizes.

I believe you are supposed to provide equivalent security levels
across algorithms. If you are honoring NIST's recommendations, then
you can find them in SP 800-57 Part 1, Revision 3
(http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf);
and SP 800-131 A-Rev.1 (Draft)
(http://csrc.nist.gov/publications/drafts/800-131A/sp800-131a_r1_draft.pdf).

ECRYPT, NESSIE, and others provide similar recommendations. We can
probably add the IETF to the list :)

> with the change to 2048 bit).

Regarding "who would actually use it": folks in US Federal (and those
doing business in US Federal) don't have the choices that others have.

Jeff

---

From: Dave Garrett <[email-masked]>
Date: Tue, 1 Sep 2015 13:16:42 -0400

> doing business in US Federal) don't have the choices that others have.

They, however, obviously do have the choice of switching from DSA to ECDSA, so that argument doesn't make much sense here.

Dave

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 1 Sep 2015 13:24:05 -0400

> They, however, obviously do have the choice of switching from DSA to ECDSA, so that argument doesn't make much sense here.
I suppose that depends on how threatened you feel by Certicom's
claimed patents on EC.

Did the IETF ever procure a waiver on any claims when used in TLS?

Jeff

---

From: Dave Garrett <[email-masked]>
Date: Tue, 1 Sep 2015 13:54:05 -0400

> I suppose that depends on how threatened you feel by Certicom's

If the US Federal government actually got sued over ECC patents, I would hope they'd just abolish them and move on.

This is all a side-discussion, here, though. The US government's requirements are not our concern here. Dropping DSA in TLS leaves two perfectly fine options available to them, RSA & ECDSA, plus a new one yet to be added by the CFRG. They have to eventually keep up with things just like everyone else. If they want to be sloppy and keep DSA around, it's not like they couldn't just ignore that part of the eventual TLS 1.3 RFC within their own ecosystem. Everyone else, however, will be fine with the rest.

Dave

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 1 Sep 2015 17:58:33 +0000

There is a third option:  you don't get to use TLS 1.3 until the government requirements are updated.

I'm fine with that.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 1 Sep 2015 18:02:04 +0000

On 9/1/15, 13:54 , "TLS on behalf of Dave Garrett" <[email-masked]
on behalf of [email-masked]> wrote:

>>> They, however, obviously do have the choice of switching from DSA to
>>>ECDSA, so that argument doesn't make much sense here.
>>
>> I suppose that depends on how threatened you feel by Certicom’s claimed
>>patents on EC.
>
>If the US Federal government actually got sued over ECC patents, I would
>hope they'd just abolish them and move on.

I don’t think it’s as simple as that. US government licensed some of the
ECC technology from Certicom. But I’ve heard Certicom claim that the
licensing terms are so narrow that only direct national security
applications qualify for that license.

This isn’t something where vendors (and their lawyers) can rely on “would
hope”.

>This is all a side-discussion, here, though. The US government's
>requirements are not our concern here. Dropping DSA in TLS leaves two
>perfectly fine options available to them, RSA & ECDSA, plus a new one yet
>to be added by the CFRG. They have to eventually keep up with things just
>like everyone else. If they want to be sloppy and keep DSA around, it's
>not like they couldn't just ignore that part of the eventual TLS 1.3 RFC
>within their own ecosystem. Everyone else, however, will be fine with the
>rest.

The problem is that standardization of an algorithm or a technology by
IETF or IRTF is completely unrelated to the patent/licensing status of
that algorithm or technology. So unless Certicom comes forward and
explicitly releases its IPR, most of the vendors would consider the
patended and therefore toxic. I know I would. And forcing those vendors to
spend money on licensing isn’t going to work (recall RSA).

This would be a strong reason to hold on to DSA until the ECC patents
expire. (Like it happened with RSA.)

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 1 Sep 2015 11:26:38 -0700

> expire. (Like it happened with RSA.)

Why do we need DSA if we have RSA? Nobody is using DSA/DSS. Everyone is
using RSA or ECDSA.

-- 
Tony Arcieri

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 1 Sep 2015 14:29:42 -0400

> If the US Federal government actually got sued over ECC patents, I would hope they'd just abolish them and move on.

Its not the government - its those who do business with the US government.

> This is all a side-discussion, here, though. The US government's requirements are not our concern here. ... Everyone else, however, will be fine with the rest.
>
The US government and those who do business with them are typical TLS users.

So I'll take it the IETF did *not* procure the IP waiver...

Jeff

---

From: Dave Garrett <[email-masked]>
Date: Tue, 1 Sep 2015 14:48:31 -0400

> So I'll take it the IETF did *not* procure the IP waiver...

Just to be very clear, as this was in a reply to me: I personally have no knowledge on this specific topic and am not in a position to be authoritative on it. Someone else will have to provide that information.

> There is a third option:  you don't get to use TLS 1.3 until the government requirements are updated.

+1

Dave

---

From: Watson Ladd <[email-masked]>
Date: Tue, 1 Sep 2015 14:49:42 -0400

> applications qualify for that license.

Did Certicom ever have patents applying to the use of ECDHE in TLS?
It's not clear that they did: certainly RFC 6090 goes so far as to
claim that there are patent-free implementation methods based on
pre-1985 sources.

> expire. (Like it happened with RSA.)

And what patents are you concerned about, and when were they issued?

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

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Blumenthal, Uri -- 0553 -- MITLL" <[email-masked]>
Date: Tue, 1 Sep 2015 15:17:43 -0400

> claim that there are patent-free implementation methods based on
I do not know. It is not my field of expertise, and I'm not employed by 
a commercial vendor to really care.

So I have neither skills nor incentives (nor time!) to research patents 
issued for ECC to figure how they could impact my work, because in 
general they cannot.

But I'm conscious of other people for who it could be important.

> And what patents are you concerned about, and when were they issued?

See above.

I am not tracking patents - have neither time, nor interest in doing 
that. But I'm not releasing commercial software. I think somebody made a 
list of the patents owned by Certicom, but I can't recall the details. 
That would be the first thing to look at, IMHO.

Since (AFAIK) nobody here is a patent lawyer (and even if there were :), 
any recommendation or opinion regarding those patents posted here isn't 
worth much. E.g. if you implement and sell ECDSA or EdDSA, and are sued 
by e.g. Certicom for not licensing it from them - who's going to pay 
your legal fees? Probably not the participants of this forum. :)

It boils down to Certicom (and other companies???) holding some IPR on 
(some?) ECC technology that commercial vendors must license from them, 
or risk lawsuits. The famed NSA deal doesn't seem to be wide enough to 
cover the industry because of that "national security applications" 
clause that is a subject to interpretation. And those companies 
(intentionally?) keep the scope of their patents vague...

At least this is how I understand the state of the field.

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 1 Sep 2015 12:23:56 -0700

On Tue, Sep 1, 2015 at 12:17 PM, Blumenthal, Uri -- 0553 -- MITLL <
[email-masked]> wrote:

> I am not tracking patents - have neither time, nor interest in doing that.
> But I'm not releasing commercial software. I think somebody made a list of
> the patents owned by Certicom, but I can't recall the details. That would
> be the first thing to look at, IMHO.

Dan Bernstein has made lists of ECC patents here:

http://cr.yp.to/ecdh/patents.html
http://ed25519.cr.yp.to/software.html (see "Patents" at the bottom of the
page)

According to him, no extant patents should apply to the CFRG curves or
EdDSA (and it's seeming highly likely that the CFRG signature algorithm
will greatly resemble or be EdDSA)

-- 
Tony Arcieri

---

From: "Blumenthal, Uri -- 0553 -- MITLL" <[email-masked]>
Date: Tue, 1 Sep 2015 15:37:44 -0400

DJB's work is good and commendable. I personally think that EdDSA (and 
ECDSA, for that matter) are not covered by Certicom's patents.

But IANAL (I Am Not A Lawyer)... I *can* understand vendors who would 
hold until either an explicit IPR release is posted, or the 
(potentially!) relevant patents expire.

On 9/1/15 15:23 , Tony Arcieri wrote:
> On Tue, Sep 1, 2015 at 12:17 PM, Blumenthal, Uri -- 0553 -- MITLL 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I am not tracking patents - have neither time, nor interest in
>     doing that. But I'm not releasing commercial software. I think
>     somebody made a list of the patents owned by Certicom, but I can't
>     recall the details. That would be the first thing to look at, IMHO.
>
>
> http://ed25519.cr.yp.to/software.html (see "Patents" at the bottom of 
> the page)
>
> EdDSA (and it's seeming highly likely that the CFRG signature 
> algorithm will greatly resemble or be EdDSA)

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 1 Sep 2015 13:12:40 -0700

On Tuesday, September 1, 2015, Blumenthal, Uri -- 0553 -- MITLL <
[email-masked]> wrote:

> But IANAL (I Am Not A Lawyer)... I *can* understand vendors who would hold
> until either an explicit IPR release is posted, or the (potentially!)
> relevant patents expire.
>
> Then those hypothetical people should use RSA signatures and FFDHE key
exchange

-- 
Tony Arcieri

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 1 Sep 2015 16:48:21 -0400

> Then those hypothetical people should use RSA signatures and FFDHE key
Ah, but they are not hypothetical. For example, one OpenSSL customer
commissioned the project to provide a modified EC implementation to
avoid some of the potential patents. The result was the downloads with
*-ecp in their name (ftp://ftp.openssl.org/source/).

I think the minefield in this discussion is the bikeshedding.
External, non-technical pressures and requirements exists, and they
are not easily dismissed with "Just use X". For example, in US
Federal, its C&A and FIPS. In Europe or Asia, it might be political
and distrust of NIST.

I'd love to see one true cipher, but I don't think its going to
happen. Its not feasible (and its not a technical limitation).

Jeff

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 1 Sep 2015 14:20:47 -0700

On Tuesday, September 1, 2015, Jeffrey Walton <[email-masked]> wrote:
> are not easily dismissed with "Just use X".
>

This is exactly why I keep asking for real world use cases.

Can you please clearly describe what problems are solved by DSA/DSS which
are not solved by RSA signatures, and give a real-world example where this
problem/solution are manifesting in practice?

I agree there is a bikeshedding debate going on here. I also am yet to see
a clear argument why keeping DSA/DSS around is a good idea.

-- 
Tony Arcieri

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 2 Sep 2015 20:49:52 +0300

> government requirements are updated.

I think they already have, with NSA seemingly saying RSA3k is OK for
up to TOP SECRET (unless I misunderstood).

The same table from NSA that mentions RSA (and the 3k limit) does
not mention DSA (the only other signature algo is ECDSA with
384 limit).

So maybe even US govt. is not using DSA?

-Ilari

---

From: "Dang, Quynh" <[email-masked]>
Date: Fri, 4 Sep 2015 10:56:19 +0000

Hi IIari,

>From all of the RFCs about suite B that I have read, DSA has never been a part of it.

RSA can be used for signatures and key wrap/transport.

Quynh. 

________________________________________
From: TLS <[email-masked]> on behalf of Ilari Liusvaara <[email-masked]>
Sent: Wednesday, September 2, 2015 1:49 PM
To: Salz, Rich
Cc: [email-masked]
Subject: Re: [TLS] DSA support in TLS 1.3.

-Ilari