Re: [TLS] DSA support in TLS 1.3.

[Ilari Liusvaara]

On Tue, Sep 01, 2015 at 05:58:33PM +, Salz, Rich wrote:
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Blumenthal, Uri -- 0553 -- MITLL]

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


smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Blumenthal, Uri -- 0553 -- MITLL]

On 9/1/15 14:49 , Watson Ladd wrote:

On Tue, Sep 1, 2015 at 2:02 PM, Blumenthal, Uri - 0553 - MITLL
 wrote:

On 9/1/15, 13:54 , "TLS on behalf of Dave Garrett"  wrote:


On Tuesday, September 01, 2015 01:24:05 pm Jeffrey Walton 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.

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


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

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.



smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Tony Arcieri]

On Tuesday, September 1, 2015, Blumenthal, Uri -- 0553 -- MITLL <
u...@ll.mit.edu> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Jeffrey Walton]

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

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

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

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Robert Relyea]

On 08/28/2015 08:17 PM, Geoffrey Keating wrote:

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

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.



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




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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls





smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Dang, Quynh]

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 <tls-boun...@ietf.org> on behalf of Dang, Quynh <quynh.d...@nist.gov>
Sent: Friday, August 28, 2015 3:17 PM
To: e...@rtfm.com; tls@ietf.org
Subject: [TLS] DSA support in TLS 1.3.


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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Hanno Böck]

On Mon, 31 Aug 2015 12:13:09 +
"Dang, Quynh"  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/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgp_GgoJZKH3_.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Dave Garrett]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Geoffrey Keating]

Jeffrey Walton noloa...@gmail.com 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.

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Jeffrey Walton]

 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.

Jeff

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Ronald del Rosario]

 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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Dave Garrett]

On Friday, August 28, 2015 04:21:53 pm Hanno Böck wrote:
 On Fri, 28 Aug 2015 19:17:39 +
 Dang, Quynh quynh.d...@nist.gov wrote:
  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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Hanno Böck]

On Fri, 28 Aug 2015 19:17:39 +
Dang, Quynh quynh.d...@nist.gov 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: ha...@hboeck.de
GPG: BBB51E42


pgpNMWVrh6boY.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Tony Arcieri]

On Friday, August 28, 2015, Dang, Quynh quynh.d...@nist.gov 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Ilari Liusvaara]

On Fri, Aug 28, 2015 at 07:17:39PM +, 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] DSA support in TLS 1.3.

[Dang, Quynh]

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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DSA support in TLS 1.3.

[Jacob Appelbaum]

On 8/28/15, Dang, Quynh quynh.d...@nist.gov 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.


 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.


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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls