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

Stephen Farrell <> Fri, 04 November 2016 22:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9B431299C2; Fri, 4 Nov 2016 15:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.798
X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wVA7oULlDgi4; Fri, 4 Nov 2016 15:45:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B04251299AA; Fri, 4 Nov 2016 15:45:50 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0167CBE5B; Fri, 4 Nov 2016 22:45:48 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bXjzTFVORqop; Fri, 4 Nov 2016 22:45:46 +0000 (GMT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 9C0E0BE56; Fri, 4 Nov 2016 22:45:45 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1478299546; bh=P7IDhHHI6bhvuo7PZ++2TrYYvvIpmBHDzWD6UaRZUCM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=c+2xjyzBQbQLWKL1PnCGgctpDFe5r+AOgaGRui3AOVFhIaOM00UUsbnjAitZFfZju 5KBBxu2qGmLiKOhSm18UDikoXQ1AliLimRfEAVd/4FAc2gbhtO1RLnQ0EYW5ewE8OL F0igiyOpmOwbbQuHVv/4x2jRb0Q3gjlLR7g1R0aE=
To: Chris Wendt <>, Eric Burger <>
References: <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Fri, 04 Nov 2016 22:45:45 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms010600050207010401030806"
Archived-At: <>
Cc: IETF STIR Mail List <>, The IESG <>
Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-passport-10: (with DISCUSS)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Nov 2016 22:45:54 -0000


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?


> 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
>> <> 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
>>> <> 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
>>>> <> 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
>>>> for
>>>> more information about IESG DISCUSS and COMMENT positions.
>>>> The document, along with other ballot positions, can be found
>>>> here: 
>>>> ----------------------------------------------------------------------
>>>> ----------------------------------------------------------------------
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 mailing list 
> _______________________________________________ stir mailing list