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

Eric Burger <eburger@standardstrack.com> Fri, 04 November 2016 18:58 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB2D129569; Fri, 4 Nov 2016 11:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.012
X-Spam-Level:
X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZuqVUYSuO23; Fri, 4 Nov 2016 11:58:51 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B42471293DC; Fri, 4 Nov 2016 11:58:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CZSg8Uds4/hjwwK6LoYzCI4sWs6mcggLYse9H8eSot8=; b=siyfXohJpjSeffghXVX0EkKgb cu3OTaHpPFl19LpOAqOTzkuFGM0RS6k5COOjGpaJQQZGBYWmra2Ylk8npBIqEpjUbkog3sGkMiBP+ 87Hhk6gnYTo8CFKiIrT1NGNkFIS+qR4jRuPLli0wxQU/3rcvmrBw4XaKbwhAwwcFf/yLc=;
Received: from [141.161.133.199] (port=53625 helo=[10.129.224.170]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from <eburger@standardstrack.com>) id 1c2jhP-0000IU-Au; Fri, 04 Nov 2016 11:58:51 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_4E232FF8-36F6-495F-B027-D2562D1D9B69"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Eric Burger <eburger@standardstrack.com>
In-Reply-To: <CEF5F03E-023A-4A52-B64E-E336FC2E2977@chriswendt.net>
Date: Fri, 04 Nov 2016 14:58:45 -0400
Message-Id: <1E70EB66-4F9A-45FD-BFFE-086435939AC6@standardstrack.com>
References: <147813889365.24118.12619854983152878871.idtracker@ietfa.amsl.com> <CEF5F03E-023A-4A52-B64E-E336FC2E2977@chriswendt.net>
To: IETF STIR Mail List <stir@ietf.org>
X-Mailer: Apple Mail (2.3124)
X-OutGoing-Spam-Status: No, score=-0.2
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Authenticated-Sender: biz104.inmotionhosting.com: eburger@standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/2X3KUHDTkXrkYSSOLH2Debv7tiA>
Cc: The IESG <iesg@ietf.org>
Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-passport-10: (with DISCUSS)
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Nov 2016 18:58:53 -0000

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