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

Chris Wendt <> Fri, 04 November 2016 15:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 808BC129563 for <>; Fri, 4 Nov 2016 08:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fNzMHUdg6JOh for <>; Fri, 4 Nov 2016 08:29:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2209912943C for <>; Fri, 4 Nov 2016 08:29:30 -0700 (PDT)
Received: by with SMTP id n204so91197189qke.2 for <>; Fri, 04 Nov 2016 08:29:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=POrbSgzjJxpqIIQ/W7CGMyO4ioDszZYVZCb8uyW9q68=; b=j70rGVxlF69Fugso8ISwP9Y8Fho+jlkR/pjCJN5nsgvaweaK929xLYB7rVTqDPsoga wQXz4oY2U/SZulBiNh5D5BqNAqbpQNfgnT+gfFgS+wo0992rqk5GWFisRsbiJanctKnM Aej4vs5GkUGjgVNVGApEibRyMnlAE4AAxzvelP/Xicthd2GKqGsSZtBl4bsTRn0BuphO WHsjge1XZQtYNyxaFedqSGpUj0f4AIZ/LWukcTq28GMdLNObv7TontETLTGj0zG6wOe+ +/4gwYVxWTo8hw/ElFa00J89sLP6WCFzBkmf1dx/zaeL3bBYFbwIExRqXxh2AAK5BDNf Y8Nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=POrbSgzjJxpqIIQ/W7CGMyO4ioDszZYVZCb8uyW9q68=; b=C5uCqkLekWIKEV8PVPFMJBIYAsWGcoPxX4ytR0IBfzyji0kIEkpVAZPMhYlnDGGcvX 8ihJI/kPpwoyHHXVAOexgnkdqx+SFp/qvB9gjMIX2VExyiMK8S3UY2DgI7n0mtv+gAS6 cu6yJureQt8DSAuISYKeK41/n6tGU5dTZla907+iXCVHhzqvQegzzqE/mjQs80f1Mw7J 5zQXjPmDRNmSfGwGV3YXxC6Ttcd75dbEqLzTHT8pBAaeJYRNY8kWdZZ0zXeKE+KfviHn OS2xCCJteczP0Fb44fnslQNOknC1AVYnAjH0viIaDPWJrORVCqhJtEN5rj/wOTp7nORi yaHg==
X-Gm-Message-State: ABUngvdp34t7jDOujj/q0rbvcI6M2PD7lH10AU16z+0R0U9L9tk26DGRkhB2xUr6VNOtrg==
X-Received: by with SMTP id 126mr12921278qkh.224.1478273369273; Fri, 04 Nov 2016 08:29:29 -0700 (PDT)
Received: from ?IPv6:2601:41:c101:9364:d057:f30a:2440:c90? ([2601:41:c101:9364:d057:f30a:2440:c90]) by with ESMTPSA id q65sm7088109qki.20.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 08:29:28 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Chris Wendt <>
In-Reply-To: <>
Date: Fri, 04 Nov 2016 11:29:27 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.3251)
Archived-At: <>
Cc:,, Robert Sparks <>, 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 15:29:32 -0000

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?



> 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.