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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 02 Nov 2016 19:08:13 -0700

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.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 3 Nov 2016 13:33:21 +0000

>deterministic ECDSA? (Or better, make it a MUST.)

I don't recall that we gave this any prior consideration. Would be fine
with me, but I'll defer to some of our more security-focused folks.

Jon Peterson
Neustar, Inc.

---

From: Chris Wendt <[email-masked]>
Date: Fri, 4 Nov 2016 11:29:27 -0400

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 <[email-masked]> wrote:
>

---

From: Eric Burger <[email-masked]>
Date: Fri, 4 Nov 2016 14:58:45 -0400

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 <[email-masked]> wrote:
> 
> Hi Stephen,
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Chris Wendt <[email-masked]>
Date: Fri, 4 Nov 2016 15:18:58 -0400

“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 <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Nov 2016 22:45:45 +0000

Hiya,

> “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.
> 
> 
>> 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.
>> 
>>> 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.
>>> 
>>>> 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.
>>>> 
>>>> 
>>>> 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 [email-masked] https://www.ietf.org/mailman/listinfo/stir
>> 
>> _______________________________________________ stir mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/stir
> 
> _______________________________________________ stir mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/stir
>

---

From: Chris Wendt <[email-masked]>
Date: Mon, 7 Nov 2016 09:34:46 -0500

I’m good with that.

-Chris

> On Nov 4, 2016, at 6:45 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
>> [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>