Subject: [TLS] DSA support in TLS 1.3.

From: "Dang, Quynh" <[email-masked]>
Date: Fri, 28 Aug 2015 19:17:39 +0000

Hi all,

DSA is supported in the previous versions of TLS. It would be nice if someone who uses DSA can use it in TLS 1.3 as well.

People who don't use DSA, then they don't use DSA. People who use DSA right, it should be fine for them to use DSA.

I don't see a convincing reason to remove support of DSA in TLS 1.3.

Quynh.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 28 Aug 2015 22:49:22 +0300

On Fri, Aug 28, 2015 at 07:17:39PM +0000, Dang, Quynh wrote:
> Hi all,
> 
> DSA is supported in the previous versions of TLS. It would be nice
> if someone who uses DSA can use it in TLS 1.3 as well.

Well, at least for the web, DSA is no longer an option because
major browsers have dropped support for it.

> People who don't use DSA, then they don't use DSA. People who use
> DSA right, it should be fine for them to use DSA.

Unfortunately, it is not just signers, it is also verifiers.
 
> I don't see a convincing reason to remove support of DSA in TLS 1.3.

Well, no (projected) use. Many features have been stripped from TLS
1.3 on those grounds only.

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.

-Ilari

---

From: Sean Turner <[email-masked]>
Date: Fri, 28 Aug 2015 16:06:32 -0400

Quynh,

You must have been reading my mind because I’m working on something that will help Joe and I judge consensus on what to do about DSA.

Let’s hold off on this thread for a bit while I get that msg together.

spt

On Aug 28, 2015, at 15:17, Dang, Quynh <[email-masked]> wrote:

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

---

From: Hanno Böck <[email-masked]>
Date: Fri, 28 Aug 2015 22:21:53 +0200

On Fri, 28 Aug 2015 19:17:39 +0000
"Dang, Quynh" <[email-masked]> wrote:

> DSA is supported in the previous versions of TLS. It would be nice if
> someone who uses DSA can use it in TLS 1.3 as well.

Do you have a plausible reason why you want to use DSA? Or is this
purely a theoretical consideration?
Because this discussion came up multiple times here and I can't
remember anyone having a real world use case for DSA. From net wide
scans it seems DSA certs are almost nonexistent.

> I don't see a convincing reason to remove support of DSA in TLS 1.3.

The reason is avoiding feature bloat. I think it makes a lot of sense
to question the support of features nobody uses. Therefore I'm very
interested to hear why anybody would want to use DSA. "Just because
someone could" isn't a good reason.
(Also DSA has a well-known weakness with bad random numbers.)

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 28 Aug 2015 13:27:57 -0700

On Friday, August 28, 2015, Dang, Quynh <[email-masked]> wrote:
>
> People who don't use DSA, then they don't use DSA. People who use DSA
> right, it should be fine for them to use DSA.
>
Can you name one of these people? If not, you seem to be arguing for
including legacy protocols with no real-world use case in mind.

In absence of real-world use cases, removing legacy baggage from TLS
reduces attack surface and makes things easier for implementers.

-- 
Tony Arcieri

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 28 Aug 2015 20:48:11 +0000

> reduces attack surface and makes things easier for implementers.

Also *improves* interoperability, because the client HELLO carries
fewer cipher-suite code points, helping with systems that are
intolerant of large HELLO messages or only process a subset of the
indicated ciphers.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 28 Aug 2015 16:59:56 -0400

On Friday, August 28, 2015 04:21:53 pm Hanno Böck wrote:
> to question the support of features nobody uses.

At minimum, it's almost certainly getting cut from the TLS 1.3 specification document. It's obsolete, even by DSS standards, and either needs significant updating (e.g. use SHA-2) or dropping. The question will likely be whether it should be considered no longer acceptable or something which is permitted, just rarely supported and described in another document. I'd rather just declare it obsolete and no longer permitted to avoid the attack surface and complexity, and I get an impression that this is a common opinion in the WG.

Dave

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 28 Aug 2015 14:06:36 -0700

On Fri, Aug 28, 2015 at 1:59 PM, Dave Garrett <[email-masked]>
wrote:

> I'd rather just declare it obsolete and no longer permitted to avoid the
> attack surface and complexity, and I get an impression that this is a
> common opinion in the WG.

+1. Most people seem to oppose its inclusion, and the people asking for it
to be retained do not seem to have real-world use cases.

-- 
Tony Arcieri

---

From: Jacob Appelbaum <[email-masked]>
Date: Sat, 29 Aug 2015 00:41:23 +0000

> I don't see a convincing reason to remove support of DSA in TLS 1.3.

What do you suggest for the construction of the k value in DSA? The
old NSA backdoor that leaks the private key? Or perhaps a different
NIST endorsed construction?

All the best,
Jacob

---

From: Dave Garrett <[email-masked]>
Date: Fri, 28 Aug 2015 21:41:46 -0400

On Friday, August 28, 2015 08:41:23 pm Jacob Appelbaum wrote:
> What do you suggest for the construction of the k value in DSA?

https://tools.ietf.org/html/rfc6979#section-3.2 ?

Also, we still have ECDSA, so the 'k' issue isn't going away. Should we cite this RFC?

Dave

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 28 Aug 2015 21:47:56 -0400

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

Jeff

---

From: Geoffrey Keating <[email-masked]>
Date: 28 Aug 2015 20:17:11 -0700

> partially remediates the issue. DSA now includes 2048 and 3072 sizes.

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.

Which really highlights the question: who would actually use it?
ECDSA can be smaller, faster, and more secure all at once; and if you
don't like ECDSA or want an alternative, there's RSA.

---

From: Ronald del Rosario <[email-masked]>
Date: Sat, 29 Aug 2015 04:20:00 +0000

> "ECDSA can be smaller, faster, and more secure all at once; and if you don't like ECDSA or want an alternative, there's RSA."
>
Isn't that a step backward reverting to RSA?

Ron F. Del Rosario

________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential information of Five9 and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Five9 and/or its affiliated entities.

---

From: "Dang, Quynh" <[email-masked]>
Date: Mon, 31 Aug 2015 12:13:09 +0000

Hi all,

I thank everyone who took time to think about the issue.

The tone of my message below asked for a discussion of "allowed"/optional support for DSA with key size of 2K or bigger. So there would not be a required support for it.

There is a number of validated DSA implementations out there with key size of 2K (http://csrc.nist.gov/groups/STM/cavp/documents/dss/dsanewval.htm) ( of course I don't know the number of the implementations without validations).  DSA with 2K or bigger key sizes were added to FIPS 186 in June 2009 (FIPS 186-3).  TLSs are used in more places than just public servers and common browsers. For the people who use DSA in TLSs, it would be nice if they could run TLS 1.3 with DSA if they choose to do so.

Quynh.

________________________________
From: TLS <[email-masked]> on behalf of Dang, Quynh <[email-masked]>
Sent: Friday, August 28, 2015 3:17 PM
To: [email-masked]; [email-masked]
Subject: [TLS] DSA support in TLS 1.3.

Hi all,

Quynh.

---

From: Hanno Böck <[email-masked]>
Date: Mon, 31 Aug 2015 14:43:16 +0200

On Mon, 31 Aug 2015 12:13:09 +0000
"Dang, Quynh" <[email-masked]> wrote:

> TLSs are used in more places than just
> public servers and common browsers. For the people who use DSA in
> TLSs, it would be nice if they could run TLS 1.3 with DSA if they
> choose to do so.

I think we all know that TLS is more than browsers.
However the "people who use DSA in TLS" are currently a mere statement
from you, we don't know if they exist. Several people have asked you
whether you can name use cases. You haven't answered.

As long as that's the case this discussion is pointless. We shouldn't
keep DSA just because someone we don't know might have a use case we
can't imagine.

If you can tell us
a) who is using DSA
b) why they think this has an advantage
we can have a useful discussion.

-- 
Hanno Böck
http://hboeck.de/

---

From: Dave Garrett <[email-masked]>
Date: Mon, 31 Aug 2015 19:06:14 -0400

> we can have a useful discussion.

Not to mention:
c) why they aren't switching to ECDSA

Dave

---

From: Robert Relyea <[email-masked]>
Date: Mon, 31 Aug 2015 17:47:26 -0700

> implementations do not necessarily support those today.

That's sort of a generic statement. I know NSS supports 2048 and 3072 
bit DSA.