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

“hobble” is a hugely inappropriate term.

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 <eburger@standardstrack.com> 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 <chris-ietf@chriswendt.net> 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 <stephen.farrell@cs.tcd.ie> 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
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir