[TLS] Fwd: Re: Require deterministic ECDSA

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 <msj@nthpermutation.com>
To: 	Geoffrey Keating <geoffk@geoffk.org>

On 1/23/2016 8:05 PM, Geoffrey Keating wrote:
> Michael StJohns <msj@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