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

Chris Wendt <> Mon, 07 November 2016 14:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A2AD129766 for <>; Mon, 7 Nov 2016 06:34:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EiqMoihMCo3V for <>; Mon, 7 Nov 2016 06:34:50 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92C56129706 for <>; Mon, 7 Nov 2016 06:34:50 -0800 (PST)
Received: by with SMTP id c47so88007065qtc.2 for <>; Mon, 07 Nov 2016 06:34:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vCJ7xYZKQeKx86quprd7PpNcfmaC6tVVVibZ9faG4RU=; b=1D40VNNqgwQkS/wNVGDaJyZg4fPDSyfEKeYxcOPXfRVMrfGoLZNoZ36T8jrPv8xkJB aJ7H+4sCn5QQQ1v93xYSePbNAR5grW5GBAlP9WTvH5sHN0SwIgQGsiIWrOBNbVMiWWNH 5/wDdwaliv3nz5TmRuMRiAekOuUxNANh2ys93OkgfiuROnSN+vkBa3u8ifJB+wL8m5KD RPpYTQNl3hdJY9R2A29Wdeacl318wmnHu2qX2HjAMqOpqsdP3dtTkpnveNFIpRjhiLZP lALHeAWxkv1sz2eNhuW21ExjkfqX6uTIvZZ9TMxYn6QtRuvWfmyKXHfADufunpDW9VZe MYWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vCJ7xYZKQeKx86quprd7PpNcfmaC6tVVVibZ9faG4RU=; b=l4+xya6ovpWrkF/F+zpMLik95i6KcmNcIATq4rkj3NE6fAiRrHtPK3ICpg0LMmJaFD 0e+sBu+42Q06zfcqAMQBrOt0eTnFmZ4PzZ6BbR5xtcaa2uVfGElH2L4V89KRI6Bgvgi8 oxtBAeI8fHDpqQWi3myTeeKQJhcfgo22P3FgjYRUVFTyujOJn/JL1diFLJ6BzZShgJCX aW0WHvzThshASySK9fpoy4B7asDd7BWT5XjH3GYO1vl1ZnA7q5nQjU1ZZ9pTRykvvFgn E4RATj9bwXvNWpkfeUfBHEEkLYPTWx8WZgmhM3OUSAevkHOCHjzs7c59iyxzCZ0hQAau gFKg==
X-Gm-Message-State: ABUngvf1lh0bfBWWcuNOLX5eu6WPKlShiM4z4gljrJnkH4gkB8YTV7eHx4snuEoVqeheUA==
X-Received: by with SMTP id y9mr6887792qty.26.1478529288665; Mon, 07 Nov 2016 06:34:48 -0800 (PST)
Received: from ?IPv6:2601:a40:100:d3:10a6:6f2:1e76:d362? ([2601:a40:100:d3:10a6:6f2:1e76:d362]) by with ESMTPSA id s41sm16514474qtc.39.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Nov 2016 06:34:47 -0800 (PST)
From: Chris Wendt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E90E07E6-B25C-41C6-BF2A-E6602045AB4B"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Date: Mon, 07 Nov 2016 09:34:46 -0500
In-Reply-To: <>
To: Stephen Farrell <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3251)
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: Mon, 07 Nov 2016 14:34:53 -0000

I’m good with that.


> On Nov 4, 2016, at 6:45 PM, Stephen Farrell <> 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
>>> <> 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 
>> <> <>