Sorry - I hit the wrong "reply to" button.
-------- Forwarded Message --------
Subject: Re: Require deterministic ECDSA
Date: Sat, 23 Jan 2016 20:52:53 -0500
From: Michael StJohns <m...@nthpermutation.com>
To: Geoffrey Keating <geo...@geoffk.org>
On 1/23/2016 8:05 PM, Geoffrey Keating wrote:
Michael StJohns <m...@nthpermutation.com> writes:
On 1/23/2016 2:13 PM, Joseph Birr-Pixton wrote:
Hi,
I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA.
For discussion, here's a pull request with possible language:
https://github.com/tlswg/tls13-spec/pull/406
Cheers,
Joe
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Correct me if I'm wrong but:
1) A receiver of an deterministic ECDSA signature verifies it EXACTLY
like they would a non-deterministic signature.
2) A receiver of an ECDSA signature cannot determine whether or not
the signer did a deterministic signature.
3) A TLS implementation has no way (absent repeating signatures over
identical data) of telling whether or not a given signature using the
client or server private key is deterministic.
All that suggests that this is a completely unenforceable
requirement with respect to TLS.
A test suite can easily determine, if it knows the private key in use
by the implementation under test, whether that implementation is
generating RFC 6979 deterministic signatures or not. That seems to me
an adequate enforcement mechanism.
Um.. not really. The actual worked example is FIPS. There are lots
of FIPS TLS implementations and they all go through testing (your
proposed enforcement mechanism), and there is exactly NO way for one
FIPS implementation to ensure that it is talking to another FIPS
implementation. The best they can do is limit the offer and acceptance
of specific crypto suites.
MUST or "Required" in IETF parlance is usually reserved for choices
that have to be made to have interoperable products. Neither FIPS nor
deterministic ECDSA rise to that level. FIPS at least recognizes that
and imposes its requirements on the buyers (US Gov't and US Gov't
contractors) who then ask for FIPS capable products. And people who want
to sell to the government then make FIPS capable products that ... wait
for it... interoperate with non-FIPS products.
From 2119:
In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
Or would you argue that I'm misinterpreting the above and the impact of
your suggested change?
(Um.. in the above "causing harm" has usually been interpreted to mean
"harm to the network" - not preventing stupidity in implementation).
Later, Mike
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
