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
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
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
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
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the
IETF.
Title : The Transport Layer Security (TLS) Protocol Version
1.3
Author : Eric Rescorla
Folks,
I've just posted draft-08 which includes the changes discussed on-list
to require digital signatures from the client even if you are re-using
a previous configuration in 0-RTT (per WG discussion).
This version also includes a bunch of other cleanup, as detailed below:
- Remove support
https://github.com/tlswg/tls13-spec/issues/233
Folks,
We presently have some support for DH_anon cipher suites. I agree that this
is a useful use case, but it's yet another mode.
I would like to suggest that we instead deprecate it and instead always use
Raw Public Key mode
How's it done with IPv6, generally?
We don't see address-sharing with IPv6, although I wonder if that will change
when the routing tables get too big. :) We also don't see anyone willing to go
IPv6-only; it's not close to universal enough yet.
I agree that it's a lot of effort for
On 28 August 2015 at 11:33, Viktor Dukhovni ietf-d...@dukhovni.org wrote:
On the other hand, it allows servers to detect that a
client is not planning to authenticate the server, which has forensic
value, and can be used to grant appropriately restricted access.
I think that these are
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
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
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
On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote:
This seems fine to me, though I'll note that 7250 only really saves
you space when it comes down to it. You can wrap your raw public key
in a certificate, just like we do in WebRTC, and then you don't need
7250 support in your
Or what we do in WebRTC, which uses a certificate that has no good
information in it?”
+1. Anxiously waiting for response on this, as I am currently helping
non-profit groups build a private and secure P2P Messaging System using WebRTC,
which of course utilizes encrypted P2P connection between
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
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
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
17 matches
Mail list logo