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

[Chris Wendt <[e-mail]>]

I’m good with that.

-Chris

> On Nov 4, 2016, at 6:45 PM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> 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] <mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>