Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-passport-10: (with DISCUSS)

[Stephen Farrell <[e-mail]>]

Hiya,

On 04/11/16 19:18, Chris Wendt wrote:
> “hobble” is a hugely inappropriate term.

Well, arguably so is "hugely inappropriate" :-)

I'd agree though that hobble is a teeny bit overstated.

I think Eric does have a point though that STIR involves a chunk of
new code so the problems aren't as bad as in other situations. I'd
also encourage the WG to maybe look some more - as I said in the
case of COSE, recent findings were that deterministic ECDSA was
available in most crypto libraries now. That might not yet have
percolated up to higher level libraries I guess (though last I
looked neither had ECDSA, but it's been a while).

Nonetheless that doesn't stop you saying something like:

"Signers SHOULD use deterministic ECDSA if/when supported in their
development environment for the reasons stated in [RFC6979]."

As you said, verifiers don't need to care and I think the above
is also painless for those writing signing code, but does give
better guidance.

Sound reasonable?

Cheers,
S.

> 
> I’m not seeing any huge push to move to deterministic ECDSA although
> to be frank i won’t claim to be in the middle of this issue either.
> 
> Seems to me, if deterministic ECDSA becomes the preferred/default
> implementation, then problem solved and we didn’t have to change
> anything because both are compatible with each other from a signature
> validation point of view.
> 
> 
>> On Nov 4, 2016, at 2:58 PM, Eric Burger
>> <[e-mail]> wrote:
>> 
>> I would offer saying that the limited, but existing, availability
>> of deterministic ECDSA is a barrier to widespread adoption barriers
>> for STIR is a non-issue. We are not talking about how to update 300
>> different browser-OS-hardware combinations in the wild where 15%
>> are running Mosaic on WindowsXP. We are talking about code that has
>> yet to be written. As such, there is no reason to effectively say
>> “strong security is not important if the alternative is no
>> security” or “we cannot get the major browser players to adopt our
>> approach because OpenSSL does not implement the feature.”
>> 
>> Rather, given all this code is being written *today*, there is
>> absolutely no reason to hobble STIR before it launches.
>> 
>>> On Nov 4, 2016, at 11:29 AM, Chris Wendt
>>> <[e-mail]> wrote:
>>> 
>>> Hi Stephen,
>>> 
>>> As Jon mentioned, we can’t claim to have spent time on this, but
>>> I did look at over the past two days and discussed it with some
>>> of the relevant security folks and I think this would be our
>>> position:
>>> 
>>> The main concern around not using deterministic ECDSA is that you
>>> “may” have bad random number generators as an input K, and
>>> therefore may have some way of looking at patterns and finding
>>> exploits perhaps for a given signature.
>>> 
>>> I did a brief survey of popular packages used as part of popular
>>> server side languages, golang, java, python, and only found a
>>> single mention of python package last updated in early 2015
>>> implementing RFC6979/deterministic ECDSA.
>>> 
>>> Given the availability of solid implementations of RFC6979, I
>>> would say we have a big hurdle here to getting acceptance and
>>> usage of STIR/passport by implementation providers, and i would
>>> have a personal concern that we may force folks to use less
>>> tested and less accepted implementations of ECDSA and therefore
>>> potentially reduce security from a completely different angle.
>>> 
>>> For the initial deployment of STIR, most implementations are
>>> going to be server side in any case where there is less concern
>>> about bad random number generation.  So i think we are covered
>>> until and unless deterministic ECDSA becomes more widely adopted.
>>> For the point when smart phones may start doing STIR signatures,
>>> perhaps because they are becoming as powerful as PCs, their
>>> random generators if they don’t already (i suspect) will provide
>>> acceptable security in the signatures as well.
>>> 
>>> One thing i could do in the passport document is have an
>>> informative note to talk about this concern and if you are
>>> implementing passport signatures on devices without proper random
>>> number generation capabilities you may want to consider
>>> implementing RFC6979.  Signatures that are produced by normal
>>> ECDSA and deterministic ECDSA are compatible so there shouldn’t
>>> be any concern there.
>>> 
>>> Would that be acceptable?  Or after the above discussion do you
>>> think that is necessary?
>>> 
>>> Thanks.
>>> 
>>> -Chris
>>> 
>>> 
>>>> On Nov 2, 2016, at 10:08 PM, Stephen Farrell
>>>> <[e-mail]> wrote:
>>>> 
>>>> Stephen Farrell has entered the following ballot position for 
>>>> draft-ietf-stir-passport-10: Discuss
>>>> 
>>>> When responding, please keep the subject line intact and reply
>>>> to all email addresses included in the To and CC lines. (Feel
>>>> free to cut this introductory paragraph, however.)
>>>> 
>>>> 
>>>> Please refer to
>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for
>>>> more information about IESG DISCUSS and COMMENT positions.
>>>> 
>>>> 
>>>> The document, along with other ballot positions, can be found
>>>> here: 
>>>> https://datatracker.ietf.org/doc/draft-ietf-stir-passport/
>>>> 
>>>> 
>>>> 
>>>> ----------------------------------------------------------------------
>>>>
>>>> 
DISCUSS:
>>>> ----------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> 
Deterministic ECDSA (RFC6979) gets rid of a significant weakness
>>>> with ECDSA. IIRC when JOSE was done there was a feeling that
>>>> adding a MUST or SHOULD for that was tricky due to lack of
>>>> support in libraries. When we recently re-checked for COSE, the
>>>> answer was that today, it's ok to have that as a MUST or
>>>> SHOULD. (If some kind of FIPS-140 stuff precludes a MUST, then
>>>> a "SHOULD unless you're sad enough to be stuck having to pay
>>>> lip lipservice to FIPS-140" clause might be right. So the
>>>> DISCUSS point here is: given the real-world demonstrated
>>>> weakness inherent in the need for an RNG in ECDSA why didn't
>>>> the WG choose to at least RECOMMEND deterministic ECDSA? (Or
>>>> better, make it a MUST.)
>>>> 
>>>> If the answer is: "we thought about it [ref] and decided to not
>>>> require deterministic" then I'll clear. But even if the WG did
>>>> consider it a couple of years ago, the situation may have
>>>> changed so a quick re-think might be worthwhile.
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> _______________________________________________ stir mailing
>>> list [e-mail] https://www.ietf.org/mailman/listinfo/stir
>> 
>> _______________________________________________ stir mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/stir
> 
> _______________________________________________ stir mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/stir
>