From nobody Tue Apr 5 07:36:57 2016 Return-Path: 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 DC3C612D507 for ; Tue, 5 Apr 2016 07:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 PJlniqpz_XDt for ; Tue, 5 Apr 2016 07:36:53 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8259912D145 for ; Tue, 5 Apr 2016 07:36:52 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-d6-5703cd82c46d Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4B.63.22880.28DC3075; Tue, 5 Apr 2016 16:36:50 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.106]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Tue, 5 Apr 2016 16:36:50 +0200 From: John Mattsson To: "stir@ietf.org" Thread-Topic: Choice of STIR signature algorithm Thread-Index: AQHRj0iWb832AGdGDEePNXJedu5tug== Date: Tue, 5 Apr 2016 14:36:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7nG7TWeZwg/fbLS2Wr93G5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDu/F7IUXBGt6Hp1lrWBsUe0i5GTQ0LARGLW6+1sELaYxIV7 64FsLg4hgSOMEpMXvGKGcBYzSvxb1cAOUsUmYCAxd08DWIeIgLLElnV3wOLCAtoSM5+eY4WI G0hMOXgDqIYDyNaTeLHOBsRkEVCRmPajAKSCV8Bc4tPmBWCdjEB7v59awwRiMwuIS9x6Mp8J 4h4BiSV7zjND2KISLx//A5suCjTxdsdadoi4ksTaw9tZQMYzC2hKrN+lDzHGWmLlnQ8sELai xJTuh+wQawUlTs58wjKBUXQWkm2zELpnIemehaR7FpLuBYysqxhFi1OLi3PTjYz1Uosyk4uL 8/P08lJLNjECo+Tglt+6OxhXv3Y8xCjAwajEw6sgwxwuxJpYVlyZe4hRgoNZSYQ3+wRQiDcl sbIqtSg/vqg0J7X4EKM0B4uSOG9O5L8wIYH0xJLU7NTUgtQimCwTB6dUA2PsCpkZK8olpfvY 56VwhL2cmR+7jGcZL1eL4MtXtQ+E9V/qbf5wtH1JZcGar+07v4lEa+cbb/rFZScYwOl2UHTL tt650/7JdSYqhPfI7P/4NHWC1NqkDZFPgr7tbZX5u7LNfWGHWNuHrba3dq/+b2T/0yv5HYPy jE03phs+u73y0UfDKdqrw3YpsRRnJBpqMRcVJwIARsKF1I4CAAA= Archived-At: Subject: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Tue, 05 Apr 2016 14:36:56 -0000 SSB0aGluayB0aGVyZSBhcmUgc2V2ZXJhbCBzdHJvbmcgcmVhc29ucyB0byBjaGFuZ2UgdGhlIGRl ZmF1bHQgc2lnbmF0dXJlDQphbGdvcml0aG0gaW4gZHJhZnQtaWV0Zi1zdGlyLXJmYzQ0NzRiaXMg YW5kIGRyYWZ0LWlldGYtc3Rpci1wYXNzcG9ydC4gVGhlDQpjdXJyZW50IGRlZmF1bHQgYWxnb3Jp dGhtIGlzIFJTMjU2IChSU0FTU0EtUEtDUzEtdjFfNSB1c2luZyBTSEEtMjU2KSwgYnV0DQpJIGNh bm5vdCBmaW5kIGFueSBudW1iZXIgZm9yIE1USS9SZWNvbW1lbmRlZC9NaW5pbXVtL0RlZmF1bHQg a2V5IGxlbmd0aC4NCg0KMS4gUlNBIHNpZ25pbmcgaXMgZXh0cmVtZWx5IHNsb3cgY29tcGFyZWQg dG8gbW9kZXJuIGFsdGVybmF0aXZlcy4gT24gYQ0KQ29yZSBpNS02NjAwLCBFUzI1NiAoRUNEU0Eg dXNpbmcgUC0yNTYgYW5kIFNIQS0yNTYpIGlzIDIxIHRpbWVzIGZhc3Rlcg0KdGhhbiBSU0EtMjA0 OCwgYW5kIEVkMjU1MTkgaXMgNjcgdGltZXMgZmFzdGVyDQooaHR0cHM6Ly9iZW5jaC5jci55cC50 by9yZXN1bHRzLXNpZ24uaHRtbCkuIEFzIFJTQS0yMDQ4IGlzIG5vcm1hbGx5DQpjbGFzc2lmaWVk IGFzIHJvdWdobHkgMTEyLWJpdCBzZWN1cml0eSAoUkZDMzc2NiwgTklTVCwgRU5JU0EpLCBhIG1v cmUgZmFpcg0KY29tcGFyaXNvbiBpcyB3aXRoIFJTQS0zMDcyLCBhbmQgdGhlbiBFUzI1NiBpcyA1 MiB0aW1lcyBmYXN0ZXIgYW5kIEVkMjU1MTkNCmlzIDE2OSB0aW1lcyBmYXN0ZXIuDQoNCjIuIFJT QSBzaWduYXR1cmVzIGFyZSBtdWNoIGxhcmdlciB0aGFuIHRoZWlyIEVDQyBjb3VudGVycGFydHMu IFJTQS0yMDQ4DQpzaWduYXR1cmVzIGFyZSAyNTYgYnl0ZXMgYW5kIFJTQS0zMDcyIHNpZ25hdHVy ZXMgYXJlIDM4NCBieXRlcywgd2hpbGUNCkVTMjU2IGFuZCBFZDI1NTE5IHNpZ25hdHVyZXMgYXJl IG9ubHkgNjQgYnl0ZXMuDQoNCjMuIFBLQ1MxLXYxXzUgaXMgbm90IGEgdmVyeSBnb29kIGFsZ29y aXRobS4gSXQgaGFzIG5vIHNlY3VyaXR5IHByb29mcywgbm8NCmFkdmFudGFnZXMsIGlzIGRpc3Jl Y29tbWVuZGVkIGJ5IEVOSVNBIChFdXJvcGVhbiBVbmlvbiBBZ2VuY3kgZm9yIE5ldHdvcmsNCmFu ZCBJbmZvcm1hdGlvbiBTZWN1cml0eSksIGFuZCBoYXMgYmVlbiByZXBsYWNlZCBpbiBUTFMgMS4z LiBJIGRvIG5vdA0KdGhpbmsgdGhpcyBpcyB0aGUgYWxnb3JpdGhtIHdlIHNob3VsZCB1c2UgaW4g U1RJUi4NCg0KSSB0aGluayB0aGUgcmlnaHQgYWxnb3JpdGhtIGNob2ljZSBmb3IgU1RJUiBpcyBF UzI1NiBvciBFZDI1NTE5Lg0KU2lnbmF0dXJlIHByb2Nlc3NpbmcgaXMgbGlrZWx5IHRoZSBtYWlu IGJ1cmRlbiBmb3IgdGhlIEF1dGhlbnRpY2F0aW9uDQpTZXJ2aWNlLCBhbmQgY2hhbmdpbmcgZnJv bSBSU0EgdG8gRUNDIHNpZ25pZmljYW50bHkgcmVkdWNlcyB0aGUgYW1vdW50IG9mDQpoYXJkd2Fy ZSBuZWVkZWQsIGFuZCB0aGVyZWZvcmUgdGhlIGNvc3QuIEEgc2luZ2xlIDMuMyBHaHogU2t5bGFr ZSBjb3JlIGNhbg0KZG8gb25seSA0MDAgUlNBLTMwNzIgb3IgMSwwMDAgUlNBLTIwNDggc2lnbmF0 dXJlcyBwZXIgc2Vjb25kLCBidXQgMjEsMDAwDQpFUzI1NiBvciA2OCwwMDAgRWQyNTUxOSBzaWdu YXR1cmVzIHBlciBzZWNvbmQuIFJTQSB2ZXJpZmljYXRpb24gaXMgYSBiaXQNCmZhc3RlciB0aGFu IEVDQywgYnV0IHRoZSBkaWZmZXJlbnQgaXMgbXVjaCBzbWFsbGVyIHRoYXQgZm9yIHNpZ25pbmcs DQpSU0EtMzA3MiB2ZXJpZmljYXRpb25zIGFyZSBlLmcuIHR3aWNlIGFzIGZhc3QgYXMgRWQyNTUx OSB2ZXJpZmljYXRpb25zLg0KDQpDaGVlcnMsDQpKb2huDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpKT0hOIE1B VFRTU09ODQpNU2MgRW5naW5lZXJpbmcgUGh5c2ljcywgTVNjIEJ1c2luZXNzIEFkbWluaXN0cmF0 aW9uIGFuZCBFY29ub21pY3MNCkVyaWNzc29uIElFVEYgU2VjdXJpdHkgQ29vcmRpbmF0b3INClNl bmlvciBSZXNlYXJjaGVyLCBTZWN1cml0eQ0KDQo= From nobody Tue Apr 5 09:20:34 2016 Return-Path: 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 EF05112D0DA for ; Tue, 5 Apr 2016 09:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 WvKRQ8Qc-ZZ2 for ; Tue, 5 Apr 2016 09:20:31 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CDE312D6CB for ; Tue, 5 Apr 2016 09:20:27 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id r184so6917988qkc.1 for ; Tue, 05 Apr 2016 09:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZbyHy4mPnH94ArLXpUvtpcwIdToAimecIikXGTXXIjU=; b=ftiflNl9AcWbiVIAZMQOTP5f/YRH72PYnywF5d3Hpz+98gzKEOAkuoZMSj+dq5O5Bd h7H+VJG5ArbCR/S6nGg+uyrK43snanOPQwUXpIrFpAdh1QUUdwbtwJMcPkFrhOyJvHul ggf+B1D2ARhnU1JDM+1vkJROotDc2zXc2RdzM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZbyHy4mPnH94ArLXpUvtpcwIdToAimecIikXGTXXIjU=; b=mvfSg0ffYsJmm4jrDo5j1t9gYWBn87KP8LvONRBQIU0Yozrq9KrasjdqlHMDr6nzAp XTNx/6pNuVLRuU1poOreKFanr+2nfvuw1RPMBwQSX9HNrsaUxj42PTDtViMgmJpih33v dkcsf8q6I5NwQDO1xx2bgpd1kJg7e09qAB4T9gbGhUOp3sm0Il0JGof6aQ88epGkjCGJ NtqyrCUBBr755CkXGFLlrFFKqAb30nWswsBu0Cb8zz70P88pgN1fhGqf+Pwho4R+sLZN H8Bhsmk2PlxddVlllOBld0ieoGY+/USkrLNEJqAuLquyMv8Y7eTkk4MO9DygInRUuYb1 2HVg== X-Gm-Message-State: AD7BkJLS5NyU8sJmsy555FHLdJdc337UneWHV0vLpRd8BHoMJJHvn9fTUbRGLW/XpBsc+w== X-Received: by 10.55.74.75 with SMTP id x72mr41629590qka.100.1459873226705; Tue, 05 Apr 2016 09:20:26 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:a0a7:9d9d:54f6:501? ([2001:67c:370:176:a0a7:9d9d:54f6:501]) by smtp.gmail.com with ESMTPSA id 9sm14878028qgl.18.2016.04.05.09.20.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2016 09:20:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Tue, 5 Apr 2016 13:20:23 -0300 Content-Transfer-Encoding: 7bit Message-Id: References: To: John Mattsson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Tue, 05 Apr 2016 16:20:33 -0000 On Apr 05, 2016, at 11:36, John Mattsson wrote: > > I think the right algorithm choice for STIR is ES256 or Ed25519. I agree. spt From nobody Tue Apr 5 10:09:14 2016 Return-Path: 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 389C312D918 for ; Tue, 5 Apr 2016 10:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 DgEl-KsSMptJ for ; Tue, 5 Apr 2016 10:09:10 -0700 (PDT) Received: from mail-qg0-x244.google.com (mail-qg0-x244.google.com [IPv6:2607:f8b0:400d:c04::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A46012D6FD for ; Tue, 5 Apr 2016 10:09:10 -0700 (PDT) Received: by mail-qg0-x244.google.com with SMTP id y89so1789478qge.0 for ; Tue, 05 Apr 2016 10:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hxg3xp4x5yX+9T/xWZgvoglCwApEca47by2WQCXKWxA=; b=MmDXx/nqvM6ILPa7GDPY1/9X5S1uu1KYWAuygeSgZfS7NumOQau19t+kVOvO1sSQiF Q4uI651mAEYQ+6bSJquxnFcLSP8Tzn4Cr6emaAyg3TqoCngD4vOAxzwGc+NPRVEwq8ki 5savJ+SmTjlERMzcvpTSg3HrPW5sOXXaTgrlRveHnVtERIACYAszcecIHo2geqZf2btg 70vX7EfNyOk+Dllas8MXF0RhUMM+xhea7ee0tcJE1SsDmdi73fVRUQPDw1YZt1c7SRkn NXsIYDMO8mP94PIWgXEjDDK8TZLghWLHoEB50zvBTzymYM/R81oJnmeWL/qMNGRzpuFm xUTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hxg3xp4x5yX+9T/xWZgvoglCwApEca47by2WQCXKWxA=; b=HvIdEAmkApWIs9/Owf78pbnHWdEMUehAp0sw+o8R3NZpxu7mPj5xVg1/JejYTg+muX Fz4puIC4pSy5GdyNSKB1isn8pewTU9lN5QJmkCbQFHw/7fnvzK0ysk4YmYUEtuj/cor5 g8Agah6h3/OnmxrqBH3MPfqGOkWJVdFYLM2GFVdDYAYLO0McNxoui+mLqLUUAHncI2BN tN2Ir1U66jN68WcFOYyNnHxrcwjFH5uNQDwZ6VSTj4lVL+JfQYAWULt6Sq1rlw5yBSbU 2rcktMtHxW+EsYjjcHpgZ7DG9MZ9ZJHYM23+OLkqARYio87lvOIcrs8tciNcEbZednZd FxBw== X-Gm-Message-State: AD7BkJJ0jhPDOGy16Vfi67ylPrvBH2LiXXH73XIt0TEPqV4RrnNDLCRgygIB6vkLkKUSHA== X-Received: by 10.140.101.81 with SMTP id t75mr30248861qge.24.1459876134887; Tue, 05 Apr 2016 10:08:54 -0700 (PDT) Received: from [172.20.10.33] (200-127-148-163.net.prima.net.ar. [200.127.148.163]) by smtp.gmail.com with ESMTPSA id g6sm14953672qge.0.2016.04.05.10.08.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Apr 2016 10:08:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chris Wendt In-Reply-To: Date: Tue, 5 Apr 2016 14:08:49 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sean Turner X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" , John Mattsson Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Tue, 05 Apr 2016 17:09:13 -0000 I=E2=80=99m supportive of that, I can try to remember to bring it up in = the session on passport this afternoon as well to discuss. -Chris > On Apr 5, 2016, at 1:20 PM, Sean Turner wrote: >=20 > On Apr 05, 2016, at 11:36, John Mattsson = wrote: >>=20 >> I think the right algorithm choice for STIR is ES256 or Ed25519. >=20 > I agree. >=20 > spt >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Tue Apr 5 10:27:54 2016 Return-Path: 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 B0E9312D645 for ; Tue, 5 Apr 2016 10:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no 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 SL-AZATiv8vE for ; Tue, 5 Apr 2016 10:27:51 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A616112D119 for ; Tue, 5 Apr 2016 10:27:50 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id u35HNu9L002480; Tue, 5 Apr 2016 13:27:47 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 224f2gy4ud-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Apr 2016 13:27:47 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u35HRjYu003810; Tue, 5 Apr 2016 13:27:45 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u35HRXEW003562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Apr 2016 13:27:37 -0400 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 5 Apr 2016 17:27:21 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.15]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0248.002; Tue, 5 Apr 2016 13:27:20 -0400 From: "DOLLY, MARTIN C" To: Chris Wendt Thread-Topic: [stir] Choice of STIR signature algorithm Thread-Index: AQHRj13mcbROkvqrQ0eXPc8KYZ2sqZ97ohQw Date: Tue, 5 Apr 2016 17:27:20 +0000 Message-ID: <7876A01B-344B-450E-AB8B-38930AB1CC31@att.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-05_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1604050252 Archived-At: Cc: "stir@ietf.org" , Sean Turner , John Mattsson Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Tue, 05 Apr 2016 17:27:53 -0000 I can support as well Martin C Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards=20 AT&T Cell: 609-903-3360 Email: md3135@att.com > On Apr 5, 2016, at 1:09 PM, Chris Wendt wrote= : >=20 > I=92m supportive of that, I can try to remember to bring it up in the ses= sion on passport this afternoon as well to discuss. >=20 > -Chris >=20 >> On Apr 5, 2016, at 1:20 PM, Sean Turner wrote: >>=20 >> On Apr 05, 2016, at 11:36, John Mattsson wr= ote: >>>=20 >>> I think the right algorithm choice for STIR is ES256 or Ed25519. >>=20 >> I agree. >>=20 >> spt >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Tue Apr 5 10:43:24 2016 Return-Path: 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 669A612D1D2 for ; Tue, 5 Apr 2016 10:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 m66opwdUZjB6 for ; Tue, 5 Apr 2016 10:43:20 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEEC212D7D4 for ; Tue, 5 Apr 2016 10:43:19 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-9b-5703f9356630 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 25.7C.23401.539F3075; Tue, 5 Apr 2016 19:43:17 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.106]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Tue, 5 Apr 2016 19:43:00 +0200 From: John Mattsson To: Chris Wendt , Sean Turner Thread-Topic: [stir] Choice of STIR signature algorithm Thread-Index: AQHRj0iWb832AGdGDEePNXJedu5tup97bgOAgAANiID//9dAAA== Date: Tue, 5 Apr 2016 17:42:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7va7pT+Zwg82PNS2mf9rNbHFlVSOz xfK125gcmD0m9K1h9Viy5CeTx8GDjAHMUVw2Kak5mWWpRfp2CVwZizatYS+Ywl7x/8l65gbG P2xdjJwcEgImEo1HpzNB2GISF+6tB4pzcQgJHGGU+HBgPpSzmFFi25Y/LCBVbAIGEnP3NIB1 iwh4Shxf8BDI5uBgFlCW+LfbHiQsLGAmMX/eFUaIEnOJA/8mskLYThIzlk4DG8MioCIx68Z1 sDgvUM2c/gmsELsWMUqc/bKVGSTBCdRw/t5tsCJGoOu+n1oDdimzgLjErSfzoa4WkFiy5zwz hC0q8fLxP7B6UQE9idsda9kh4koSK7ZfYoS4U1Ni/S59iDHWEmcf7GWFsBUlpnQ/ZIe4R1Di 5MwnLBMYJWYh2TYLoXsWku5ZSLpnIelewMi6ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMw Lg9u+W21g/Hgc8dDjAIcjEo8vAoyzOFCrIllxZW5hxglOJiVRHhrvwOFeFMSK6tSi/Lji0pz UosPMUpzsCiJ8+ZE/gsTEkhPLEnNTk0tSC2CyTJxcEo1MDY4pL5N4mjhz9+x8sWyw5fj/W5V KQV1tHJJBT5Z9GN3tm2HstCWK4drZy31f9NZar/7ALu3cc1enue/XiyfaW5+LuPXLs0+w6Yi 8yt3JwYxlZo1ureoJdiEHi1evvqQcNp9AQtjrgUHVSbI1S+e++rG0TCzCjOWyesTl08qjlzz Ibyj8+sObyWW4oxEQy3mouJEABcIfUDHAgAA Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Tue, 05 Apr 2016 17:43:22 -0000 DQoNCk9uIDA1LzA0LzE2IDE0OjA4LCAiQ2hyaXMgV2VuZHQiIDxjaHJpcy1pZXRmQGNocmlzd2Vu ZHQubmV0PiB3cm90ZToNCg0KPknigJltIHN1cHBvcnRpdmUgb2YgdGhhdCwgSSBjYW4gdHJ5IHRv IHJlbWVtYmVyIHRvIGJyaW5nIGl0IHVwIGluIHRoZQ0KPnNlc3Npb24gb24gcGFzc3BvcnQgdGhp cyBhZnRlcm5vb24gYXMgd2VsbCB0byBkaXNjdXNzLg0KDQpQbGVhc2UgZG8sIGdvb2QgdG8gZ2V0 IGRpc2N1c3Npb24uDQoNCj4tQ2hyaXMNCj4NCj4+IE9uIEFwciA1LCAyMDE2LCBhdCAxOjIwIFBN LCBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb20+IHdyb3RlOg0KPj4gDQo+PiBPbiBBcHIgMDUs IDIwMTYsIGF0IDExOjM2LCBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNv bT4NCj4+d3JvdGU6DQo+Pj4gDQo+Pj4gSSB0aGluayB0aGUgcmlnaHQgYWxnb3JpdGhtIGNob2lj ZSBmb3IgU1RJUiBpcyBFUzI1NiBvciBFZDI1NTE5Lg0KPj4gDQo+PiBJIGFncmVlLg0KPj4gDQo+ PiBzcHQNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+IHN0aXIgbWFpbGluZyBsaXN0DQo+PiBzdGlyQGlldGYub3JnDQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCj4NCg0K From nobody Tue Apr 5 11:08:20 2016 Return-Path: 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 BB5C412D7BE for ; Tue, 5 Apr 2016 11:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 cK28r7dsD93x for ; Tue, 5 Apr 2016 11:08:04 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC9A912D13D for ; Tue, 5 Apr 2016 11:08:03 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u35I2W6a012205; Tue, 5 Apr 2016 14:07:56 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 222xkduy1c-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 05 Apr 2016 14:07:56 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.49]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Tue, 5 Apr 2016 14:07:55 -0400 From: "Peterson, Jon" To: John Mattsson Thread-Topic: [stir] Choice of STIR signature algorithm Thread-Index: AQHRj2YTntt3b3ZzjUyODuhm37BkpA== Date: Tue, 5 Apr 2016 18:07:54 +0000 Message-ID: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-05_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1604050260 Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Tue, 05 Apr 2016 18:08:17 -0000 To date we have not moved this to EC because (at least as far as I understa= nd things) many elements of web PKI, including many CAs, don't support thes= e algorithms yet. If our assessment of that is changing, then let's revisit= it.=20 Jon Peterson Neustar, Inc.=20 Sent from my iPad > On Apr 5, 2016, at 11:37 AM, John Mattsson w= rote: >=20 > I think there are several strong reasons to change the default signature > algorithm in draft-ietf-stir-rfc4474bis and draft-ietf-stir-passport. The > current default algorithm is RS256 (RSASSA-PKCS1-v1_5 using SHA-256), but > I cannot find any number for MTI/Recommended/Minimum/Default key length. >=20 > 1. RSA signing is extremely slow compared to modern alternatives. On a > Core i5-6600, ES256 (ECDSA using P-256 and SHA-256) is 21 times faster > than RSA-2048, and Ed25519 is 67 times faster > (https://bench.cr.yp.to/results-sign.html). As RSA-2048 is normally > classified as roughly 112-bit security (RFC3766, NIST, ENISA), a more fai= r > comparison is with RSA-3072, and then ES256 is 52 times faster and Ed2551= 9 > is 169 times faster. >=20 > 2. RSA signatures are much larger than their ECC counterparts. RSA-2048 > signatures are 256 bytes and RSA-3072 signatures are 384 bytes, while > ES256 and Ed25519 signatures are only 64 bytes. >=20 > 3. PKCS1-v1_5 is not a very good algorithm. It has no security proofs, no > advantages, is disrecommended by ENISA (European Union Agency for Network > and Information Security), and has been replaced in TLS 1.3. I do not > think this is the algorithm we should use in STIR. >=20 > I think the right algorithm choice for STIR is ES256 or Ed25519. > Signature processing is likely the main burden for the Authentication > Service, and changing from RSA to ECC significantly reduces the amount of > hardware needed, and therefore the cost. A single 3.3 Ghz Skylake core ca= n > do only 400 RSA-3072 or 1,000 RSA-2048 signatures per second, but 21,000 > ES256 or 68,000 Ed25519 signatures per second. RSA verification is a bit > faster than ECC, but the different is much smaller that for signing, > RSA-3072 verifications are e.g. twice as fast as Ed25519 verifications. >=20 > Cheers, > John >=20 >=20 > ------------------------------------------------------------------ > JOHN MATTSSON > MSc Engineering Physics, MSc Business Administration and Economics > Ericsson IETF Security Coordinator > Senior Researcher, Security >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Tue Apr 5 13:05:02 2016 Return-Path: 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 9D24112D7FC for ; Tue, 5 Apr 2016 13:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mLEq80IRJo6Y for ; Tue, 5 Apr 2016 13:04:56 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D3812D7FF for ; Tue, 5 Apr 2016 13:04:55 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-6f-57041a66a978 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2B.15.16394.66A14075; Tue, 5 Apr 2016 22:04:54 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.106]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Tue, 5 Apr 2016 22:04:53 +0200 From: John Mattsson To: "Peterson, Jon" Thread-Topic: [stir] Choice of STIR signature algorithm Thread-Index: AQHRj0iWb832AGdGDEePNXJedu5tup97jA0A///uY4A= Date: Tue, 5 Apr 2016 20:04:52 +0000 Message-ID: References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> In-Reply-To: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <061F8ADD04C94940BF98C7DBF141ED6D@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7im6aFEu4wZoVAhZnGiwtlq/dxuTA 5LFkyU8mjx0Nz5kDmKK4bFJSczLLUov07RK4Mh5vWcBYcEyp4sX6K2wNjFcUuxg5OCQETCT6 t3F1MXICmWISF+6tZwOxhQSOMEpcu6XUxcgFZC9mlLjz4DMzSIJNwEBi7p4GsCIRAT2Jb99n MIHMYRZQlvi32x4kLCxgJjF/3hVGiBJziQP/JrJC2FYSr56tAbNZBFQkOhZtYwexeYFqvi98 DLU3R2LumclgNZwC9hIP3+0EW8sIdNv3U2uYQGxmAXGJW0/mM0HcLCCxZM95ZghbVOLl439g vaJAp93uWMsOEVeSaFzyhBXiTE2J9bv0IcZYS1za9ZsZwlaUmNL9EOocQYmTM5+wTGCUmIVk 2yyE7llIumch6Z6FpHsBI+sqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMDoO7jlt+oOxstv HA8xCnAwKvHwKsgwhwuxJpYVV+YeYpTgYFYS4dUQYQkX4k1JrKxKLcqPLyrNSS0+xCjNwaIk zpsd+S9MSCA9sSQ1OzW1ILUIJsvEwSnVwOj3MlKGe07didjfhwLCF/y0E5W/fnTPJo3N7W/f F4p9Vj5os22N0AyRZbb/Plm8uHgz7N7WR2Fs/DXbwpZt3DxF/nyUduK225msGSdTsr5uqV+z fYVW+Pp9p2+ndpzqme+9ct6db09vvv02qerhcpOjGXvqX0RMPfDnaEZT0cy8f/NP3uBVvd3G r8RSnJFoqMVcVJwIAPpPbT66AgAA Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Tue, 05 Apr 2016 20:05:00 -0000 SSB0aGluayB0aGF0IHRoaXMgaGFzIGNoYW5nZWQsIGFuZCB3aWxsIGNoYW5nZSBldmVuIG1vcmUg dW50aWwgU1RJUiBpcw0KZGVwbG95ZWQuIEFjY29yZGluZyB0byBub3RhcnkuaWNzaS5iZXJrZWxl eS5lZHUvI3N0YXRpc3RpY3MgMjMgJSBvZiBhbGwNClRMUyBjb25uZWN0aW9ucyBhcmUgY3VycmVu dGx5IHNldHVwIHdpdGggRUNEU0EgY2VydGlmaWNhdGVzLiBPbmUgZXhhbXBsZQ0KaXMgaHR0cHM6 Ly9lbi53aWtpcGVkaWEub3JnLiBBbmQgd2UgZG9u4oCZdCBuZWVkIHVuYW5pbW91cyBzdXBwb3J0 IGZyb20gYWxsDQpDQXM7IGl0IGlzIGVub3VnaCB0aGF0IEVDRFNBIGNlcnRpZmljYXRlcyBhcmUg ZmFpcmx5IGVhc3kgdG8gZ2V0Lg0KDQooRWQyNTUxOSBjZXJ0aWZpY2F0ZXMgYXJlIHByb2JhYmx5 IGhhcmQgdG8gZ2V0IHVubGVzcyB5b3UgcnVuIHlvdXIgb3duIENBKS4NCg0KDQpKb2huDQoNCk9u IDA1LzA0LzE2IDE1OjA3LCAiUGV0ZXJzb24sIEpvbiIgPGpvbi5wZXRlcnNvbkBuZXVzdGFyLmJp ej4gd3JvdGU6DQoNCj5UbyBkYXRlIHdlIGhhdmUgbm90IG1vdmVkIHRoaXMgdG8gRUMgYmVjYXVz ZSAoYXQgbGVhc3QgYXMgZmFyIGFzIEkNCj51bmRlcnN0YW5kIHRoaW5ncykgbWFueSBlbGVtZW50 cyBvZiB3ZWIgUEtJLCBpbmNsdWRpbmcgbWFueSBDQXMsIGRvbid0DQo+c3VwcG9ydCB0aGVzZSBh bGdvcml0aG1zIHlldC4gSWYgb3VyIGFzc2Vzc21lbnQgb2YgdGhhdCBpcyBjaGFuZ2luZywgdGhl bg0KPmxldCdzIHJldmlzaXQgaXQuIA0KPg0KPkpvbiBQZXRlcnNvbg0KPk5ldXN0YXIsIEluYy4g DQo+DQo+U2VudCBmcm9tIG15IGlQYWQNCj4NCj4+IE9uIEFwciA1LCAyMDE2LCBhdCAxMTozNyBB TSwgSm9obiBNYXR0c3NvbiA8am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20+DQo+Pndyb3RlOg0K Pj4gDQo+PiBJIHRoaW5rIHRoZXJlIGFyZSBzZXZlcmFsIHN0cm9uZyByZWFzb25zIHRvIGNoYW5n ZSB0aGUgZGVmYXVsdCBzaWduYXR1cmUNCj4+IGFsZ29yaXRobSBpbiBkcmFmdC1pZXRmLXN0aXIt cmZjNDQ3NGJpcyBhbmQgZHJhZnQtaWV0Zi1zdGlyLXBhc3Nwb3J0Lg0KPj5UaGUNCj4+IGN1cnJl bnQgZGVmYXVsdCBhbGdvcml0aG0gaXMgUlMyNTYgKFJTQVNTQS1QS0NTMS12MV81IHVzaW5nIFNI QS0yNTYpLA0KPj5idXQNCj4+IEkgY2Fubm90IGZpbmQgYW55IG51bWJlciBmb3IgTVRJL1JlY29t bWVuZGVkL01pbmltdW0vRGVmYXVsdCBrZXkgbGVuZ3RoLg0KPj4gDQo+PiAxLiBSU0Egc2lnbmlu ZyBpcyBleHRyZW1lbHkgc2xvdyBjb21wYXJlZCB0byBtb2Rlcm4gYWx0ZXJuYXRpdmVzLiBPbiBh DQo+PiBDb3JlIGk1LTY2MDAsIEVTMjU2IChFQ0RTQSB1c2luZyBQLTI1NiBhbmQgU0hBLTI1Nikg aXMgMjEgdGltZXMgZmFzdGVyDQo+PiB0aGFuIFJTQS0yMDQ4LCBhbmQgRWQyNTUxOSBpcyA2NyB0 aW1lcyBmYXN0ZXINCj4+IChodHRwczovL2JlbmNoLmNyLnlwLnRvL3Jlc3VsdHMtc2lnbi5odG1s KS4gQXMgUlNBLTIwNDggaXMgbm9ybWFsbHkNCj4+IGNsYXNzaWZpZWQgYXMgcm91Z2hseSAxMTIt Yml0IHNlY3VyaXR5IChSRkMzNzY2LCBOSVNULCBFTklTQSksIGEgbW9yZQ0KPj5mYWlyDQo+PiBj b21wYXJpc29uIGlzIHdpdGggUlNBLTMwNzIsIGFuZCB0aGVuIEVTMjU2IGlzIDUyIHRpbWVzIGZh c3RlciBhbmQNCj4+RWQyNTUxOQ0KPj4gaXMgMTY5IHRpbWVzIGZhc3Rlci4NCj4+IA0KPj4gMi4g UlNBIHNpZ25hdHVyZXMgYXJlIG11Y2ggbGFyZ2VyIHRoYW4gdGhlaXIgRUNDIGNvdW50ZXJwYXJ0 cy4gUlNBLTIwNDgNCj4+IHNpZ25hdHVyZXMgYXJlIDI1NiBieXRlcyBhbmQgUlNBLTMwNzIgc2ln bmF0dXJlcyBhcmUgMzg0IGJ5dGVzLCB3aGlsZQ0KPj4gRVMyNTYgYW5kIEVkMjU1MTkgc2lnbmF0 dXJlcyBhcmUgb25seSA2NCBieXRlcy4NCj4+IA0KPj4gMy4gUEtDUzEtdjFfNSBpcyBub3QgYSB2 ZXJ5IGdvb2QgYWxnb3JpdGhtLiBJdCBoYXMgbm8gc2VjdXJpdHkgcHJvb2ZzLA0KPj5ubw0KPj4g YWR2YW50YWdlcywgaXMgZGlzcmVjb21tZW5kZWQgYnkgRU5JU0EgKEV1cm9wZWFuIFVuaW9uIEFn ZW5jeSBmb3INCj4+TmV0d29yaw0KPj4gYW5kIEluZm9ybWF0aW9uIFNlY3VyaXR5KSwgYW5kIGhh cyBiZWVuIHJlcGxhY2VkIGluIFRMUyAxLjMuIEkgZG8gbm90DQo+PiB0aGluayB0aGlzIGlzIHRo ZSBhbGdvcml0aG0gd2Ugc2hvdWxkIHVzZSBpbiBTVElSLg0KPj4gDQo+PiBJIHRoaW5rIHRoZSBy aWdodCBhbGdvcml0aG0gY2hvaWNlIGZvciBTVElSIGlzIEVTMjU2IG9yIEVkMjU1MTkuDQo+PiBT aWduYXR1cmUgcHJvY2Vzc2luZyBpcyBsaWtlbHkgdGhlIG1haW4gYnVyZGVuIGZvciB0aGUgQXV0 aGVudGljYXRpb24NCj4+IFNlcnZpY2UsIGFuZCBjaGFuZ2luZyBmcm9tIFJTQSB0byBFQ0Mgc2ln bmlmaWNhbnRseSByZWR1Y2VzIHRoZSBhbW91bnQNCj4+b2YNCj4+IGhhcmR3YXJlIG5lZWRlZCwg YW5kIHRoZXJlZm9yZSB0aGUgY29zdC4gQSBzaW5nbGUgMy4zIEdoeiBTa3lsYWtlIGNvcmUNCj4+ Y2FuDQo+PiBkbyBvbmx5IDQwMCBSU0EtMzA3MiBvciAxLDAwMCBSU0EtMjA0OCBzaWduYXR1cmVz IHBlciBzZWNvbmQsIGJ1dCAyMSwwMDANCj4+IEVTMjU2IG9yIDY4LDAwMCBFZDI1NTE5IHNpZ25h dHVyZXMgcGVyIHNlY29uZC4gUlNBIHZlcmlmaWNhdGlvbiBpcyBhIGJpdA0KPj4gZmFzdGVyIHRo YW4gRUNDLCBidXQgdGhlIGRpZmZlcmVudCBpcyBtdWNoIHNtYWxsZXIgdGhhdCBmb3Igc2lnbmlu ZywNCj4+IFJTQS0zMDcyIHZlcmlmaWNhdGlvbnMgYXJlIGUuZy4gdHdpY2UgYXMgZmFzdCBhcyBF ZDI1NTE5IHZlcmlmaWNhdGlvbnMuDQo+PiANCj4+IENoZWVycywNCj4+IEpvaG4NCj4+IA0KPj4g DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4+IEpPSE4gTUFUVFNTT04NCj4+IE1TYyBFbmdpbmVlcmluZyBQaHlz aWNzLCBNU2MgQnVzaW5lc3MgQWRtaW5pc3RyYXRpb24gYW5kIEVjb25vbWljcw0KPj4gRXJpY3Nz b24gSUVURiBTZWN1cml0eSBDb29yZGluYXRvcg0KPj4gU2VuaW9yIFJlc2VhcmNoZXIsIFNlY3Vy aXR5DQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBzdGlyIG1haWxpbmcgbGlzdA0KPj4gc3RpckBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQoNCg== From nobody Tue Apr 5 13:46:41 2016 Return-Path: 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 F08E812D9EC for ; Tue, 5 Apr 2016 13:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 Svslyycmbbvb for ; Tue, 5 Apr 2016 13:46:37 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 0B15912D9E8 for ; Tue, 5 Apr 2016 13:46:37 -0700 (PDT) Received: (qmail 5942 invoked by uid 0); 5 Apr 2016 20:46:32 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy1.mail.unifiedlayer.com with SMTP; 5 Apr 2016 20:46:32 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id ekmS1s01L1MNPNq01kmVMo; Tue, 05 Apr 2016 14:46:32 -0600 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=8WrITzYgnNwA:10 a=p-_XEfp0GhYA:10 a=kziv93cY1bsA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8 a=8pif782wAAAA:8 a=hGBaWAWWAAAA:8 a=MVff1mliAAAA:8 a=nbRfDxon0Duzle702M8A:9 a=nRw0jt1MwxszphxT:21 a=FIAh7FYQHjqmeUYG:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=6-C5ikvthBEA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:CC:To:From:Subject:Date; bh=EuqtzIXyToJXau5IKqE0KWYVpeQaC7bWC6U4oxonjw4=; b=S4EygWDxjh+yt9GJ6NFzk8nGo3 yABEeWPiQaT/RRcNya85hrk4frnu0/udNwfwu2wsseL0Vw4zTZpVH9oUi87Q38Mnzm8mEeDFIHmob AYe6uVeKPPzKBOvf4kwEZ84eV; Received: from [100.36.35.60] (port=62953 helo=[192.168.1.9]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1anXrm-0002hs-O5; Tue, 05 Apr 2016 14:46:26 -0600 User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Tue, 05 Apr 2016 16:46:19 -0400 From: Richard Shockey To: John Mattsson , "Peterson, Jon" Message-ID: Thread-Topic: [stir] Choice of STIR signature algorithm References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.35.60 authed with richard+shockey.us} Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Tue, 05 Apr 2016 20:46:40 -0000 And on a nation state basis my assumption would be that something like ECC2= 56 would be a requirement for the computational load factor if nothing else. Its certainly how I would write a STIR RFP for a CA if this were for the ca= rriers in the NANP. Setting one or two SHOULD supports seem sensible. I woul= d not set the requirement to MUST.=20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 On 4/5/16, 4:04 PM, "stir on behalf of John Mattsson" wrote: >I think that this has changed, and will change even more until STIR is >deployed. According to notary.icsi.berkeley.edu/#statistics 23 % of all >TLS connections are currently setup with ECDSA certificates. One example >is https://en.wikipedia.org. And we don=E2=80=99t need unanimous support from al= l >CAs; it is enough that ECDSA certificates are fairly easy to get. > >(Ed25519 certificates are probably hard to get unless you run your own CA)= . > > >John > >On 05/04/16 15:07, "Peterson, Jon" wrote: > >>To date we have not moved this to EC because (at least as far as I >>understand things) many elements of web PKI, including many CAs, don't >>support these algorithms yet. If our assessment of that is changing, then >>let's revisit it.=20 >> >>Jon Peterson >>Neustar, Inc.=20 >> >>Sent from my iPad >> >>> On Apr 5, 2016, at 11:37 AM, John Mattsson >>>wrote: >>>=20 >>> I think there are several strong reasons to change the default signatur= e >>> algorithm in draft-ietf-stir-rfc4474bis and draft-ietf-stir-passport. >>>The >>> current default algorithm is RS256 (RSASSA-PKCS1-v1_5 using SHA-256), >>>but >>> I cannot find any number for MTI/Recommended/Minimum/Default key length= . >>>=20 >>> 1. RSA signing is extremely slow compared to modern alternatives. On a >>> Core i5-6600, ES256 (ECDSA using P-256 and SHA-256) is 21 times faster >>> than RSA-2048, and Ed25519 is 67 times faster >>> (https://bench.cr.yp.to/results-sign.html). As RSA-2048 is normally >>> classified as roughly 112-bit security (RFC3766, NIST, ENISA), a more >>>fair >>> comparison is with RSA-3072, and then ES256 is 52 times faster and >>>Ed25519 >>> is 169 times faster. >>>=20 >>> 2. RSA signatures are much larger than their ECC counterparts. RSA-2048 >>> signatures are 256 bytes and RSA-3072 signatures are 384 bytes, while >>> ES256 and Ed25519 signatures are only 64 bytes. >>>=20 >>> 3. PKCS1-v1_5 is not a very good algorithm. It has no security proofs, >>>no >>> advantages, is disrecommended by ENISA (European Union Agency for >>>Network >>> and Information Security), and has been replaced in TLS 1.3. I do not >>> think this is the algorithm we should use in STIR. >>>=20 >>> I think the right algorithm choice for STIR is ES256 or Ed25519. >>> Signature processing is likely the main burden for the Authentication >>> Service, and changing from RSA to ECC significantly reduces the amount >>>of >>> hardware needed, and therefore the cost. A single 3.3 Ghz Skylake core >>>can >>> do only 400 RSA-3072 or 1,000 RSA-2048 signatures per second, but 21,00= 0 >>> ES256 or 68,000 Ed25519 signatures per second. RSA verification is a bi= t >>> faster than ECC, but the different is much smaller that for signing, >>> RSA-3072 verifications are e.g. twice as fast as Ed25519 verifications. >>>=20 >>> Cheers, >>> John >>>=20 >>>=20 >>> ------------------------------------------------------------------ >>> JOHN MATTSSON >>> MSc Engineering Physics, MSc Business Administration and Economics >>> Ericsson IETF Security Coordinator >>> Senior Researcher, Security >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Tue Apr 5 14:31:45 2016 Return-Path: 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 8FF9F12D0A2 for ; Tue, 5 Apr 2016 14:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 9Oxccr5ub9dy for ; Tue, 5 Apr 2016 14:31:43 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26BD812DA31 for ; Tue, 5 Apr 2016 14:24:33 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id c6so21477890qga.1 for ; Tue, 05 Apr 2016 14:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=YyT0Qm72Q3ERMiPHpYmhR2Uj2XPM/I76JQ2cQ6C7irI=; b=Zj38elRizu1nppao9JpwZ/oUg5bCXnH9V0H1PsQ1uaj7DntOqm2chyQeDq/VJo4rgq LmsWFEHlHqPiWl24od43MXjAtPwGdHtDeZPihtX0KVLnxkp0fkIIY0OoZOdhM81t7vs1 O2F6JYRjFd5Y5ngLlTwN2O5d+xOQ+TFvR0HHI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=YyT0Qm72Q3ERMiPHpYmhR2Uj2XPM/I76JQ2cQ6C7irI=; b=hj4qfFlNT3gC9hoNXhuWL+XkGmJZnOkVZYUO1O0S2rs2VFIpMKZqLEBkDuHKm2sZlV radMuHt7ikP6oCO8Ha2YDvbZUJAFen7FJ3T02wWLF+tHu/v1JmqZUFrTQhDc1FlE0jsa Qu/7A4g5xW/wNsGM/I3aSuyqYK8Z/KeLDcppCwXTkdvXiRuKGI2Ni3dN1XmEmUMvJbsg 5ksH9VIWhaqnURy755bV2zW9XTlFS/4aLBK692ElQEpdX9pFII7yJc8PjB/mYt3PyScH YpX9HZNBYQSxPn8O0xgaRFG4RkdI8hAq5bI/lBCVmzN5wd1CG/6DSDXJcgRtuWyVlNB7 EzJg== X-Gm-Message-State: AD7BkJKi+1oju2XQvaJvPrUEwagRHtwXj8iqDHFmKi0Kk0UcizIj7I9QiNZuDabop+Py5g== X-Received: by 10.140.181.137 with SMTP id c131mr23610929qha.94.1459891462792; Tue, 05 Apr 2016 14:24:22 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:3cda:b3c1:48ea:6fbb? ([2001:67c:370:176:3cda:b3c1:48ea:6fbb]) by smtp.gmail.com with ESMTPSA id p101sm14762995qge.13.2016.04.05.14.24.21 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Apr 2016 14:24:22 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <05DD1ACB-C395-4333-A36C-56443A954199@sn3rd.com> Date: Tue, 5 Apr 2016 18:24:19 -0300 To: stir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [stir] registering application/passport X-BeenThere: stir@ietf.org 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: Tue, 05 Apr 2016 21:31:44 -0000 Chris, Turns out we can submit a request via this handy submission tool: https://www.iana.org/form/media-types You can request a provisional one for testing that will then get the = final one when the draft becomes and RFC. spt= From nobody Tue Apr 5 14:55:51 2016 Return-Path: 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 EBDE612D1F0 for ; Tue, 5 Apr 2016 14:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 ClGApNjYyUx4 for ; Tue, 5 Apr 2016 14:55:47 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8CF12D0CC for ; Tue, 5 Apr 2016 14:55:47 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 6AA7EF24064 for ; Tue, 5 Apr 2016 17:55:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id wmkfUFWjz17G for ; Tue, 5 Apr 2016 17:41:16 -0400 (EDT) Received: from dhcp-b4d9.meeting.ietf.org (dhcp-b4d9.meeting.ietf.org [31.133.180.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 10CD1F24035 for ; Tue, 5 Apr 2016 17:55:45 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Tue, 5 Apr 2016 17:55:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Tue, 05 Apr 2016 21:55:50 -0000 There was just a discussion of this point in the STIR session at IETF = 95. The sense of the room is to require verification of both RSA and = ECC signatures. This allows the use of existing infrastructure, and = allows rapid movement to ECC as soon as that infrastructure is readily = available Russ On Apr 5, 2016, at 4:46 PM, Richard Shockey wrote: >=20 > And on a nation state basis my assumption would be that something like = ECC256 would be a requirement for the computational load factor if = nothing else. >=20 > Its certainly how I would write a STIR RFP for a CA if this were for = the carriers in the NANP. Setting one or two SHOULD supports seem = sensible. I would not set the requirement to MUST.=20 >=20 > =97=20 > Richard Shockey > Shockey Consulting LLC > Chairman of the Board SIP Forum > www.shockey.us > www.sipforum.org > richardshockey.us > Skype-Linkedin-Facebook rshockey101 > PSTN +1 703-593-2683 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 4/5/16, 4:04 PM, "stir on behalf of John Mattsson" = wrote: >=20 >> I think that this has changed, and will change even more until STIR = is >> deployed. According to notary.icsi.berkeley.edu/#statistics 23 % of = all >> TLS connections are currently setup with ECDSA certificates. One = example >> is https://en.wikipedia.org. And we don=92t need unanimous support = from all >> CAs; it is enough that ECDSA certificates are fairly easy to get. >>=20 >> (Ed25519 certificates are probably hard to get unless you run your = own CA). >>=20 >>=20 >> John >>=20 >> On 05/04/16 15:07, "Peterson, Jon" wrote: >>=20 >>> To date we have not moved this to EC because (at least as far as I >>> understand things) many elements of web PKI, including many CAs, = don't >>> support these algorithms yet. If our assessment of that is changing, = then >>> let's revisit it.=20 >>>=20 >>> Jon Peterson >>> Neustar, Inc.=20 >>>=20 >>> Sent from my iPad >>>=20 >>>> On Apr 5, 2016, at 11:37 AM, John Mattsson = >>>> wrote: >>>>=20 >>>> I think there are several strong reasons to change the default = signature >>>> algorithm in draft-ietf-stir-rfc4474bis and = draft-ietf-stir-passport. >>>> The >>>> current default algorithm is RS256 (RSASSA-PKCS1-v1_5 using = SHA-256), >>>> but >>>> I cannot find any number for MTI/Recommended/Minimum/Default key = length. >>>>=20 >>>> 1. RSA signing is extremely slow compared to modern alternatives. = On a >>>> Core i5-6600, ES256 (ECDSA using P-256 and SHA-256) is 21 times = faster >>>> than RSA-2048, and Ed25519 is 67 times faster >>>> (https://bench.cr.yp.to/results-sign.html). As RSA-2048 is normally >>>> classified as roughly 112-bit security (RFC3766, NIST, ENISA), a = more >>>> fair >>>> comparison is with RSA-3072, and then ES256 is 52 times faster and >>>> Ed25519 >>>> is 169 times faster. >>>>=20 >>>> 2. RSA signatures are much larger than their ECC counterparts. = RSA-2048 >>>> signatures are 256 bytes and RSA-3072 signatures are 384 bytes, = while >>>> ES256 and Ed25519 signatures are only 64 bytes. >>>>=20 >>>> 3. PKCS1-v1_5 is not a very good algorithm. It has no security = proofs, >>>> no >>>> advantages, is disrecommended by ENISA (European Union Agency for >>>> Network >>>> and Information Security), and has been replaced in TLS 1.3. I do = not >>>> think this is the algorithm we should use in STIR. >>>>=20 >>>> I think the right algorithm choice for STIR is ES256 or Ed25519. >>>> Signature processing is likely the main burden for the = Authentication >>>> Service, and changing from RSA to ECC significantly reduces the = amount >>>> of >>>> hardware needed, and therefore the cost. A single 3.3 Ghz Skylake = core >>>> can >>>> do only 400 RSA-3072 or 1,000 RSA-2048 signatures per second, but = 21,000 >>>> ES256 or 68,000 Ed25519 signatures per second. RSA verification is = a bit >>>> faster than ECC, but the different is much smaller that for = signing, >>>> RSA-3072 verifications are e.g. twice as fast as Ed25519 = verifications. >>>>=20 >>>> Cheers, >>>> John >>>>=20 >>>>=20 >>>> ------------------------------------------------------------------ >>>> JOHN MATTSSON >>>> MSc Engineering Physics, MSc Business Administration and Economics >>>> Ericsson IETF Security Coordinator >>>> Senior Researcher, Security >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Tue Apr 5 14:57:30 2016 Return-Path: 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 96AD512D527 for ; Tue, 5 Apr 2016 14:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.388 X-Spam-Level: X-Spam-Status: No, score=0.388 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, 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 kuVLf556hFQ0 for ; Tue, 5 Apr 2016 14:57:27 -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 7195212D4FF for ; Tue, 5 Apr 2016 14:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Mime-Version:To:Message-Id:Date:Subject: Content-Type:From; bh=w27kpel4NVBsd4Yci3whWPG+3OJiYvwZmNU0stfwwxM=; b=l+iSKiw 4XgRUNRzcKdADB1Yb86EYSQgIPl9v2xZFVJ2k05GUY56xFae1OlePvOSEl15rwgBuzHTfMUOORx9l 4v8HSfn8Se0ghURzG+QYZlyXN3Wvoh/nSmO6gqEnJBnzMd4bGeYyY5nbwzfYyB3JHjulMWUMVbjQT vnfW9wgSG8=; Received: from dhcp-9a7b.meeting.ietf.org ([31.133.154.123]:60524) by biz104.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1anYyU-0008MP-8N for stir@ietf.org; Tue, 05 Apr 2016 14:57:27 -0700 From: Eric Burger X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_6E81C74A-21D6-4B71-888D-389C6ED59F28"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Tue, 5 Apr 2016 18:57:23 -0300 Message-Id: To: stir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 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 Archived-At: Subject: [stir] Am I missing something? X-BeenThere: stir@ietf.org 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: Tue, 05 Apr 2016 21:57:28 -0000 --Apple-Mail=_6E81C74A-21D6-4B71-888D-389C6ED59F28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A quick Google search on CA=E2=80=99s issuing ECC certs include: DigiCert Entrust GlobalSign Symantec Certicom That is a much longer list than =E2=80=9CYou cannot get it today.=E2=80=9D= What am I missing? --Apple-Mail=_6E81C74A-21D6-4B71-888D-389C6ED59F28 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXBDTDAAoJEORoZaSQsc1INQUP/itOyO6oTvH7PCZBvIDVWphK sUhTHZdM6ipyj8VNw94iNAPExqyuJk8Qg9mCqcy2U7IyaydHAJqvoxPfn8YlaIyz aqdfhs9r6WahQGBoC2Prli1M7Fn57U40VzH9l8tW2hXhgrsaaE7lyBAIajYVU9dh AJ+DGZP0JQrRQ8PVhNB7ff1AdF1Qgupo0KKLo+v3UxRQRkaYuXogwm09+MqQBxEF +VeuYPhFWGO5vtdBV0YVv7UR4fuA75ODswKfvUrs6Kc7hUXKB3N5z1KK5/baiosE eiiU1qidvQZcfOoCrZg0Rai3XY2PVQwkcfd03IMlKY6inkZek40UzfPs7dFkEP/T Jbe0b/Bh4wWfTplXVUSaYoTkTt4xJb1omfbjg4DkCj0l9tjgso5Wi2Cyfr57SaoX ENjry5IlXJ+y2k5fh6/JM03bg3SRdn8+CK7pqZfFIL6BesNTmOcPB89k7aDuqmoF xm/XxOmohAF5JWxGm00XAIkCPP8cIPbprR+X/aehdg0CULDBtOpiwV9bytBoLDsS kBRtumBaqMoBDsvtF8DUbGU9uELedtT7+ywKCODb0m9VCMveFoQpPHTYzuBAWz9M C3xlNoR29F4E/MO873NiPCcydvNOyhDJiQN/7m81kJhf4NRPbd2vLlYXcZtSO+4A dixQ2PDadZtiF3T0pvHf =c1rt -----END PGP SIGNATURE----- --Apple-Mail=_6E81C74A-21D6-4B71-888D-389C6ED59F28-- From nobody Tue Apr 5 15:48:32 2016 Return-Path: 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 55D4912D14D for ; Tue, 5 Apr 2016 15:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 kPrgYLGZkQF3 for ; Tue, 5 Apr 2016 15:48:17 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 6600D12D0CC for ; Tue, 5 Apr 2016 15:48:17 -0700 (PDT) Received: (qmail 28916 invoked by uid 0); 5 Apr 2016 22:48:16 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy10.mail.unifiedlayer.com with SMTP; 5 Apr 2016 22:48:16 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id emo11s0191MNPNq01mo4TF; Tue, 05 Apr 2016 16:48:14 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=8WrITzYgnNwA:10 a=p-_XEfp0GhYA:10 a=kziv93cY1bsA:10 a=48vgC7mUAAAA:8 a=tGX7uwomAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=0FD05c-RAAAA:8 a=8pif782wAAAA:8 a=hGBaWAWWAAAA:8 a=MVff1mliAAAA:8 a=MMvpRA9cQ3ez7-iWS9kA:9 a=KYd9lLM_syZlyZZl:21 a=b3no-JDRn6y5YPAs:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=6-C5ikvthBEA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date; bh=EdfeOSFCWh6SaRNMyt6BhO05GK44JQIfx6k8Urn+Jm8=; b=OjcRDcA8+PGplS9zVNKRMeokn9 V5MU1FnOsFwahn/8OGbRH9GGcGidgXwDzcXQoDfdlsAIPAbZNwnp46OaNUcJ3hPnYSTjFGeV/RSN5 Ns9YnKHMCx43FtZSS8NY52W60; Received: from [100.36.35.60] (port=65073 helo=[192.168.1.9]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1anZlT-0007hk-Ia; Tue, 05 Apr 2016 16:48:03 -0600 User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Tue, 05 Apr 2016 18:47:56 -0400 From: Richard Shockey To: Russ Housley , IETF STIR Mail List Message-ID: <0DD82221-E79D-4F15-B2B5-93165EC98919@shockey.us> Thread-Topic: [stir] Choice of STIR signature algorithm References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.35.60 authed with richard+shockey.us} Archived-At: Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Tue, 05 Apr 2016 22:48:24 -0000 Well I would have to insist that such a statement is SHOULD verify, either = or both, how it deploys and under what conditions are still probably a natio= n-state matter certainly if they are used with E.164 plan. On 4/5/16, 5:55 PM, "stir on behalf of Russ Housley" wrote: >There was just a discussion of this point in the STIR session at IETF 95. = The sense of the room is to require verification of both RSA and ECC signat= ures. This allows the use of existing infrastructure, and allows rapid move= ment to ECC as soon as that infrastructure is readily available > >Russ > > >On Apr 5, 2016, at 4:46 PM, Richard Shockey wrote: > >>=20 >> And on a nation state basis my assumption would be that something like E= CC256 would be a requirement for the computational load factor if nothing el= se. >>=20 >> Its certainly how I would write a STIR RFP for a CA if this were for the= carriers in the NANP. Setting one or two SHOULD supports seem sensible. I w= ould not set the requirement to MUST.=20 >>=20 >> =E2=80=94=20 >> Richard Shockey >> Shockey Consulting LLC >> Chairman of the Board SIP Forum >> www.shockey.us >> www.sipforum.org >> richardshockey.us >> Skype-Linkedin-Facebook rshockey101 >> PSTN +1 703-593-2683 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 4/5/16, 4:04 PM, "stir on behalf of John Mattsson" wrote: >>=20 >>> I think that this has changed, and will change even more until STIR is >>> deployed. According to notary.icsi.berkeley.edu/#statistics 23 % of all >>> TLS connections are currently setup with ECDSA certificates. One exampl= e >>> is https://en.wikipedia.org. And we don=E2=80=99t need unanimous support from= all >>> CAs; it is enough that ECDSA certificates are fairly easy to get. >>>=20 >>> (Ed25519 certificates are probably hard to get unless you run your own = CA). >>>=20 >>>=20 >>> John >>>=20 >>> On 05/04/16 15:07, "Peterson, Jon" wrote: >>>=20 >>>> To date we have not moved this to EC because (at least as far as I >>>> understand things) many elements of web PKI, including many CAs, don't >>>> support these algorithms yet. If our assessment of that is changing, t= hen >>>> let's revisit it.=20 >>>>=20 >>>> Jon Peterson >>>> Neustar, Inc.=20 >>>>=20 >>>> Sent from my iPad >>>>=20 >>>>> On Apr 5, 2016, at 11:37 AM, John Mattsson >>>>> wrote: >>>>>=20 >>>>> I think there are several strong reasons to change the default signat= ure >>>>> algorithm in draft-ietf-stir-rfc4474bis and draft-ietf-stir-passport. >>>>> The >>>>> current default algorithm is RS256 (RSASSA-PKCS1-v1_5 using SHA-256), >>>>> but >>>>> I cannot find any number for MTI/Recommended/Minimum/Default key leng= th. >>>>>=20 >>>>> 1. RSA signing is extremely slow compared to modern alternatives. On = a >>>>> Core i5-6600, ES256 (ECDSA using P-256 and SHA-256) is 21 times faste= r >>>>> than RSA-2048, and Ed25519 is 67 times faster >>>>> (https://bench.cr.yp.to/results-sign.html). As RSA-2048 is normally >>>>> classified as roughly 112-bit security (RFC3766, NIST, ENISA), a more >>>>> fair >>>>> comparison is with RSA-3072, and then ES256 is 52 times faster and >>>>> Ed25519 >>>>> is 169 times faster. >>>>>=20 >>>>> 2. RSA signatures are much larger than their ECC counterparts. RSA-20= 48 >>>>> signatures are 256 bytes and RSA-3072 signatures are 384 bytes, while >>>>> ES256 and Ed25519 signatures are only 64 bytes. >>>>>=20 >>>>> 3. PKCS1-v1_5 is not a very good algorithm. It has no security proofs= , >>>>> no >>>>> advantages, is disrecommended by ENISA (European Union Agency for >>>>> Network >>>>> and Information Security), and has been replaced in TLS 1.3. I do not >>>>> think this is the algorithm we should use in STIR. >>>>>=20 >>>>> I think the right algorithm choice for STIR is ES256 or Ed25519. >>>>> Signature processing is likely the main burden for the Authentication >>>>> Service, and changing from RSA to ECC significantly reduces the amoun= t >>>>> of >>>>> hardware needed, and therefore the cost. A single 3.3 Ghz Skylake cor= e >>>>> can >>>>> do only 400 RSA-3072 or 1,000 RSA-2048 signatures per second, but 21,= 000 >>>>> ES256 or 68,000 Ed25519 signatures per second. RSA verification is a = bit >>>>> faster than ECC, but the different is much smaller that for signing, >>>>> RSA-3072 verifications are e.g. twice as fast as Ed25519 verification= s. >>>>>=20 >>>>> Cheers, >>>>> John >>>>>=20 >>>>>=20 >>>>> ------------------------------------------------------------------ >>>>> JOHN MATTSSON >>>>> MSc Engineering Physics, MSc Business Administration and Economics >>>>> Ericsson IETF Security Coordinator >>>>> Senior Researcher, Security >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Wed Apr 6 06:02:14 2016 Return-Path: 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 2844512D182 for ; Wed, 6 Apr 2016 06:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 C-w9Iq68nDlC for ; Wed, 6 Apr 2016 06:01:59 -0700 (PDT) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3873F12D0C5 for ; Wed, 6 Apr 2016 06:01:58 -0700 (PDT) Received: by mail-qk0-x244.google.com with SMTP id e124so2070481qkc.3 for ; Wed, 06 Apr 2016 06:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M3ugJvmrtRoX9BLeIMPZ8pGHniAa9GqjvEAM6E1NvFk=; b=vdyrqBNWDP1rYW/bV04B7TxEZ6qxwKWOAM07xEPM38LqzYS1LlwVChn4HxdaGBv2iN hbh7Wpdbt0QAq75kyBZYgLrvyPIsAQnuCqgtBzi1rR0Ox9qAzm8VcV/dO5sqF/hOuX7k jvTC9MCsfWGu5ipZipdTkU7rldaY1dkuLaCMzKP/V67knv0fUsJGQVMcCL/aVdXmHYb9 TMMVFNnZHrl+7OETexZb2+6SFluZJc4GEaNoywVwc5mkBHwu7pWeWG1HHJXhyCzxaW3e yq9XiFdqAwKOcJyeCHvbcPfECqij7xtasdYMw1F1M1HfOJTDRAjHR0svJjnZQ4/6NTen 3IlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M3ugJvmrtRoX9BLeIMPZ8pGHniAa9GqjvEAM6E1NvFk=; b=iYp8hDNGlzQqhgwxcx70GvJHTySEP7ORnXksYKvI5dWi9pVsjPIdPy9kO5zf23j6qy Zl4GNvQbxcWLeD+mHNufnW+BO7dHpub2rWKe4PQVTBlx0FqpKaCo6sBwaCWyZrG/tp/h lwFQXwyRGVeV5N+e5DtLaaZujZ1ze96CbOQoSQGtvQ7Bjn7swOfTjecbcWgqVJxEj1LM 3spAp+J16qTWRm13q4OCNk6Fqwe19k4Pd2VK9GI28PhNBUCrR7lL0EuJPx0e2Vvl0CAA +9yDiR/MYEqauH2DWxWwJ0s6QI3yNyDggsYQeMKuL+A2B9JuJmuumO3L9eIVRj5Dx0c/ XPLw== X-Gm-Message-State: AD7BkJKAqKC4CP39fcYooDV/71XudwCoHUVl4v1lof8DzIKYhhiHRI5k12WrtQr94kqxvA== X-Received: by 10.55.74.75 with SMTP id x72mr47020416qka.100.1459947717157; Wed, 06 Apr 2016 06:01:57 -0700 (PDT) Received: from [172.20.10.33] (200-127-148-163.net.prima.net.ar. [200.127.148.163]) by smtp.gmail.com with ESMTPSA id c66sm1203214qha.27.2016.04.06.06.01.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Apr 2016 06:01:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chris Wendt In-Reply-To: <05DD1ACB-C395-4333-A36C-56443A954199@sn3rd.com> Date: Wed, 6 Apr 2016 10:01:52 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3A1ACE55-2F47-4644-99B8-3B0208221F8D@chriswendt.net> References: <05DD1ACB-C395-4333-A36C-56443A954199@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3124) Archived-At: Cc: stir@ietf.org Subject: Re: [stir] registering application/passport X-BeenThere: stir@ietf.org 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: Wed, 06 Apr 2016 13:02:03 -0000 Done. Thanks Sean. > On Apr 5, 2016, at 6:24 PM, Sean Turner wrote: >=20 > Chris, >=20 > Turns out we can submit a request via this handy submission tool: >=20 > https://www.iana.org/form/media-types >=20 > You can request a provisional one for testing that will then get the = final one when the draft becomes and RFC. >=20 > spt > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Apr 6 07:56:23 2016 Return-Path: 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 4322F12D5DE for ; Wed, 6 Apr 2016 07:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 r9KmiL77dOuG for ; Wed, 6 Apr 2016 07:56:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D752812D57E for ; Wed, 6 Apr 2016 07:56:16 -0700 (PDT) Received: from dhcp-8915.meeting.ietf.org ([IPv6:2001:67c:370:136:748f:23e3:67bb:9a35]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u36EuDtJ042339 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 6 Apr 2016 09:56:15 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [IPv6:2001:67c:370:136:748f:23e3:67bb:9a35] claimed to be dhcp-8915.meeting.ietf.org To: stir@ietf.org From: "A. Jean Mahoney" Message-ID: <5705238B.4060408@nostrum.com> Date: Wed, 6 Apr 2016 11:56:11 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [stir] stir 95 meeting notes - raw X-BeenThere: stir@ietf.org 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: Wed, 06 Apr 2016 14:56:22 -0000 Below are my raw notes from the meeting. I marked places where I missed stuff with ellipses (...). Thanks, Jean ----------------------------------------------------------------------------------- STIR: IETF 95 Tuesday, Afternoon Session III 1740-1910 Quebracho B ----------------------------------------------------------------------------------- 5m Administrivia presenter: Robert Sparks slides: https://www.ietf.org/proceedings/95/slides/slides-95-stir-0.pdf Note takers: Brian Rosen and Jean Mahoney Jabber relay: Sean Turner Jabber log: http://www.ietf.org/jabber/logs/stir/2016-04-05.html Note well and agenda were presented. No changes to the agenda. ----------------------------------------------------------------------------------- 10m Overview of changes across the WG documents presenter: Sean Turner slides: https://www.ietf.org/proceedings/95/slides/slides-95-stir-1.pdf Brian Rosen asked if it was still true that anyone on path can do the verification. Sean said that it was still true. No actions. ----------------------------------------------------------------------------------- 30m draft-ietf-stir-rfc4474bis presenter: Jon Peterson slides: https://www.ietf.org/proceedings/95/slides/slides-95-stir-2.pdf slide 1: Title slide 2: Divide and Conquer slide 3: Changes since -06 slide 4: Date Fix Jonathan Lennox - You need to check for copy-n-paste attacks. Jon - It's there in the text. Jon (to the room) - we're cool? The Date fix is the biggest change. Room had no objections. slide 5: Extensibility Chris Wendt - The worst case would be 2 identity headers with two tokens. It would nice to combine those. Jon - Either we build it into ppt or create a MIME type. We can do either. There's no good reason to do one or the other. Now we're doing nothing. If PASSporT decides to make the MIME type a component of ppt, then we don't need to change. Eric Burger - There might be different network elements that put them in. Having multiple headers may be desirable. Jon - It could. we'll talk about it when we talk about extending with CNAM. Chris - We want something that can combine them like CNAM. Jon - It would be nice not to have 15 of these things. slide 6: Opportunistic STIR Jon - This is of marginal benefit but still offers some benefit. This is not in the main path of deliverables. Alan Johnston - This is orthogonal to OSRTP. I don't have an opinion on this. Jon - The signature is only as good as the entity that signed over it. Can be added without knowledge or consent of the app, but not meddled with by a MITM. Alan - It can't be used in place of OSRTP. Jon - The draft in dispatch will just point to OSRTP. This doesn't replace it. It relies on it. Anyone have a problem with opportunistic STIR? Room had no objections. slide 7: Future work Jon - Please review carefully because of swapping in passport. Robert Sparks - You need to add a few words about backward compatibility into the next draft. Robert - I see some implementers in room, will you sign up to review? Martin Dolly, Eric Burger, John Mattsson volunteered Robert - Is anyone going to SIPit? Eric Burger - We'll have something. ACTIONs: Authors to add text on backward compatibility. Martin Dolly, Eric Burger, John Mattsson to review draft-ietf-stir-rfc4474bis. ----------------------------------------------------------------------------------- 30m draft-ietf-stir-passport presenter: Chris Wendt slides: https://www.ietf.org/proceedings/95/slides/slides-95-stir-3.pdf slide 1: Title slide 2: Overview slide 3: PASSporT Header Sean - Have you already registered the MIME Type? It's really easy. Just send me email and I can help with that. slide 4: PASSporT Payload slide 5: PASSporT Payload slide 6: PASSporT Payload - Identity Types Jon - What about Dr. Hardie's comment that they need to be strictly typed and extensible? We're not excluding WEBRTC. Richard Barnes - What about Tel URIs? Jon - We using otn and dtn. We won't do tel URIs because we want it to be canonicalized. Chris - Should we forbid tel URIs? A passport can have tel URIs, but it wouldn't be for 4474bis. Brian Rosen - a ... is a pretty straight forward thing to canonicalize. Jon - I'd rather see a phone number in otn and dtn and explain what we mean. I would prefer not to see a tel URI. Chris - You don't have an option for telephone numbers. Must use otn and dtn. Jon - Let me look at it. slide 7: PASSporT Payload - Media Key Jon - If it's a telephone number, then use otn and dtn. 4474bis allows ouri and dturi. Christer Holmberg - There are multiple fingerprints. Chris - It's covered in the text. Jon - They're alphabetized and concatenated. This is a misalignment between passport and 4474bis now. When we'll get to serializing, I'll get to it. slide 8: Multi-Party Communications Richard - When doing .... you may be tempted to do a string and then array, don't. Chris - There's nothing to prevent it. That can happen in passport and 4474bis. slide 9: Extension to PASSporT base claims slide 10: Extending base claims slide 11: Extending base claims slide 12: Defining new set of claims slide 13: Registering PASSporT extensions Chris - Any opinions on registering extensions? Jon - We want to make sure we understand what we're asking people to do. People need sufficient guidance when extending passport. What are pitfalls? We need to get that language correct. slide 14: Deterministic JSON serialization Jon - We can replace the whitespace with a dot or something. Chris - Or we can just remove it. Jon - With non-SIP protocols this may be the only place the info is. If we want people to be able to look at it. It's not terribly confusing. If there was a new session negotiation protocol, and it chose to use passport, what would be the form to use? Our responsibility is to be more semantically clear. One part gives the algo for the keying. Multiple algos listed. The other part, separate. Chris - a JSON array. Jon - If it's a one-way hash, it can be crunched together. Robert - For debugging, I can't think of many cases of visual ambiguity, but SHA25 and the first characters are 25 is one. Chris - ... Jon - If we're passing the entire object outside of SIP, then base 64 could be appropriate. In SIP, it should be as human readable as possible. Not base 64. I think this is an open issue. We can take a couple of cracks at it. We can explore alternate key mechanisms. New keys for JWS. It may be sufficient for STIR. We need to get this done. We may revise this with an array going forward. Chris - We should have guidelines for future claims. But we don't have text yet. Other than "no whitespace". Jon - JWS gives guidance. Need to think of semantics. I would prefer to see separable characters. Keep the semicolon. Good enough. Anyone here upset? Richard - Don't worry about whitespace in the the JSON string, you'll have other problems. Eric - We can deal with the space. Chris - I'm ok with the period. Jon - Have a separator. Richard - I see no reason why a decoder would want to enforce that. Russ - It's so that it can hash the same string. Go away. Chris - Space or period? Eric - period or vertical bar? Brian - vertical bar looks too much like an I. Richard - Use template filling. Write the template in the draft. ... Jon sends Richard to the corner. Chris - We'll use a period. Jon - We need to provide an example. Last meeting, someone was on the hook on this. We need to show whole shebang. Robert - I was supposed to find someone to do the example. Cullen was to help me. I would like to borrow from the passport document. Show multiple fingerprints in an example. Chris - I have a tn and uri in that example. Sean - I want to see an elliptic curve example. slide 15: Examples slide 16: passport-02 Jon - I'd like to talk about ECC. There is an email saying we should move away from RS256. JWT uses this, which is why we are using it. John Mattsson - ... both are required. Jon - This is a certs issue as much as a passport issue. Can I get this from web CAs today? No. We can be forward-looking in our implementation. Will use existing web PKI from web CAs. There are people who want to use commercial web CAs. If we assume that we will build all new CAs for this, I've been told that will take too long. Telling regulators that we'll wait for implementers is unacceptable. If we can turn on this year. Chris - EC256 has CPU benefits. Richard - ECC is technically better. Chris - can we say both with a preference? Richard - ECC are generally available in the modern CA market. If you use Web PKI, you have to commit to move as fast they move. Getting behind means that the devices cannot work. It's worth having a system that has its own CAs. Chris - For future proofing, should we recommend higher keys as well? 384, 512? Richard - I don't think I understand. You don't want to specify a single elliptic curve. You can say 256 is mandatory to implement and 384 is optional. Ensuring that your software is upgradable is an implementation issue. John Mattsson - DHA (? ECDSA?) should be required and RSA is optional. Chris - CPU Sean - We need to get this out in 9 months. Would have to stick with RSA. You can get elliptic curves. Verify both - be liberal in what you receive. Chris - I like that conclusion. Jon - Small keys are great. I listen to Russ, Sean, and ekr. I don't know about when it's ready for runtime. Russ, please chime in. I don't have an opinion. Russ - Do you need one mandatory to implement. Or can you verify both? Jon - I'm cool with verifying both. Richard - Let's Encrypt will have free ECC certs available in the time frame. Eric - One and only one is the way to go. ECC certs will be available. Why should we make ourselves do more work? Russ - Very few EC certs are available today. Eric - Only one country will be doing this anytime soon, and in that market, it doesn't matter that it's a small handful. Jon - It will matter when you are dragged in front of the FCC. Saying that we can't do this today makes me nervous. People want it done today. Chris - Have it there and then move to ECC. Jon - This sounds like a road block. Robert, as chair - I'm not seeing pushback on verifiers having to implement more that one algo. Eric - It's only money. Robert - If you don't have a cert that uses the ECC, you won't exercise that code. Russ - My sense of the room is that we have verification of both RSA and ECC signatures so that we can have a smooth transition to ECC. Sean - .... why you didn't use the phone number. Add explicit text. Jon - JWS registration for claims doesn't require a lot of text, but we can provide text. Non-normative text about why we're aren't using the current JWT claim for telephone. Jon - Need to align on MIME type versus ppt. Chris - we can chat about it. A plus in between - can we settle on that? Jon - let's just do that. Get this done. Robert, as chair - There are just a few minutes left in the meeting. Should we break and pick it up next session? Martin Dolly - You need to make extensibility very clear in the examples. For instance, I'll be writing up extending passport for the Resource-Priority header. I'd like to write that doc in ADIS and do the registration in the IETF. Russ - We had planned to discuss this today, or we can discuss in the next session. Jon - We can do it now. ACTIONs: Authors to register the MIME type (Done). Have verification of both RSA and ECC signatures. ----------------------------------------------------------------------------------- 15m Passport extensibility presenter: Jon Peterson slides: https://www.ietf.org/proceedings/95/slides/slides-95-stir-4.pdf slide 1: Title slide 2: Twofold STIR extensibility model slide 3: Testing extensibility slide 4: The "cna" extension slide 5: Elaborating on "cna" Brian Rosen - in your example, you didn't sign the display name in the SIP headers, you created a new CNAM thing. Jon - the draft does, the slides don't. Brian - all I care about is taking a base type and adding a subtype to it. Jon - I think it does. If the new claim is not in the SIP message, you MUST include canon. Resource-Priority will not require canon. slide 6: Should we test MIME as well? slide 7: Sanity checking ACTIONs: None Russ - have a good evening. EOM From nobody Wed Apr 6 09:10:09 2016 Return-Path: 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 01F6212D57C for ; Wed, 6 Apr 2016 09:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 rpoWlOunOHRM for ; Wed, 6 Apr 2016 09:09:59 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 841EE12D577 for ; Wed, 6 Apr 2016 09:09:59 -0700 (PDT) Received: from dhcp-b103.meeting.ietf.org (dhcp-b103.meeting.ietf.org [31.133.177.3]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u36G9vij053934 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Wed, 6 Apr 2016 11:09:58 -0500 (CDT) (envelope-from rjsparks@nostrum.com) To: stir@ietf.org References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <0DD82221-E79D-4F15-B2B5-93165EC98919@shockey.us> From: Robert Sparks Message-ID: <570534D4.6010707@nostrum.com> Date: Wed, 6 Apr 2016 13:09:56 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <0DD82221-E79D-4F15-B2B5-93165EC98919@shockey.us> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Wed, 06 Apr 2016 16:10:07 -0000 To be clear, the suggestion is must implement, not must use. Specifically, for _this_ part of the conversation, its that the code in a verifier must be _able_ to verify presented with either. On 4/5/16 7:47 PM, Richard Shockey wrote: > Well I would have to insist that such a statement is SHOULD verify, either or both, how it deploys and under what conditions are still probably a nation-state matter certainly if they are used with E.164 plan. > > > On 4/5/16, 5:55 PM, "stir on behalf of Russ Housley" wrote: > >> There was just a discussion of this point in the STIR session at IETF 95. The sense of the room is to require verification of both RSA and ECC signatures. This allows the use of existing infrastructure, and allows rapid movement to ECC as soon as that infrastructure is readily available >> >> Russ >> >> >> On Apr 5, 2016, at 4:46 PM, Richard Shockey wrote: >> >>> And on a nation state basis my assumption would be that something like ECC256 would be a requirement for the computational load factor if nothing else. >>> >>> Its certainly how I would write a STIR RFP for a CA if this were for the carriers in the NANP. Setting one or two SHOULD supports seem sensible. I would not set the requirement to MUST. >>> >>> — >>> Richard Shockey >>> Shockey Consulting LLC >>> Chairman of the Board SIP Forum >>> www.shockey.us >>> www.sipforum.org >>> richardshockey.us >>> Skype-Linkedin-Facebook rshockey101 >>> PSTN +1 703-593-2683 >>> >>> >>> >>> >>> >>> >>> >>> >>> On 4/5/16, 4:04 PM, "stir on behalf of John Mattsson" wrote: >>> >>>> I think that this has changed, and will change even more until STIR is >>>> deployed. According to notary.icsi.berkeley.edu/#statistics 23 % of all >>>> TLS connections are currently setup with ECDSA certificates. One example >>>> is https://en.wikipedia.org. And we don’t need unanimous support from all >>>> CAs; it is enough that ECDSA certificates are fairly easy to get. >>>> >>>> (Ed25519 certificates are probably hard to get unless you run your own CA). >>>> >>>> >>>> John >>>> >>>> On 05/04/16 15:07, "Peterson, Jon" wrote: >>>> >>>>> To date we have not moved this to EC because (at least as far as I >>>>> understand things) many elements of web PKI, including many CAs, don't >>>>> support these algorithms yet. If our assessment of that is changing, then >>>>> let's revisit it. >>>>> >>>>> Jon Peterson >>>>> Neustar, Inc. >>>>> >>>>> Sent from my iPad >>>>> >>>>>> On Apr 5, 2016, at 11:37 AM, John Mattsson >>>>>> wrote: >>>>>> >>>>>> I think there are several strong reasons to change the default signature >>>>>> algorithm in draft-ietf-stir-rfc4474bis and draft-ietf-stir-passport. >>>>>> The >>>>>> current default algorithm is RS256 (RSASSA-PKCS1-v1_5 using SHA-256), >>>>>> but >>>>>> I cannot find any number for MTI/Recommended/Minimum/Default key length. >>>>>> >>>>>> 1. RSA signing is extremely slow compared to modern alternatives. On a >>>>>> Core i5-6600, ES256 (ECDSA using P-256 and SHA-256) is 21 times faster >>>>>> than RSA-2048, and Ed25519 is 67 times faster >>>>>> (https://bench.cr.yp.to/results-sign.html). As RSA-2048 is normally >>>>>> classified as roughly 112-bit security (RFC3766, NIST, ENISA), a more >>>>>> fair >>>>>> comparison is with RSA-3072, and then ES256 is 52 times faster and >>>>>> Ed25519 >>>>>> is 169 times faster. >>>>>> >>>>>> 2. RSA signatures are much larger than their ECC counterparts. RSA-2048 >>>>>> signatures are 256 bytes and RSA-3072 signatures are 384 bytes, while >>>>>> ES256 and Ed25519 signatures are only 64 bytes. >>>>>> >>>>>> 3. PKCS1-v1_5 is not a very good algorithm. It has no security proofs, >>>>>> no >>>>>> advantages, is disrecommended by ENISA (European Union Agency for >>>>>> Network >>>>>> and Information Security), and has been replaced in TLS 1.3. I do not >>>>>> think this is the algorithm we should use in STIR. >>>>>> >>>>>> I think the right algorithm choice for STIR is ES256 or Ed25519. >>>>>> Signature processing is likely the main burden for the Authentication >>>>>> Service, and changing from RSA to ECC significantly reduces the amount >>>>>> of >>>>>> hardware needed, and therefore the cost. A single 3.3 Ghz Skylake core >>>>>> can >>>>>> do only 400 RSA-3072 or 1,000 RSA-2048 signatures per second, but 21,000 >>>>>> ES256 or 68,000 Ed25519 signatures per second. RSA verification is a bit >>>>>> faster than ECC, but the different is much smaller that for signing, >>>>>> RSA-3072 verifications are e.g. twice as fast as Ed25519 verifications. >>>>>> >>>>>> Cheers, >>>>>> John >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------ >>>>>> JOHN MATTSSON >>>>>> MSc Engineering Physics, MSc Business Administration and Economics >>>>>> Ericsson IETF Security Coordinator >>>>>> Senior Researcher, Security >>>>>> >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Apr 6 18:11:27 2016 Return-Path: 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 53BDE12D5EF for ; Wed, 6 Apr 2016 18:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 Tpkg-HO4jx8c for ; Wed, 6 Apr 2016 18:11:24 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 93A8712D1DC for ; Wed, 6 Apr 2016 18:11:23 -0700 (PDT) Received: (qmail 32593 invoked by uid 0); 7 Apr 2016 01:11:21 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 7 Apr 2016 01:11:21 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id fDBC1s00h1MNPNq01DBFt1; Wed, 06 Apr 2016 19:11:19 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=8WrITzYgnNwA:10 a=p-_XEfp0GhYA:10 a=kziv93cY1bsA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=Z80JlwQ0AAAA:8 a=tGX7uwomAAAA:8 a=0FD05c-RAAAA:8 a=8pif782wAAAA:8 a=hGBaWAWWAAAA:8 a=MVff1mliAAAA:8 a=Bazu1r3KBx9amlsb5zUA:9 a=KHo9IcPLAyyuifCJ:21 a=pGHNEZwo78ZfAB75:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=6-C5ikvthBEA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date; bh=P5SD2IqRR97qVkcY9L4PNvaRGiPNPeVwBLFicBtpysM=; b=kgnThixcnqzYNVhW5xH51dTfq+ j1nJMZHUc4/g8lP0XX+KAP/QlTODdiFNzpSoOd3EgxRzYgQYsZocwuCmmaay+iVgipCdllJRW7WXk HqSQDapueAwi1NRN2JiAz1NGF; Received: from [100.36.35.60] (port=61367 helo=[192.168.1.9]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1anyTa-0002Yw-CH; Wed, 06 Apr 2016 19:11:14 -0600 User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Wed, 06 Apr 2016 21:11:07 -0400 From: Richard Shockey To: Robert Sparks , Message-ID: <5195FEBC-8395-4E77-B768-2B2D81144121@shockey.us> Thread-Topic: [stir] Choice of STIR signature algorithm References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <0DD82221-E79D-4F15-B2B5-93165EC98919@shockey.us> <570534D4.6010707@nostrum.com> In-Reply-To: <570534D4.6010707@nostrum.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.35.60 authed with richard+shockey.us} Archived-At: Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Thu, 07 Apr 2016 01:11:26 -0000 Implement is one thing, must use in verification is another. I won=E2=80=99t sup= port MUST be able to verify.=20 This is shaping up to be another TLS food fight re SIP PBX=E2=80=99s and the carr= iers re SIP Connect and we all know where that went. Nowhere. Must support u= se ..well maybe.=20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 On 4/6/16, 12:09 PM, "stir on behalf of Robert Sparks" wrote: >To be clear, the suggestion is must implement, not must use.=20 >Specifically, for _this_ part of the conversation, its that the code in=20 >a verifier must be _able_ to verify presented with either. > > >On 4/5/16 7:47 PM, Richard Shockey wrote: >> Well I would have to insist that such a statement is SHOULD verify, eith= er or both, how it deploys and under what conditions are still probably a na= tion-state matter certainly if they are used with E.164 plan. >> >> >> On 4/5/16, 5:55 PM, "stir on behalf of Russ Housley" wrote: >> >>> There was just a discussion of this point in the STIR session at IETF 9= 5. The sense of the room is to require verification of both RSA and ECC sig= natures. This allows the use of existing infrastructure, and allows rapid m= ovement to ECC as soon as that infrastructure is readily available >>> >>> Russ >>> >>> >>> On Apr 5, 2016, at 4:46 PM, Richard Shockey wrote: >>> >>>> And on a nation state basis my assumption would be that something like= ECC256 would be a requirement for the computational load factor if nothing = else. >>>> >>>> Its certainly how I would write a STIR RFP for a CA if this were for t= he carriers in the NANP. Setting one or two SHOULD supports seem sensible. I= would not set the requirement to MUST. >>>> >>>> =E2=80=94 >>>> Richard Shockey >>>> Shockey Consulting LLC >>>> Chairman of the Board SIP Forum >>>> www.shockey.us >>>> www.sipforum.org >>>> richardshockey.us >>>> Skype-Linkedin-Facebook rshockey101 >>>> PSTN +1 703-593-2683 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 4/5/16, 4:04 PM, "stir on behalf of John Mattsson" wrote: >>>> >>>>> I think that this has changed, and will change even more until STIR i= s >>>>> deployed. According to notary.icsi.berkeley.edu/#statistics 23 % of a= ll >>>>> TLS connections are currently setup with ECDSA certificates. One exam= ple >>>>> is https://en.wikipedia.org. And we don=E2=80=99t need unanimous support fr= om all >>>>> CAs; it is enough that ECDSA certificates are fairly easy to get. >>>>> >>>>> (Ed25519 certificates are probably hard to get unless you run your ow= n CA). >>>>> >>>>> >>>>> John >>>>> >>>>> On 05/04/16 15:07, "Peterson, Jon" wrote: >>>>> >>>>>> To date we have not moved this to EC because (at least as far as I >>>>>> understand things) many elements of web PKI, including many CAs, don= 't >>>>>> support these algorithms yet. If our assessment of that is changing,= then >>>>>> let's revisit it. >>>>>> >>>>>> Jon Peterson >>>>>> Neustar, Inc. >>>>>> >>>>>> Sent from my iPad >>>>>> >>>>>>> On Apr 5, 2016, at 11:37 AM, John Mattsson >>>>>>> wrote: >>>>>>> >>>>>>> I think there are several strong reasons to change the default sign= ature >>>>>>> algorithm in draft-ietf-stir-rfc4474bis and draft-ietf-stir-passpor= t. >>>>>>> The >>>>>>> current default algorithm is RS256 (RSASSA-PKCS1-v1_5 using SHA-256= ), >>>>>>> but >>>>>>> I cannot find any number for MTI/Recommended/Minimum/Default key le= ngth. >>>>>>> >>>>>>> 1. RSA signing is extremely slow compared to modern alternatives. O= n a >>>>>>> Core i5-6600, ES256 (ECDSA using P-256 and SHA-256) is 21 times fas= ter >>>>>>> than RSA-2048, and Ed25519 is 67 times faster >>>>>>> (https://bench.cr.yp.to/results-sign.html). As RSA-2048 is normally >>>>>>> classified as roughly 112-bit security (RFC3766, NIST, ENISA), a mo= re >>>>>>> fair >>>>>>> comparison is with RSA-3072, and then ES256 is 52 times faster and >>>>>>> Ed25519 >>>>>>> is 169 times faster. >>>>>>> >>>>>>> 2. RSA signatures are much larger than their ECC counterparts. RSA-= 2048 >>>>>>> signatures are 256 bytes and RSA-3072 signatures are 384 bytes, whi= le >>>>>>> ES256 and Ed25519 signatures are only 64 bytes. >>>>>>> >>>>>>> 3. PKCS1-v1_5 is not a very good algorithm. It has no security proo= fs, >>>>>>> no >>>>>>> advantages, is disrecommended by ENISA (European Union Agency for >>>>>>> Network >>>>>>> and Information Security), and has been replaced in TLS 1.3. I do n= ot >>>>>>> think this is the algorithm we should use in STIR. >>>>>>> >>>>>>> I think the right algorithm choice for STIR is ES256 or Ed25519. >>>>>>> Signature processing is likely the main burden for the Authenticati= on >>>>>>> Service, and changing from RSA to ECC significantly reduces the amo= unt >>>>>>> of >>>>>>> hardware needed, and therefore the cost. A single 3.3 Ghz Skylake c= ore >>>>>>> can >>>>>>> do only 400 RSA-3072 or 1,000 RSA-2048 signatures per second, but 2= 1,000 >>>>>>> ES256 or 68,000 Ed25519 signatures per second. RSA verification is = a bit >>>>>>> faster than ECC, but the different is much smaller that for signing= , >>>>>>> RSA-3072 verifications are e.g. twice as fast as Ed25519 verificati= ons. >>>>>>> >>>>>>> Cheers, >>>>>>> John >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------ >>>>>>> JOHN MATTSSON >>>>>>> MSc Engineering Physics, MSc Business Administration and Economics >>>>>>> Ericsson IETF Security Coordinator >>>>>>> Senior Researcher, Security >>>>>>> >>>>>>> _______________________________________________ >>>>>>> stir mailing list >>>>>>> stir@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Thu Apr 7 02:43:44 2016 Return-Path: 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 59ACF12D5E5 for ; Thu, 7 Apr 2016 02:43:42 -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, 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 sLsYE_ZDQpMo for ; Thu, 7 Apr 2016 02:43:40 -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 928F612D606 for ; Thu, 7 Apr 2016 02:43:40 -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:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type; bh=JEk5zpYx5QoZ7lMryyhhkMfJXOsY7OaeSJa9E1lEQA0=; b=o70eEVMfLQQq3y8Ip7tczg4Nfl AtH8/FSYu45IWuj1FjdkAvD35kL6Xgly9GgZi91Uf7JO3Gx58qC5DJn8HpXvAdHCYvbdnC6rYdfJb 5hc8Im9uioBqychCr6h+3j6fra92IIxfBzagovPTp5fdhEZR3/mpnhN9+INHBzpEeUdM=; Received: from [190.192.31.24] (port=53169 helo=[192.168.0.6]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1ao6TO-0008RV-Dr for stir@ietf.org; Thu, 07 Apr 2016 02:43:38 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_E9F3688D-A1F4-408F-A23D-C4FFA33125D3"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail 2.6b2 From: Eric Burger In-Reply-To: Date: Thu, 7 Apr 2016 06:43:32 -0300 Message-Id: <6C45B889-0874-4C2A-891D-8ABFD3F0D2B2@standardstrack.com> References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> To: "stir@ietf.org" X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.1 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 Archived-At: Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Thu, 07 Apr 2016 09:43:42 -0000 --Apple-Mail=_E9F3688D-A1F4-408F-A23D-C4FFA33125D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The statement that using ECDSA at the single MTI would hold up STIR = deployment is factually incorrect. It is not a changing view that CA=E2=80= =99s do ECDSA. Major CA=E2=80=99s have been doing ECDSA for over a year. Personally, going from RSA to ECDSA is a minor pain for me because my = RSA code is running. However, I expect my ECDSA code to be running next = week. Thus, I might have a selfish incentive to say, =E2=80=9CDo RSA now = and we will do ECDSA in phase never.=E2=80=9D However, I would much = rather have a well-implemented, useful, and scalable implementation than = a weak, already obsolete, and resource intensive implementation. If one is trying to slow down the adoption of STIR by saying we could = not possibly use modern, scalable crypto, or trying to slow down the = adoption of STIR by saying that we need a more complex protocol that is = statistically more likely to have bugs, that is a losing argument IMHO. = To quote someone from the room, I would not want to be the person = standing in front of the FCC explaining why STIR is not up to IETF = standards. I would rather be the person who is explaining why STIR is = the appropriate solution for VoIP caller ID spoofing mitigation. > On Apr 5, 2016, at 5:04 PM, John Mattsson = wrote: >=20 > I think that this has changed, and will change even more until STIR is > deployed. According to notary.icsi.berkeley.edu/#statistics 23 % of = all > TLS connections are currently setup with ECDSA certificates. One = example > is https://en.wikipedia.org. And we don=E2=80=99t need unanimous = support from all > CAs; it is enough that ECDSA certificates are fairly easy to get. >=20 > (Ed25519 certificates are probably hard to get unless you run your own = CA). >=20 >=20 > John >=20 > On 05/04/16 15:07, "Peterson, Jon" wrote: >=20 >> To date we have not moved this to EC because (at least as far as I >> understand things) many elements of web PKI, including many CAs, = don't >> support these algorithms yet. If our assessment of that is changing, = then >> let's revisit it. >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> Sent from my iPad >>=20 >>> On Apr 5, 2016, at 11:37 AM, John Mattsson = >>> wrote: >>>=20 >>> I think there are several strong reasons to change the default = signature >>> algorithm in draft-ietf-stir-rfc4474bis and = draft-ietf-stir-passport. >>> The >>> current default algorithm is RS256 (RSASSA-PKCS1-v1_5 using = SHA-256), >>> but >>> I cannot find any number for MTI/Recommended/Minimum/Default key = length. >>>=20 >>> 1. RSA signing is extremely slow compared to modern alternatives. On = a >>> Core i5-6600, ES256 (ECDSA using P-256 and SHA-256) is 21 times = faster >>> than RSA-2048, and Ed25519 is 67 times faster >>> (https://bench.cr.yp.to/results-sign.html). As RSA-2048 is normally >>> classified as roughly 112-bit security (RFC3766, NIST, ENISA), a = more >>> fair >>> comparison is with RSA-3072, and then ES256 is 52 times faster and >>> Ed25519 >>> is 169 times faster. >>>=20 >>> 2. RSA signatures are much larger than their ECC counterparts. = RSA-2048 >>> signatures are 256 bytes and RSA-3072 signatures are 384 bytes, = while >>> ES256 and Ed25519 signatures are only 64 bytes. >>>=20 >>> 3. PKCS1-v1_5 is not a very good algorithm. It has no security = proofs, >>> no >>> advantages, is disrecommended by ENISA (European Union Agency for >>> Network >>> and Information Security), and has been replaced in TLS 1.3. I do = not >>> think this is the algorithm we should use in STIR. >>>=20 >>> I think the right algorithm choice for STIR is ES256 or Ed25519. >>> Signature processing is likely the main burden for the = Authentication >>> Service, and changing from RSA to ECC significantly reduces the = amount >>> of >>> hardware needed, and therefore the cost. A single 3.3 Ghz Skylake = core >>> can >>> do only 400 RSA-3072 or 1,000 RSA-2048 signatures per second, but = 21,000 >>> ES256 or 68,000 Ed25519 signatures per second. RSA verification is a = bit >>> faster than ECC, but the different is much smaller that for signing, >>> RSA-3072 verifications are e.g. twice as fast as Ed25519 = verifications. >>>=20 >>> Cheers, >>> John >>>=20 >>>=20 >>> ------------------------------------------------------------------ >>> JOHN MATTSSON >>> MSc Engineering Physics, MSc Business Administration and Economics >>> Ericsson IETF Security Coordinator >>> Senior Researcher, Security >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_E9F3688D-A1F4-408F-A23D-C4FFA33125D3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXBivEAAoJEORoZaSQsc1IxnQP/3p8+h7qx4L7/8YVsUaVp6Jx 4zSiey9WCXye4wZtQn4J3HM55vWwSOzTDZJof8XIkO7DjRVq1DbwsPV+cQE1S29q 2UFbeD8Lg8Pn7yVxPSvy7XzlPZj4xOLdcabPo7La4O4u/fBSBL3DZ5JaN3PQRiHD qq1+b2PcnBMTFUmVzWOEBbRVvOZh1PDG3Ic4ANTLGH1gHynfoWBoqF+wPUw4Qba8 jIcLa7ABnXB74SDgA0gf3kypNCNzssl6a9O0ihZEN/iUgBm1667TSYvo/0vZD1fg 0DSyssWEY0Kxg710a9No2KouwWM+D5JqQOpTkgFNu9qtC+9b2ORuAZh11ZKsLuj5 SIUyOCKPkE9Pu1+lrTbqg/wIInQq6T9gPyoZBD/HxnC2HhMgGRLfxeNMwlRYO2V5 gt/Rp72zUK2kOhySrIHMaA/XH71pdPrDYuRx7LGGUQwFD94Xf+ajBzMcELgkL9pk +FGtpDZSkhrGkc9JNxsXn9W9ywEy3bDEnPmhlYuOagi8DZ9FUWLTg2WvyCr0jL4Q tgnHTsgSAzAMJV4kKHVyYL/NsWme49Ay9apnq6lYCXIbKrQt/ez+7VVJFXY5M6Wr UCimo6wOvGFi2iWfsVlckDb3fx5d4PD3i+W/uKfwOYsll9e8PqHyAa2OKp3JHbmF 2rpFn4C0e039ie0o9e2K =EA+e -----END PGP SIGNATURE----- --Apple-Mail=_E9F3688D-A1F4-408F-A23D-C4FFA33125D3-- From nobody Thu Apr 7 02:45:27 2016 Return-Path: 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 0954D12D644 for ; Thu, 7 Apr 2016 02:45:23 -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, 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 igQTY4od5bbR for ; Thu, 7 Apr 2016 02:45:21 -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 A7E1312D64C for ; Thu, 7 Apr 2016 02:45:21 -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:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type; bh=WTn9q0e9+2DAt6JhBjRSsYTNWfPlG6bRrhozhV/N/oM=; b=px4uw6N8KO2mGL7boNABAbh19D KsOzVeijga3oTbcoyeGNFSRvXNck3UOzp+RtVRokArLgogwGPjAFw+JRSR2zi2cx+5jAROTJxJd21 BzUj2+ENphMqc41ibV4ha4ajTHBCp6YpSZUN1frIkUXUJK7z1ym8wOwwYJxT7KvJaBmA=; Received: from [190.192.31.24] (port=53173 helo=[192.168.0.6]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1ao6Uz-00011U-Pz for stir@ietf.org; Thu, 07 Apr 2016 02:45:21 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_70C3E7FA-9013-4C23-8237-398F9635A150"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail 2.6b2 From: Eric Burger In-Reply-To: <5195FEBC-8395-4E77-B768-2B2D81144121@shockey.us> Date: Thu, 7 Apr 2016 06:45:11 -0300 Message-Id: References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <0DD82221-E79D-4F15-B2B5-93165EC98919@shockey.us> <570534D4.6010707@nostrum.com> <5195FEBC-8395-4E77-B768-2B2D81144121@shockey.us> To: stir@ietf.org X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.1 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 Archived-At: Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Thu, 07 Apr 2016 09:45:25 -0000 --Apple-Mail=_70C3E7FA-9013-4C23-8237-398F9635A150 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Learning from SIP Connect, having one and only one MTI ensures some = interoperability. It also allows us to demonstrate interoperability = between now and when the regulators do their thing and regulate. Better = yet, the regulators are more likely to say, =E2=80=9CUse what you=E2=80=99= ve got=E2=80=9D if what we have is up to modern crypto standards. > On Apr 6, 2016, at 10:11 PM, Richard Shockey = wrote: >=20 >=20 >=20 > Implement is one thing, must use in verification is another. I = won=E2=80=99t support MUST be able to verify. >=20 > This is shaping up to be another TLS food fight re SIP PBX=E2=80=99s = and the carriers re SIP Connect and we all know where that went. = Nowhere. Must support use ..well maybe. >=20 >=20 > =E2=80=94 > Richard Shockey > Shockey Consulting LLC > Chairman of the Board SIP Forum > www.shockey.us > www.sipforum.org > richardshockey.us > Skype-Linkedin-Facebook rshockey101 > PSTN +1 703-593-2683 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 4/6/16, 12:09 PM, "stir on behalf of Robert Sparks" = wrote: >=20 >> To be clear, the suggestion is must implement, not must use. >> Specifically, for _this_ part of the conversation, its that the code = in >> a verifier must be _able_ to verify presented with either. >>=20 >>=20 >> On 4/5/16 7:47 PM, Richard Shockey wrote: >>> Well I would have to insist that such a statement is SHOULD verify, = either or both, how it deploys and under what conditions are still = probably a nation-state matter certainly if they are used with E.164 = plan. >>>=20 >>>=20 >>> On 4/5/16, 5:55 PM, "stir on behalf of Russ Housley" = wrote: >>>=20 >>>> There was just a discussion of this point in the STIR session at = IETF 95. The sense of the room is to require verification of both RSA = and ECC signatures. This allows the use of existing infrastructure, and = allows rapid movement to ECC as soon as that infrastructure is readily = available >>>>=20 >>>> Russ >>>>=20 >>>>=20 >>>> On Apr 5, 2016, at 4:46 PM, Richard Shockey = wrote: >>>>=20 >>>>> And on a nation state basis my assumption would be that something = like ECC256 would be a requirement for the computational load factor if = nothing else. >>>>>=20 >>>>> Its certainly how I would write a STIR RFP for a CA if this were = for the carriers in the NANP. Setting one or two SHOULD supports seem = sensible. I would not set the requirement to MUST. >>>>>=20 >>>>> =E2=80=94 >>>>> Richard Shockey >>>>> Shockey Consulting LLC >>>>> Chairman of the Board SIP Forum >>>>> www.shockey.us >>>>> www.sipforum.org >>>>> richardshockey.us >>>>> Skype-Linkedin-Facebook rshockey101 >>>>> PSTN +1 703-593-2683 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 4/5/16, 4:04 PM, "stir on behalf of John Mattsson" = wrote: >>>>>=20 >>>>>> I think that this has changed, and will change even more until = STIR is >>>>>> deployed. According to notary.icsi.berkeley.edu/#statistics 23 % = of all >>>>>> TLS connections are currently setup with ECDSA certificates. One = example >>>>>> is https://en.wikipedia.org. And we don=E2=80=99t need unanimous = support from all >>>>>> CAs; it is enough that ECDSA certificates are fairly easy to get. >>>>>>=20 >>>>>> (Ed25519 certificates are probably hard to get unless you run = your own CA). >>>>>>=20 >>>>>>=20 >>>>>> John >>>>>>=20 >>>>>> On 05/04/16 15:07, "Peterson, Jon" = wrote: >>>>>>=20 >>>>>>> To date we have not moved this to EC because (at least as far as = I >>>>>>> understand things) many elements of web PKI, including many CAs, = don't >>>>>>> support these algorithms yet. If our assessment of that is = changing, then >>>>>>> let's revisit it. >>>>>>>=20 >>>>>>> Jon Peterson >>>>>>> Neustar, Inc. >>>>>>>=20 >>>>>>> Sent from my iPad >>>>>>>=20 >>>>>>>> On Apr 5, 2016, at 11:37 AM, John Mattsson = >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>> I think there are several strong reasons to change the default = signature >>>>>>>> algorithm in draft-ietf-stir-rfc4474bis and = draft-ietf-stir-passport. >>>>>>>> The >>>>>>>> current default algorithm is RS256 (RSASSA-PKCS1-v1_5 using = SHA-256), >>>>>>>> but >>>>>>>> I cannot find any number for MTI/Recommended/Minimum/Default = key length. >>>>>>>>=20 >>>>>>>> 1. RSA signing is extremely slow compared to modern = alternatives. On a >>>>>>>> Core i5-6600, ES256 (ECDSA using P-256 and SHA-256) is 21 times = faster >>>>>>>> than RSA-2048, and Ed25519 is 67 times faster >>>>>>>> (https://bench.cr.yp.to/results-sign.html). As RSA-2048 is = normally >>>>>>>> classified as roughly 112-bit security (RFC3766, NIST, ENISA), = a more >>>>>>>> fair >>>>>>>> comparison is with RSA-3072, and then ES256 is 52 times faster = and >>>>>>>> Ed25519 >>>>>>>> is 169 times faster. >>>>>>>>=20 >>>>>>>> 2. RSA signatures are much larger than their ECC counterparts. = RSA-2048 >>>>>>>> signatures are 256 bytes and RSA-3072 signatures are 384 bytes, = while >>>>>>>> ES256 and Ed25519 signatures are only 64 bytes. >>>>>>>>=20 >>>>>>>> 3. PKCS1-v1_5 is not a very good algorithm. It has no security = proofs, >>>>>>>> no >>>>>>>> advantages, is disrecommended by ENISA (European Union Agency = for >>>>>>>> Network >>>>>>>> and Information Security), and has been replaced in TLS 1.3. I = do not >>>>>>>> think this is the algorithm we should use in STIR. >>>>>>>>=20 >>>>>>>> I think the right algorithm choice for STIR is ES256 or = Ed25519. >>>>>>>> Signature processing is likely the main burden for the = Authentication >>>>>>>> Service, and changing from RSA to ECC significantly reduces the = amount >>>>>>>> of >>>>>>>> hardware needed, and therefore the cost. A single 3.3 Ghz = Skylake core >>>>>>>> can >>>>>>>> do only 400 RSA-3072 or 1,000 RSA-2048 signatures per second, = but 21,000 >>>>>>>> ES256 or 68,000 Ed25519 signatures per second. RSA verification = is a bit >>>>>>>> faster than ECC, but the different is much smaller that for = signing, >>>>>>>> RSA-3072 verifications are e.g. twice as fast as Ed25519 = verifications. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> John >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> = ------------------------------------------------------------------ >>>>>>>> JOHN MATTSSON >>>>>>>> MSc Engineering Physics, MSc Business Administration and = Economics >>>>>>>> Ericsson IETF Security Coordinator >>>>>>>> Senior Researcher, Security >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> stir mailing list >>>>>>>> stir@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_70C3E7FA-9013-4C23-8237-398F9635A150 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXBiwnAAoJEORoZaSQsc1IpMUQANWsbfNCmCJnBmMyTbAOxiX9 +i+89guvAwM3z2DcFbBVrLZ2aFCJJWpfa6YWtygK618JIX/8z7TlcfzWtAxXlq4n pvy2hwaE0UhrLDrxZ5d7T9/XlYosdCfTmwLV+7Q5mHCe5HHB6NmhAJvWLF3uD6Un UsXSDTiK8rvTjUzLNKlwqI3Qp5tJK6cdOrY6QOsjEepNnYgvHjvyDr0FR5YjhZPT CaiO5FvmwruipIeJ2dTvKO9dGdCmqJ7VfcCRLx39hllk0Lq936tLK38R031Lpbdy 1rVUuSM0vNzqxcPTDrv5brT7WKwj6appL9bLng5vFWz2xAubjNhuES+HJc/xDQXW jacySkv/p2SxRTiU7kabwa08Sxsn9cfXBlkaTdsWS2VoYl10OhWZJ/THRpQeY/Dt nSlSngRxiTHr/gmqK3NyYP5I+g4TsA9pVcQOpHlZTO4sH6zxMmidZzSBVFSawGvw tZo5uf7SzU5CxgiaY5i+k2Q/8fXFXsNhyepmjZvbf3B2XWCY41BRJpxYMH20tQbH qgXIOMnd53FMSaEtnoJuA6biKy79VXN/2fYwL0y+NB9CBppqJVshUkTzjhC9isNU PzVD7S3okNOjqSRRZwdatBEYz2hRfFi0xGgOsOr/JWYFk/k8CjVodtsjptxM0vj8 PONFs0V31CoLZIUfergJ =mEZi -----END PGP SIGNATURE----- --Apple-Mail=_70C3E7FA-9013-4C23-8237-398F9635A150-- From nobody Thu Apr 7 05:05:05 2016 Return-Path: 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 D626412D829 for ; Thu, 7 Apr 2016 05:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 BdbhTQZfItNe for ; Thu, 7 Apr 2016 05:05:00 -0700 (PDT) Received: from mail-qg0-x241.google.com (mail-qg0-x241.google.com [IPv6:2607:f8b0:400d:c04::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6789A12D80F for ; Thu, 7 Apr 2016 05:04:44 -0700 (PDT) Received: by mail-qg0-x241.google.com with SMTP id b32so7042672qgf.2 for ; Thu, 07 Apr 2016 05:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rqgwPTtrkFFXLt87+FS9HIQzUlCks2/+274IzpQa9Dg=; b=rRETTI7UZjsjtlISS2qv3WKagvc2M1r7nTfBa6rF6peMMr5JBMlR+ZNS224NJhQDub smFm0tmhAP8B1ZKz4QdNZYNGiimWS/jl8WZkIdOdG0tKxlIYia9iAb7ET3NEJl8U39Yf ITbKWV275O3iHURhTSyAdGMxYk8UyIB8Lku6EwPhonDpUOG/byMTkw8AAjpIB2Xeb4GO YzfvHE1EXw6OMsDDZBWEemxhOa+GBGqmsDlpb6astMNGOwcp6ld8iSPLvkA4gfflp348 WBwdCRRIKUyNKbCmJtQszTs5Tb/bpjW6eXoXWtxL3MQRZ3xuo/eABjy6SOEZUIjslX06 NQCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rqgwPTtrkFFXLt87+FS9HIQzUlCks2/+274IzpQa9Dg=; b=KMI/J9J/yL5DZr8zcVphgPGyMo+EwYtPH961fGEpALpx6wRoM5aUChypUPFqyFyBxd wLMkfzLog29ISP9Fhj6dUcwZrwm/q5l7m0w8mS4fO0cTdru8aHxcRTzzeNAzQE6DoOnB Ji/vETUqdZUaaBrTBtlEB7fqVYp5Q3XVy+bjnj6ljWvg0UwmS4Drt0AtTjHrJ1mkbjts Zqgr/wbp/KvRJ5pvnpJOrV/+aLWZboVY3XEghQovh1qAx2XhLQs3zJdfmtwpPKpBoAgN mPCTHL4o+hRgZYJKZBNCkCmdrm05Ubl+n5rUI3vH/dtMJKmyKJ7Y1ghO46F0jw0Czy8A PWfg== X-Gm-Message-State: AD7BkJIPkImcXHiRB6PuKCmBsePJyntNTkwPJN7KsvkGb5zRjoP5eiE8GusuElTBVGlhEw== X-Received: by 10.140.170.70 with SMTP id q67mr3278103qhq.8.1460030683310; Thu, 07 Apr 2016 05:04:43 -0700 (PDT) Received: from [172.20.10.33] (200-127-148-163.net.prima.net.ar. [200.127.148.163]) by smtp.gmail.com with ESMTPSA id x189sm3215072qhb.43.2016.04.07.05.04.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 05:04:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chris Wendt In-Reply-To: <5195FEBC-8395-4E77-B768-2B2D81144121@shockey.us> Date: Thu, 7 Apr 2016 09:04:36 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <56DF2D20-9381-45CB-8057-6B1AB99B05E9@chriswendt.net> References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <0DD82221-E79D-4F15-B2B5-93165EC98919@shockey.us> <570534D4.6010707@nostrum.com> <5195FEBC-8395-4E77-B768-2B2D81144121@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.3124) Archived-At: Cc: stir@ietf.org, Robert Sparks Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Thu, 07 Apr 2016 12:05:03 -0000 Hi Richard, I=E2=80=99m not sure that is the right perspective to look at this. EC has good properties, especially when it comes to CPU, but also from = it=E2=80=99s cryptographic strength. I care a lot about the CPU part, = from a cost point of view, so i think that is number 1 priority. But, RSA256 is there today as most commonly used, so it=E2=80=99s hard = to not include. I think the consensus was that RSA256 comes mostly free in many of the = likely implementations out there. I would argue EC does as well, but i=E2=80=99ll give the benefit of the = doubt to say, not everyone is completely comfortable with it or may need = some more time to have a production grade implementation perhaps. We do need to recognize that as time goes on, the best practice will = change so the number of algorithms will follow a similar path that the = TLS world is dealing with, so this isn=E2=80=99t the end of the story = either. Two MTI today, likely more tomorrow, or deprecated algorithms as well. This is reality, so let=E2=80=99s look at it more in that light. -Chris > On Apr 6, 2016, at 10:11 PM, Richard Shockey = wrote: >=20 >=20 >=20 > Implement is one thing, must use in verification is another. I = won=E2=80=99t support MUST be able to verify.=20 >=20 > This is shaping up to be another TLS food fight re SIP PBX=E2=80=99s = and the carriers re SIP Connect and we all know where that went. = Nowhere. Must support use ..well maybe.=20 >=20 >=20 > =E2=80=94=20 > Richard Shockey > Shockey Consulting LLC > Chairman of the Board SIP Forum > www.shockey.us > www.sipforum.org > richardshockey.us > Skype-Linkedin-Facebook rshockey101 > PSTN +1 703-593-2683 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 4/6/16, 12:09 PM, "stir on behalf of Robert Sparks" = wrote: >=20 >> To be clear, the suggestion is must implement, not must use.=20 >> Specifically, for _this_ part of the conversation, its that the code = in=20 >> a verifier must be _able_ to verify presented with either. >>=20 >>=20 >> On 4/5/16 7:47 PM, Richard Shockey wrote: >>> Well I would have to insist that such a statement is SHOULD verify, = either or both, how it deploys and under what conditions are still = probably a nation-state matter certainly if they are used with E.164 = plan. >>>=20 >>>=20 >>> On 4/5/16, 5:55 PM, "stir on behalf of Russ Housley" = wrote: >>>=20 >>>> There was just a discussion of this point in the STIR session at = IETF 95. The sense of the room is to require verification of both RSA = and ECC signatures. This allows the use of existing infrastructure, and = allows rapid movement to ECC as soon as that infrastructure is readily = available >>>>=20 >>>> Russ >>>>=20 >>>>=20 >>>> On Apr 5, 2016, at 4:46 PM, Richard Shockey = wrote: >>>>=20 >>>>> And on a nation state basis my assumption would be that something = like ECC256 would be a requirement for the computational load factor if = nothing else. >>>>>=20 >>>>> Its certainly how I would write a STIR RFP for a CA if this were = for the carriers in the NANP. Setting one or two SHOULD supports seem = sensible. I would not set the requirement to MUST. >>>>>=20 >>>>> =E2=80=94 >>>>> Richard Shockey >>>>> Shockey Consulting LLC >>>>> Chairman of the Board SIP Forum >>>>> www.shockey.us >>>>> www.sipforum.org >>>>> richardshockey.us >>>>> Skype-Linkedin-Facebook rshockey101 >>>>> PSTN +1 703-593-2683 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 4/5/16, 4:04 PM, "stir on behalf of John Mattsson" = wrote: >>>>>=20 >>>>>> I think that this has changed, and will change even more until = STIR is >>>>>> deployed. According to notary.icsi.berkeley.edu/#statistics 23 % = of all >>>>>> TLS connections are currently setup with ECDSA certificates. One = example >>>>>> is https://en.wikipedia.org. And we don=E2=80=99t need unanimous = support from all >>>>>> CAs; it is enough that ECDSA certificates are fairly easy to get. >>>>>>=20 >>>>>> (Ed25519 certificates are probably hard to get unless you run = your own CA). >>>>>>=20 >>>>>>=20 >>>>>> John >>>>>>=20 >>>>>> On 05/04/16 15:07, "Peterson, Jon" = wrote: >>>>>>=20 >>>>>>> To date we have not moved this to EC because (at least as far as = I >>>>>>> understand things) many elements of web PKI, including many CAs, = don't >>>>>>> support these algorithms yet. If our assessment of that is = changing, then >>>>>>> let's revisit it. >>>>>>>=20 >>>>>>> Jon Peterson >>>>>>> Neustar, Inc. >>>>>>>=20 >>>>>>> Sent from my iPad >>>>>>>=20 >>>>>>>> On Apr 5, 2016, at 11:37 AM, John Mattsson = >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>> I think there are several strong reasons to change the default = signature >>>>>>>> algorithm in draft-ietf-stir-rfc4474bis and = draft-ietf-stir-passport. >>>>>>>> The >>>>>>>> current default algorithm is RS256 (RSASSA-PKCS1-v1_5 using = SHA-256), >>>>>>>> but >>>>>>>> I cannot find any number for MTI/Recommended/Minimum/Default = key length. >>>>>>>>=20 >>>>>>>> 1. RSA signing is extremely slow compared to modern = alternatives. On a >>>>>>>> Core i5-6600, ES256 (ECDSA using P-256 and SHA-256) is 21 times = faster >>>>>>>> than RSA-2048, and Ed25519 is 67 times faster >>>>>>>> (https://bench.cr.yp.to/results-sign.html). As RSA-2048 is = normally >>>>>>>> classified as roughly 112-bit security (RFC3766, NIST, ENISA), = a more >>>>>>>> fair >>>>>>>> comparison is with RSA-3072, and then ES256 is 52 times faster = and >>>>>>>> Ed25519 >>>>>>>> is 169 times faster. >>>>>>>>=20 >>>>>>>> 2. RSA signatures are much larger than their ECC counterparts. = RSA-2048 >>>>>>>> signatures are 256 bytes and RSA-3072 signatures are 384 bytes, = while >>>>>>>> ES256 and Ed25519 signatures are only 64 bytes. >>>>>>>>=20 >>>>>>>> 3. PKCS1-v1_5 is not a very good algorithm. It has no security = proofs, >>>>>>>> no >>>>>>>> advantages, is disrecommended by ENISA (European Union Agency = for >>>>>>>> Network >>>>>>>> and Information Security), and has been replaced in TLS 1.3. I = do not >>>>>>>> think this is the algorithm we should use in STIR. >>>>>>>>=20 >>>>>>>> I think the right algorithm choice for STIR is ES256 or = Ed25519. >>>>>>>> Signature processing is likely the main burden for the = Authentication >>>>>>>> Service, and changing from RSA to ECC significantly reduces the = amount >>>>>>>> of >>>>>>>> hardware needed, and therefore the cost. A single 3.3 Ghz = Skylake core >>>>>>>> can >>>>>>>> do only 400 RSA-3072 or 1,000 RSA-2048 signatures per second, = but 21,000 >>>>>>>> ES256 or 68,000 Ed25519 signatures per second. RSA verification = is a bit >>>>>>>> faster than ECC, but the different is much smaller that for = signing, >>>>>>>> RSA-3072 verifications are e.g. twice as fast as Ed25519 = verifications. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> John >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> = ------------------------------------------------------------------ >>>>>>>> JOHN MATTSSON >>>>>>>> MSc Engineering Physics, MSc Business Administration and = Economics >>>>>>>> Ericsson IETF Security Coordinator >>>>>>>> Senior Researcher, Security >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> stir mailing list >>>>>>>> stir@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Thu Apr 7 05:26:18 2016 Return-Path: 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 26BD612D876 for ; Thu, 7 Apr 2016 05:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 wl0jQF8UtmNg for ; Thu, 7 Apr 2016 05:26:14 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA9E312D875 for ; Thu, 7 Apr 2016 05:26:14 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37CQAaR026867 for ; Thu, 7 Apr 2016 08:26:10 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 2201q9mtcw-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 07 Apr 2016 08:26:09 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 7 Apr 2016 07:26:09 -0500 From: Jonathan Lennox To: "stir@ietf.org" Thread-Topic: Problem with STIR signing of fingerprints? Thread-Index: AQHRkMipSDuEgVgnvkameKFV2J9VVw== Date: Thu, 7 Apr 2016 12:26:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.137.240] Content-Type: text/plain; charset="utf-8" Content-ID: <6F318D815C69C84DB28674B4AE15E348@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_08:2016-04-07,2016-04-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1601100000 definitions=main-1604070180 Archived-At: Subject: [stir] Problem with STIR signing of fingerprints? X-BeenThere: stir@ietf.org 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: Thu, 07 Apr 2016 12:26:16 -0000 QW4gaXNzdWUgb2NjdXJyZWQgdG8gbWUgd2hlbiBwb25kZXJpbmcgdGhlIFNUSVIgc2lnbmluZyBv ZiBmaW5nZXJwcmludHMuDQoNCkl0IHNlZW1zIGxpa2UgaXTigJlzIHBlcmZlY3RseSByZWFzb25h YmxlIGZvciBhIEIyQlVBIHRvIHN0cmlwIGFuIG09IGJsb2NrIGZyb20gYW4gb2ZmZXIsIGluIGNh c2UgaXQgZG9lc27igJl0IHdhbnQgdG8gYWxsb3cgaXQgdG8gcGFzcyAoZS5nLiwgcmVtb3Zpbmcg bT12aWRlbykuICBBbmQgSSB0aGluayB0aGlzIHNob3VsZG7igJl0IGJyZWFrIFNUSVIuDQoNCkhv d2V2ZXIsIHNpbmNlIHRoZSB0d28gbT0gYmxvY2tzIGNhbiBoYXZlIGRpZmZlcmVudCBmaW5nZXJw cmludHMsIHRoaXMgd291bGQgbWVhbiB0aGF0IHRoZSBwYXNzcG9ydCBvYmplY3QgY29tcHV0ZWQg YnkgdGhlIHZlcmlmaWVyIHdvdWxkbuKAmXQgaGF2ZSBhbGwgdGhlIGZpbmdlcnByaW50cyBpbmNs dWRlZCBpbiB0aGUgcGFzc3BvcnQgb2JqZWN0IGNyZWF0ZWQgYnkgdGhlIG9mZmVyZXIsIHNvIGl0 IHdvdWxkbuKAmXQgbWF0Y2guDQoNClRoaXMgb2NjdXJyZWQgdG8gbWUgYmVjYXVzZSBJIHdhcyB0 YWxraW5nIHRvIE1hcnRpbiBUaG9tc29uIOKAlCBoZSBtZW50aW9uZWQgdGhhdCBoaXMgcnVsZSBm b3IgdGhlIFdlYlJUQyBpZGVudGl0eSBhc3NlcnRpb25zIChkcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1 cml0eS1hcmNoIHNlY3Rpb24gNS42KSBqdXN0IHJlcXVpcmVkIHRoYXQgdGhlIGZpbmdlcnByaW50 cyBpbiB0aGUgcmVjZWl2ZWQgb2ZmZXIgYmUgYSAqc3Vic2V0KiBvZiB0aGUgZmluZ2VycHJpbnRz IGluIHRoZSBpZGVudGl0eSwgZm9yIG11Y2ggdGhlIHNhbWUgcmVhc29uLg0KDQpQcmVzdW1hYmx5 LCB0aGUg4oCcY2Fub27igJ0gcmVxdWVzdCBwcm9jZWR1cmUgY2FuIHNvbHZlIHRoaXMsIGJ1dCB0 aGUgdmVyaWZpZXIgc3RpbGwgdGhlbiBuZWVkcyB0byBjb25maXJtIHRoYXQgdGhlIGZpbmdlcnBy aW50cyBpbiB0aGUgY2Fub24gYXJlIGluZGVlZCBhIHN1cGVyc2V0IG9mIHRoZSBmaW5nZXJwcmlu dHMgaW4gdGhlIG9mZmVyLiAgU3VwcG9ydGluZyB0aGlzIG1lYW5zIHRoYXQgU1RJUuKAmXMgZmlu Z2VycHJpbnQgbGlzdCBuZWVkcyB0byBiZSBlYXNpbHkgcGFyc2VhYmxlLCBub3QganVzdCBoYXNo YWJsZS4gIChJIHN1Z2dlc3QgY29weWluZyB0aGUgc2FtZSBKU09OIGZvcm1hdCBhcyBJZFAgdXNl cy4pDQoNCkluY2lkZW50YWxseSwgdGhpcyBwcm9ibGVtIG9jY3VycmVkIHRvIG1lIGluIHRoZSBj b250ZXh0IG9mIHRoaW5raW5nIGFib3V0IGFuIGF0dGFjayBvbiBTVElSIHdoZXJlIGEgQjJCVUEg Km1vdmVzKiBmaW5nZXJwcmludHMgYmV0d2VlbiBtPSBibG9ja3MsIGUuZy4gYmVjYXVzZSBpdCBo YXMgYSBjb2xsaXNpb24gb3IgYSBzdG9sZW4gcHJpdmF0ZSBrZXkgZm9yIG9uZSBvZiB0aGVtLCBz byBpdCBtb3ZlcyBhbGwgdGhlIG90aGVyIGZpbmdlcnByaW50cyB0byBhbiBtPSBibG9jayBpdCBr bm93cyB0aGUgcmVjZWl2ZXIgd2lsbCByZWplY3QuICBTdG9sZW4gcHJpdmF0ZSBrZXlzIGNhbiBw cm9iYWJseSBuZXZlciBiZSBzb2x2ZWQsIGJ1dCBJIHRoaW5rIHRoZSBiZXN0IHdheSB0byBwcmV2 ZW50IHRoaXMgYXR0YWNrIG90aGVyd2lzZSBpcyBqdXN0IHRvIGhhdmUgNDU3MmJpcyBzYXkgdGhh dCB5b3UgbmV2ZXIgdXNlIGEgZmluZ2VycHJpbnQgd2l0aCBhIHdlYWsgaGFzaCwgcGVyaW9kLiAg KEnigJlsbCBzZW5kIGEgbm90ZSB0byBtbXVzaWMgdG8gdGhpcyBlZmZlY3QuKQ== From nobody Thu Apr 7 08:18:06 2016 Return-Path: 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 8CA6312D5B7 for ; Thu, 7 Apr 2016 08:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 of5bsyUBfajK for ; Thu, 7 Apr 2016 08:17:58 -0700 (PDT) Received: from mail-qg0-x242.google.com (mail-qg0-x242.google.com [IPv6:2607:f8b0:400d:c04::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B1412D189 for ; Thu, 7 Apr 2016 08:05:54 -0700 (PDT) Received: by mail-qg0-x242.google.com with SMTP id b32so7498924qgf.2 for ; Thu, 07 Apr 2016 08:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Hdvu5ZwfFS0nStTbkPXSho2lmQcWYZ7BlTsWogvQCBI=; b=QY3UgMTyI6rl6Fn1YsZV4mqWzzR2q5QCHOoLanVnvMyIKDlIEVNkYlXAmR1Pv0+3iQ WFOSVJTBIlEp2dAzHVx0JDxzrJy9T3QCmb36y+D1zkt2l1Hub23OycMoQF1iPmaZEwrn cpNxh8pYId+xotXttWxf2AJK4XRrIKgCpMitiQDSKfDdvnRgLr/UX4NgHJZAgsKu+Ub3 bpHQg4Bk2rupSYBYD6nuK5g1YHTlgQabHRIMOxgvuhXrTzAE4AzIubit0UryOPseQbaW oGbS8qjPNlGooq1b48EmbhnswM47LcIJO/RdfpND+4GQCR0P5VQ4kjah6HkKjwca+U2m HF5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Hdvu5ZwfFS0nStTbkPXSho2lmQcWYZ7BlTsWogvQCBI=; b=dJrsXlv3vu/dv6Jr7Lo7AtUzy9clhMwC/qQR1GCTpZyebc1qsF8trlgysfP30bLZWa CJ0XalYfjXzJdtjkM+GTyolHpd5kEVpAeV1A0YpeCzhhAEhKGh3qxNMIqhsiZTfP+29q q+UwJkezOgqrMos2CCpGeGYz7O2yB9EeOPVEBlRu5AhPfh3hAA06y/Ky+OjkZ5R0D7Gt gFaUOTR3LKTQi02g0mAd+hLaQpgMwCLySMnCSO36mHvukFVoDYYQ8/bi6L4YyMh32TFP UT6FTpQj6y4zLGeUbhcM80N/idCbVBKUUyNM4uf9MKP+F/odmvqZb47Kfg2Xn+LLSC1m TKQA== X-Gm-Message-State: AD7BkJIlX4usqYCvXWhBIYvtWx+iI62AbH95mY0hjuJzQtOuqpSpmnSd6Ea6FVG0gy8qkQ== X-Received: by 10.140.89.178 with SMTP id v47mr4294843qgd.11.1460041553090; Thu, 07 Apr 2016 08:05:53 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:759b:cdbe:1c6d:1162? ([2001:67c:370:160:759b:cdbe:1c6d:1162]) by smtp.gmail.com with ESMTPSA id d187sm3538855qhc.38.2016.04.07.08.05.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 08:05:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_24C04013-5D77-4843-BB68-03284A79216F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chris Wendt In-Reply-To: <3A1ACE55-2F47-4644-99B8-3B0208221F8D@chriswendt.net> Date: Thu, 7 Apr 2016 12:05:51 -0300 Message-Id: References: <05DD1ACB-C395-4333-A36C-56443A954199@sn3rd.com> <3A1ACE55-2F47-4644-99B8-3B0208221F8D@chriswendt.net> To: Sean Turner X-Mailer: Apple Mail (2.3124) Archived-At: Cc: stir@ietf.org Subject: Re: [stir] registering application/passport X-BeenThere: stir@ietf.org 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: Thu, 07 Apr 2016 15:18:04 -0000 --Apple-Mail=_24C04013-5D77-4843-BB68-03284A79216F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI = http://www.iana.org/assignments/provisional-standard-media-types/provision= al-standard-media-types.xhtml = > On Apr 6, 2016, at 10:01 AM, Chris Wendt = wrote: >=20 > Done. >=20 > Thanks Sean. >=20 >> On Apr 5, 2016, at 6:24 PM, Sean Turner wrote: >>=20 >> Chris, >>=20 >> Turns out we can submit a request via this handy submission tool: >>=20 >> https://www.iana.org/form/media-types >>=20 >> You can request a provisional one for testing that will then get the = final one when the draft becomes and RFC. >>=20 >> spt >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 --Apple-Mail=_24C04013-5D77-4843-BB68-03284A79216F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI

http://www.iana.org/assignments/provisional-standard-media-type= s/provisional-standard-media-types.xhtml


On Apr = 6, 2016, at 10:01 AM, Chris Wendt <chris-ietf@chriswendt.net> wrote:

Done.

Thanks Sean.

On Apr 5, = 2016, at 6:24 PM, Sean Turner <sean@sn3rd.com> wrote:

Chris,

Turns out we can submit a = request via this handy submission tool:

https://www.iana.org/form/media-types

You can request a provisional one for testing that will then = get the final one when the draft becomes and RFC.

spt
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir


= --Apple-Mail=_24C04013-5D77-4843-BB68-03284A79216F-- From nobody Thu Apr 7 09:04:38 2016 Return-Path: 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 56EF212D145 for ; Thu, 7 Apr 2016 09:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 HjeMWOWsBWgL for ; Thu, 7 Apr 2016 09:04:34 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A63512D0FA for ; Thu, 7 Apr 2016 09:04:18 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by comcast with SMTP id oCNgaryhF2R4woCPpah8DB; Thu, 07 Apr 2016 16:04:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460045057; bh=UIt1UqUmZ4FretZvqdmTOtDI8Ii0qg0n0YT0654SpxM=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ISCa6xJg0mxGvvSn4da/IjZ3NW8HsXzxD0Dp/NN5gK044FtoaywCKOjt8r2dSeAOW aNIqMNcErobBOrvSJtRBInLlaj2ozjDzftX2SJsQWnf1JQTF2Cfba666yThVsjliHb Z2JDwVm3k+OwtsA8b/fcQLJJLXoOGRlBFgBT0ac8pSNvJgVyfD0+YhPT2WxtTURkga V1qS6kKYQPvLgvkpFM8xJ+6ZhRpXsJ0qRkUxcci65fY/QwXMb7VZqGIzJGEMjGS9Rx cp0a/J/wrqmV/tTZfPNW7DKT5VgqRxGOoRYOZaE9JeLM8CWwfc0B/nnuXs1uk+1wjR XQW9m44CLIF2w== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with comcast id fU4H1s00B3KdFy101U4H4z; Thu, 07 Apr 2016 16:04:17 +0000 To: stir@ietf.org References: From: Paul Kyzivat Message-ID: <57068500.5020903@alum.mit.edu> Date: Thu, 7 Apr 2016 12:04:16 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [stir] Problem with STIR signing of fingerprints? X-BeenThere: stir@ietf.org 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: Thu, 07 Apr 2016 16:04:36 -0000 On 4/7/16 8:26 AM, Jonathan Lennox wrote: > An issue occurred to me when pondering the STIR signing of fingerprints. > > It seems like it’s perfectly reasonable for a B2BUA to strip an m= block from an offer, in case it doesn’t want to allow it to pass (e.g., removing m=video). And I think this shouldn’t break STIR. > > However, since the two m= blocks can have different fingerprints, this would mean that the passport object computed by the verifier wouldn’t have all the fingerprints included in the passport object created by the offerer, so it wouldn’t match. > > This occurred to me because I was talking to Martin Thomson — he mentioned that his rule for the WebRTC identity assertions (draft-ietf-rtcweb-security-arch section 5.6) just required that the fingerprints in the received offer be a *subset* of the fingerprints in the identity, for much the same reason. Wouldn't this open things up for a bid-down attack on fingerprint strength? (This couldn't take it below the weakest that the receiver will accept, but still an attack.) And if this is to be supported, what else might "reasonably" be done? What about reordering m-lines? Thanks, Paul > Presumably, the “canon” request procedure can solve this, but the verifier still then needs to confirm that the fingerprints in the canon are indeed a superset of the fingerprints in the offer. Supporting this means that STIR’s fingerprint list needs to be easily parseable, not just hashable. (I suggest copying the same JSON format as IdP uses.) > > Incidentally, this problem occurred to me in the context of thinking about an attack on STIR where a B2BUA *moves* fingerprints between m= blocks, e.g. because it has a collision or a stolen private key for one of them, so it moves all the other fingerprints to an m= block it knows the receiver will reject. Stolen private keys can probably never be solved, but I think the best way to prevent this attack otherwise is just to have 4572bis say that you never use a fingerprint with a weak hash, period. (I’ll send a note to mmusic to this effect.) > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From nobody Thu Apr 7 13:02:23 2016 Return-Path: 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 608CA12D18B for ; Thu, 7 Apr 2016 13:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 20G6_xLpZk6Y for ; Thu, 7 Apr 2016 13:02:20 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A3D12D17D for ; Thu, 7 Apr 2016 13:02:20 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id k1so113488319vkb.0 for ; Thu, 07 Apr 2016 13:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=rva/1rjC6sM17+P5xV9SyOYL2h1R0JIDz++kubpHEV0=; b=Qb9Wpk2Q7Kvz9nadTiIyNTtpZ0fn0LVIiv8qcfgjYmDXERCa5mXRnqDxt0py+c0QFg Htg17laF2bVSDCGQ4lpZFjhRIJuhQCV9+/7dXv0x6W6HRKiDKe1/PqVs4ZpC1OKVb7By MumA9c3L0kantmWQUcXHDSUl0LhHNgRu8EzLMy637QJsuMXbPtQwaB8JoGbvERnLmTqv NtnXak/mKOH9YHusE7uhpySc3LbtPRX73RvQOqAsqEUmXj3Z0+2fYbuQSKWC+wNDhd2b DLElsWzV3hNKJFlm8pAwM1+oFEP71WxyxDXOf4LofNi8MWboLtIKTn9xsjLF6aYyBryv bLCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=rva/1rjC6sM17+P5xV9SyOYL2h1R0JIDz++kubpHEV0=; b=XECe3kGSwKbiTJk4qqfDTOngJwe06IP6GnNQcCnmMx/phwLEznkMxfFaFvrb7fWtDu 8TP+8GYen60aj6ERbaUB9DWEJUywXh3A6qVW1cN23PBH63+IMnpPASBkiA0bPh2m71b8 gwD4TxdKH9tCVq5zpHcdDckbRI+m69qZQffWkHaZ3WDEPK7T3caMAz6ov/kzFXbuRbpP cyHF7cn3jl1ONoQ4S9QxsSRQJdnR6jKAsJAOaEpbmpxk5XOteh3iwD8s2CqnBIQUlXnA /GiQ+1UuTUuB2B1CRmgNEsfcYMjtYgc7wI8V/sHtu2z7QbPe9rlGWmA0fhwkqLLcoOlk Yl7w== X-Gm-Message-State: AD7BkJJk9j7ma0trR/Vq2j7uPL7rCS+oa/h75pJea63zmNnYEr9x+PCd+ugfCjWV9Ws9qjoKbEHZP3Rihu+Wrw== MIME-Version: 1.0 X-Received: by 10.176.7.97 with SMTP id h88mr2296544uah.125.1460059339049; Thu, 07 Apr 2016 13:02:19 -0700 (PDT) Received: by 10.31.151.85 with HTTP; Thu, 7 Apr 2016 13:02:19 -0700 (PDT) Date: Thu, 7 Apr 2016 17:02:19 -0300 Message-ID: From: Richard Barnes To: "stir@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1231e6416661052fea8e51 Archived-At: Subject: [stir] Implications of using the web PKI X-BeenThere: stir@ietf.org 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: Thu, 07 Apr 2016 20:02:22 -0000 --94eb2c1231e6416661052fea8e51 Content-Type: text/plain; charset=UTF-8 Hey all, I mentioned in the meeting the other day that there can be some negative implications of re-using WebPKI certs. Payment processors have been using WebPKI certificates for servers that payment terminals talk to. These terminals only support the obsolete SHA-1 algorithm, which is now forbidden by the CABF Baseline Requirements. So those payment processors have had to ask the browsers for permission just to keep their payment terminals operating. As though on call, a new instance of this problem cropped up this morning: https://cabforum.org/pipermail/public/2016-April/007182.html Those advocating for reuse of WebPKI certificates should imagine whether we want telcos in this position next time. --Richard --94eb2c1231e6416661052fea8e51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey all,

I mentioned in the meeting the= other day that there can be some negative implications of re-using WebPKI = certs.=C2=A0 Payment processors have been using WebPKI certificates for ser= vers that payment terminals talk to.=C2=A0 These terminals only support the= obsolete SHA-1 algorithm, which is now forbidden by the CABF Baseline Requ= irements.=C2=A0 So those payment processors have had to ask the browsers fo= r permission just to keep their payment terminals operating.

=
As though on call, a new instance of this problem cropped up thi= s morning:


Those advocating for r= euse of WebPKI certificates should imagine whether we want telcos in this p= osition next time.

--Richard
--94eb2c1231e6416661052fea8e51-- From nobody Thu Apr 7 13:16:28 2016 Return-Path: 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 2D4BA12D6A7 for ; Thu, 7 Apr 2016 13:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 AQvguEqkay2u for ; Thu, 7 Apr 2016 13:16:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1DD12D69D for ; Thu, 7 Apr 2016 13:16:20 -0700 (PDT) Received: from dhcp-b103.meeting.ietf.org (dhcp-b103.meeting.ietf.org [31.133.177.3]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u37KGIRW094795 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Thu, 7 Apr 2016 15:16:20 -0500 (CDT) (envelope-from rjsparks@nostrum.com) To: stir@ietf.org From: Robert Sparks Message-ID: <5706C011.6040905@nostrum.com> Date: Thu, 7 Apr 2016 17:16:17 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [stir] Early notice: Interim meeting X-BeenThere: stir@ietf.org 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: Thu, 07 Apr 2016 20:16:27 -0000 We are planning to have a virtual interim in the late may timeframe. Please hold May 26 for now (and let us know if that's problematic). More details will follow. RjS From nobody Thu Apr 7 13:23:33 2016 Return-Path: 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 916A712D66F for ; Thu, 7 Apr 2016 13:23:30 -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, 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 CAkI_mEKH4Xb for ; Thu, 7 Apr 2016 13:23:29 -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 7DC2012D0B8 for ; Thu, 7 Apr 2016 13:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Mime-Version:To:Message-Id:Date:Subject: Content-Type:From; bh=x8rJeCnQMIGkLj9uXWlP4B58ktJ3Cr5hojoyJpUZME8=; b=AXy63qv IOptFYI/vWiK1WT8SVIoPJw/i9wNdQQ7z/iOdtD5K8XQt/C3N3aK0g7o6aAImQjgIypKCXt1leabe QRL7t71QsyrkxT6V6lCRTnkTgkls+yLQspLLrfgKMgjnChD9zfEJ4WwRBObbnU5v+fYdr7JmeBJsk P49QR+Z5ig=; Received: from [200.51.92.238] (port=51842 helo=[10.0.13.222]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1aoGSd-0006gf-Ux for stir@ietf.org; Thu, 07 Apr 2016 13:23:29 -0700 From: Eric Burger X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_8E008A6E-2DF1-4948-A0DD-D1F4CD8314A5"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Thu, 7 Apr 2016 17:23:22 -0300 Message-Id: To: stir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 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 Archived-At: Subject: [stir] Certificate Policy Documents X-BeenThere: stir@ietf.org 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: Thu, 07 Apr 2016 20:23:30 -0000 --Apple-Mail=_8E008A6E-2DF1-4948-A0DD-D1F4CD8314A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Currently the certificate policy document, = draft-ietf-stir-certificates-03, has two approaches. One approach says = there is an entity that has a certificate that vouches for the veracity = of the asserted Passport identity. The other approach has the caller or = vouching entity hold a certificate that includes within it the = attestation for the number being asserted by Passport. The first approach is done today and is deployable today and addresses = the needs of at least the U.S. spoofing problem. The second approach is not fleshed out and is not clear will work in at = least the U.S. Since we know a=E2=80=99priori that certificate policy will be mandated = by regulators and not the IETF, I propose we separate what is likely to = be numerous certificate policy schemes. My expectation is there will be = at least three: o A certificate that cryptographically identifies who is vouching = for a particular number o A certificate that vouches for a particular number or range of = numbers o A certificate that is issued by a singular CA that vouches for a = particular identity Let us not hold up the early deployment of STIR, more especially since = the first mechanism is already fully documented and requires no new = protocol machinery (good work Jon!). Instead, let us publish STIR and = today=E2=80=99s certificate policy mechanism today. Our work is not = done! With actual experience, instead of theoretical hypothesis of what = will and will not work, we can figure out how to make the second model = work. We publish that when we have it. I would stay far, far away from = the third certificate model, as I see that as a vehicle for repressive = regimes that have high personal attestation needs. --Apple-Mail=_8E008A6E-2DF1-4948-A0DD-D1F4CD8314A5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXBsG6AAoJEORoZaSQsc1IFPgP/09srZWFfpCeDiP19i4SHMDc hjUZcdKYGxrl8tnfrl1qeURqGuxnqadSeNlipPdCmFPyGlPtPGG+g5XIyz4glyRs bQEA8EMzkkTBJeOHYFm0bPyWzXqhTaZ0SADo3kQjpmRP8j/ANFcMP0ErpiYgt2Xo 5WbR67xRQ+pfb0NBifBa2daBOVrEzE1zPadXj0j5dzKkBwvpzF3PibV6cm5AcOJB ktnSxEUSOq8SSAeieIfY+fB8LWenkOFxNAZqwaq/PNb8FPCx8+Wwx9Ko6FejtclZ bY+BVcuPOWTb0a9c20PoLoJaCMM03F/opihuUjX1w067cFEVuYHMP13Kgircxx1E pECepU4eF0+TIqEjhu+CpRG3gJnpJ8iCy2mQGzs8KBPwlFWuyD7oEnWKDwjkd15N INPoPaWNk+ww6ouTUlPa9hsS/5Q8GYazMdqN6iRvhOtdFzpwlwdycUSsZoV/SPU/ zHl8llQrZDvQTo8X2hqSGVTJ1TMy5VwA8F2T9smeZ10kWuCEwQfoG9dS1vswMNWb joKA9NxbFBUHNzHSvm/kqAeZ8lssjv/mhb0om9JpHkkN72HbkAY8jV8XM9huZnnj ijslRXia1+Qk2A0jbxwJKYqZlfa4mfVovAllgXSOcEW6BwGshn0ZIl2cudvKXtHW AzE1GuK3PxMrjiFCCFlC =7ylA -----END PGP SIGNATURE----- --Apple-Mail=_8E008A6E-2DF1-4948-A0DD-D1F4CD8314A5-- From nobody Thu Apr 7 17:43:47 2016 Return-Path: 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 29FF212D0E9 for ; Thu, 7 Apr 2016 17:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 Aff6MVDDJ80v for ; Thu, 7 Apr 2016 17:43:43 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 8448E12D0C7 for ; Thu, 7 Apr 2016 17:43:43 -0700 (PDT) Received: (qmail 15620 invoked by uid 0); 8 Apr 2016 00:43:40 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 8 Apr 2016 00:43:40 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id fcjX1s0051MNPNq01cjakf; Thu, 07 Apr 2016 18:43:38 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=8WrITzYgnNwA:10 a=p-_XEfp0GhYA:10 a=kziv93cY1bsA:10 a=w1VtefKfAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=Z80JlwQ0AAAA:8 a=tGX7uwomAAAA:8 a=0FD05c-RAAAA:8 a=8pif782wAAAA:8 a=hGBaWAWWAAAA:8 a=MVff1mliAAAA:8 a=GDEHwG8v-QRhv8rC0qwA:9 a=OtYDK2KW3OwzbpWW:21 a=Im7K5P8ExQgjslJP:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=6-C5ikvthBEA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:CC:To:From:Subject:Date; bh=+W8GB6U+zfdzuge8807JP3dOmtsOhJuKZmWkJ0j5FtQ=; b=QZ0xxoFV4F4Ag8Ncswu9VaUvF6 dSfIp1J2oBe3CqkckcpsM/A/8t0HD1t1LflzG2wUnfiXBD6qQe0iyA3VYy5vUym5wI7MItd8Vm7hv ACLfie68FfKA1FmXa8x6LHen9; Received: from [100.36.35.60] (port=56251 helo=[192.168.1.9]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1aoKWK-0001tO-SQ; Thu, 07 Apr 2016 18:43:33 -0600 User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Thu, 07 Apr 2016 20:43:25 -0400 From: Richard Shockey To: Chris Wendt Message-ID: Thread-Topic: [stir] Choice of STIR signature algorithm References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <0DD82221-E79D-4F15-B2B5-93165EC98919@shockey.us> <570534D4.6010707@nostrum.com> <5195FEBC-8395-4E77-B768-2B2D81144121@shockey.us> <56DF2D20-9381-45CB-8057-6B1AB99B05E9@chriswendt.net> In-Reply-To: <56DF2D20-9381-45CB-8057-6B1AB99B05E9@chriswendt.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.35.60 authed with richard+shockey.us} Archived-At: Cc: stir@ietf.org, Robert Sparks Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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, 08 Apr 2016 00:43:46 -0000 On 4/7/16, 8:04 AM, "Chris Wendt" wrote: >Hi Richard, > >I=E2=80=99m not sure that is the right perspective to look at this. > >EC has good properties, especially when it comes to CPU, but also from it=E2= =80=99s cryptographic strength. I care a lot about the CPU part, from a cost po= int of view, so i think that is number 1 priority. ca RS> Of course there is no argument about that. In a US/CA NANP carrier impl= ementation environment I would assume its mandated. If you started to look a= t how a NANP STIR RFP would be constructed you would put severe constraints = on options. And on costs.. Well no one, certainly not your employer, is goi= ng to pay 500M a year for this or even 140M if you know what I mean. :-)=20 > >But, RSA256 is there today as most commonly used, so it=E2=80=99s hard to not in= clude. RS> MUST support but do not mandate implementation. We=E2=80=99ll deal with that = when we start to look at the national specific deployment options. Chris wha= t I want to see is a protocol and nothing else. Please insert implementable = examples in the drafts. Where do you see this in the INVITE with actually ex= amples. I will raise hell if I don=E2=80=99t see this in the future. Jon=E2=80=99s draf= t is rhetoric and nothing else it is non implementable.=20 > >I think the consensus was that RSA256 comes mostly free in many of the lik= ely implementations out there. > >I would argue EC does as well, but i=E2=80=99ll give the benefit of the doubt to= say, not everyone is completely comfortable with it or may need some more t= ime to have a production grade implementation perhaps. RS> I still think the TLS issue in SIPConnect is applicable. The IETF can b= ark all it wants but in the end if the industry will not support it will not= deploy and there is way too much ideology and political correctness in the = way some protocols are developed. > >We do need to recognize that as time goes on, the best practice will chang= e so the number of algorithms will follow a similar path that the TLS world = is dealing with, so this isn=E2=80=99t the end of the story either. RS> Agreed but STIR with your new concepts has a great chance of actually d= eploying. Do not burden it by defining constraints you know our industry wil= l not accept.=20 > >Two MTI today, likely more tomorrow, or deprecated algorithms as well. > >This is reality, so let=E2=80=99s look at it more in that light. > >-Chris > > >> On Apr 6, 2016, at 10:11 PM, Richard Shockey wrote: >>=20 >>=20 >>=20 >> Implement is one thing, must use in verification is another. I won=E2=80=99t = support MUST be able to verify.=20 >>=20 >> This is shaping up to be another TLS food fight re SIP PBX=E2=80=99s and the c= arriers re SIP Connect and we all know where that went. Nowhere. Must suppor= t use ..well maybe.=20 >>=20 >>=20 >> =E2=80=94=20 >> Richard Shockey >> Shockey Consulting LLC >> Chairman of the Board SIP Forum >> www.shockey.us >> www.sipforum.org >> richardshockey.us >> Skype-Linkedin-Facebook rshockey101 >> PSTN +1 703-593-2683 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 4/6/16, 12:09 PM, "stir on behalf of Robert Sparks" wrote: >>=20 >>> To be clear, the suggestion is must implement, not must use.=20 >>> Specifically, for _this_ part of the conversation, its that the code in= =20 >>> a verifier must be _able_ to verify presented with either. >>>=20 >>>=20 >>> On 4/5/16 7:47 PM, Richard Shockey wrote: >>>> Well I would have to insist that such a statement is SHOULD verify, ei= ther or both, how it deploys and under what conditions are still probably a = nation-state matter certainly if they are used with E.164 plan. >>>>=20 >>>>=20 >>>> On 4/5/16, 5:55 PM, "stir on behalf of Russ Housley" wrote: >>>>=20 >>>>> There was just a discussion of this point in the STIR session at IETF= 95. The sense of the room is to require verification of both RSA and ECC s= ignatures. This allows the use of existing infrastructure, and allows rapid= movement to ECC as soon as that infrastructure is readily available >>>>>=20 >>>>> Russ >>>>>=20 >>>>>=20 >>>>> On Apr 5, 2016, at 4:46 PM, Richard Shockey wrot= e: >>>>>=20 >>>>>> And on a nation state basis my assumption would be that something li= ke ECC256 would be a requirement for the computational load factor if nothin= g else. >>>>>>=20 >>>>>> Its certainly how I would write a STIR RFP for a CA if this were for= the carriers in the NANP. Setting one or two SHOULD supports seem sensible.= I would not set the requirement to MUST. >>>>>>=20 >>>>>> =E2=80=94 >>>>>> Richard Shockey >>>>>> Shockey Consulting LLC >>>>>> Chairman of the Board SIP Forum >>>>>> www.shockey.us >>>>>> www.sipforum.org >>>>>> richardshockey.us >>>>>> Skype-Linkedin-Facebook rshockey101 >>>>>> PSTN +1 703-593-2683 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 4/5/16, 4:04 PM, "stir on behalf of John Mattsson" wrote: >>>>>>=20 >>>>>>> I think that this has changed, and will change even more until STIR= is >>>>>>> deployed. According to notary.icsi.berkeley.edu/#statistics 23 % of= all >>>>>>> TLS connections are currently setup with ECDSA certificates. One ex= ample >>>>>>> is https://en.wikipedia.org. And we don=E2=80=99t need unanimous support = from all >>>>>>> CAs; it is enough that ECDSA certificates are fairly easy to get. >>>>>>>=20 >>>>>>> (Ed25519 certificates are probably hard to get unless you run your = own CA). >>>>>>>=20 >>>>>>>=20 >>>>>>> John >>>>>>>=20 >>>>>>> On 05/04/16 15:07, "Peterson, Jon" wrote= : >>>>>>>=20 >>>>>>>> To date we have not moved this to EC because (at least as far as I >>>>>>>> understand things) many elements of web PKI, including many CAs, d= on't >>>>>>>> support these algorithms yet. If our assessment of that is changin= g, then >>>>>>>> let's revisit it. >>>>>>>>=20 >>>>>>>> Jon Peterson >>>>>>>> Neustar, Inc. >>>>>>>>=20 >>>>>>>> Sent from my iPad >>>>>>>>=20 >>>>>>>>> On Apr 5, 2016, at 11:37 AM, John Mattsson >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> I think there are several strong reasons to change the default si= gnature >>>>>>>>> algorithm in draft-ietf-stir-rfc4474bis and draft-ietf-stir-passp= ort. >>>>>>>>> The >>>>>>>>> current default algorithm is RS256 (RSASSA-PKCS1-v1_5 using SHA-2= 56), >>>>>>>>> but >>>>>>>>> I cannot find any number for MTI/Recommended/Minimum/Default key = length. >>>>>>>>>=20 >>>>>>>>> 1. RSA signing is extremely slow compared to modern alternatives.= On a >>>>>>>>> Core i5-6600, ES256 (ECDSA using P-256 and SHA-256) is 21 times f= aster >>>>>>>>> than RSA-2048, and Ed25519 is 67 times faster >>>>>>>>> (https://bench.cr.yp.to/results-sign.html). As RSA-2048 is normal= ly >>>>>>>>> classified as roughly 112-bit security (RFC3766, NIST, ENISA), a = more >>>>>>>>> fair >>>>>>>>> comparison is with RSA-3072, and then ES256 is 52 times faster an= d >>>>>>>>> Ed25519 >>>>>>>>> is 169 times faster. >>>>>>>>>=20 >>>>>>>>> 2. RSA signatures are much larger than their ECC counterparts. RS= A-2048 >>>>>>>>> signatures are 256 bytes and RSA-3072 signatures are 384 bytes, w= hile >>>>>>>>> ES256 and Ed25519 signatures are only 64 bytes. >>>>>>>>>=20 >>>>>>>>> 3. PKCS1-v1_5 is not a very good algorithm. It has no security pr= oofs, >>>>>>>>> no >>>>>>>>> advantages, is disrecommended by ENISA (European Union Agency for >>>>>>>>> Network >>>>>>>>> and Information Security), and has been replaced in TLS 1.3. I do= not >>>>>>>>> think this is the algorithm we should use in STIR. >>>>>>>>>=20 >>>>>>>>> I think the right algorithm choice for STIR is ES256 or Ed25519. >>>>>>>>> Signature processing is likely the main burden for the Authentica= tion >>>>>>>>> Service, and changing from RSA to ECC significantly reduces the a= mount >>>>>>>>> of >>>>>>>>> hardware needed, and therefore the cost. A single 3.3 Ghz Skylake= core >>>>>>>>> can >>>>>>>>> do only 400 RSA-3072 or 1,000 RSA-2048 signatures per second, but= 21,000 >>>>>>>>> ES256 or 68,000 Ed25519 signatures per second. RSA verification i= s a bit >>>>>>>>> faster than ECC, but the different is much smaller that for signi= ng, >>>>>>>>> RSA-3072 verifications are e.g. twice as fast as Ed25519 verifica= tions. >>>>>>>>>=20 >>>>>>>>> Cheers, >>>>>>>>> John >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----------------------------------------------------------------= - >>>>>>>>> JOHN MATTSSON >>>>>>>>> MSc Engineering Physics, MSc Business Administration and Economic= s >>>>>>>>> Ericsson IETF Security Coordinator >>>>>>>>> Senior Researcher, Security >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>> _______________________________________________ >>>>>>> stir mailing list >>>>>>> stir@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > From nobody Thu Apr 7 18:25:12 2016 Return-Path: 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 C578612D532 for ; Thu, 7 Apr 2016 18:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 nYur2Z_WVhUf for ; Thu, 7 Apr 2016 18:25:07 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 8FD0412D59F for ; Thu, 7 Apr 2016 18:24:59 -0700 (PDT) Received: (qmail 13355 invoked by uid 0); 8 Apr 2016 01:24:55 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy4.mail.unifiedlayer.com with SMTP; 8 Apr 2016 01:24:55 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id fdQp1s00i1MNPNq01dQsyb; Thu, 07 Apr 2016 19:24:54 -0600 X-Authority-Analysis: v=2.1 cv=G/WPTbU5 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=8WrITzYgnNwA:10 a=p-_XEfp0GhYA:10 a=kziv93cY1bsA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=bfLuiRfvAAAA:8 a=f7F2uHp9o7uMKvOeaPsA:9 a=2dPnBrRdJtbtZjWN:21 a=Kj0eooNxTZxfoZCG:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date; bh=DRd+Fd5phW0M6kxESZXKY9LyDm7S0Kv/AVS0PFtc5FY=; b=dnqPWaxEaiJGfPk24ZRgIlis+m ZtAMbR/hZFAU+B1G8KSbA9OPDbt7ZSwLSpxMjDrIoNvrGvqM+pZxlNRDKl3ZJ3zyT7OXE4yyAqMpV oCOxZO5IKX14W4VVE3ZZoaAGg; Received: from [100.36.35.60] (port=59382 helo=[192.168.1.9]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1aoLAJ-00087e-09; Thu, 07 Apr 2016 19:24:51 -0600 User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Thu, 07 Apr 2016 21:24:43 -0400 From: Richard Shockey To: Eric Burger , IETF STIR Mail List Message-ID: Thread-Topic: [stir] Certificate Policy Documents References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.35.60 authed with richard+shockey.us} Archived-At: Subject: Re: [stir] Certificate Policy Documents X-BeenThere: stir@ietf.org 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, 08 Apr 2016 01:25:10 -0000 +1 only that the only deployable model,for now, is a transactional between = authenticated service providers (AS) with access to E.164. I am Comcast and = I assert that I vouch for this INVITE to you ATT or BT FT etc. This is actua= lly how things work today. There are endless national rules on Voice interco= nnection that I will not go into.=20 I can=E2=80=99t go to Congress or the EU and change those rules so I have to live= with what exists for now or at least what exists in the US for the next 9 m= onths or so. Oh and BTW rule changes at the FCC are at least a 5 year proces= s. Believe me I know. We are discussing National Geographic Number Portabil= ity right now and that process will take years. If you think the FCC or OFCO= M, CRTC etc is going listen to Jon=E2=80=99s rants on per Number call validation I= want to know what you are smoking and why are you not sharing.=20 I=E2=80=99m really getting sick of the politically correct model of how some in t= he IETF wants things to work. Or how certain document authors are trying to = create a business model based on a proposed RFC.=20 Just tell how this works in the INVITE please and we=E2=80=99ll take care of the = rest thank you very much.=20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 On 4/7/16, 4:23 PM, "stir on behalf of Eric Burger" wrote: >Currently the certificate policy document, draft-ietf-stir-certificates-03= , has two approaches. One approach says there is an entity that has a certi= ficate that vouches for the veracity of the asserted Passport identity. The = other approach has the caller or vouching entity hold a certificate that inc= ludes within it the attestation for the number being asserted by Passport. > >The first approach is done today and is deployable today and addresses the= needs of at least the U.S. spoofing problem. > >The second approach is not fleshed out and is not clear will work in at le= ast the U.S. > >Since we know a=E2=80=99priori that certificate policy will be mandated by regul= ators and not the IETF, I propose we separate what is likely to be numerous = certificate policy schemes. My expectation is there will be at least three: > > o A certificate that cryptographically identifies who is vouching for = a particular number > o A certificate that vouches for a particular number or range of numbe= rs > o A certificate that is issued by a singular CA that vouches for a par= ticular identity > >Let us not hold up the early deployment of STIR, more especially since the= first mechanism is already fully documented and requires no new protocol ma= chinery (good work Jon!). Instead, let us publish STIR and today=E2=80=99s certifi= cate policy mechanism today. Our work is not done! With actual experience, i= nstead of theoretical hypothesis of what will and will not work, we can figu= re out how to make the second model work. We publish that when we have it. I= would stay far, far away from the third certificate model, as I see that as= a vehicle for repressive regimes that have high personal attestation needs. >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Thu Apr 7 18:36:11 2016 Return-Path: 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 3AF5612D5CD for ; Thu, 7 Apr 2016 18:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 60mglNp0-2vE for ; Thu, 7 Apr 2016 18:36:08 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 2EA7812D527 for ; Thu, 7 Apr 2016 18:36:08 -0700 (PDT) Received: (qmail 28347 invoked by uid 0); 8 Apr 2016 01:36:06 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy9.mail.unifiedlayer.com with SMTP; 8 Apr 2016 01:36:06 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id fdc11s00y1MNPNq01dc4df; Thu, 07 Apr 2016 19:36:04 -0600 X-Authority-Analysis: v=2.1 cv=G/WPTbU5 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=8WrITzYgnNwA:10 a=p-_XEfp0GhYA:10 a=kziv93cY1bsA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=bfLuiRfvAAAA:8 a=Rla9ciThQcLkf3I_XMsA:9 a=3MxbA-S-itNz5o3B:21 a=0fDmvby4zJUy4E7a:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date; bh=/m22S8fjDPuK8eTrWKZqy6h3wZU0o/mdok4FqvVvqhU=; b=pY/phdRer15tDxc/gSFSKVgEhU n1xNobJYqWeUcPgJg7qu1PKWDgs9IeDKOwpSbu6l8JPggdnGAAgPnY0DX0dOCxXtNhtnofhTAAVrV NH7z0AZ3DveUwmViARwhy7olI; Received: from [100.36.35.60] (port=60644 helo=[192.168.1.9]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1aoLL9-0005XC-1p; Thu, 07 Apr 2016 19:36:03 -0600 User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Thu, 07 Apr 2016 21:35:54 -0400 From: Richard Shockey To: Eric Burger , Message-ID: <53373C64-B3B1-44A2-B52B-0F45675F4E00@shockey.us> Thread-Topic: [stir] Certificate Policy Documents References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.35.60 authed with richard+shockey.us} Archived-At: Subject: Re: [stir] Certificate Policy Documents X-BeenThere: stir@ietf.org 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, 08 Apr 2016 01:36:10 -0000 Oh did I forget to mention that the validation authority is useless unless = it relults can be transmitted to the UA in the last INVITE?=20 And if you all think the industry is going to allow the IETF to define how = that is done .. After the way we have been treated so far .. MODERN etc. Its= not going to happen boys and girls.=20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 On 4/7/16, 4:23 PM, "stir on behalf of Eric Burger" wrote: >Currently the certificate policy document, draft-ietf-stir-certificates-03= , has two approaches. One approach says there is an entity that has a certi= ficate that vouches for the veracity of the asserted Passport identity. The = other approach has the caller or vouching entity hold a certificate that inc= ludes within it the attestation for the number being asserted by Passport. > >The first approach is done today and is deployable today and addresses the= needs of at least the U.S. spoofing problem. > >The second approach is not fleshed out and is not clear will work in at le= ast the U.S. > >Since we know a=E2=80=99priori that certificate policy will be mandated by regul= ators and not the IETF, I propose we separate what is likely to be numerous = certificate policy schemes. My expectation is there will be at least three: > > o A certificate that cryptographically identifies who is vouching for = a particular number > o A certificate that vouches for a particular number or range of numbe= rs > o A certificate that is issued by a singular CA that vouches for a par= ticular identity > >Let us not hold up the early deployment of STIR, more especially since the= first mechanism is already fully documented and requires no new protocol ma= chinery (good work Jon!). Instead, let us publish STIR and today=E2=80=99s certifi= cate policy mechanism today. Our work is not done! With actual experience, i= nstead of theoretical hypothesis of what will and will not work, we can figu= re out how to make the second model work. We publish that when we have it. I= would stay far, far away from the third certificate model, as I see that as= a vehicle for repressive regimes that have high personal attestation needs. >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Fri Apr 8 11:13:21 2016 Return-Path: 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 DB06B12D513 for ; Fri, 8 Apr 2016 11:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 R4SJYEXaYzOD for ; Fri, 8 Apr 2016 11:13:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D986012D148 for ; Fri, 8 Apr 2016 11:13:16 -0700 (PDT) Received: from dhcp-8ca1.meeting.ietf.org (dhcp-8ca1.meeting.ietf.org [31.133.140.161]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u38IDCW7042025 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 8 Apr 2016 13:13:15 -0500 (CDT) (envelope-from mahoney@nostrum.com) To: stir@ietf.org From: "A. Jean Mahoney" Message-ID: <5707F4B7.3040006@nostrum.com> Date: Fri, 8 Apr 2016 15:13:11 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [stir] stir 95 meeting notes, second session - raw X-BeenThere: stir@ietf.org 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, 08 Apr 2016 18:13:20 -0000 Below are my raw notes from the meeting (they are more raw than the first set of notes) Thanks, Jean ----------------------------------------------------------------------------------- STIR: IETF 95 Thursday, Afternoon Session II 1620-1720 Buen Ayre A ----------------------------------------------------------------------------------- 5m Administrivia presenter: Robert Sparks slides: https://www.ietf.org/proceedings/95/slides/slides-95-stir-0.pdf Note taker: Jean Mahoney Jabber relay: Dan York Jabber log: http://www.ietf.org/jabber/logs/stir/2016-04-07.html Note well and agenda were presented. No changes to the agenda. ----------------------------------------------------------------------------------- 45m draft-ietf-stir-certificates Presenter: Jon Peterson Slides: https://www.ietf.org/proceedings/95/slides/slides-95-stir-5.pdf slide 4: In-band STIR Logical Architecture ekr - a reference rather than the entity - fore compression? Jon - for this cert, is this number in scope. Rather than telling all the numbers. I don't want to rule out a db. ekr - Referential integrity of the info. If the protected property - see only some of the records. Tie the integrity to the info rather than to the signature. Jon - we'll go into details in a bit. slide 5: The First Approach Richard - there's a scalability issue here. Jon - 95% of the numbers are done by the top 12 carriers. Martin Dolly - you could start with this. The long pole is what's displayed to the end user. Staged deployments - 7-8 carriers deploy signing first and doing it this way. Exchanging certs. At a later date there's delivery to the end user. And it's been verified. That's a workable path. Jon - I have a migration path slide. We're not telling operators whom to trust. I want to provide support to the operators. Chris - I'm hoping that this is simpler and can rely on cryptographic trust, not just trusting self-signed certs from carriers. There's an authority that signs. Need to get the protocol in place and the calls. Jon - we need a transitional strategy. slide 6: The Second Approach Dan York on behalf of Eric Burger - Second approach simply will not work in the U.S. Numbers are regularly, and for good reasons, listed as the Caller ID that do not have anything to do with the carrier. So, a legitimate call under the Second Approach will be rejected. Approach Two is DOA, at least in North America, and probably in most jurisdictions. This issue also kills the Oracle function Jon mentioned related to the First Approach. The most we can do is trust the vouching carrier. Jon - that's a strong assertion and I would understand the motivation. That's not my understanding. Why are we not arresting Tim Cook for that? Eric - Your number is served by Verizon wholesale number but you're a Centurylink customer. You have an ATT 800 number but you're a centurylink customer. Jon - but you can delegate and it solves this problem. RjS - We have an RFC that says that we are solving this case. Jon - We are ascertaining that ... It's preposterous that this is illegal. RjS - I don't think Eric was saying it was illegal. It won't be asserted to the person that ... Dan York - For hosted apps like Doctor's offices, does the 2nd approach work? Jon - yes. I brought this up in lurk. There are ways to address secure redirect. Chris Wendt - we need a mechanism to protect law enforcement, teachers, IRS, etc. and solve this problem for them. Jon - a seasonal problem is robocalling from IRS numbers - tactically protecting some numbers. ekr - any situation get the cert and then do the fetch. Jon - if we can make it simple - is this number covered by the cert. Don't give me all the numbers covered by the cert. ekr - you can have a small cert with just one number. Jon - stapling inverts the privacy consideration. ekr - that seems viable. OCSP stapling looks like ... If I have that, I might as well have cert. You are given a large cert that you can't read, please call here for more info. You could have just had a cert with ocsp stapling. Jon - we want an optimization that protects the privacy. I think we can punt on that to get us on the migration. If you see something that prevents shorter certs, let me know. ekr - this is flexible. Are all the options useful? I'm assigned a huge block. I give you a copy of cert and the chain up the hash tree for covers you. If we think certs are enough, we're ok, if it needs to be more sophisticated- Chris - How do we get from A to B? Make sure verification services support both approaches. Richard - if these are done with a meaningful subject, you can use existing DKS (?) Jon - it's CPS. Eric - By the way, all of the delegation mechanism is TBD in the draft. How about a concrete proposal: break the draft into two (or more) certificate approaches. Why bundle them together? Approach 1 works today. Approach 2 may work if and when fleshed out. I don't want to tell the FCC we are late with STIR because we are working on an approach that may not be used. Jon - I don't want to deliver something that doesn't solve what we said in the problem statement. ... slide 7: Either Way slide 8: A migration path Jon - I look like this like DKIM. I want to see large providers do this well. We won't be late if we provide a starting point, migration path. I don't want implementers only to implement the first step. ekr - Martin - I think the first approach with OCN in the cert can go past the gang of 8. The 2nd approach is also useful. Supporting both and having a migratory path. And can get consensus around it. Eric - So, if the approach is to put out something that works for 90+% of traffic and then, with experience, will work for everybody, why toss out something that we may learn, from experience, may or may not work. We might even learn the right, right way to do it. Jon - If the gang of 8 were the source of the calls that are problematic, it would be a great solution. But it's the smaller entities that are source of problem calls. Dan York - You and Eric are in violent agreement that approach 1 can be done. Jon - the migration path is not a standard. We will put a standard that will create the path. Dan - Eric just wants to stop with approach 1. But you want to include the 2nd approach. Eric - I want to stop with Approcah 1 for now. Need to learn more before doing Approach 2. Important point is "for now", not "for ever" Jon - I disagree. It's a mistake. Chris - I'm not sure we're talking about gang of 8. Richard - looking at the charter - approach one doesn't cover it. It doesn't verify the telephone number. Need to get to 2. Jon - just doing 1 is insufficient. Russ as individual - approach 1 builds on available tech and get going. approach 2 requires new extensions. We need to work on them and learn. If we need to do a v2 of approach 2, lets do that. Jon - the stuff can be built. Eric - I *do* agree with Richard Barnes. If the threat model is Pink Carriers, Approach 1 works. Jon - pink carriers impersonate ... however the source of this. Henning has a draft on this. For VM hacking, the approach is a good one. The robocalling one, it's not. Eric - Agree with Russ: Publish Approach 1, work on and Publish Approach 2. RjS - I'd like to take a hum. First hum is, if you think we should go down Jon's path and persue both approaches. 2nd hum is split the doc - do one approach then the other. Ken Carlberg - could we push approach 2 to an appendix to get a current snapshot and continue approach 2 in another document? Russ - that's just a hybrid. RjS - Ok, first hum: Should we document both approaches now? Hums in room, not in the chat room. RjS - Second hum: Should we split the approaches - put approach 2 in an appendix or 2nd document? 2 hums in chat room. None in the room. RjS - There is a strong majority in the room. If you dissent, please argue on list. slide 9: The IETF and the industry slide 10: Moving forward Jon - Are we cool here? Should we worry about the privacy model? Any discomfiture with the approach. No comments. slide 11: One last plug... RjS - when will we see the next version of the draft? Jon - We need to schedule an interim phone call 6-8 weeks, target a draft then. RjS - late may - early june, then. HUM: There is a strong majority in the room for documenting both approaches now. ACTION: schedule an interim call. ----------------------------------------------------------------------------------- 10m Next steps No other business. From nobody Mon Apr 11 06:19:16 2016 Return-Path: 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 72D6212EE65 for ; Mon, 11 Apr 2016 06:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ERFSPXw7FPQb for ; Mon, 11 Apr 2016 06:19:08 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA95912EE64 for ; Mon, 11 Apr 2016 06:19:07 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-5b-570ba449fd27 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9F.A8.16394.944AB075; Mon, 11 Apr 2016 15:19:05 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.106]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Mon, 11 Apr 2016 15:19:05 +0200 From: John Mattsson To: Richard Shockey , Chris Wendt Thread-Topic: [stir] Choice of STIR signature algorithm Thread-Index: AQHRj0iWb832AGdGDEePNXJedu5tup97jA0A///uY4CAAD3ggIAAE2SAgAAOlwCAASMiAIAAlzSAgAC2lQCAANQDgIAFq7sA Date: Mon, 11 Apr 2016 13:19:04 +0000 Message-ID: References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <0DD82221-E79D-4F15-B2B5-93165EC98919@shockey.us> <570534D4.6010707@nostrum.com> <5195FEBC-8395-4E77-B768-2B2D81144121@shockey.us> <56DF2D20-9381-45CB-8057-6B1AB99B05E9@chriswendt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="utf-8" Content-ID: <52DF72FF15753345B3A7AD4297212BB9@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUyM+Jvja7nEu5wg5Z+G4vpn3YzW8z4YWBx bU4jm8XytduYHFg8JvStYfVYsuQnk8esnU9YPCZ+PMMcwBLFZZOSmpNZllqkb5fAlbH67X+2 gjsNjBV3eprYGhi31HYxcnJICJhIzJzxmh3CFpO4cG89WxcjF4eQwFFGib37XkM5Sxglpsyf AlbFJmAgMXdPAxuILSIQLNEwfxMTiM0s4CnxcsZMVhBbWMBMYv68K4wQNeYSB/5NZIWw8yR2 TToBVM/BwSKgKvHyFliYF6hkX9dnVohdP5kl+ve1g83nFLCTWPzzGtheRqDrvp9aA7VLXOLW k/lMEFcLSCzZc54ZwhaVePn4H9hQUQE9idsda6E+U5Rof9rACLKXWUBTYv0ufYgx1hKf5u5i hLAVJaZ0P2SHuEdQ4uTMJywTGCVmIdk2C6F7FpLuWUi6ZyHpXsDIuopRtDi1OCk33chYL7Uo M7m4OD9PLy+1ZBMjMFoPbvmtuoPx8hvHQ4wCHIxKPLwKrNzhQqyJZcWVuYcYJTiYlUR4jRcB hXhTEiurUovy44tKc1KLDzFKc7AoifNmR/4LExJITyxJzU5NLUgtgskycXBKNTB6KFU9uhfz O+Tap37VHZsjHBecO3Z6ii2rodgL3weajQfC761ScMthWv0siEl3WqOafGulucba7f83pm7u 8dEon/ea4dJkYfkdZY12hSVPpjsrWzotTQqvaHDkny10/8uKx4e4RLn23ha7837houiuXYc6 1wbNfJodWN3hp/JJItp7z6w970qVWIozEg21mIuKEwHVFFQT0gIAAA== Archived-At: Cc: "stir@ietf.org" , Robert Sparks Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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, 11 Apr 2016 13:19:15 -0000 SSBkb27igJl0IGtub3cgd2h5IHNvIG11Y2ggb2YgdGhlIGRpc2N1c3Npb24gZHVyaW5nIHRoZSBU dWVzZGF5IG1lZXRpbmcgd2FzDQphYm91dCByb290IGNlcnRpZmljYXRlcy4gQXMgRXJpYyBwb2lu dGVkIG91dCBvbiB0aGUgbWFpbCwgaXQgaXMgbm90IGhhcmQNCnRvIGdldCBhIEVDRFNBIGNlcnRp ZmljYXRlIGFzIERpZ2ljZXJ0LCBFbnRydXN0LCBHbG9iYWxpc2luZywgU3ltYW50ZWMsDQpDZXJ0 aWNvbSwgQ29tb2RvLCBhbmQgc29vbiBMZXTigJlzIGVuY3J5cHQgd2lsbCBoYXBwaWx5IGdpdmUg eW91IG9uZS4gQXMNClJ1c3MgcG9pbnRlZCBvdXQgbW9zdCAob3IgYWxsKSBvZiB0aGVzZSBFQ0RT QSBjZXJ0aWZpY2F0ZXMgd2lsbCBiZSBzaWduZWQNCmJ5IGEgUlNBIHJvb3QgY2VydGlmaWNhdGUu IEJ1dCByb290IGNlcnRpZmljYXRlcyBhbmQgdmVyaWZpY2F0aW9uIG9mIHRoZQ0KY3JlZGVudGlh bHMgc2VlbXMgdG8gYmUgb3V0IG9mIHNjb3BlIG9mIFNUSVIgYW5kIGRvZXMgbm90IGFmZmVjdCB0 aGUNClBBU1Nwb3JUIG9iamVjdC4gQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgdGhlIG9ubHkgdGhp bmcgU1RJUiBzaG91bGQNCnNwZWNpZnkgaXMgdmVyaWZpY2F0aW9uIG9mIHRoZSBQQVNTcG9yVCBv YmplY3QuDQoNCklmIHdlIG1hbmRhdGUgUlNBIGluIGFkZGl0aW9uIHRvIEVDQyAod2hpY2ggSSBk b27igJl0IHRoaW5rIGlzIG5lY2Vzc2FyeSwNCmJ1dCBkbyBub3Qgb3Bwb3NlKSwgdGhlbiBJIHRo aW5rIHRoYXQgUlMyNTYgKFBLQ1MxLXYxXzUpIGlzIHRoZSB3cm9uZw0KYWxnb3JpdGhtLiBCb3Ro IFRMUyAxLjMgKGRyYWZ0LWlldGYtdGxzLXRsczEzKSBhbmQgSVBTZWMNCihkcmFmdC1pZXRmLWlw c2VjbWUtcmZjNDMwN2JpcykgYXJlIHJlcGxhY2luZyBQS0NTMS12MV81IHdpdGggUFNTIChKT1NF DQphbGcgUFMyNTYpLiBJZiBTVElSIHVzZXMgUlNBLCBpdCBzaG91bGQgZG8gdGhlIHNhbWUuDQoN CklmIFNUSVIgdXNlcyBSUzI1NiAoUEtDUzEtdjFfNSkgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxp dHkgKHdoaWNoIEkgZG9u4oCZdA0Kc2VlIGFzIG5lY2Vzc2FyeSBhcyBSRkM0NDc0IGlzIG5vdCBk ZXBsb3llZCkgdGhlbiB0aGlzIHNob3VsZCBiZSBjbGVhcmx5DQpzdGF0ZWQsIGFuZCBSUzI1NiAo UEtDUzEtdjFfNSkgc2hvdWxkIGJlIE5PVCBSRUNPTU1FTkRFRC4NCg0KDQpDaGVlcnMsDQpKb2hu DQoNCg0KDQpPbiAwNy8wNC8xNiAyMTo0MywgInN0aXIgb24gYmVoYWxmIG9mIFJpY2hhcmQgU2hv Y2tleSINCjxzdGlyLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHJpY2hhcmRAc2hvY2tl eS51cz4gd3JvdGU6DQoNCj4NCj5PbiA0LzcvMTYsIDg6MDQgQU0sICJDaHJpcyBXZW5kdCIgPGNo cmlzLWlldGZAY2hyaXN3ZW5kdC5uZXQ+IHdyb3RlOg0KPg0KPj5IaSBSaWNoYXJkLA0KPj4NCj4+ SeKAmW0gbm90IHN1cmUgdGhhdCBpcyB0aGUgcmlnaHQgcGVyc3BlY3RpdmUgdG8gbG9vayBhdCB0 aGlzLg0KPj4NCj4+RUMgaGFzIGdvb2QgcHJvcGVydGllcywgZXNwZWNpYWxseSB3aGVuIGl0IGNv bWVzIHRvIENQVSwgYnV0IGFsc28gZnJvbQ0KPj5pdOKAmXMgY3J5cHRvZ3JhcGhpYyBzdHJlbmd0 aC4gIEkgY2FyZSBhIGxvdCBhYm91dCB0aGUgQ1BVIHBhcnQsIGZyb20gYQ0KPj5jb3N0IHBvaW50 IG9mIHZpZXcsIHNvIGkgdGhpbmsgdGhhdCBpcyBudW1iZXIgMSBwcmlvcml0eS4NCj4NCj5jYQ0K PlJTPiBPZiBjb3Vyc2UgdGhlcmUgaXMgbm8gYXJndW1lbnQgYWJvdXQgdGhhdC4gSW4gYSBVUy9D QSBOQU5QIGNhcnJpZXINCj5pbXBsZW1lbnRhdGlvbiBlbnZpcm9ubWVudCBJIHdvdWxkIGFzc3Vt ZSBpdHMgbWFuZGF0ZWQuIElmIHlvdSBzdGFydGVkIHRvDQo+bG9vayBhdCBob3cgYSBOQU5QIFNU SVIgUkZQIHdvdWxkIGJlIGNvbnN0cnVjdGVkIHlvdSB3b3VsZCBwdXQgc2V2ZXJlDQo+Y29uc3Ry YWludHMgb24gb3B0aW9ucy4gQW5kIG9uIGNvc3RzLi4gV2VsbCBubyBvbmUsIGNlcnRhaW5seSBu b3QgeW91cg0KPmVtcGxveWVyLCAgaXMgZ29pbmcgdG8gcGF5IDUwME0gYSB5ZWFyIGZvciB0aGlz IG9yIGV2ZW4gMTQwTSBpZiB5b3Uga25vdw0KPndoYXQgSSBtZWFuLiA6LSkgDQo+DQo+DQo+DQo+ Pg0KPj5CdXQsIFJTQTI1NiBpcyB0aGVyZSB0b2RheSBhcyBtb3N0IGNvbW1vbmx5IHVzZWQsIHNv IGl04oCZcyBoYXJkIHRvIG5vdA0KPj5pbmNsdWRlLg0KPg0KPg0KPlJTPiBNVVNUIHN1cHBvcnQg YnV0IGRvIG5vdCBtYW5kYXRlIGltcGxlbWVudGF0aW9uLiBXZeKAmWxsIGRlYWwgd2l0aCB0aGF0 DQo+d2hlbiB3ZSBzdGFydCB0byBsb29rIGF0IHRoZSBuYXRpb25hbCBzcGVjaWZpYyBkZXBsb3lt ZW50IG9wdGlvbnMuIENocmlzDQo+d2hhdCBJIHdhbnQgdG8gc2VlIGlzIGEgcHJvdG9jb2wgYW5k IG5vdGhpbmcgZWxzZS4gUGxlYXNlIGluc2VydA0KPmltcGxlbWVudGFibGUgZXhhbXBsZXMgaW4g dGhlIGRyYWZ0cy4gV2hlcmUgZG8geW91IHNlZSB0aGlzIGluIHRoZSBJTlZJVEUNCj53aXRoIGFj dHVhbGx5IGV4YW1wbGVzLiAgSSB3aWxsIHJhaXNlIGhlbGwgaWYgSSBkb27igJl0IHNlZSB0aGlz IGluIHRoZQ0KPmZ1dHVyZS4gSm9u4oCZcyBkcmFmdCBpcyByaGV0b3JpYyBhbmQgbm90aGluZyBl bHNlIGl0IGlzIG5vbiBpbXBsZW1lbnRhYmxlLg0KPg0KPg0KPj4NCj4+SSB0aGluayB0aGUgY29u c2Vuc3VzIHdhcyB0aGF0IFJTQTI1NiBjb21lcyBtb3N0bHkgZnJlZSBpbiBtYW55IG9mIHRoZQ0K Pj5saWtlbHkgaW1wbGVtZW50YXRpb25zIG91dCB0aGVyZS4NCj4+DQo+Pkkgd291bGQgYXJndWUg RUMgZG9lcyBhcyB3ZWxsLCBidXQgaeKAmWxsIGdpdmUgdGhlIGJlbmVmaXQgb2YgdGhlIGRvdWJ0 IHRvDQo+PnNheSwgbm90IGV2ZXJ5b25lIGlzIGNvbXBsZXRlbHkgY29tZm9ydGFibGUgd2l0aCBp dCBvciBtYXkgbmVlZCBzb21lDQo+Pm1vcmUgdGltZSB0byBoYXZlIGEgcHJvZHVjdGlvbiBncmFk ZSBpbXBsZW1lbnRhdGlvbiBwZXJoYXBzLg0KPg0KPlJTPiBJIHN0aWxsIHRoaW5rIHRoZSBUTFMg aXNzdWUgaW4gU0lQQ29ubmVjdCBpcyBhcHBsaWNhYmxlLiBUaGUgSUVURiBjYW4NCj5iYXJrIGFs bCBpdCB3YW50cyBidXQgaW4gdGhlIGVuZCBpZiB0aGUgaW5kdXN0cnkgd2lsbCBub3Qgc3VwcG9y dCBpdCB3aWxsDQo+bm90IGRlcGxveSBhbmQgdGhlcmUgaXMgd2F5IHRvbyBtdWNoIGlkZW9sb2d5 IGFuZCBwb2xpdGljYWwgY29ycmVjdG5lc3MNCj5pbiB0aGUgd2F5IHNvbWUgcHJvdG9jb2xzIGFy ZSBkZXZlbG9wZWQuDQo+DQo+DQo+Pg0KPj5XZSBkbyBuZWVkIHRvIHJlY29nbml6ZSB0aGF0IGFz IHRpbWUgZ29lcyBvbiwgdGhlIGJlc3QgcHJhY3RpY2Ugd2lsbA0KPj5jaGFuZ2Ugc28gdGhlIG51 bWJlciBvZiBhbGdvcml0aG1zIHdpbGwgZm9sbG93IGEgc2ltaWxhciBwYXRoIHRoYXQgdGhlDQo+ PlRMUyB3b3JsZCBpcyBkZWFsaW5nIHdpdGgsIHNvIHRoaXMgaXNu4oCZdCB0aGUgZW5kIG9mIHRo ZSBzdG9yeSBlaXRoZXIuDQo+DQo+DQo+UlM+IEFncmVlZCBidXQgU1RJUiB3aXRoIHlvdXIgbmV3 IGNvbmNlcHRzIGhhcyBhIGdyZWF0IGNoYW5jZSBvZiBhY3R1YWxseQ0KPmRlcGxveWluZy4gRG8g bm90IGJ1cmRlbiBpdCBieSBkZWZpbmluZyBjb25zdHJhaW50cyB5b3Uga25vdyBvdXIgaW5kdXN0 cnkNCj53aWxsIG5vdCBhY2NlcHQuIA0KPg0KPg0KPj4NCj4+VHdvIE1USSB0b2RheSwgbGlrZWx5 IG1vcmUgdG9tb3Jyb3csIG9yIGRlcHJlY2F0ZWQgYWxnb3JpdGhtcyBhcyB3ZWxsLg0KPj4NCj4+ VGhpcyBpcyByZWFsaXR5LCBzbyBsZXTigJlzIGxvb2sgYXQgaXQgbW9yZSBpbiB0aGF0IGxpZ2h0 Lg0KPj4NCj4+LUNocmlzDQo+Pg0KPj4NCj4+PiBPbiBBcHIgNiwgMjAxNiwgYXQgMTA6MTEgUE0s IFJpY2hhcmQgU2hvY2tleSA8cmljaGFyZEBzaG9ja2V5LnVzPg0KPj4+d3JvdGU6DQo+Pj4gDQo+ Pj4gDQo+Pj4gDQo+Pj4gSW1wbGVtZW50IGlzIG9uZSB0aGluZywgbXVzdCB1c2UgaW4gdmVyaWZp Y2F0aW9uIGlzIGFub3RoZXIuICBJIHdvbuKAmXQNCj4+PnN1cHBvcnQgTVVTVCBiZSBhYmxlIHRv IHZlcmlmeS4NCj4+PiANCj4+PiBUaGlzIGlzIHNoYXBpbmcgdXAgdG8gYmUgYW5vdGhlciBUTFMg Zm9vZCBmaWdodCByZSBTSVAgUEJY4oCZcyBhbmQgdGhlDQo+Pj5jYXJyaWVycyByZSBTSVAgQ29u bmVjdCBhbmQgd2UgYWxsIGtub3cgd2hlcmUgdGhhdCB3ZW50LiBOb3doZXJlLiBNdXN0DQo+Pj5z dXBwb3J0IHVzZSAuLndlbGwgbWF5YmUuDQo+Pj4gDQo+Pj4gDQo+Pj4g4oCUIA0KPj4+IFJpY2hh cmQgU2hvY2tleQ0KPj4+IFNob2NrZXkgQ29uc3VsdGluZyBMTEMNCj4+PiBDaGFpcm1hbiBvZiB0 aGUgQm9hcmQgU0lQIEZvcnVtDQo+Pj4gd3d3LnNob2NrZXkudXMNCj4+PiB3d3cuc2lwZm9ydW0u b3JnDQo+Pj4gcmljaGFyZDxhdD5zaG9ja2V5LnVzDQo+Pj4gU2t5cGUtTGlua2VkaW4tRmFjZWJv b2sgcnNob2NrZXkxMDENCj4+PiBQU1ROICsxIDcwMy01OTMtMjY4Mw0KPj4+IA0KPj4+IA0KPj4+ IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IE9uIDQvNi8xNiwgMTI6MDkgUE0s ICJzdGlyIG9uIGJlaGFsZiBvZiBSb2JlcnQgU3BhcmtzIg0KPj4+PHN0aXItYm91bmNlc0BpZXRm Lm9yZyBvbiBiZWhhbGYgb2YgcmpzcGFya3NAbm9zdHJ1bS5jb20+IHdyb3RlOg0KPj4+IA0KPj4+ PiBUbyBiZSBjbGVhciwgdGhlIHN1Z2dlc3Rpb24gaXMgbXVzdCBpbXBsZW1lbnQsIG5vdCBtdXN0 IHVzZS4NCj4+Pj4gU3BlY2lmaWNhbGx5LCBmb3IgX3RoaXNfIHBhcnQgb2YgdGhlIGNvbnZlcnNh dGlvbiwgaXRzIHRoYXQgdGhlIGNvZGUNCj4+Pj5pbiANCj4+Pj4gYSB2ZXJpZmllciBtdXN0IGJl IF9hYmxlXyB0byB2ZXJpZnkgcHJlc2VudGVkIHdpdGggZWl0aGVyLg0KPj4+PiANCj4+Pj4gDQo+ Pj4+IE9uIDQvNS8xNiA3OjQ3IFBNLCBSaWNoYXJkIFNob2NrZXkgd3JvdGU6DQo+Pj4+PiBXZWxs IEkgd291bGQgaGF2ZSB0byBpbnNpc3QgdGhhdCBzdWNoIGEgc3RhdGVtZW50IGlzIFNIT1VMRCB2 ZXJpZnksDQo+Pj4+PmVpdGhlciBvciBib3RoLCBob3cgaXQgZGVwbG95cyBhbmQgdW5kZXIgd2hh dCBjb25kaXRpb25zIGFyZSBzdGlsbA0KPj4+Pj5wcm9iYWJseSBhIG5hdGlvbi1zdGF0ZSBtYXR0 ZXIgY2VydGFpbmx5IGlmIHRoZXkgYXJlIHVzZWQgd2l0aCBFLjE2NA0KPj4+Pj5wbGFuLg0KPj4+ Pj4gDQo+Pj4+PiANCj4+Pj4+IE9uIDQvNS8xNiwgNTo1NSBQTSwgInN0aXIgb24gYmVoYWxmIG9m IFJ1c3MgSG91c2xleSINCj4+Pj4+PHN0aXItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg aG91c2xleUB2aWdpbHNlYy5jb20+IHdyb3RlOg0KPj4+Pj4gDQo+Pj4+Pj4gVGhlcmUgd2FzIGp1 c3QgYSBkaXNjdXNzaW9uIG9mIHRoaXMgcG9pbnQgaW4gdGhlIFNUSVIgc2Vzc2lvbiBhdA0KPj4+ Pj4+SUVURiA5NS4gIFRoZSBzZW5zZSBvZiB0aGUgcm9vbSBpcyB0byByZXF1aXJlIHZlcmlmaWNh dGlvbiBvZiBib3RoDQo+Pj4+Pj5SU0EgYW5kIEVDQyBzaWduYXR1cmVzLiAgVGhpcyBhbGxvd3Mg dGhlIHVzZSBvZiBleGlzdGluZw0KPj4+Pj4+aW5mcmFzdHJ1Y3R1cmUsIGFuZCBhbGxvd3MgcmFw aWQgbW92ZW1lbnQgdG8gRUNDIGFzIHNvb24gYXMgdGhhdA0KPj4+Pj4+aW5mcmFzdHJ1Y3R1cmUg aXMgcmVhZGlseSBhdmFpbGFibGUNCj4+Pj4+PiANCj4+Pj4+PiBSdXNzDQo+Pj4+Pj4gDQo+Pj4+ Pj4gDQo+Pj4+Pj4gT24gQXByIDUsIDIwMTYsIGF0IDQ6NDYgUE0sIFJpY2hhcmQgU2hvY2tleSA8 cmljaGFyZEBzaG9ja2V5LnVzPg0KPj4+Pj4+d3JvdGU6DQo+Pj4+Pj4gDQo+Pj4+Pj4+IEFuZCBv biBhIG5hdGlvbiBzdGF0ZSBiYXNpcyBteSBhc3N1bXB0aW9uIHdvdWxkIGJlIHRoYXQgc29tZXRo aW5nDQo+Pj4+Pj4+bGlrZSBFQ0MyNTYgd291bGQgYmUgYSByZXF1aXJlbWVudCBmb3IgdGhlIGNv bXB1dGF0aW9uYWwgbG9hZA0KPj4+Pj4+PmZhY3RvciBpZiBub3RoaW5nIGVsc2UuDQo+Pj4+Pj4+ IA0KPj4+Pj4+PiBJdHMgY2VydGFpbmx5IGhvdyBJIHdvdWxkIHdyaXRlIGEgU1RJUiBSRlAgZm9y IGEgQ0EgaWYgdGhpcyB3ZXJlDQo+Pj4+Pj4+Zm9yIHRoZSBjYXJyaWVycyBpbiB0aGUgTkFOUC4g U2V0dGluZyBvbmUgb3IgdHdvIFNIT1VMRCBzdXBwb3J0cw0KPj4+Pj4+PnNlZW0gc2Vuc2libGUu IEkgd291bGQgbm90IHNldCB0aGUgcmVxdWlyZW1lbnQgdG8gTVVTVC4NCj4+Pj4+Pj4gDQo+Pj4+ Pj4+IOKAlA0KPj4+Pj4+PiBSaWNoYXJkIFNob2NrZXkNCj4+Pj4+Pj4gU2hvY2tleSBDb25zdWx0 aW5nIExMQw0KPj4+Pj4+PiBDaGFpcm1hbiBvZiB0aGUgQm9hcmQgU0lQIEZvcnVtDQo+Pj4+Pj4+ IHd3dy5zaG9ja2V5LnVzDQo+Pj4+Pj4+IHd3dy5zaXBmb3J1bS5vcmcNCj4+Pj4+Pj4gcmljaGFy ZDxhdD5zaG9ja2V5LnVzDQo+Pj4+Pj4+IFNreXBlLUxpbmtlZGluLUZhY2Vib29rIHJzaG9ja2V5 MTAxDQo+Pj4+Pj4+IFBTVE4gKzEgNzAzLTU5My0yNjgzDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+ Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiAN Cj4+Pj4+Pj4gT24gNC81LzE2LCA0OjA0IFBNLCAic3RpciBvbiBiZWhhbGYgb2YgSm9obiBNYXR0 c3NvbiINCj4+Pj4+Pj48c3Rpci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqb2huLm1h dHRzc29uQGVyaWNzc29uLmNvbT4NCj4+Pj4+Pj53cm90ZToNCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBJ IHRoaW5rIHRoYXQgdGhpcyBoYXMgY2hhbmdlZCwgYW5kIHdpbGwgY2hhbmdlIGV2ZW4gbW9yZSB1 bnRpbA0KPj4+Pj4+Pj5TVElSIGlzDQo+Pj4+Pj4+PiBkZXBsb3llZC4gQWNjb3JkaW5nIHRvIG5v dGFyeS5pY3NpLmJlcmtlbGV5LmVkdS8jc3RhdGlzdGljcyAyMyAlDQo+Pj4+Pj4+Pm9mIGFsbA0K Pj4+Pj4+Pj4gVExTIGNvbm5lY3Rpb25zIGFyZSBjdXJyZW50bHkgc2V0dXAgd2l0aCBFQ0RTQSBj ZXJ0aWZpY2F0ZXMuIE9uZQ0KPj4+Pj4+Pj5leGFtcGxlDQo+Pj4+Pj4+PiBpcyBodHRwczovL2Vu Lndpa2lwZWRpYS5vcmcuIEFuZCB3ZSBkb27igJl0IG5lZWQgdW5hbmltb3VzIHN1cHBvcnQNCj4+ Pj4+Pj4+ZnJvbSBhbGwNCj4+Pj4+Pj4+IENBczsgaXQgaXMgZW5vdWdoIHRoYXQgRUNEU0EgY2Vy dGlmaWNhdGVzIGFyZSBmYWlybHkgZWFzeSB0byBnZXQuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IChF ZDI1NTE5IGNlcnRpZmljYXRlcyBhcmUgcHJvYmFibHkgaGFyZCB0byBnZXQgdW5sZXNzIHlvdSBy dW4NCj4+Pj4+Pj4+eW91ciBvd24gQ0EpLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ IEpvaG4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gT24gMDUvMDQvMTYgMTU6MDcsICJQZXRlcnNvbiwg Sm9uIiA8am9uLnBldGVyc29uQG5ldXN0YXIuYml6Pg0KPj4+Pj4+Pj53cm90ZToNCj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+IFRvIGRhdGUgd2UgaGF2ZSBub3QgbW92ZWQgdGhpcyB0byBFQyBiZWNhdXNl IChhdCBsZWFzdCBhcyBmYXIgYXMNCj4+Pj4+Pj4+PkkNCj4+Pj4+Pj4+PiB1bmRlcnN0YW5kIHRo aW5ncykgbWFueSBlbGVtZW50cyBvZiB3ZWIgUEtJLCBpbmNsdWRpbmcgbWFueSBDQXMsDQo+Pj4+ Pj4+Pj5kb24ndA0KPj4+Pj4+Pj4+IHN1cHBvcnQgdGhlc2UgYWxnb3JpdGhtcyB5ZXQuIElmIG91 ciBhc3Nlc3NtZW50IG9mIHRoYXQgaXMNCj4+Pj4+Pj4+PmNoYW5naW5nLCB0aGVuDQo+Pj4+Pj4+ Pj4gbGV0J3MgcmV2aXNpdCBpdC4NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBKb24gUGV0ZXJzb24N Cj4+Pj4+Pj4+PiBOZXVzdGFyLCBJbmMuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gU2VudCBmcm9t IG15IGlQYWQNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gT24gQXByIDUsIDIwMTYsIGF0IDExOjM3 IEFNLCBKb2huIE1hdHRzc29uDQo+Pj4+Pj4+Pj4+PGpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29t Pg0KPj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IEkgdGhpbmsgdGhl cmUgYXJlIHNldmVyYWwgc3Ryb25nIHJlYXNvbnMgdG8gY2hhbmdlIHRoZSBkZWZhdWx0DQo+Pj4+ Pj4+Pj4+c2lnbmF0dXJlDQo+Pj4+Pj4+Pj4+IGFsZ29yaXRobSBpbiBkcmFmdC1pZXRmLXN0aXIt cmZjNDQ3NGJpcyBhbmQNCj4+Pj4+Pj4+Pj5kcmFmdC1pZXRmLXN0aXItcGFzc3BvcnQuDQo+Pj4+ Pj4+Pj4+IFRoZQ0KPj4+Pj4+Pj4+PiBjdXJyZW50IGRlZmF1bHQgYWxnb3JpdGhtIGlzIFJTMjU2 IChSU0FTU0EtUEtDUzEtdjFfNSB1c2luZw0KPj4+Pj4+Pj4+PlNIQS0yNTYpLA0KPj4+Pj4+Pj4+ PiBidXQNCj4+Pj4+Pj4+Pj4gSSBjYW5ub3QgZmluZCBhbnkgbnVtYmVyIGZvciBNVEkvUmVjb21t ZW5kZWQvTWluaW11bS9EZWZhdWx0DQo+Pj4+Pj4+Pj4+a2V5IGxlbmd0aC4NCj4+Pj4+Pj4+Pj4g DQo+Pj4+Pj4+Pj4+IDEuIFJTQSBzaWduaW5nIGlzIGV4dHJlbWVseSBzbG93IGNvbXBhcmVkIHRv IG1vZGVybg0KPj4+Pj4+Pj4+PmFsdGVybmF0aXZlcy4gT24gYQ0KPj4+Pj4+Pj4+PiBDb3JlIGk1 LTY2MDAsIEVTMjU2IChFQ0RTQSB1c2luZyBQLTI1NiBhbmQgU0hBLTI1NikgaXMgMjEgdGltZXMN Cj4+Pj4+Pj4+Pj5mYXN0ZXINCj4+Pj4+Pj4+Pj4gdGhhbiBSU0EtMjA0OCwgYW5kIEVkMjU1MTkg aXMgNjcgdGltZXMgZmFzdGVyDQo+Pj4+Pj4+Pj4+IChodHRwczovL2JlbmNoLmNyLnlwLnRvL3Jl c3VsdHMtc2lnbi5odG1sKS4gQXMgUlNBLTIwNDggaXMNCj4+Pj4+Pj4+Pj5ub3JtYWxseQ0KPj4+ Pj4+Pj4+PiBjbGFzc2lmaWVkIGFzIHJvdWdobHkgMTEyLWJpdCBzZWN1cml0eSAoUkZDMzc2Niwg TklTVCwgRU5JU0EpLA0KPj4+Pj4+Pj4+PmEgbW9yZQ0KPj4+Pj4+Pj4+PiBmYWlyDQo+Pj4+Pj4+ Pj4+IGNvbXBhcmlzb24gaXMgd2l0aCBSU0EtMzA3MiwgYW5kIHRoZW4gRVMyNTYgaXMgNTIgdGlt ZXMgZmFzdGVyDQo+Pj4+Pj4+Pj4+YW5kDQo+Pj4+Pj4+Pj4+IEVkMjU1MTkNCj4+Pj4+Pj4+Pj4g aXMgMTY5IHRpbWVzIGZhc3Rlci4NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IDIuIFJTQSBzaWdu YXR1cmVzIGFyZSBtdWNoIGxhcmdlciB0aGFuIHRoZWlyIEVDQyBjb3VudGVycGFydHMuDQo+Pj4+ Pj4+Pj4+UlNBLTIwNDgNCj4+Pj4+Pj4+Pj4gc2lnbmF0dXJlcyBhcmUgMjU2IGJ5dGVzIGFuZCBS U0EtMzA3MiBzaWduYXR1cmVzIGFyZSAzODQgYnl0ZXMsDQo+Pj4+Pj4+Pj4+d2hpbGUNCj4+Pj4+ Pj4+Pj4gRVMyNTYgYW5kIEVkMjU1MTkgc2lnbmF0dXJlcyBhcmUgb25seSA2NCBieXRlcy4NCj4+ Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IDMuIFBLQ1MxLXYxXzUgaXMgbm90IGEgdmVyeSBnb29kIGFs Z29yaXRobS4gSXQgaGFzIG5vIHNlY3VyaXR5DQo+Pj4+Pj4+Pj4+cHJvb2ZzLA0KPj4+Pj4+Pj4+ PiBubw0KPj4+Pj4+Pj4+PiBhZHZhbnRhZ2VzLCBpcyBkaXNyZWNvbW1lbmRlZCBieSBFTklTQSAo RXVyb3BlYW4gVW5pb24gQWdlbmN5DQo+Pj4+Pj4+Pj4+Zm9yDQo+Pj4+Pj4+Pj4+IE5ldHdvcmsN Cj4+Pj4+Pj4+Pj4gYW5kIEluZm9ybWF0aW9uIFNlY3VyaXR5KSwgYW5kIGhhcyBiZWVuIHJlcGxh Y2VkIGluIFRMUyAxLjMuIEkNCj4+Pj4+Pj4+Pj5kbyBub3QNCj4+Pj4+Pj4+Pj4gdGhpbmsgdGhp cyBpcyB0aGUgYWxnb3JpdGhtIHdlIHNob3VsZCB1c2UgaW4gU1RJUi4NCj4+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4+IEkgdGhpbmsgdGhlIHJpZ2h0IGFsZ29yaXRobSBjaG9pY2UgZm9yIFNUSVIgaXMg RVMyNTYgb3IgRWQyNTUxOS4NCj4+Pj4+Pj4+Pj4gU2lnbmF0dXJlIHByb2Nlc3NpbmcgaXMgbGlr ZWx5IHRoZSBtYWluIGJ1cmRlbiBmb3IgdGhlDQo+Pj4+Pj4+Pj4+QXV0aGVudGljYXRpb24NCj4+ Pj4+Pj4+Pj4gU2VydmljZSwgYW5kIGNoYW5naW5nIGZyb20gUlNBIHRvIEVDQyBzaWduaWZpY2Fu dGx5IHJlZHVjZXMgdGhlDQo+Pj4+Pj4+Pj4+YW1vdW50DQo+Pj4+Pj4+Pj4+IG9mDQo+Pj4+Pj4+ Pj4+IGhhcmR3YXJlIG5lZWRlZCwgYW5kIHRoZXJlZm9yZSB0aGUgY29zdC4gQSBzaW5nbGUgMy4z IEdoeg0KPj4+Pj4+Pj4+PlNreWxha2UgY29yZQ0KPj4+Pj4+Pj4+PiBjYW4NCj4+Pj4+Pj4+Pj4g ZG8gb25seSA0MDAgUlNBLTMwNzIgb3IgMSwwMDAgUlNBLTIwNDggc2lnbmF0dXJlcyBwZXIgc2Vj b25kLA0KPj4+Pj4+Pj4+PmJ1dCAyMSwwMDANCj4+Pj4+Pj4+Pj4gRVMyNTYgb3IgNjgsMDAwIEVk MjU1MTkgc2lnbmF0dXJlcyBwZXIgc2Vjb25kLiBSU0EgdmVyaWZpY2F0aW9uDQo+Pj4+Pj4+Pj4+ aXMgYSBiaXQNCj4+Pj4+Pj4+Pj4gZmFzdGVyIHRoYW4gRUNDLCBidXQgdGhlIGRpZmZlcmVudCBp cyBtdWNoIHNtYWxsZXIgdGhhdCBmb3INCj4+Pj4+Pj4+Pj5zaWduaW5nLA0KPj4+Pj4+Pj4+PiBS U0EtMzA3MiB2ZXJpZmljYXRpb25zIGFyZSBlLmcuIHR3aWNlIGFzIGZhc3QgYXMgRWQyNTUxOQ0K Pj4+Pj4+Pj4+PnZlcmlmaWNhdGlvbnMuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBDaGVlcnMs DQo+Pj4+Pj4+Pj4+IEpvaG4NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pj4+Pi0NCj4+Pj4+Pj4+Pj4gSk9ITiBNQVRUU1NP Tg0KPj4+Pj4+Pj4+PiBNU2MgRW5naW5lZXJpbmcgUGh5c2ljcywgTVNjIEJ1c2luZXNzIEFkbWlu aXN0cmF0aW9uIGFuZA0KPj4+Pj4+Pj4+PkVjb25vbWljcw0KPj4+Pj4+Pj4+PiBFcmljc3NvbiBJ RVRGIFNlY3VyaXR5IENvb3JkaW5hdG9yDQo+Pj4+Pj4+Pj4+IFNlbmlvciBSZXNlYXJjaGVyLCBT ZWN1cml0eQ0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+Pj4gc3RpciBtYWlsaW5nIGxpc3QNCj4+ Pj4+Pj4+Pj4gc3RpckBpZXRmLm9yZw0KPj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3N0aXINCj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+PiBzdGlyIG1haWxpbmcgbGlzdA0KPj4+Pj4+ Pj4gc3RpckBpZXRmLm9yZw0KPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zdGlyDQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+Pj4+IHN0aXIgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IHN0aXJAaWV0 Zi5vcmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGly DQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+PiBzdGlyIG1haWxpbmcgbGlzdA0KPj4+Pj4+IHN0aXJAaWV0Zi5vcmcNCj4+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBzdGlyIG1haWxp bmcgbGlzdA0KPj4+Pj4gc3RpckBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zdGlyDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBzdGlyIG1haWxpbmcgbGlzdA0KPj4+PiBz dGlyQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3Rpcg0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4gc3RpciBtYWlsaW5nIGxpc3QNCj4+PiBzdGlyQGlldGYub3JnDQo+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQo+Pg0KPg0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c3RpciBtYWlsaW5nIGxp c3QNCj5zdGlyQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zdGlyDQoNCg== From nobody Tue Apr 12 09:31:43 2016 Return-Path: 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 D964412E4FC for ; Tue, 12 Apr 2016 09:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: 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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 3EW8RBUKYPAX for ; Tue, 12 Apr 2016 09:31:37 -0700 (PDT) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF7E12E0F1 for ; Tue, 12 Apr 2016 09:31:37 -0700 (PDT) Received: by mail-qk0-x241.google.com with SMTP id u190so424105qkh.2 for ; Tue, 12 Apr 2016 09:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Fm6zunkzBrdvDmjYdvt/EatyeoUVTSLbgM+oldG+yQ8=; b=dqIeG2KQAk28uKvX2zTIfwoJV0Z4obf3qy5IxKyiL5FODqpDGuWKSixaXm4iV0mOly 0n5dvHaT+FTHkX/7Uzgnclx/XlyBbF32H9b3QIxJB7MfBLGFPoW52Rwz+RwkFKCgqd7I h27Aomwrhu/agIZT9GptANmTW/oS+PAjH/V4eoCpaF2nhByF6RIPDmQoDggXXbyPRlBt BqzdABkWcKZPPhQr3R9CjX5nSq1jjcJpngb98J3mkkALRwKTcRHGU/QIsu4Qnj2cYJBw 0Hd0fKrzMhxZn7mbyNzlmVJ1CMgrIfqSPhzeXt7ksp3JKcZ7//ZChvYNYLlW0QhIMW5k /FRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Fm6zunkzBrdvDmjYdvt/EatyeoUVTSLbgM+oldG+yQ8=; b=KomnRcN+Hp0Ka5tnc7CntDZ2Hitsf7YybCZ5AA+caCJRyIl21g2xkO0Ug0kSp+4exg lUf7Blkpr98HrFl8VNp6s9XLqK9FGbmh5l52vrp5fox2oC9oUaWk/FuI4foK5YR5zcI3 wLfWYz3GZHpbPZpVx/sFc74ZYeQLu5Dch+zc0O20xs0rV80NKD6s04CKSq/63KRCCSD4 j2/gKRLBc1LHKgdD51fLcVSsRa0MPaYe7QGc+PTGaLnpjQL3GaBmatzrxoaQgE8l3YTl l95OhTFD3cVnWDnfdPC2UERmVGhBqq2vE+l2Lhxh9BGizWsf673PdCf4cHodHz+codv8 hP6w== X-Gm-Message-State: AOPr4FUSmsv+TFwGFvoJhgYqKDjs144kLuv/ETGIbUi5ryv9Ey+cbWzJ1EKM0BJQtL06Kw== X-Received: by 10.55.75.14 with SMTP id y14mr4866355qka.33.1460478696328; Tue, 12 Apr 2016 09:31:36 -0700 (PDT) Received: from [10.188.221.13] ([38.123.136.254]) by smtp.gmail.com with ESMTPSA id o75sm3219587qke.17.2016.04.12.09.31.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Apr 2016 09:31:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chris Wendt In-Reply-To: Date: Tue, 12 Apr 2016 12:31:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <0DD82221-E79D-4F15-B2B5-93165EC98919@shockey.us> <570534D4.6010707@nostrum.com> <5195FEBC-8395-4E77-B768-2B2D81144121@shockey.us> <56DF2D20-9381-45CB-8057-6B1AB99B05E9@chriswendt.net> To: John Mattsson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Tue, 12 Apr 2016 16:31:41 -0000 Hi John, I=E2=80=99d be happy to get RS256 and ES256 with a preference to the = later. To add PS256, i=E2=80=99d defer to others opinions. RS256 has a simple advantage that it=E2=80=99s commonly implemented in = most JWT libraries today. But that=E2=80=99s not necessarily a a great = justification. Beyond that, particularly after creating some example tokens and seeing = the very compact size of the signature, I have a big preference for = ES256 as the default from the size and CPU advantage, so I=E2=80=99m = less opinionated on PS256 as another option or replacing RS256. Just as a preview: ES256 based token: eyJ0eXAiOiJwYXNzcG9ydCIsImFsZyI6IkVTMjU2IiwieDV1IjoiaHR0cHM6Ly9j ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNydCJ9 . eyJpYXQiOiIxNDQzMjA4MzQ1Iiwib3RuIjoiMTIxNTU1NTEyMTIiLCJkdXJpIjoi c2lwOmFsaWNlQGV4YW1wbGUuY29tIn0 . KK89q2RFY-BkKQQhiB0z6-fIaFUy6NDyUboKXOix9XnYLxTCjdw1UHjCbw4CefeK wH_t7W-bnGlZz4pI-rMjfQ RS256 based token: eyJ0eXAiOiJwYXNzcG9ydCIsImFsZyI6IlJTMjU2IiwieDV1IjoiaHR0cHM6Ly9j ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNydCJ9 . eyJpYXQiOiIxNDQzMjA4MzQ1Iiwib3RuIjoiMTIxNTU1NTEyMTIiLCJkdXJpIjoi c2lwOmFsaWNlQGV4YW1wbGUuY29tIn0 . AaeXRqm7kHnkZu2j6cQmDCiomZRiaE55bYWhFgnX8xMqpBFq96M0xgMM5OLa9_LM rkuKv2ivK5GZz8OlFrmAirucRlAh8YdUkj5Cr5xPRr-gg9acD9jqJUnQ-ZxpL1yq -FFVLhvpbsE5NMPHXUp5lpt62rD-S0NlhwHNCeMqZHxt6T5BmZBXITEd1PRRij_6 FhE3wxWEhZMthWJuEbcPpRMZDu-R7lTNddn62nUKjn3s00R3gm25Dto5Z0dzfQpA ysJvnbc1QRimfsYqJPUFc57lnglVLf4WrpeZCc8-LcoXeSr_dseDgsrmg2EuHmn5 h1nTOmLgF16ZHm121ZVjiXz2sMFvs9RaIxw0AFkM7rnV56OxAFCRuzMNldiEVf8p lRZVvqZ4BfVQlCNXNyyVgPOUtNr3ta6yD2H0oANQvvHtwjuSwB9Kruj4Wsu5N7Ik i4MBs6SWJDmcUV-NW_AHYLaao-IvFVe4oCkJNjsqwwXuLv1TO2sDHdc5sQO5zm21 019PPxw1udHVtywsRVNKLo0RzE0TqYUF7XclCDur7MMOx9SnStV2PFIM7Jejyn9x 54RtJEjOnchaSalfIFr_UXqXgVmRZVTzLDQIlcmHjlhhLnCnNx3sYsAANen8Y8jt fgJ2ewjGotB4Lq8VYe1FacBKKk0VyCfImXba0u1hB8Q -Chris > On Apr 11, 2016, at 9:19 AM, John Mattsson = wrote: >=20 > I don=E2=80=99t know why so much of the discussion during the Tuesday = meeting was > about root certificates. As Eric pointed out on the mail, it is not = hard > to get a ECDSA certificate as Digicert, Entrust, Globalising, = Symantec, > Certicom, Comodo, and soon Let=E2=80=99s encrypt will happily give you = one. As > Russ pointed out most (or all) of these ECDSA certificates will be = signed > by a RSA root certificate. But root certificates and verification of = the > credentials seems to be out of scope of STIR and does not affect the > PASSporT object. As far as I understand, the only thing STIR should > specify is verification of the PASSporT object. >=20 > If we mandate RSA in addition to ECC (which I don=E2=80=99t think is = necessary, > but do not oppose), then I think that RS256 (PKCS1-v1_5) is the wrong > algorithm. Both TLS 1.3 (draft-ietf-tls-tls13) and IPSec > (draft-ietf-ipsecme-rfc4307bis) are replacing PKCS1-v1_5 with PSS = (JOSE > alg PS256). If STIR uses RSA, it should do the same. >=20 > If STIR uses RS256 (PKCS1-v1_5) for backward compatibility (which I = don=E2=80=99t > see as necessary as RFC4474 is not deployed) then this should be = clearly > stated, and RS256 (PKCS1-v1_5) should be NOT RECOMMENDED. >=20 >=20 > Cheers, > John >=20 >=20 >=20 > On 07/04/16 21:43, "stir on behalf of Richard Shockey" > wrote: >=20 >>=20 >> On 4/7/16, 8:04 AM, "Chris Wendt" wrote: >>=20 >>> Hi Richard, >>>=20 >>> I=E2=80=99m not sure that is the right perspective to look at this. >>>=20 >>> EC has good properties, especially when it comes to CPU, but also = from >>> it=E2=80=99s cryptographic strength. I care a lot about the CPU = part, from a >>> cost point of view, so i think that is number 1 priority. >>=20 >> ca >> RS> Of course there is no argument about that. In a US/CA NANP = carrier >> implementation environment I would assume its mandated. If you = started to >> look at how a NANP STIR RFP would be constructed you would put severe >> constraints on options. And on costs.. Well no one, certainly not = your >> employer, is going to pay 500M a year for this or even 140M if you = know >> what I mean. :-)=20 >>=20 >>=20 >>=20 >>>=20 >>> But, RSA256 is there today as most commonly used, so it=E2=80=99s = hard to not >>> include. >>=20 >>=20 >> RS> MUST support but do not mandate implementation. We=E2=80=99ll = deal with that >> when we start to look at the national specific deployment options. = Chris >> what I want to see is a protocol and nothing else. Please insert >> implementable examples in the drafts. Where do you see this in the = INVITE >> with actually examples. I will raise hell if I don=E2=80=99t see = this in the >> future. Jon=E2=80=99s draft is rhetoric and nothing else it is non = implementable. >>=20 >>=20 >>>=20 >>> I think the consensus was that RSA256 comes mostly free in many of = the >>> likely implementations out there. >>>=20 >>> I would argue EC does as well, but i=E2=80=99ll give the benefit of = the doubt to >>> say, not everyone is completely comfortable with it or may need some >>> more time to have a production grade implementation perhaps. >>=20 >> RS> I still think the TLS issue in SIPConnect is applicable. The IETF = can >> bark all it wants but in the end if the industry will not support it = will >> not deploy and there is way too much ideology and political = correctness >> in the way some protocols are developed. >>=20 >>=20 >>>=20 >>> We do need to recognize that as time goes on, the best practice will >>> change so the number of algorithms will follow a similar path that = the >>> TLS world is dealing with, so this isn=E2=80=99t the end of the = story either. >>=20 >>=20 >> RS> Agreed but STIR with your new concepts has a great chance of = actually >> deploying. Do not burden it by defining constraints you know our = industry >> will not accept.=20 >>=20 >>=20 >>>=20 >>> Two MTI today, likely more tomorrow, or deprecated algorithms as = well. >>>=20 >>> This is reality, so let=E2=80=99s look at it more in that light. >>>=20 >>> -Chris >>>=20 >>>=20 >>>> On Apr 6, 2016, at 10:11 PM, Richard Shockey >>>> wrote: >>>>=20 >>>>=20 >>>>=20 >>>> Implement is one thing, must use in verification is another. I = won=E2=80=99t >>>> support MUST be able to verify. >>>>=20 >>>> This is shaping up to be another TLS food fight re SIP PBX=E2=80=99s = and the >>>> carriers re SIP Connect and we all know where that went. Nowhere. = Must >>>> support use ..well maybe. >>>>=20 >>>>=20 >>>> =E2=80=94=20 >>>> Richard Shockey >>>> Shockey Consulting LLC >>>> Chairman of the Board SIP Forum >>>> www.shockey.us >>>> www.sipforum.org >>>> richardshockey.us >>>> Skype-Linkedin-Facebook rshockey101 >>>> PSTN +1 703-593-2683 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 4/6/16, 12:09 PM, "stir on behalf of Robert Sparks" >>>> wrote: >>>>=20 >>>>> To be clear, the suggestion is must implement, not must use. >>>>> Specifically, for _this_ part of the conversation, its that the = code >>>>> in=20 >>>>> a verifier must be _able_ to verify presented with either. >>>>>=20 >>>>>=20 >>>>> On 4/5/16 7:47 PM, Richard Shockey wrote: >>>>>> Well I would have to insist that such a statement is SHOULD = verify, >>>>>> either or both, how it deploys and under what conditions are = still >>>>>> probably a nation-state matter certainly if they are used with = E.164 >>>>>> plan. >>>>>>=20 >>>>>>=20 >>>>>> On 4/5/16, 5:55 PM, "stir on behalf of Russ Housley" >>>>>> wrote: >>>>>>=20 >>>>>>> There was just a discussion of this point in the STIR session at >>>>>>> IETF 95. The sense of the room is to require verification of = both >>>>>>> RSA and ECC signatures. This allows the use of existing >>>>>>> infrastructure, and allows rapid movement to ECC as soon as that >>>>>>> infrastructure is readily available >>>>>>>=20 >>>>>>> Russ >>>>>>>=20 >>>>>>>=20 >>>>>>> On Apr 5, 2016, at 4:46 PM, Richard Shockey >>>>>>> wrote: >>>>>>>=20 >>>>>>>> And on a nation state basis my assumption would be that = something >>>>>>>> like ECC256 would be a requirement for the computational load >>>>>>>> factor if nothing else. >>>>>>>>=20 >>>>>>>> Its certainly how I would write a STIR RFP for a CA if this = were >>>>>>>> for the carriers in the NANP. Setting one or two SHOULD = supports >>>>>>>> seem sensible. I would not set the requirement to MUST. >>>>>>>>=20 >>>>>>>> =E2=80=94 >>>>>>>> Richard Shockey >>>>>>>> Shockey Consulting LLC >>>>>>>> Chairman of the Board SIP Forum >>>>>>>> www.shockey.us >>>>>>>> www.sipforum.org >>>>>>>> richardshockey.us >>>>>>>> Skype-Linkedin-Facebook rshockey101 >>>>>>>> PSTN +1 703-593-2683 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 4/5/16, 4:04 PM, "stir on behalf of John Mattsson" >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> I think that this has changed, and will change even more until >>>>>>>>> STIR is >>>>>>>>> deployed. According to notary.icsi.berkeley.edu/#statistics 23 = % >>>>>>>>> of all >>>>>>>>> TLS connections are currently setup with ECDSA certificates. = One >>>>>>>>> example >>>>>>>>> is https://en.wikipedia.org. And we don=E2=80=99t need = unanimous support >>>>>>>>> from all >>>>>>>>> CAs; it is enough that ECDSA certificates are fairly easy to = get. >>>>>>>>>=20 >>>>>>>>> (Ed25519 certificates are probably hard to get unless you run >>>>>>>>> your own CA). >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> John >>>>>>>>>=20 >>>>>>>>> On 05/04/16 15:07, "Peterson, Jon" >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> To date we have not moved this to EC because (at least as far = as >>>>>>>>>> I >>>>>>>>>> understand things) many elements of web PKI, including many = CAs, >>>>>>>>>> don't >>>>>>>>>> support these algorithms yet. If our assessment of that is >>>>>>>>>> changing, then >>>>>>>>>> let's revisit it. >>>>>>>>>>=20 >>>>>>>>>> Jon Peterson >>>>>>>>>> Neustar, Inc. >>>>>>>>>>=20 >>>>>>>>>> Sent from my iPad >>>>>>>>>>=20 >>>>>>>>>>> On Apr 5, 2016, at 11:37 AM, John Mattsson >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> I think there are several strong reasons to change the = default >>>>>>>>>>> signature >>>>>>>>>>> algorithm in draft-ietf-stir-rfc4474bis and >>>>>>>>>>> draft-ietf-stir-passport. >>>>>>>>>>> The >>>>>>>>>>> current default algorithm is RS256 (RSASSA-PKCS1-v1_5 using >>>>>>>>>>> SHA-256), >>>>>>>>>>> but >>>>>>>>>>> I cannot find any number for MTI/Recommended/Minimum/Default >>>>>>>>>>> key length. >>>>>>>>>>>=20 >>>>>>>>>>> 1. RSA signing is extremely slow compared to modern >>>>>>>>>>> alternatives. On a >>>>>>>>>>> Core i5-6600, ES256 (ECDSA using P-256 and SHA-256) is 21 = times >>>>>>>>>>> faster >>>>>>>>>>> than RSA-2048, and Ed25519 is 67 times faster >>>>>>>>>>> (https://bench.cr.yp.to/results-sign.html). As RSA-2048 is >>>>>>>>>>> normally >>>>>>>>>>> classified as roughly 112-bit security (RFC3766, NIST, = ENISA), >>>>>>>>>>> a more >>>>>>>>>>> fair >>>>>>>>>>> comparison is with RSA-3072, and then ES256 is 52 times = faster >>>>>>>>>>> and >>>>>>>>>>> Ed25519 >>>>>>>>>>> is 169 times faster. >>>>>>>>>>>=20 >>>>>>>>>>> 2. RSA signatures are much larger than their ECC = counterparts. >>>>>>>>>>> RSA-2048 >>>>>>>>>>> signatures are 256 bytes and RSA-3072 signatures are 384 = bytes, >>>>>>>>>>> while >>>>>>>>>>> ES256 and Ed25519 signatures are only 64 bytes. >>>>>>>>>>>=20 >>>>>>>>>>> 3. PKCS1-v1_5 is not a very good algorithm. It has no = security >>>>>>>>>>> proofs, >>>>>>>>>>> no >>>>>>>>>>> advantages, is disrecommended by ENISA (European Union = Agency >>>>>>>>>>> for >>>>>>>>>>> Network >>>>>>>>>>> and Information Security), and has been replaced in TLS 1.3. = I >>>>>>>>>>> do not >>>>>>>>>>> think this is the algorithm we should use in STIR. >>>>>>>>>>>=20 >>>>>>>>>>> I think the right algorithm choice for STIR is ES256 or = Ed25519. >>>>>>>>>>> Signature processing is likely the main burden for the >>>>>>>>>>> Authentication >>>>>>>>>>> Service, and changing from RSA to ECC significantly reduces = the >>>>>>>>>>> amount >>>>>>>>>>> of >>>>>>>>>>> hardware needed, and therefore the cost. A single 3.3 Ghz >>>>>>>>>>> Skylake core >>>>>>>>>>> can >>>>>>>>>>> do only 400 RSA-3072 or 1,000 RSA-2048 signatures per = second, >>>>>>>>>>> but 21,000 >>>>>>>>>>> ES256 or 68,000 Ed25519 signatures per second. RSA = verification >>>>>>>>>>> is a bit >>>>>>>>>>> faster than ECC, but the different is much smaller that for >>>>>>>>>>> signing, >>>>>>>>>>> RSA-3072 verifications are e.g. twice as fast as Ed25519 >>>>>>>>>>> verifications. >>>>>>>>>>>=20 >>>>>>>>>>> Cheers, >>>>>>>>>>> John >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> = ----------------------------------------------------------------- >>>>>>>>>>> - >>>>>>>>>>> JOHN MATTSSON >>>>>>>>>>> MSc Engineering Physics, MSc Business Administration and >>>>>>>>>>> Economics >>>>>>>>>>> Ericsson IETF Security Coordinator >>>>>>>>>>> Senior Researcher, Security >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> stir mailing list >>>>>>>>>>> stir@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>> _______________________________________________ >>>>>>>> stir mailing list >>>>>>>> stir@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>> _______________________________________________ >>>>>>> stir mailing list >>>>>>> stir@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >>>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 From nobody Tue Apr 12 13:35:36 2016 Return-Path: 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 871F812D8D9 for ; Tue, 12 Apr 2016 13:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 aVEqj3_wakhK for ; Tue, 12 Apr 2016 13:35:26 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 1F89A12D7E9 for ; Tue, 12 Apr 2016 13:35:26 -0700 (PDT) Received: (qmail 3345 invoked by uid 0); 12 Apr 2016 20:35:24 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy1.mail.unifiedlayer.com with SMTP; 12 Apr 2016 20:35:24 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id hYbH1s0171MNPNq01YbL1t; Tue, 12 Apr 2016 14:35:24 -0600 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=8WrITzYgnNwA:10 a=p-_XEfp0GhYA:10 a=kziv93cY1bsA:10 a=48vgC7mUAAAA:8 a=w1VtefKfAAAA:8 a=0FD05c-RAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=Z80JlwQ0AAAA:8 a=tGX7uwomAAAA:8 a=8pif782wAAAA:8 a=hGBaWAWWAAAA:8 a=MVff1mliAAAA:8 a=0vhXp1a2ptINoiIBi3AA:9 a=6bONJYkkPyJeyrc5:21 a=gA5azET7QJtY3MYt:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=6-C5ikvthBEA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:CC:To:From:Subject:Date; bh=O3VV1tFzPKABVVMcopFiSXkZEuaGtmSBSYJt8ddmJiQ=; b=WryQfuhqDXBScsrzIF6iJV38xg Oa3CvaKzFdlrFE7mVtZveiZZpgGVKa/VtnfXWULNVH3Pz6Qh4FTrK8TlvR3QGYDRzfYjOwGtiTOvM WQhf/plFsT2yGHKuij3LZCMAi; Received: from [100.36.35.60] (port=57076 helo=[192.168.1.9]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1aq51p-0006UT-CU; Tue, 12 Apr 2016 14:35:17 -0600 User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Tue, 12 Apr 2016 16:35:09 -0400 From: Richard Shockey To: Chris Wendt , John Mattsson Message-ID: <56652A44-7ED0-4F57-A071-93FA48FA0DE4@shockey.us> Thread-Topic: [stir] Choice of STIR signature algorithm References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <0DD82221-E79D-4F15-B2B5-93165EC98919@shockey.us> <570534D4.6010707@nostrum.com> <5195FEBC-8395-4E77-B768-2B2D81144121@shockey.us> <56DF2D20-9381-45CB-8057-6B1AB99B05E9@chriswendt.net> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> In-Reply-To: <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.35.60 authed with richard+shockey.us} Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Tue, 12 Apr 2016 20:35:34 -0000 Excellent discussion. But what I will insist on in further draft revisions= is less rhetoric and more implementation examples. Do this .. look for that= . Were working on how to display the data to the UA>=20 We have to show where in the INVITE this stuff SHOULD be inserted and what = it might look like to give guidance to implementers on what to look for. The= rest is policy and we are not going there .not now not ever.=20 I could care less about root CA issues since no one in the IETF is going to= decide those problems if target address involves E.164 within national boun= dries. No one is going to tell the US, British, Swedish or French government= s how the plan to secure their voice networks. The body of law here is indis= putable.=20 On 4/12/16, 12:31 PM, "stir on behalf of Chris Wendt" wrote: >Hi John, > >I=E2=80=99d be happy to get RS256 and ES256 with a preference to the later. > >To add PS256, i=E2=80=99d defer to others opinions. > >RS256 has a simple advantage that it=E2=80=99s commonly implemented in most JWT = libraries today. But that=E2=80=99s not necessarily a a great justification. > >Beyond that, particularly after creating some example tokens and seeing th= e very compact size of the signature, I have a big preference for ES256 as t= he default from the size and CPU advantage, so I=E2=80=99m less opinionated on PS2= 56 as another option or replacing RS256. > >Just as a preview: > >ES256 based token: >eyJ0eXAiOiJwYXNzcG9ydCIsImFsZyI6IkVTMjU2IiwieDV1IjoiaHR0cHM6Ly9j >ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNydCJ9 >. >eyJpYXQiOiIxNDQzMjA4MzQ1Iiwib3RuIjoiMTIxNTU1NTEyMTIiLCJkdXJpIjoi >c2lwOmFsaWNlQGV4YW1wbGUuY29tIn0 >. >KK89q2RFY-BkKQQhiB0z6-fIaFUy6NDyUboKXOix9XnYLxTCjdw1UHjCbw4CefeK >wH_t7W-bnGlZz4pI-rMjfQ > >RS256 based token: >eyJ0eXAiOiJwYXNzcG9ydCIsImFsZyI6IlJTMjU2IiwieDV1IjoiaHR0cHM6Ly9j >ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNydCJ9 >. >eyJpYXQiOiIxNDQzMjA4MzQ1Iiwib3RuIjoiMTIxNTU1NTEyMTIiLCJkdXJpIjoi >c2lwOmFsaWNlQGV4YW1wbGUuY29tIn0 >. >AaeXRqm7kHnkZu2j6cQmDCiomZRiaE55bYWhFgnX8xMqpBFq96M0xgMM5OLa9_LM >rkuKv2ivK5GZz8OlFrmAirucRlAh8YdUkj5Cr5xPRr-gg9acD9jqJUnQ-ZxpL1yq >-FFVLhvpbsE5NMPHXUp5lpt62rD-S0NlhwHNCeMqZHxt6T5BmZBXITEd1PRRij_6 >FhE3wxWEhZMthWJuEbcPpRMZDu-R7lTNddn62nUKjn3s00R3gm25Dto5Z0dzfQpA >ysJvnbc1QRimfsYqJPUFc57lnglVLf4WrpeZCc8-LcoXeSr_dseDgsrmg2EuHmn5 >h1nTOmLgF16ZHm121ZVjiXz2sMFvs9RaIxw0AFkM7rnV56OxAFCRuzMNldiEVf8p >lRZVvqZ4BfVQlCNXNyyVgPOUtNr3ta6yD2H0oANQvvHtwjuSwB9Kruj4Wsu5N7Ik >i4MBs6SWJDmcUV-NW_AHYLaao-IvFVe4oCkJNjsqwwXuLv1TO2sDHdc5sQO5zm21 >019PPxw1udHVtywsRVNKLo0RzE0TqYUF7XclCDur7MMOx9SnStV2PFIM7Jejyn9x >54RtJEjOnchaSalfIFr_UXqXgVmRZVTzLDQIlcmHjlhhLnCnNx3sYsAANen8Y8jt >fgJ2ewjGotB4Lq8VYe1FacBKKk0VyCfImXba0u1hB8Q > >-Chris > >> On Apr 11, 2016, at 9:19 AM, John Mattsson = wrote: >>=20 >> I don=E2=80=99t know why so much of the discussion during the Tuesday meeting = was >> about root certificates. As Eric pointed out on the mail, it is not hard >> to get a ECDSA certificate as Digicert, Entrust, Globalising, Symantec, >> Certicom, Comodo, and soon Let=E2=80=99s encrypt will happily give you one. As >> Russ pointed out most (or all) of these ECDSA certificates will be signe= d >> by a RSA root certificate. But root certificates and verification of the >> credentials seems to be out of scope of STIR and does not affect the >> PASSporT object. As far as I understand, the only thing STIR should >> specify is verification of the PASSporT object. >>=20 >> If we mandate RSA in addition to ECC (which I don=E2=80=99t think is necessary= , >> but do not oppose), then I think that RS256 (PKCS1-v1_5) is the wrong >> algorithm. Both TLS 1.3 (draft-ietf-tls-tls13) and IPSec >> (draft-ietf-ipsecme-rfc4307bis) are replacing PKCS1-v1_5 with PSS (JOSE >> alg PS256). If STIR uses RSA, it should do the same. >>=20 >> If STIR uses RS256 (PKCS1-v1_5) for backward compatibility (which I don=E2= =80=99t >> see as necessary as RFC4474 is not deployed) then this should be clearly >> stated, and RS256 (PKCS1-v1_5) should be NOT RECOMMENDED. >>=20 >>=20 >> Cheers, >> John >>=20 >>=20 >>=20 >> On 07/04/16 21:43, "stir on behalf of Richard Shockey" >> wrote: >>=20 >>>=20 >>> On 4/7/16, 8:04 AM, "Chris Wendt" wrote: >>>=20 >>>> Hi Richard, >>>>=20 >>>> I=E2=80=99m not sure that is the right perspective to look at this. >>>>=20 >>>> EC has good properties, especially when it comes to CPU, but also from >>>> it=E2=80=99s cryptographic strength. I care a lot about the CPU part, from = a >>>> cost point of view, so i think that is number 1 priority. >>>=20 >>> ca >>> RS> Of course there is no argument about that. In a US/CA NANP carrier >>> implementation environment I would assume its mandated. If you started = to >>> look at how a NANP STIR RFP would be constructed you would put severe >>> constraints on options. And on costs.. Well no one, certainly not your >>> employer, is going to pay 500M a year for this or even 140M if you kno= w >>> what I mean. :-)=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> But, RSA256 is there today as most commonly used, so it=E2=80=99s hard to no= t >>>> include. >>>=20 >>>=20 >>> RS> MUST support but do not mandate implementation. We=E2=80=99ll deal with t= hat >>> when we start to look at the national specific deployment options. Chri= s >>> what I want to see is a protocol and nothing else. Please insert >>> implementable examples in the drafts. Where do you see this in the INVI= TE >>> with actually examples. I will raise hell if I don=E2=80=99t see this in the >>> future. Jon=E2=80=99s draft is rhetoric and nothing else it is non implementa= ble. >>>=20 >>>=20 >>>>=20 >>>> I think the consensus was that RSA256 comes mostly free in many of the >>>> likely implementations out there. >>>>=20 >>>> I would argue EC does as well, but i=E2=80=99ll give the benefit of the doub= t to >>>> say, not everyone is completely comfortable with it or may need some >>>> more time to have a production grade implementation perhaps. >>>=20 >>> RS> I still think the TLS issue in SIPConnect is applicable. The IETF c= an >>> bark all it wants but in the end if the industry will not support it wi= ll >>> not deploy and there is way too much ideology and political correctness >>> in the way some protocols are developed. >>>=20 >>>=20 >>>>=20 >>>> We do need to recognize that as time goes on, the best practice will >>>> change so the number of algorithms will follow a similar path that the >>>> TLS world is dealing with, so this isn=E2=80=99t the end of the story either= . >>>=20 >>>=20 >>> RS> Agreed but STIR with your new concepts has a great chance of actual= ly >>> deploying. Do not burden it by defining constraints you know our indust= ry >>> will not accept.=20 >>>=20 >>>=20 >>>>=20 >>>> Two MTI today, likely more tomorrow, or deprecated algorithms as well. >>>>=20 >>>> This is reality, so let=E2=80=99s look at it more in that light. >>>>=20 >>>> -Chris >>>>=20 >>>>=20 >>>>> On Apr 6, 2016, at 10:11 PM, Richard Shockey >>>>> wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Implement is one thing, must use in verification is another. I won=E2=80= =99t >>>>> support MUST be able to verify. >>>>>=20 >>>>> This is shaping up to be another TLS food fight re SIP PBX=E2=80=99s and th= e >>>>> carriers re SIP Connect and we all know where that went. Nowhere. Mus= t >>>>> support use ..well maybe. >>>>>=20 >>>>>=20 >>>>> =E2=80=94=20 >>>>> Richard Shockey >>>>> Shockey Consulting LLC >>>>> Chairman of the Board SIP Forum >>>>> www.shockey.us >>>>> www.sipforum.org >>>>> richardshockey.us >>>>> Skype-Linkedin-Facebook rshockey101 >>>>> PSTN +1 703-593-2683 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 4/6/16, 12:09 PM, "stir on behalf of Robert Sparks" >>>>> wrote: >>>>>=20 >>>>>> To be clear, the suggestion is must implement, not must use. >>>>>> Specifically, for _this_ part of the conversation, its that the code >>>>>> in=20 >>>>>> a verifier must be _able_ to verify presented with either. >>>>>>=20 >>>>>>=20 >>>>>> On 4/5/16 7:47 PM, Richard Shockey wrote: >>>>>>> Well I would have to insist that such a statement is SHOULD verify, >>>>>>> either or both, how it deploys and under what conditions are still >>>>>>> probably a nation-state matter certainly if they are used with E.16= 4 >>>>>>> plan. >>>>>>>=20 >>>>>>>=20 >>>>>>> On 4/5/16, 5:55 PM, "stir on behalf of Russ Housley" >>>>>>> wrote: >>>>>>>=20 >>>>>>>> There was just a discussion of this point in the STIR session at >>>>>>>> IETF 95. The sense of the room is to require verification of both >>>>>>>> RSA and ECC signatures. This allows the use of existing >>>>>>>> infrastructure, and allows rapid movement to ECC as soon as that >>>>>>>> infrastructure is readily available >>>>>>>>=20 >>>>>>>> Russ >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Apr 5, 2016, at 4:46 PM, Richard Shockey >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> And on a nation state basis my assumption would be that something >>>>>>>>> like ECC256 would be a requirement for the computational load >>>>>>>>> factor if nothing else. >>>>>>>>>=20 >>>>>>>>> Its certainly how I would write a STIR RFP for a CA if this were >>>>>>>>> for the carriers in the NANP. Setting one or two SHOULD supports >>>>>>>>> seem sensible. I would not set the requirement to MUST. >>>>>>>>>=20 >>>>>>>>> =E2=80=94 >>>>>>>>> Richard Shockey >>>>>>>>> Shockey Consulting LLC >>>>>>>>> Chairman of the Board SIP Forum >>>>>>>>> www.shockey.us >>>>>>>>> www.sipforum.org >>>>>>>>> richardshockey.us >>>>>>>>> Skype-Linkedin-Facebook rshockey101 >>>>>>>>> PSTN +1 703-593-2683 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 4/5/16, 4:04 PM, "stir on behalf of John Mattsson" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> I think that this has changed, and will change even more until >>>>>>>>>> STIR is >>>>>>>>>> deployed. According to notary.icsi.berkeley.edu/#statistics 23 % >>>>>>>>>> of all >>>>>>>>>> TLS connections are currently setup with ECDSA certificates. One >>>>>>>>>> example >>>>>>>>>> is https://en.wikipedia.org. And we don=E2=80=99t need unanimous suppo= rt >>>>>>>>>> from all >>>>>>>>>> CAs; it is enough that ECDSA certificates are fairly easy to get= . >>>>>>>>>>=20 >>>>>>>>>> (Ed25519 certificates are probably hard to get unless you run >>>>>>>>>> your own CA). >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> John >>>>>>>>>>=20 >>>>>>>>>> On 05/04/16 15:07, "Peterson, Jon" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> To date we have not moved this to EC because (at least as far a= s >>>>>>>>>>> I >>>>>>>>>>> understand things) many elements of web PKI, including many CAs= , >>>>>>>>>>> don't >>>>>>>>>>> support these algorithms yet. If our assessment of that is >>>>>>>>>>> changing, then >>>>>>>>>>> let's revisit it. >>>>>>>>>>>=20 >>>>>>>>>>> Jon Peterson >>>>>>>>>>> Neustar, Inc. >>>>>>>>>>>=20 >>>>>>>>>>> Sent from my iPad >>>>>>>>>>>=20 >>>>>>>>>>>> On Apr 5, 2016, at 11:37 AM, John Mattsson >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> I think there are several strong reasons to change the default >>>>>>>>>>>> signature >>>>>>>>>>>> algorithm in draft-ietf-stir-rfc4474bis and >>>>>>>>>>>> draft-ietf-stir-passport. >>>>>>>>>>>> The >>>>>>>>>>>> current default algorithm is RS256 (RSASSA-PKCS1-v1_5 using >>>>>>>>>>>> SHA-256), >>>>>>>>>>>> but >>>>>>>>>>>> I cannot find any number for MTI/Recommended/Minimum/Default >>>>>>>>>>>> key length. >>>>>>>>>>>>=20 >>>>>>>>>>>> 1. RSA signing is extremely slow compared to modern >>>>>>>>>>>> alternatives. On a >>>>>>>>>>>> Core i5-6600, ES256 (ECDSA using P-256 and SHA-256) is 21 time= s >>>>>>>>>>>> faster >>>>>>>>>>>> than RSA-2048, and Ed25519 is 67 times faster >>>>>>>>>>>> (https://bench.cr.yp.to/results-sign.html). As RSA-2048 is >>>>>>>>>>>> normally >>>>>>>>>>>> classified as roughly 112-bit security (RFC3766, NIST, ENISA), >>>>>>>>>>>> a more >>>>>>>>>>>> fair >>>>>>>>>>>> comparison is with RSA-3072, and then ES256 is 52 times faster >>>>>>>>>>>> and >>>>>>>>>>>> Ed25519 >>>>>>>>>>>> is 169 times faster. >>>>>>>>>>>>=20 >>>>>>>>>>>> 2. RSA signatures are much larger than their ECC counterparts. >>>>>>>>>>>> RSA-2048 >>>>>>>>>>>> signatures are 256 bytes and RSA-3072 signatures are 384 bytes= , >>>>>>>>>>>> while >>>>>>>>>>>> ES256 and Ed25519 signatures are only 64 bytes. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3. PKCS1-v1_5 is not a very good algorithm. It has no security >>>>>>>>>>>> proofs, >>>>>>>>>>>> no >>>>>>>>>>>> advantages, is disrecommended by ENISA (European Union Agency >>>>>>>>>>>> for >>>>>>>>>>>> Network >>>>>>>>>>>> and Information Security), and has been replaced in TLS 1.3. I >>>>>>>>>>>> do not >>>>>>>>>>>> think this is the algorithm we should use in STIR. >>>>>>>>>>>>=20 >>>>>>>>>>>> I think the right algorithm choice for STIR is ES256 or Ed2551= 9. >>>>>>>>>>>> Signature processing is likely the main burden for the >>>>>>>>>>>> Authentication >>>>>>>>>>>> Service, and changing from RSA to ECC significantly reduces th= e >>>>>>>>>>>> amount >>>>>>>>>>>> of >>>>>>>>>>>> hardware needed, and therefore the cost. A single 3.3 Ghz >>>>>>>>>>>> Skylake core >>>>>>>>>>>> can >>>>>>>>>>>> do only 400 RSA-3072 or 1,000 RSA-2048 signatures per second, >>>>>>>>>>>> but 21,000 >>>>>>>>>>>> ES256 or 68,000 Ed25519 signatures per second. RSA verificatio= n >>>>>>>>>>>> is a bit >>>>>>>>>>>> faster than ECC, but the different is much smaller that for >>>>>>>>>>>> signing, >>>>>>>>>>>> RSA-3072 verifications are e.g. twice as fast as Ed25519 >>>>>>>>>>>> verifications. >>>>>>>>>>>>=20 >>>>>>>>>>>> Cheers, >>>>>>>>>>>> John >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> --------------------------------------------------------------= --- >>>>>>>>>>>> - >>>>>>>>>>>> JOHN MATTSSON >>>>>>>>>>>> MSc Engineering Physics, MSc Business Administration and >>>>>>>>>>>> Economics >>>>>>>>>>>> Ericsson IETF Security Coordinator >>>>>>>>>>>> Senior Researcher, Security >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> stir mailing list >>>>>>>>>>>> stir@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>>> _______________________________________________ >>>>>>>>>> stir mailing list >>>>>>>>>> stir@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>>> _______________________________________________ >>>>>>>>> stir mailing list >>>>>>>>> stir@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>>> _______________________________________________ >>>>>>>> stir mailing list >>>>>>>> stir@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>> _______________________________________________ >>>>>>> stir mailing list >>>>>>> stir@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>>=20 >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir >>>>>=20 >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir >>>>=20 >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Tue Apr 12 13:57:36 2016 Return-Path: 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 1A06412E0BF for ; Tue, 12 Apr 2016 13:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 Vtb2QyBEOuv3 for ; Tue, 12 Apr 2016 13:57:34 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id AC9A512E093 for ; Tue, 12 Apr 2016 13:57:34 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 341D8F2404B; Tue, 12 Apr 2016 16:57:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 7Uh23kzDB4sZ; Tue, 12 Apr 2016 16:42:36 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id B3981F24045; Tue, 12 Apr 2016 16:57:33 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> Date: Tue, 12 Apr 2016 16:57:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <0DD82221-E79D-4F15-B2B5-93165EC98919@shockey.us> <570534D4.6010707@nostrum.com> <5195FEBC-8395-4E77-B768-2B2D81144121@shockey.us> <56DF2D20-9381-45CB-8057-6B1AB99B05E9@chriswendt.net> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> To: John Mattsson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Tue, 12 Apr 2016 20:57:36 -0000 > I don=92t know why so much of the discussion during the Tuesday = meeting was > about root certificates. As Eric pointed out on the mail, it is not = hard > to get a ECDSA certificate as Digicert, Entrust, Globalising, = Symantec, > Certicom, Comodo, and soon Let=92s encrypt will happily give you one. = As > Russ pointed out most (or all) of these ECDSA certificates will be = signed > by a RSA root certificate. But root certificates and verification of = the > credentials seems to be out of scope of STIR and does not affect the > PASSporT object. As far as I understand, the only thing STIR should > specify is verification of the PASSporT object. We will need to say that the validation will include RFC 5280 path = validation to a trust anchor. This means that the signature on each = certificate will be validated. So, for quite some time we will need to = be able to validate RSA PKCS#1 v1.5 signatures, either on the PASSporT = object or on a certificate, even if we state a strong preference for = ECDSA. Russ From nobody Wed Apr 13 13:48:49 2016 Return-Path: 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 5E32C12E523 for ; Wed, 13 Apr 2016 13:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 4uAtge5SlEKd for ; Wed, 13 Apr 2016 13:48:45 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0122.outbound.protection.outlook.com [207.46.100.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6725012E51E for ; Wed, 13 Apr 2016 13:48:44 -0700 (PDT) Received: from BY2FFO11FD024.protection.gbl (10.1.14.31) by BY2FFO11HUB051.protection.gbl (10.1.15.229) with Microsoft SMTP Server (TLS) id 15.1.453.6; Wed, 13 Apr 2016 20:48:43 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BY2FFO11FD024.mail.protection.outlook.com (10.1.15.213) with Microsoft SMTP Server (TLS) id 15.1.453.6 via Frontend Transport; Wed, 13 Apr 2016 20:48:43 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u3DKj9NE031167; Wed, 13 Apr 2016 15:48:42 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by plsapdm2.corp.sprint.com with ESMTP id 229e5yvt5m-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Apr 2016 15:48:42 -0500 Received: from plsapdm2.corp.sprint.com (plsapdm2.corp.sprint.com [127.0.0.1]) by pps.reinject (8.15.0.59/8.15.0.59) with SMTP id u3DKmgtK033333; Wed, 13 Apr 2016 15:48:42 -0500 Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm2.corp.sprint.com with ESMTP id 229e5yvt5g-2 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 13 Apr 2016 15:48:42 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Wed, 13 Apr 2016 15:48:40 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed]) by PLSWE13M08.ad.sprint.com ([fe80::5db1:e508:58c7:c6ed%24]) with mapi id 15.00.1156.000; Wed, 13 Apr 2016 15:48:41 -0500 From: "Gorman, Pierce A [CTO]" To: Russ Housley , John Mattsson Thread-Topic: [stir] Choice of STIR signature algorithm Thread-Index: AQHRlba6Rz+WZDStnkGDuD7Rhu3LUZ+IXSrw Date: Wed, 13 Apr 2016 20:48:40 +0000 Message-ID: <4c13eb4e98994874bae22011c6235c1e@PLSWE13M08.ad.sprint.com> References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <0DD82221-E79D-4F15-B2B5-93165EC98919@shockey.us> <570534D4.6010707@nostrum.com> <5195FEBC-8395-4E77-B768-2B2D81144121@shockey.us> <56DF2D20-9381-45CB-8057-6B1AB99B05E9@chriswendt.net> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> In-Reply-To: <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.172.38; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(13464003)(377454003)(189002)(199003)(50466002)(19580395003)(2906002)(76176999)(46406003)(102836003)(189998001)(11100500001)(97756001)(5250100002)(4326007)(586003)(2900100001)(1220700001)(1096002)(47776003)(33646002)(92566002)(23726003)(5003600100002)(87936001)(50986999)(106466001)(3846002)(81166005)(108616004)(54356999)(106116001)(2950100001)(5004730100002)(19580405001)(5001770100001)(93886004)(5008740100001)(24736003)(86362001)(6116002)(6806005)(4001450100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB051; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD024; 1:iVI3LXN3hjr9G6lFRvWYfjVoTV0Jt+1UArDkcSJNT30RedDQxJJH19SjCtOrP1KgeTZ28SsJdKUq4zhZnaRX+YHZFE++o7oNOz2ynFzWBpJK7S6y/4Lm3PM+kN89wBUmTsPGd4Rf97yOEM/l2HHV+SQmxQlS47uF8BJIKRTDSGoJbwC9XRrcqEr8V9w25La+i4bAh2Mwm+Mo2XZjpapNb0smFm3K21haC59kfENchT8pKmybTiEIeWsP0VGPrR7okAATva6bFH8oZTBO1bYWTDZMhL2nxGKXBcswICVTKaVCdPJNcDO09l33HMSzDiFYqqgr26Lx7/sKGrs9C4uNmpl+Wz+TADTdjorR5qFVG4x/IuT81eIdF7zkjKdd8pR12F983JJnupF6YjnmMt1Jzw1CMhMXQ718JmGIgO7HMcAwjyXEggAeTO97NmRKGjahh/XTu8dSM6gHlvuMA/JsXLy/3gOqPOhJy9lEn+LbPkEQDxKTzLzHIWah3hOX4zdLmIkx0nt1VaCAxR/3OxDBQA== X-MS-Office365-Filtering-Correlation-Id: 6af59f92-5eec-4d94-b45d-08d363dd005f X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB051; 2:NbnQzkeB/k2LXCdhr/iQtCKmwWa24a1wR/daOEyFzTpaOwcPr5sWxmGbUPTra69WNuC68RJSHz2V95uaYrlyxelQlTnHZBCvo3hLHubq8fZxSlc4Dt+6Ei/fui1CdjiGM/cT3DMYmWYK8FAFi2gWAerBAuRw3U/RSgSuk9dMpcWfSpz5BzdcwQlBUJSDv/EE; 3:qE15qcD2va/nekaWgq7uY1IVZCSfGdYBWqe5aSPdM8ZWQ8AJDMay3WHnvIjmOoNaooVdy9GRd+dZIXaC7InqKcsgCepEIpyzzkLNkWeS/h0JkOamNgohV9piBVzriyJnBEftZLrRdOGCWJMQus559ZxtgJ7RuWS7PuzZtvNQeg4i6BWJr4VIDlhiX4wnHGTP27ZMHE71TXBonYXZ7rDUKk0aypHxkaa4BDPotWFq4H36OaMrJxO0+aDoMroFjrNE2IaEOjKhqlLKAg2Uxk+cTg==; 25:qM5ncNodahuLjIsseFZzocOszFKii+gM9BX7481dLuqCFXq92e2uAztruRh2TvMyhqYKEHPKqOvHkNWHPrHfFO2luUw1PZ5aSeiN7bZxUsYqnodVHny8wmr6dnwti4cblqXEtsqKi8C2GcROe7pNan5pUj756DQbcEfFhDfJ7liDCn1ZrqjqVnezM4UpTAkS5VdDx7Kfc7yE7uHwTinV7ZMNET+4Deb93rTJUDjtD4raSNHn7yZSnX1uGKNhHoCPWpJljZFiodoD8pCqg2wwtHFvUqPM6BUkXkx5a7T2BtZH8ZL+XW4c+X7DXLSCJJgExzTnh4xQFY+x8WNpJf5Jvw== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BY2FFO11HUB051; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB051; 20:n+QMwdBZmLGSvAzMwQ43Mg761xrKu2TGtebunBvjiT6HZPltYLyWo2Vu4d0URL+mx769TFsy9zqT1brdOt5VdrNxUct4RQ1/uGOtH4iV/1ozES2OkD1tB99Ag4QS97Q0pkd23vJyi/QLviR0kE9H7hLbRZYDs8ZWzIL7+rkmsoNFnYyJNoNc6wVG9en88A/Kl1O27DTUceduL6ionJ9qUt4WjAAJzB2zZLNBHfQQmiH2IzSZpH7VxGa/PUL952O8; 4:ukEm2fPaSNDma9ZjWDoNzfH7OA+u4YER4P/PFGTRBAHqphCr4sZjX037IZWH1RR5VtvGPFODva4NNbDn4qqFmctcrTa5dYC8bFI7Dy+MRxzsNvmIUkhnt3HtI+eRbxAaUb9NLcewMkOkVCmrWVOClhDcdv/Z8FGuliefpoj0QdvqySjkKzE40+c00OT29chrbF4qW8Vc3sEYyM/HCnIKvAj6TgKsk0zj0dYRvaEpD/nxiwyJYJZn80rV6pnNTgtZJUF8/x0X9wXaC5oWihbE5/0LNIwcPG8YzEZ5WX2JlMlKWA8S+dekWqrmIyD1GX5TWO98iZTsY3Fj+GoCD+48aKrBt2P5SrPGGyBvGY3s+H/wP2KyS9o/IkJ3S2zgHeIeZkcpdgBxlSLkrpB4ktuEAsNF1LThEISZKor3a3pL9Q5bt0NCVPVhy+ZnEQ5k5wE8hzZLsdectRGrbUVWqaHnUJxFnmXOypS2u17EdNvrPeY= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13023025)(13017025)(8121501046)(13018025)(5005006)(13015025)(13024025)(3002001)(10201501046)(6055026); SRVR:BY2FFO11HUB051; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB051; X-Forefront-PRVS: 0911D5CE78 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB051; 23:YF7enZ4evLOK9ydC2LqxETTcLZ/xBVMfzB3BWWly?= =?us-ascii?Q?L/Gmhs4H0qc0pxj2bYLhkkOgnHSginY993eMSzVTHlpDDpYIqPcqJSj6MBko?= =?us-ascii?Q?CfGNB1goScQ28qCGpKSUmLM0smVfTHFmdwwtXtdGuSeyqUejga/CTIAmxSql?= =?us-ascii?Q?XUOuUuY8OmLSXOqmYKZLCOALfqkau60M3BSS8fIVCaWOo6DvXzPI5sM8ECGN?= =?us-ascii?Q?qTYeCCL44mqB5BoU/LpSI4NCLeOPpTXIDdv1NKoVpLS7PnCZNYvPm1IrcLhb?= =?us-ascii?Q?hoi2/v1XTohnKCVijTF/m13ZrKnSARWM+dACc1Uz6lIhiuS5WzGuceizCSx8?= =?us-ascii?Q?eM9Mz/reClagg5hCklny6DOIN8LXtcOUo5fHuODxKT64CkTpyY127Cnwek0D?= =?us-ascii?Q?5D4i280DFzJFiOEyZ/zl79AHZfNiK0VQ9BubOrL0Buc0dzIDZlmySfdcv5BK?= =?us-ascii?Q?iY+ZTKSfZs/vnscmf+NEsaebY+2za9/JT/i2D+3XUILcTAQI9cpCfa6hmidL?= =?us-ascii?Q?mbuzBbxtjYrWOSxXRkksIsDTiz7E0a4S7BY+SMMVONSAOfe/QGmh6w9bWwYg?= =?us-ascii?Q?9ATf0oRCVWj1rWIAUEkyDMHXmCWeiGLpmc++MfSJXrlYgqBn5CAZCy8DKmfR?= =?us-ascii?Q?W3wyG3BnukhxdBCgKnNTR7v7yOoiqU34TYCQs/6nu6H3QJyOzNkDJEBqz/iZ?= =?us-ascii?Q?KW97tO/cqbxMwjpWaU4jqjXwlfld9v+SmFmn/aLjhiXKWJ/2SfElb2UviSHE?= =?us-ascii?Q?USpzpmfKgMub2OQ1Q/iatSxxGVSmocKYCGZ4+kNB+05LE+lpY0zV1cdZRB96?= =?us-ascii?Q?aflX0P5SWiw3fW1tEnUw0aw1klLKBrZBEtxlpXGamEHKBzk/QUK+tZGAY0St?= =?us-ascii?Q?y46xgUJjT5/pP41GZdqleUtHeSYAsI6/mJkK8ycnP74gh+up8a2iN10/0Wcs?= =?us-ascii?Q?xlNP56Bq8vTWdf2LnvMtAIgufaeYAO8iNIXzF1ciOiDn+acUM3QlOc6tbsLl?= =?us-ascii?Q?bzWWdLOAYNrr4Jmct2EBxEZkC38o+KQ/EOrdKnGiu0mw5RkQ4gV/0CkCSIli?= =?us-ascii?Q?JR36dAzLIZG3IBP4tKD1Rwp457Kf//WLuqU0XhpiJ7WUbI3VwQsocqbPQWcD?= =?us-ascii?Q?Tc0xsumu78l3S4uJjLtEjP+A1kqn8sGhwSArOslyCeVbg0FJ+gFA5aqw2Xxl?= =?us-ascii?Q?aaEGRZOnPq4oIz0dVbptXl21mrrmbKGAc4vA?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB051; 5:EqFdX/TpZayk6v6jjg1zn7x+QiQtLB+2JcIp784Ob2YNTbwVUjfIhTUzPvyMYp5qVS19WXPPc+lbzZ1JB5criu5GhPr4DF9xtiS/n3xlgVkTBEmPmrIlULJP/VISOh616xkOhThM8NLnhNHHNDr66w==; 24:eEH3mN1B4UftZmRC9PizUxCKYb3ABoKPxstGzL2V8iKWytkr4jSqhb90upHzY1um+Bps3YP3ueYtiiCV38PGYaEBWZv4I9bTcIsxho9McsQ= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2016 20:48:43.2538 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB051 Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Wed, 13 Apr 2016 20:48:47 -0000 I'll expose the depth of my ignorance by mentioning that I am hopeful that = whatever credentials are used, they can be cached in the call processing se= rvers using them. Real-time call processing tens of thousands of calls per second during the = busy hour in an environment where post-dial delay is monitored very critica= lly (as one example) means that we don't want to add (iterative?) query/res= ponse flows to certificate authority systems whose capacity, availability, = and performance we have no control over. I suspect every single person reading this e-mail has personal experience w= ith folks who've been frustrated in one way or another by application secur= ity based on certificates. I am staunchly in favor of a very circumspect approach to their use in auth= enticating calling party numbers in calls signaled in SIP. Pierce Gorman -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: April 12, 2016 3:58 PM To: John Mattsson Cc: IETF STIR Mail List Subject: Re: [stir] Choice of STIR signature algorithm > I don't know why so much of the discussion during the Tuesday meeting > was about root certificates. As Eric pointed out on the mail, it is > not hard to get a ECDSA certificate as Digicert, Entrust, Globalising, > Symantec, Certicom, Comodo, and soon Let's encrypt will happily give > you one. As Russ pointed out most (or all) of these ECDSA certificates > will be signed by a RSA root certificate. But root certificates and > verification of the credentials seems to be out of scope of STIR and > does not affect the PASSporT object. As far as I understand, the only > thing STIR should specify is verification of the PASSporT object. We will need to say that the validation will include RFC 5280 path validati= on to a trust anchor. This means that the signature on each certificate wi= ll be validated. So, for quite some time we will need to be able to valida= te RSA PKCS#1 v1.5 signatures, either on the PASSporT object or on a certif= icate, even if we state a strong preference for ECDSA. Russ ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Wed Apr 13 15:38:21 2016 Return-Path: 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 F033C12DECE for ; Wed, 13 Apr 2016 15:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 LJSGiiDzl1cZ for ; Wed, 13 Apr 2016 15:38:17 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id B80AD12DE44 for ; Wed, 13 Apr 2016 15:38:17 -0700 (PDT) Received: (qmail 7126 invoked by uid 0); 13 Apr 2016 22:38:15 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy5.mail.unifiedlayer.com with SMTP; 13 Apr 2016 22:38:15 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id hye91s01A1MNPNq01yeCRd; Wed, 13 Apr 2016 16:38:15 -0600 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=8WrITzYgnNwA:10 a=p-_XEfp0GhYA:10 a=kziv93cY1bsA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=tGX7uwomAAAA:8 a=0FD05c-RAAAA:8 a=6nzofKq6Z271YizunzMA:9 a=jEV5gP42Sff45a34:21 a=e3t_fpbwpDO7sA-3:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:CC:To:From:Subject:Date; bh=ByIKrWtmR98FdIHJxKAPl3vGsHh39gxxvPq3uOX3uQs=; b=KgZYLdGyR3k/HcTPGJkA7NUVZW UgKEvc0a3Ga+/DMOxlKKu1On5ysU0BrVUU11UUnfbqEpruIMthuwMhBTFeRbvcFsMdWDvOryVyQAp qP2+sElXE3O+ENVfOjGRDIks8; Received: from [100.36.35.60] (port=58598 helo=[192.168.1.9]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1aqTQH-0000vk-A8; Wed, 13 Apr 2016 16:38:09 -0600 User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Wed, 13 Apr 2016 18:38:01 -0400 From: Richard Shockey To: "Gorman, Pierce A [CTO]" , Russ Housley , John Mattsson Message-ID: <82BB3F80-5CFA-436E-A520-A64A601BD85E@shockey.us> Thread-Topic: [stir] Choice of STIR signature algorithm References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <0DD82221-E79D-4F15-B2B5-93165EC98919@shockey.us> <570534D4.6010707@nostrum.com> <5195FEBC-8395-4E77-B768-2B2D81144121@shockey.us> <56DF2D20-9381-45CB-8057-6B1AB99B05E9@chriswendt.net> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> <4c13eb4e98994874bae22011c6235c1e@PLSWE13M08.ad.sprint.com> In-Reply-To: <4c13eb4e98994874bae22011c6235c1e@PLSWE13M08.ad.sprint.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.35.60 authed with richard+shockey.us} Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Wed, 13 Apr 2016 22:38:20 -0000 Duh.. Pierce there is no question in my mind that all we want from STIR is = the protocol and where it sits in the INVITE. Beyond that STIR is done. Shu= t it down. Quickly please.=20 We need examples to enable implementers to code correctly within either Th= e CSCF or TAS which is my earlier point. I could care less where these exist= in the documents but if you are Nokia, Ericcson, Genband etc the existing d= ocuments are insufficient in my judgement. To much rhetoric and too little e= xamples.=20 How we deploy this in the NANP is a separate and totally political issue. I= may have to personally deal with this within this in the NANC.=20 What the British et al want to do is their problem, though we need to coord= inate and be extremely sensitive on how our friends at OFCOM, CRTC, ARCEP, F= ICORA think. Its their numbers. But that is not a IETF problem. =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 On 4/13/16, 4:48 PM, "stir on behalf of Gorman, Pierce A [CTO]" wrote: >I'll expose the depth of my ignorance by mentioning that I am hopeful that= whatever credentials are used, they can be cached in the call processing se= rvers using them. > >Real-time call processing tens of thousands of calls per second during the= busy hour in an environment where post-dial delay is monitored very critica= lly (as one example) means that we don't want to add (iterative?) query/resp= onse flows to certificate authority systems whose capacity, availability, an= d performance we have no control over. > >I suspect every single person reading this e-mail has personal experience = with folks who've been frustrated in one way or another by application secur= ity based on certificates. > >I am staunchly in favor of a very circumspect approach to their use in aut= henticating calling party numbers in calls signaled in SIP. > >Pierce Gorman > > > >-----Original Message----- >From: Russ Housley [mailto:housley@vigilsec.com] >Sent: April 12, 2016 3:58 PM >To: John Mattsson >Cc: IETF STIR Mail List >Subject: Re: [stir] Choice of STIR signature algorithm > > >> I don't know why so much of the discussion during the Tuesday meeting >> was about root certificates. As Eric pointed out on the mail, it is >> not hard to get a ECDSA certificate as Digicert, Entrust, Globalising, >> Symantec, Certicom, Comodo, and soon Let's encrypt will happily give >> you one. As Russ pointed out most (or all) of these ECDSA certificates >> will be signed by a RSA root certificate. But root certificates and >> verification of the credentials seems to be out of scope of STIR and >> does not affect the PASSporT object. As far as I understand, the only >> thing STIR should specify is verification of the PASSporT object. > >We will need to say that the validation will include RFC 5280 path validat= ion to a trust anchor. This means that the signature on each certificate wi= ll be validated. So, for quite some time we will need to be able to validat= e RSA PKCS#1 v1.5 signatures, either on the PASSporT object or on a certific= ate, even if we state a strong preference for ECDSA. > >Russ > > > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the so= le use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of t= he message. > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Thu Apr 14 16:29:51 2016 Return-Path: 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 A1EC512D96E for ; Thu, 14 Apr 2016 16:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 ozszv_8lU_3o for ; Thu, 14 Apr 2016 16:29:47 -0700 (PDT) Received: from mail-qg0-x243.google.com (mail-qg0-x243.google.com [IPv6:2607:f8b0:400d:c04::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BBDA12DF26 for ; Thu, 14 Apr 2016 16:29:47 -0700 (PDT) Received: by mail-qg0-x243.google.com with SMTP id 7so8851340qgj.0 for ; Thu, 14 Apr 2016 16:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=iDD3W/8rR9AhGgRDr00IObxytmAIuCuaju6Iorwon/o=; b=uHzPdqK7f8LS2i/nZ+ujwhrIlNwtRTyBZR3RZ2NKzLUT8+ysQ5wkRZo33IBKWXWahp dD9Sytja38B9N8TezUIjrXVwNYskc/rSsancguNyVDGivMnNERh/G9FECKPTJrGz4mBM RFNdKUUFiDQ2U4pCVo2KEnZH/D98KTnA+MIRab2TzoPByseyXXU/qgH+KJV5i/tikfJC xnn1/VNs88KBV9XMoHKdD77dOsMAPM0jNtkWcLGzq+WhlNieMiUWt+BtuLcnuok3bH3X MtGt/9Vr1dc5NrRCpRmj5vnP7dSL71gcoRch42o/Go6mRGqgJzs+g28qgMRflF9NYRRi Bq+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=iDD3W/8rR9AhGgRDr00IObxytmAIuCuaju6Iorwon/o=; b=Stm3iFPpLqi2oeLqZmhI6KgblUjRzaPa9+pS7bnJn8q68FNGL37iz9b6uledvIYPJS BHrHekC6jk43CqC2ozl2aV0ozTuo/i/EdJGtaeSVvG0YlEQuzmzjpQwv3JZcIRxQy/gr oMgK8MnAlUV2ZwrMPsmRWCTd1yGZyALy+7bYgeDlPYb9VGr3R9JQ44PeVmdzy/7OlnpV aWgmAhUFkm3KKeCH1G8Txqv770o4CKK7Q9KtZPuttRruShv6FM3L4GInIIzo2gKKgzia ywngU71lVzOMtyTjAQQWkf8LM0V8Ht8bic+G8OpALKW+CM9vlR9/corj6dYISoTSN/Vh johQ== X-Gm-Message-State: AOPr4FVLHClExhtNVc5Z8IhmNKGcr0IX65ESHJb40KOx9IsEzrUAttUNj5IJocaxbuHqWg== X-Received: by 10.140.239.66 with SMTP id k63mr23001117qhc.11.1460676586491; Thu, 14 Apr 2016 16:29:46 -0700 (PDT) Received: from [172.20.10.3] (mobile-166-171-056-004.mycingular.net. [166.171.56.4]) by smtp.gmail.com with ESMTPSA id a85sm1312956qhb.12.2016.04.14.16.29.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Apr 2016 16:29:45 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E048299B-0AF9-4F33-862E-BDFAD33D5E9A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chris Wendt In-Reply-To: <4c13eb4e98994874bae22011c6235c1e@PLSWE13M08.ad.sprint.com> Date: Thu, 14 Apr 2016 19:29:43 -0400 Message-Id: References: <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <0DD82221-E79D-4F15-B2B5-93165EC98919@shockey.us> <570534D4.6010707@nostrum.com> <5195FEBC-8395-4E77-B768-2B2D81144121@shockey.us> <56DF2D20-9381-45CB-8057-6B1AB99B05E9@chriswendt.net> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> <4c13eb4e98994874bae22011c6235c1e@PLSWE13M08.ad.sprint.com> To: "Gorman, Pierce A [CTO]" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF STIR Mail List , Russ Housley , John Mattsson Subject: Re: [stir] Choice of STIR signature algorithm X-BeenThere: stir@ietf.org 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: Thu, 14 Apr 2016 23:29:49 -0000 --Apple-Mail=_E048299B-0AF9-4F33-862E-BDFAD33D5E9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Pierce, Exactly why we are very clearly advocating the ability to start with a = slow and steady approach both in ATIS and IETF, until we can build up = operational experience and efficiencies at a large scale. Certificate cachability is key starting out, may even want proactive = caching or push strategies if possible (did i hear somebody say = distributed registries?) :) Also want to make sure initial deployment doesn=E2=80=99t block call = processing for any potential certificate retrieval issues or problems, = until we build more confidence in the system. -Chris > On Apr 13, 2016, at 4:48 PM, Gorman, Pierce A [CTO] = wrote: >=20 > I'll expose the depth of my ignorance by mentioning that I am hopeful = that whatever credentials are used, they can be cached in the call = processing servers using them. >=20 > Real-time call processing tens of thousands of calls per second during = the busy hour in an environment where post-dial delay is monitored very = critically (as one example) means that we don't want to add (iterative?) = query/response flows to certificate authority systems whose capacity, = availability, and performance we have no control over. >=20 > I suspect every single person reading this e-mail has personal = experience with folks who've been frustrated in one way or another by = application security based on certificates. >=20 > I am staunchly in favor of a very circumspect approach to their use in = authenticating calling party numbers in calls signaled in SIP. >=20 > Pierce Gorman >=20 >=20 >=20 > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com = ] > Sent: April 12, 2016 3:58 PM > To: John Mattsson > > Cc: IETF STIR Mail List > > Subject: Re: [stir] Choice of STIR signature algorithm >=20 >=20 >> I don't know why so much of the discussion during the Tuesday meeting >> was about root certificates. As Eric pointed out on the mail, it is >> not hard to get a ECDSA certificate as Digicert, Entrust, = Globalising, >> Symantec, Certicom, Comodo, and soon Let's encrypt will happily give >> you one. As Russ pointed out most (or all) of these ECDSA = certificates >> will be signed by a RSA root certificate. But root certificates and >> verification of the credentials seems to be out of scope of STIR and >> does not affect the PASSporT object. As far as I understand, the only >> thing STIR should specify is verification of the PASSporT object. >=20 > We will need to say that the validation will include RFC 5280 path = validation to a trust anchor. This means that the signature on each = certificate will be validated. So, for quite some time we will need to = be able to validate RSA PKCS#1 v1.5 signatures, either on the PASSporT = object or on a certificate, even if we state a strong preference for = ECDSA. >=20 > Russ >=20 >=20 >=20 > ________________________________ >=20 > This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir = --Apple-Mail=_E048299B-0AF9-4F33-862E-BDFAD33D5E9A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Pierce,

Exactly why we are very clearly advocating the ability to = start with a slow and steady approach both in ATIS and IETF, until we = can build up operational experience and efficiencies at a large = scale.

Certificate cachability is key starting out, may even want = proactive caching or push strategies if possible (did i hear somebody = say distributed registries?) :)
Also want to make = sure initial deployment doesn=E2=80=99t block call processing for any = potential certificate retrieval issues or problems, until we build more = confidence in the system.

-Chris

On Apr 13, 2016, at 4:48 PM, = Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com> wrote:

I'll expose the depth of my ignorance by = mentioning that I am hopeful that whatever credentials are used, they = can be cached in the call processing servers using them.

Real-time call processing tens of = thousands of calls per second during the busy hour in an environment = where post-dial delay is monitored very critically (as one example) = means that we don't want to add (iterative?) query/response flows to = certificate authority systems whose capacity, availability, and = performance we have no control over.

I suspect every single person reading this = e-mail has personal experience with folks who've been frustrated in one = way or another by application security based on certificates.

I am staunchly in favor of a very = circumspect approach to their use in authenticating calling party = numbers in calls signaled in SIP.

Pierce Gorman



-----Original Message-----
From: Russ Housley = [mailto:housley@vigilsec.com]
Sent: April 12, 2016 3:58 PM
To: John Mattsson = <john.mattsson@ericsson.com>
Cc: IETF STIR Mail = List <stir@ietf.org>
Subject: Re: [stir] = Choice of STIR signature algorithm


I don't know why so much of = the discussion during the Tuesday meeting
was about root = certificates. As Eric pointed out on the mail, it is
not = hard to get a ECDSA certificate as Digicert, Entrust, Globalising,
Symantec, Certicom, Comodo, and soon Let's encrypt will = happily give
you one. As Russ pointed out most (or all) of = these ECDSA certificates
will be signed by a RSA root = certificate. But root certificates and
verification of the = credentials seems to be out of scope of STIR and
does not = affect the PASSporT object. As far as I understand, the only
thing STIR should specify is verification of the PASSporT = object.

We will need to say that the validation = will include RFC 5280 path validation to a trust anchor.  This = means that the signature on each certificate will be validated. =  So, for quite some time we will need to be able to validate RSA = PKCS#1 v1.5 signatures, either on the PASSporT object or on a = certificate, even if we state a strong preference for ECDSA.

Russ



________________________________

This e-mail may contain Sprint = proprietary information intended for the sole use of the recipient(s). = Any use by others is prohibited. If you are not the intended recipient, = please contact the sender and delete all copies of the = message.

_______________________________________________
stir mailing = list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_E048299B-0AF9-4F33-862E-BDFAD33D5E9A-- From nobody Wed Apr 20 14:02:27 2016 Return-Path: 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 0465512EA6E for ; Wed, 20 Apr 2016 14:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no 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 sCevEgv3evXF for ; Wed, 20 Apr 2016 14:02:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985E212E909 for ; Wed, 20 Apr 2016 14:02:24 -0700 (PDT) Received: from unnumerable.local ([173.57.167.89]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3KL2N11013262 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Wed, 20 Apr 2016 16:02:24 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.57.167.89] claimed to be unnumerable.local To: stir@ietf.org From: Robert Sparks Message-ID: <5717EE5F.9000707@nostrum.com> Date: Wed, 20 Apr 2016 16:02:23 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [stir] Draft minutes: STIR at IETF95 X-BeenThere: stir@ietf.org 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: Wed, 20 Apr 2016 21:02:26 -0000 The draft minutes are available here: Please send corrections to the list or directly to the chairs. RjS From nobody Thu Apr 21 10:45:06 2016 Return-Path: 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 15DF712E1FC for ; Thu, 21 Apr 2016 10:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 OuP1__n9P-jm for ; Thu, 21 Apr 2016 10:45:03 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id B437D12DE1A for ; Thu, 21 Apr 2016 10:45:03 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id E17F0F2401F for ; Thu, 21 Apr 2016 13:45:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 3h8bvWoe41eO for ; Thu, 21 Apr 2016 13:29:20 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7643BF24013 for ; Thu, 21 Apr 2016 13:44:51 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <9D68E244-1E03-4FF1-8343-F661FF3D629D@vigilsec.com> Date: Thu, 21 Apr 2016 13:44:37 -0400 To: IETF STIR Mail List Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [stir] A few comments on the PASSporT Document X-BeenThere: stir@ietf.org 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: Thu, 21 Apr 2016 17:45:05 -0000 I needed to chase a bunch of references to figure out what really goes = in the iat claim. This leads me to two comments. (1) Let=92s help the reader and tell them that the iat claim contains a = JSON numeric value representing the number of seconds from 1970-01-01 = 00:00:00 UTC. (2) The iat claim carries the time that the token was issued. Section 7 = tells that the token should be handled in a "reasonable for clock drift = and transmission time.=94 This makes sense, but neither Section 3.2.1.1 = nor Section 7 tells what ought to happen if it is determined to be = stale. The syntax of the mky claim seems to go against a JOSE design principle. = JOSE used very compact representations for everything. However, the = mky claim uses a whole lot of colons. This leads to a third comment. (3) To align with the JOSE principle, should the mky claim syntax use a = hex string or a base64 string to carry the hash values. Thanks, Russ From nobody Thu Apr 21 11:05:00 2016 Return-Path: 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 E0E6312D836 for ; Thu, 21 Apr 2016 11:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 JKku4IbpLcgz for ; Thu, 21 Apr 2016 11:04:57 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E26512D0C1 for ; Thu, 21 Apr 2016 11:04:56 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.11/8.16.0.11) with SMTP id u3LI3RGY023956; Thu, 21 Apr 2016 14:04:56 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 22bhqb27ma-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Apr 2016 14:04:56 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 21 Apr 2016 14:04:55 -0400 From: "Peterson, Jon" To: Russ Housley , IETF STIR Mail List Thread-Topic: [stir] A few comments on the PASSporT Document Thread-Index: AQHRm/WOXRE/mgQwJkOStxpBoVrKhZ+UhmQA Date: Thu, 21 Apr 2016 18:04:54 +0000 Message-ID: References: <9D68E244-1E03-4FF1-8343-F661FF3D629D@vigilsec.com> In-Reply-To: <9D68E244-1E03-4FF1-8343-F661FF3D629D@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.148] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8025029B73AC4A469E7921DBED07D33C@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-21_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604210285 Archived-At: Subject: Re: [stir] A few comments on the PASSporT Document X-BeenThere: stir@ietf.org 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: Thu, 21 Apr 2016 18:04:59 -0000 Thanks for these notes Russ. >I needed to chase a bunch of references to figure out what really goes in >the iat claim. This leads me to two comments. > >(1) Let=B9s help the reader and tell them that the iat claim contains a >JSON numeric value representing the number of seconds from 1970-01-01 >00:00:00 UTC. Sounds good to me. That claim is defined in baseline JWS/JWT, but agreed it would be helpful to informationally reiterate its syntax in the PASSporT spec. >(2) The iat claim carries the time that the token was issued. Section 7 >tells that the token should be handled in a "reasonable for clock drift >and transmission time.=B2 This makes sense, but neither Section 3.2.1.1 >nor Section 7 tells what ought to happen if it is determined to be stale. This is where the hand-off between RFC4474bis and PASSporT can be murky. The behavior for SIP as a using protocol of PASSporT with regards to the freshness of Date/iat is given in RFC4474bis. Other using protocols might want to use other means to ascertain freshness; SIP behavior really comes down to comparing iat with the Date header, and we don't want that using-protocol-specific language to be in PASSporT. I can also imagine PASSporT tokens being evaluated historically, rather than in real time, and the determination of "freshness" for those purposes might be different, or even just irrelevant. What we can say about iat in PASSporT though is that using protocols are required to specify how they determine freshness (like, what they compare it to). Would that make sense as a way to approach this? >The syntax of the mky claim seems to go against a JOSE design principle. >JOSE used very compact representations for everything. However, the mky >claim uses a whole lot of colons. This leads to a third comment. > >(3) To align with the JOSE principle, should the mky claim syntax use a >hex string or a base64 string to carry the hash values. Jonathan Lennox provided some compelling reasons for us to move mky to a JSON array format, similar to what WebRTC has done (so it's clear which keys can match to which m=3D lines in SDP, say). That at least was my take-away from the discussions around this in Buenos Aires. Would that be satisfactory for you? Jon Peterson Neustar, Inc. > >Thanks, > Russ > > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Thu Apr 21 13:26:25 2016 Return-Path: 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 BFD0812DB47 for ; Thu, 21 Apr 2016 13:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 zDCOl3JaRmgx for ; Thu, 21 Apr 2016 13:26:22 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2145B12D8BF for ; Thu, 21 Apr 2016 13:26:22 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 6FB0BF2401F; Thu, 21 Apr 2016 16:26:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id ru9ozWlDcosV; Thu, 21 Apr 2016 16:10:49 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D9646F24013; Thu, 21 Apr 2016 16:26:20 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Thu, 21 Apr 2016 16:26:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <84B51A25-EBF9-48EA-8BFF-4D76647715CB@vigilsec.com> References: <9D68E244-1E03-4FF1-8343-F661FF3D629D@vigilsec.com> To: Jon Peterson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] A few comments on the PASSporT Document X-BeenThere: stir@ietf.org 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: Thu, 21 Apr 2016 20:26:23 -0000 Jon: > Thanks for these notes Russ. >=20 >> I needed to chase a bunch of references to figure out what really = goes in >> the iat claim. This leads me to two comments. >>=20 >> (1) Let=B9s help the reader and tell them that the iat claim = contains a >> JSON numeric value representing the number of seconds from 1970-01-01 >> 00:00:00 UTC. >=20 > Sounds good to me. That claim is defined in baseline JWS/JWT, but = agreed > it would be helpful to informationally reiterate its syntax in the > PASSporT spec. Thanks. >> (2) The iat claim carries the time that the token was issued. = Section 7 >> tells that the token should be handled in a "reasonable for clock = drift >> and transmission time.=B2 This makes sense, but neither Section = 3.2.1.1 >> nor Section 7 tells what ought to happen if it is determined to be = stale. >=20 > This is where the hand-off between RFC4474bis and PASSporT can be = murky. > The behavior for SIP as a using protocol of PASSporT with regards to = the > freshness of Date/iat is given in RFC4474bis. Other using protocols = might > want to use other means to ascertain freshness; SIP behavior really = comes > down to comparing iat with the Date header, and we don't want that > using-protocol-specific language to be in PASSporT. >=20 > I can also imagine PASSporT tokens being evaluated historically, = rather > than in real time, and the determination of "freshness" for those = purposes > might be different, or even just irrelevant. >=20 > What we can say about iat in PASSporT though is that using protocols = are > required to specify how they determine freshness (like, what they = compare > it to). Would that make sense as a way to approach this? Yes, that makes sense to me. >> The syntax of the mky claim seems to go against a JOSE design = principle. >> JOSE used very compact representations for everything. However, the = mky >> claim uses a whole lot of colons. This leads to a third comment. >>=20 >> (3) To align with the JOSE principle, should the mky claim syntax use = a >> hex string or a base64 string to carry the hash values. >=20 > Jonathan Lennox provided some compelling reasons for us to move mky to = a > JSON array format, similar to what WebRTC has done (so it's clear = which > keys can match to which m=3D lines in SDP, say). That at least was my > take-away from the discussions around this in Buenos Aires. Would that = be > satisfactory for you? I think so. Russ From nobody Thu Apr 21 17:56:56 2016 Return-Path: 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 93A0712E4C3 for ; Thu, 21 Apr 2016 17:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 c6iqrveZOgqN for ; Thu, 21 Apr 2016 17:56:52 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B9512E33F for ; Thu, 21 Apr 2016 17:56:52 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id r184so33106450qkc.1 for ; Thu, 21 Apr 2016 17:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=TLUifLiS7jMggNZMbXc7DBodHzyKQnJeGiZgsYn+Xnk=; b=kncArM1Y9nqpydtdrpJdB5O2RAxKT4L//Uh7Dp5EtVffdclO0iaOqttCfdCGoyt0WE 70814d2RTklrDIf2KW3mNdJj83yzJ7eyLlIi70V6LTu0uT0WYjdDRPZ2Si4lFuBlVUDN G5n12EUFglJSX/a7JKNtPOzMXcuyf56KGSbFxdusihyB5GH0IUK8mmryOnic+Um7Oi3f KFob5Q48GhLBy0wkV6ZC7bDz7sGigZT94dQgfL/1Ru6493oYyFRVnw3CoUsTXWyxBQ6F aWcZs0wpgdxFD4lN7DI2kiTjQvJdSucoLXpCLlV7/ujGilDY5Axiyht04IVz3LEM/FP1 wJjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=TLUifLiS7jMggNZMbXc7DBodHzyKQnJeGiZgsYn+Xnk=; b=ONPmSo49xGo8WHKGPFqtYZyBBmPTe25EKvEpj8RuzCjF0BrTNPBHLJdF8p3hGPr0TW f52qm7K1NbC5hqK4ZgW1bG1a/sCF0LChipymqv0JdhsMgVXkg056m2XRow1ixU/2AYJR 17vWuaUCkIXfGQlyDs+zWmJlMhouIt4j2hkfQajZY+NBBx9YQWT58qaHZovaF3ECpoat p+uDD7y+3+edGapt5kL11H5/Qn3K55ONygXp/mvBp0Fhz6FYOLePKRxgd+xb4pkdU2cj as3ljVzalnbvzY57cnBTXKO2bUwjyImWsR6sjgu6+y6b597/6+kcvqB/caDlefg4mGgT mrBA== X-Gm-Message-State: AOPr4FXuHgAxRPKUCyYrwhsJFPwPEEyQQEo1MoAq4cMmLJJYKeE57ywFQPa4xTMSrEXl9A== X-Received: by 10.55.158.18 with SMTP id h18mr23129090qke.58.1461286611449; Thu, 21 Apr 2016 17:56:51 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:1cce:a470:49b7:fba7? ([2601:41:c101:9364:1cce:a470:49b7:fba7]) by smtp.gmail.com with ESMTPSA id e127sm1414194qkb.34.2016.04.21.17.56.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Apr 2016 17:56:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1B7E25E7-E2FE-4E5C-837F-F0A170D56439" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chris Wendt In-Reply-To: <84B51A25-EBF9-48EA-8BFF-4D76647715CB@vigilsec.com> Date: Thu, 21 Apr 2016 20:56:48 -0400 Message-Id: <6C7F922E-3472-423D-B430-AA87B36C239F@chriswendt.net> References: <9D68E244-1E03-4FF1-8343-F661FF3D629D@vigilsec.com> <84B51A25-EBF9-48EA-8BFF-4D76647715CB@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF STIR Mail List , Jon Peterson Subject: Re: [stir] A few comments on the PASSporT Document X-BeenThere: stir@ietf.org 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, 22 Apr 2016 00:56:54 -0000 --Apple-Mail=_1B7E25E7-E2FE-4E5C-837F-F0A170D56439 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 21, 2016, at 4:26 PM, Russ Housley = wrote: >=20 > Jon: >=20 >> Thanks for these notes Russ. >>=20 >>> I needed to chase a bunch of references to figure out what really = goes in >>> the iat claim. This leads me to two comments. >>>=20 >>> (1) Let=C2=B9s help the reader and tell them that the iat claim = contains a >>> JSON numeric value representing the number of seconds from = 1970-01-01 >>> 00:00:00 UTC. >>=20 >> Sounds good to me. That claim is defined in baseline JWS/JWT, but = agreed >> it would be helpful to informationally reiterate its syntax in the >> PASSporT spec. >=20 > Thanks. Agree. >=20 >>> (2) The iat claim carries the time that the token was issued. = Section 7 >>> tells that the token should be handled in a "reasonable for clock = drift >>> and transmission time.=C2=B2 This makes sense, but neither Section = 3.2.1.1 >>> nor Section 7 tells what ought to happen if it is determined to be = stale. >>=20 >> This is where the hand-off between RFC4474bis and PASSporT can be = murky. >> The behavior for SIP as a using protocol of PASSporT with regards to = the >> freshness of Date/iat is given in RFC4474bis. Other using protocols = might >> want to use other means to ascertain freshness; SIP behavior really = comes >> down to comparing iat with the Date header, and we don't want that >> using-protocol-specific language to be in PASSporT. >>=20 >> I can also imagine PASSporT tokens being evaluated historically, = rather >> than in real time, and the determination of "freshness" for those = purposes >> might be different, or even just irrelevant. >>=20 >> What we can say about iat in PASSporT though is that using protocols = are >> required to specify how they determine freshness (like, what they = compare >> it to). Would that make sense as a way to approach this? >=20 > Yes, that makes sense to me. Agree. >=20 >>> The syntax of the mky claim seems to go against a JOSE design = principle. >>> JOSE used very compact representations for everything. However, the = mky >>> claim uses a whole lot of colons. This leads to a third comment. >>>=20 >>> (3) To align with the JOSE principle, should the mky claim syntax = use a >>> hex string or a base64 string to carry the hash values. >>=20 >> Jonathan Lennox provided some compelling reasons for us to move mky = to a >> JSON array format, similar to what WebRTC has done (so it's clear = which >> keys can match to which m=3D lines in SDP, say). That at least was my >> take-away from the discussions around this in Buenos Aires. Would = that be >> satisfactory for you? >=20 > I think so. So, Jon, the idea is to use this format? { "fingerprint": [ { "algorithm": "sha-256", "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB" }, { "algorithm": "sha-1", "digest": "74:E9:76:C8:19:...:F4:45:6B" } ] } (from 5.6.4) in draft-ietf-rtcweb-security-arch-11 I=E2=80=99m not sure that addresses the size part, do we need the = colon=E2=80=99s as Russ suggests? Maybe use smaller key=E2=80=99s? { "fp": [ { "alg": "sha-256", "dgst": "4AADB9B13F...E57CAB" }, { "alg": "sha-1", "dgst": "74E976C819...F4456B" } ] } Could do even further encoding of fingerprint to reduce size as = suggested in https://webrtchacks.com/the-minimum-viable-sdp/ = Thoughts? --Apple-Mail=_1B7E25E7-E2FE-4E5C-837F-F0A170D56439 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 21, 2016, at 4:26 PM, Russ Housley <housley@vigilsec.com> wrote:

Jon:

Thanks = for these notes Russ.

I needed to chase a bunch of references to = figure out what really goes in
the iat claim.  This = leads me to two comments.

(1)  Let=C2=B9= s help the reader and tell them that the iat claim contains a
JSON numeric value representing the number of seconds from = 1970-01-01
00:00:00 UTC.

Sounds good to me. That claim is defined in baseline JWS/JWT, = but agreed
it would be helpful to informationally = reiterate its syntax in the
PASSporT spec.

Thanks.

Agree.


(2) The iat claim = carries the time that the token was issued.  Section 7
tells that the token should be handled in a "reasonable for = clock drift
and transmission time.=C2=B2  This makes = sense, but neither Section 3.2.1.1
nor Section 7 tells = what ought to happen if it is determined to be stale.

This is where the hand-off = between RFC4474bis and PASSporT can be murky.
The behavior = for SIP as a using protocol of PASSporT with regards to the
freshness of Date/iat is given in RFC4474bis. Other using = protocols might
want to use other means to ascertain = freshness; SIP behavior really comes
down to comparing iat = with the Date header, and we don't want that
using-protocol-specific language to be in PASSporT.

I can also imagine PASSporT tokens being = evaluated historically, rather
than in real time, and the = determination of "freshness" for those purposes
might be = different, or even just irrelevant.

What we = can say about iat in PASSporT though is that using protocols are
required to specify how they determine freshness (like, what = they compare
it to). Would that make sense as a way to = approach this?

Yes, that makes sense to me.

Agree.


The syntax of the mky = claim seems to go against a JOSE design principle.
JOSE = used very compact representations for everything.  However, the = mky
claim uses a whole lot of colons.  This leads to = a third comment.

(3) To align with the JOSE = principle, should the mky claim syntax use a
hex string or = a base64 string to carry the hash values.

Jonathan Lennox provided some compelling reasons for us to = move mky to a
JSON array format, similar to what WebRTC = has done (so it's clear which
keys can match to which m=3D = lines in SDP, say). That at least was my
take-away from = the discussions around this in Buenos Aires. Would that be
satisfactory for you?

I think = so.

So, Jon, the = idea is to use this format?

{
       "fingerprint": [ {
         "algorithm": "sha-256",
         "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB"
       }, {
         "algorithm": "sha-1",
         "digest": "74:E9:76:C8:19:...:F4:45:6B"
       } ]
     }

(from = 5.6.4) in draft-ietf-rtcweb-security-arch-11

I=E2=80=99m not sure that addresses the = size part, do we need the colon=E2=80=99s as Russ suggests?
Maybe use smaller key=E2=80=99s?

{
       "fp": [ {
         "alg": "sha-256",
         "dgst": "4AADB9B13F...E57CAB"
       }, {
         "alg": "sha-1",
         "dgst": "74E976C819...F4456B"
       } ]
     }

Could do even further encoding of = fingerprint to reduce size as suggested in https://webrtchacks.com/the-minimum-viable-sdp/

Thoughts?




= --Apple-Mail=_1B7E25E7-E2FE-4E5C-837F-F0A170D56439-- From nobody Thu Apr 21 18:21:53 2016 Return-Path: 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 475DD12EB08 for ; Thu, 21 Apr 2016 18:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 qbXLAzSjqB7g for ; Thu, 21 Apr 2016 18:21:48 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id D802C12E916 for ; Thu, 21 Apr 2016 18:21:47 -0700 (PDT) Received: (qmail 28891 invoked by uid 0); 22 Apr 2016 01:21:47 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 22 Apr 2016 01:21:47 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id lDMe1s00Q1MNPNq01DMhSY; Thu, 21 Apr 2016 19:21:45 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=8WrITzYgnNwA:10 a=p-_XEfp0GhYA:10 a=kziv93cY1bsA:10 a=PeFO9FbFhS32YxYntvkA:9 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=w1VtefKfAAAA:8 a=tGX7uwomAAAA:8 a=hGBaWAWWAAAA:8 a=wqCdSphEAAAA:8 a=QSof3KEQRY8zfnz_rc0A:9 a=NRCzwpkS4axj99lh:21 a=RhqpYOTD1HniYxwe:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=aY2WEzcl6vMYlDi6DLoA:9 a=_pogsq4XmJkgCYMF:21 a=QJkJdB0RUcPyXaMe:21 a=JIiHooqc4NY2MAIk:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC: To:From:Subject:Date; bh=7eJdAih/YnBpQG5GmCCIFA3cuVlx4RPqMtiN5p9iqQ4=; b=feU6 +WVeN5X87u0ccfne3UB3JJVSlNnIrETF7KFLcxPOlxM0kzmrTVZiRBvFqNuoRJSkhLrn2vuzrk58h m2bmSz/ybU21rFx0Y3C4mGhwxgRpuucH9/2SZuTnAnCwGzv; Received: from [100.36.35.60] (port=49958 helo=[192.168.1.9]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1atPmu-0001Fv-6B; Thu, 21 Apr 2016 19:21:40 -0600 User-Agent: Microsoft-MacOutlook/f.15.1.160411 Date: Thu, 21 Apr 2016 21:21:32 -0400 From: Richard Shockey To: Chris Wendt , Russ Housley Message-ID: <8868AD90-74D6-4356-B540-816CB068BEDC@shockey.us> Thread-Topic: [stir] A few comments on the PASSporT Document References: <9D68E244-1E03-4FF1-8343-F661FF3D629D@vigilsec.com> <84B51A25-EBF9-48EA-8BFF-4D76647715CB@vigilsec.com> <6C7F922E-3472-423D-B430-AA87B36C239F@chriswendt.net> In-Reply-To: <6C7F922E-3472-423D-B430-AA87B36C239F@chriswendt.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3544118500_632296364" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.35.60 authed with richard+shockey.us} Archived-At: Cc: IETF STIR Mail List , Jon Peterson Subject: Re: [stir] A few comments on the PASSporT Document X-BeenThere: stir@ietf.org 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, 22 Apr 2016 01:21:51 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3544118500_632296364 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable And please more examples. The vendor community is begining to ask serious= questions about time tables and roadmaps. The commitment to deploy is very= real.=20 Where does this actually show up in the headers. What does or should it loo= k like?=20 How this might show up on UA=E2=80=99s is another issue but totally out of scope = for this WG now and in the future.=20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: stir on behalf of Chris Wendt Date: Thursday, April 21, 2016 at 8:56 PM To: Russ Housley Cc: IETF STIR Mail List , Jon Peterson Subject: Re: [stir] A few comments on the PASSporT Document On Apr 21, 2016, at 4:26 PM, Russ Housley wrote: Jon: Thanks for these notes Russ. I needed to chase a bunch of references to figure out what really goes in the iat claim. This leads me to two comments. (1) Let=C2=B9s help the reader and tell them that the iat claim contains a JSON numeric value representing the number of seconds from 1970-01-01 00:00:00 UTC. Sounds good to me. That claim is defined in baseline JWS/JWT, but agreed it would be helpful to informationally reiterate its syntax in the PASSporT spec. Thanks. Agree. (2) The iat claim carries the time that the token was issued. Section 7 tells that the token should be handled in a "reasonable for clock drift and transmission time.=C2=B2 This makes sense, but neither Section 3.2.1.1 nor Section 7 tells what ought to happen if it is determined to be stale. This is where the hand-off between RFC4474bis and PASSporT can be murky. The behavior for SIP as a using protocol of PASSporT with regards to the freshness of Date/iat is given in RFC4474bis. Other using protocols might want to use other means to ascertain freshness; SIP behavior really comes down to comparing iat with the Date header, and we don't want that using-protocol-specific language to be in PASSporT. I can also imagine PASSporT tokens being evaluated historically, rather than in real time, and the determination of "freshness" for those purposes might be different, or even just irrelevant. What we can say about iat in PASSporT though is that using protocols are required to specify how they determine freshness (like, what they compare it to). Would that make sense as a way to approach this? Yes, that makes sense to me. Agree. The syntax of the mky claim seems to go against a JOSE design principle. JOSE used very compact representations for everything. However, the mky claim uses a whole lot of colons. This leads to a third comment. (3) To align with the JOSE principle, should the mky claim syntax use a hex string or a base64 string to carry the hash values. Jonathan Lennox provided some compelling reasons for us to move mky to a JSON array format, similar to what WebRTC has done (so it's clear which keys can match to which m=3D lines in SDP, say). That at least was my take-away from the discussions around this in Buenos Aires. Would that be satisfactory for you? I think so. So, Jon, the idea is to use this format? { "fingerprint": [ { "algorithm": "sha-256", "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB" }, { "algorithm": "sha-1", "digest": "74:E9:76:C8:19:...:F4:45:6B" } ] } (from 5.6.4) in draft-ietf-rtcweb-security-arch-11 I=E2=80=99m not sure that addresses the size part, do we need the colon=E2=80=99s as Ru= ss suggests? Maybe use smaller key=E2=80=99s? { "fp": [ { "alg": "sha-256", "dgst": "4AADB9B13F...E57CAB" }, { "alg": "sha-1", "dgst": "74E976C819...F4456B" } ] } Could do even further encoding of fingerprint to reduce size as suggested i= n https://webrtchacks.com/the-minimum-viable-sdp/ Thoughts? _______________________________________________ stir mailing list stir@ietf= .org https://www.ietf.org/mailman/listinfo/stir --B_3544118500_632296364 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

And pleas= e more examples.  The vendor community is begining  to ask serious= questions about time tables and roadmaps.  The commitment to deploy is= very real. 

Where does this actually show up = in the headers. What does or should it look like? 

=
How this might show up on UA’s is another issue but totally out o= f scope for this WG now and in the future. 

— 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>= ;shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 = 703-593-2683


From: stir <stir-bounces@ietf.org> on behalf of Chris Wendt <chris-ietf@chriswendt.net>
Date: Thursday, April 21, 2016 at 8:56 PM
<= span style=3D"font-weight:bold">To: Russ Housley <housley@vigilsec.com>
Cc: IETF STIR Mail List <s= tir@ietf.org>, Jon Peterson <jon.peterson@neustar.biz>
Subj= ect: Re: [stir] A few comments on the PASSporT Document


O= n Apr 21, 2016, at 4:26 PM, Russ Housley <housley@vigilsec.com> wrote:

Jon:

Thank= s for these notes Russ.

I needed to chase a bunch of references to figure out what really goes= in
the iat claim.  This leads me to two comments.

(1)  Let=C2=B9s help the reader and tell them that the iat= claim contains a
JSON numeric value representing the number of = seconds from 1970-01-01
00:00:00 UTC.
<= br class=3D"">Sounds good to me. That claim is defined in baseline JWS/JWT, bu= t agreed
it would be helpful to informationally reiterate its sy= ntax in the
PASSporT spec.

Thanks.
<= /div>

Agree.


(2) The iat claim carries the time t= hat the token was issued.  Section 7
tells that the token s= hould be handled in a "reasonable for clock drift
and transmissi= on time.=C2=B2  This makes sense, but neither Section 3.2.1.1
n= or Section 7 tells what ought to happen if it is determined to be stale.

This is where the hand-off between RFC447= 4bis and PASSporT can be murky.
The behavior for SIP as a using = protocol of PASSporT with regards to the
freshness of Date/iat i= s given in RFC4474bis. Other using protocols might
want to use o= ther means to ascertain freshness; SIP behavior really comes
dow= n to comparing iat with the Date header, and we don't want that
= using-protocol-specific language to be in PASSporT.

I can also imagine PASSporT tokens being evaluated historically, rather
than in real time, and the determination of "freshness" for those p= urposes
might be different, or even just irrelevant.

What we can say about iat in PASSporT though is that using pro= tocols are
required to specify how they determine freshness (lik= e, what they compare
it to). Would that make sense as a way to a= pproach this?

Yes, that makes sense to me.

Agree.


The syntax of the mky claim seems to go = against a JOSE design principle.
JOSE used very compact represen= tations for everything.  However, the mky
claim uses a whol= e lot of colons.  This leads to a third comment.

(3) To align with the JOSE principle, should the mky claim syntax use ahex string or a base64 string to carry the hash values.

Jonathan Lennox provided some compelling reason= s for us to move mky to a
JSON array format, similar to what Web= RTC has done (so it's clear which
keys can match to which m=3D lin= es in SDP, say). That at least was my
take-away from the discuss= ions around this in Buenos Aires. Would that be
satisfactory for= you?

I think so.

So, Jon, the idea is to use this format?

{
       "fingerprint": [ {
         "algorithm": "sha-256",
         "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB"
       }, {
         "algorithm": "sha-1",
         "digest": "74:E9:76:C8:19:...:F4:45:6B"
       } ]
     }

(from 5.6.4) in = draft-ietf-rtcweb-security-arch-11

I’m not sure that addresses the size part, do we need the c= olon’s as Russ suggests?
Maybe use smaller key̵= 7;s?

{
       "fp": [ {
         "alg": "sha-256",
         "dgst": "4AADB9B13F...E57CAB"
       }, {
         "alg": "sha-1",
         "dgst": "74E976C819...F4456B"
       } ]
     }


Could do even further encoding of fingerprint to redu= ce size as suggested in https://webrtchacks.com/the-minimum-viable-sdp/

Thoughts?



_______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/m= ailman/listinfo/stir --B_3544118500_632296364-- From nobody Thu Apr 21 19:42:06 2016 Return-Path: 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 4DEAC12E9CE for ; Thu, 21 Apr 2016 19:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no 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 p6Cr9Kwi0mKU for ; Thu, 21 Apr 2016 19:42:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643C012E9CC for ; Thu, 21 Apr 2016 19:42:03 -0700 (PDT) Received: from unnumerable.local ([173.57.167.89]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3M2g1Tp098525 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Thu, 21 Apr 2016 21:42:02 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.57.167.89] claimed to be unnumerable.local To: stir@ietf.org References: <9D68E244-1E03-4FF1-8343-F661FF3D629D@vigilsec.com> <84B51A25-EBF9-48EA-8BFF-4D76647715CB@vigilsec.com> <6C7F922E-3472-423D-B430-AA87B36C239F@chriswendt.net> <8868AD90-74D6-4356-B540-816CB068BEDC@shockey.us> From: Robert Sparks Message-ID: <57198F7A.90405@nostrum.com> Date: Thu, 21 Apr 2016 21:42:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <8868AD90-74D6-4356-B540-816CB068BEDC@shockey.us> Content-Type: multipart/alternative; boundary="------------070009090806070600040307" Archived-At: Subject: Re: [stir] A few comments on the PASSporT Document X-BeenThere: stir@ietf.org 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, 22 Apr 2016 02:42:05 -0000 This is a multi-part message in MIME format. --------------070009090806070600040307 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Of course. As I noted in the meeting at IETF95, I will produce some in the next month or so. I'm expecting implementations to produce even more. That said, the text is there now, and the list conversation has been pretty clear about what's still in motion. I hope nobody is waiting on examples before commenting or beginning implementation. RjS On 4/21/16 8:21 PM, Richard Shockey wrote: > > And please more examples. The vendor community is begining to ask > serious questions about time tables and roadmaps. The commitment to > deploy is very real. > > Where does this actually show up in the headers. What does or should > it look like? > > How this might show up on UA’s is another issue but totally out of > scope for this WG now and in the future. > > — > Richard Shockey > Shockey Consulting LLC > Chairman of the Board SIP Forum > www.shockey.us > www.sipforum.org > richardshockey.us > Skype-Linkedin-Facebook rshockey101 > PSTN +1 703-593-2683 > > > From: stir > on > behalf of Chris Wendt > > Date: Thursday, April 21, 2016 at 8:56 PM > To: Russ Housley > > Cc: IETF STIR Mail List >, Jon > Peterson > > Subject: Re: [stir] A few comments on the PASSporT Document > > >> On Apr 21, 2016, at 4:26 PM, Russ Housley > > wrote: >> >> Jon: >> >>> Thanks for these notes Russ. >>> >>>> I needed to chase a bunch of references to figure out what really >>>> goes in >>>> the iat claim. This leads me to two comments. >>>> >>>> (1) Letąs help the reader and tell them that the iat claim contains a >>>> JSON numeric value representing the number of seconds from 1970-01-01 >>>> 00:00:00 UTC. >>> >>> Sounds good to me. That claim is defined in baseline JWS/JWT, but agreed >>> it would be helpful to informationally reiterate its syntax in the >>> PASSporT spec. >> >> Thanks. > > Agree. > >> >>>> (2) The iat claim carries the time that the token was issued. >>>> Section 7 >>>> tells that the token should be handled in a "reasonable for clock drift >>>> and transmission time.˛ This makes sense, but neither Section 3.2.1.1 >>>> nor Section 7 tells what ought to happen if it is determined to be >>>> stale. >>> >>> This is where the hand-off between RFC4474bis and PASSporT can be murky. >>> The behavior for SIP as a using protocol of PASSporT with regards to the >>> freshness of Date/iat is given in RFC4474bis. Other using protocols >>> might >>> want to use other means to ascertain freshness; SIP behavior really >>> comes >>> down to comparing iat with the Date header, and we don't want that >>> using-protocol-specific language to be in PASSporT. >>> >>> I can also imagine PASSporT tokens being evaluated historically, rather >>> than in real time, and the determination of "freshness" for those >>> purposes >>> might be different, or even just irrelevant. >>> >>> What we can say about iat in PASSporT though is that using protocols are >>> required to specify how they determine freshness (like, what they >>> compare >>> it to). Would that make sense as a way to approach this? >> >> Yes, that makes sense to me. > > Agree. > >> >>>> The syntax of the mky claim seems to go against a JOSE design >>>> principle. >>>> JOSE used very compact representations for everything. However, >>>> the mky >>>> claim uses a whole lot of colons. This leads to a third comment. >>>> >>>> (3) To align with the JOSE principle, should the mky claim syntax use a >>>> hex string or a base64 string to carry the hash values. >>> >>> Jonathan Lennox provided some compelling reasons for us to move mky to a >>> JSON array format, similar to what WebRTC has done (so it's clear which >>> keys can match to which m= lines in SDP, say). That at least was my >>> take-away from the discussions around this in Buenos Aires. Would >>> that be >>> satisfactory for you? >> >> I think so. > > So, Jon, the idea is to use this format? > > { > "fingerprint": [ { > "algorithm": "sha-256", > "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB" > }, { > "algorithm": "sha-1", > "digest": "74:E9:76:C8:19:...:F4:45:6B" > } ] > } > > (from 5.6.4) in draft-ietf-rtcweb-security-arch-11 > > I’m not sure that addresses the size part, do we need the colon’s as > Russ suggests? > Maybe use smaller key’s? > > { > "fp": [ { > "alg": "sha-256", > "dgst": "4AADB9B13F...E57CAB" > }, { > "alg": "sha-1", > "dgst": "74E976C819...F4456B" > } ] > } > > > Could do even further encoding of fingerprint to reduce size as > suggested in https://webrtchacks.com/the-minimum-viable-sdp/ > > Thoughts? > > > > > _______________________________________________ stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --------------070009090806070600040307 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Of course.

As I noted in the meeting at IETF95, I will produce some in the next month or so. I'm expecting implementations to produce even more.

That said, the text is there now, and the list conversation has been pretty clear about what's still in motion. I hope nobody is waiting on examples before commenting or beginning implementation.

RjS

On 4/21/16 8:21 PM, Richard Shockey wrote:

And please more examples.  The vendor community is begining  to ask serious questions about time tables and roadmaps.  The commitment to deploy is very real. 

Where does this actually show up in the headers. What does or should it look like? 

How this might show up on UA’s is another issue but totally out of scope for this WG now and in the future. 

— 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683


From: stir <stir-bounces@ietf.org> on behalf of Chris Wendt <chris-ietf@chriswendt.net>
Date: Thursday, April 21, 2016 at 8:56 PM
To: Russ Housley <housley@vigilsec.com>
Cc: IETF STIR Mail List <stir@ietf.org>, Jon Peterson <jon.peterson@neustar.biz>
Subject: Re: [stir] A few comments on the PASSporT Document


On Apr 21, 2016, at 4:26 PM, Russ Housley <housley@vigilsec.com> wrote:

Jon:

Thanks for these notes Russ.

I needed to chase a bunch of references to figure out what really goes in
the iat claim.  This leads me to two comments.

(1)  Letąs help the reader and tell them that the iat claim contains a
JSON numeric value representing the number of seconds from 1970-01-01
00:00:00 UTC.

Sounds good to me. That claim is defined in baseline JWS/JWT, but agreed
it would be helpful to informationally reiterate its syntax in the
PASSporT spec.

Thanks.

Agree.


(2) The iat claim carries the time that the token was issued.  Section 7
tells that the token should be handled in a "reasonable for clock drift
and transmission time.˛  This makes sense, but neither Section 3.2.1.1
nor Section 7 tells what ought to happen if it is determined to be stale.

This is where the hand-off between RFC4474bis and PASSporT can be murky.
The behavior for SIP as a using protocol of PASSporT with regards to the
freshness of Date/iat is given in RFC4474bis. Other using protocols might
want to use other means to ascertain freshness; SIP behavior really comes
down to comparing iat with the Date header, and we don't want that
using-protocol-specific language to be in PASSporT.

I can also imagine PASSporT tokens being evaluated historically, rather
than in real time, and the determination of "freshness" for those purposes
might be different, or even just irrelevant.

What we can say about iat in PASSporT though is that using protocols are
required to specify how they determine freshness (like, what they compare
it to). Would that make sense as a way to approach this?

Yes, that makes sense to me.

Agree.


The syntax of the mky claim seems to go against a JOSE design principle.
JOSE used very compact representations for everything.  However, the mky
claim uses a whole lot of colons.  This leads to a third comment.

(3) To align with the JOSE principle, should the mky claim syntax use a
hex string or a base64 string to carry the hash values.

Jonathan Lennox provided some compelling reasons for us to move mky to a
JSON array format, similar to what WebRTC has done (so it's clear which
keys can match to which m= lines in SDP, say). That at least was my
take-away from the discussions around this in Buenos Aires. Would that be
satisfactory for you?

I think so.

So, Jon, the idea is to use this format?

{
       "fingerprint": [ {
         "algorithm": "sha-256",
         "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB"
       }, {
         "algorithm": "sha-1",
         "digest": "74:E9:76:C8:19:...:F4:45:6B"
       } ]
     }

(from 5.6.4) in draft-ietf-rtcweb-security-arch-11

I’m not sure that addresses the size part, do we need the colon’s as Russ suggests?
Maybe use smaller key’s?

{
       "fp": [ {
         "alg": "sha-256",
         "dgst": "4AADB9B13F...E57CAB"
       }, {
         "alg": "sha-1",
         "dgst": "74E976C819...F4456B"
       } ]
     }


Could do even further encoding of fingerprint to reduce size as suggested in https://webrtchacks.com/the-minimum-viable-sdp/

Thoughts?




_______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir 

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

--------------070009090806070600040307-- From nobody Fri Apr 22 12:12:37 2016 Return-Path: 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 4CB5A12E275 for ; Fri, 22 Apr 2016 12:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 YCkfXr6kalkx for ; Fri, 22 Apr 2016 12:12:33 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 30A7612E252 for ; Fri, 22 Apr 2016 12:12:33 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 824F6F2402A for ; Fri, 22 Apr 2016 15:12:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id tYEymhyUq6f8 for ; Fri, 22 Apr 2016 14:56:56 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CF559F2401F for ; Fri, 22 Apr 2016 15:12:31 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_42401B55-FB48-429F-AA86-F61B5705BB69" Message-Id: <2E8DCD83-7D46-4609-BE77-EF3D74AFCEE5@vigilsec.com> Date: Fri, 22 Apr 2016 15:12:31 -0400 To: IETF STIR Mail List Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [stir] ATIS Publishes Calling Party Spoofing Mechanisms and Mitigation Techniques Whitepaper X-BeenThere: stir@ietf.org 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, 22 Apr 2016 19:12:36 -0000 --Apple-Mail=_42401B55-FB48-429F-AA86-F61B5705BB69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Please see attached communication from Susan M. Miller, ATIS President = and CEO. I will have this letter posted as a liaison statement. Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D=20 ATIS 1200 G Street, NW Suite 500 Washington, DC 20005 April 21, 2016 via email, housley@vigilsec.com Russ Housley IETF, STIR WG Co-Chair c/o IETF Secretariat 48377 Fremont Blvd., Suite 117 Fremont, California 94538 Re: ATIS White Paper on Calling Party Anti Spoofing Dear Mr. Housley: On behalf of the Alliance for Telecommunications Industry Solutions = (ATIS), I am pleased to announce the publication of ATIS=E2=80=99 White = Paper on Calling Party Spoofing Mechanisms and Mitigation Techniques. = This white paper provides information on caller ID spoofing mitigation = techniques and is available via the ATIS White Paper Library at: = http://www.atis.org/01_resources/whitepapers.asp. Both existing and proposed caller ID mitigation techniques are examined, = including technical specifications and standards that would allow phone = numbers to be =E2=80=9Csigned=E2=80=9D at the origin and =E2=80=9Cverified= =E2=80=9D at the termination. The paper concludes that Caller ID = spoofing is not a problem that can be fixed with a single solution and, = as an alternative, proposes a layered approach, similar to that used in = cybersecurity efforts. This white paper is just one of several ATIS work programs aimed at = examining and mitigating challenges associated with caller ID spoofing. = Other relevant work is being completed in ATIS=E2=80=99 Next Generation = Interconnection Interoperability Forum (NGIIF), which has recently = published its Next Generation Network (NGN) Reference Document, = outlining Caller ID issues and their impacts to consumers and to the = network. The ATIS Packet Technologies and Systems Committee (PTSC) is = working on a Technical Report on Originating Party Spoofing in IP = Communication Networks. Additionally, ATIS is working with the SIP Forum = on proposed enhancements to Secure Telephone Identity Revisited (STIR). = We would be happy to provide further information on its Caller ID = spoofing mitigation work programs. =EF=BF=BC If you have any questions or would like further information, please do = not hesitate to contact me at smiller@atis.org or (202) 434-8828. Sincerely, Susan Miller President and CEO =EF=BF=BC=EF=BF=BC= --Apple-Mail=_42401B55-FB48-429F-AA86-F61B5705BB69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Please see attached communication from Susan M. = Miller, ATIS President and CEO.


I will have this = letter posted as a liaison = statement.

Russ

=3D =3D = =3D =3D =3D =3D =3D =3D =3D = =3D 

ATIS
1200 G Street, NW = Suite 500
Washington, DC = 20005

April 21, = 2016

Ru= ss Housley
IETF, STIR WG Co-Chair
c/o IETF = Secretariat
48377 Fremont Blvd., Suite 117
Fremont, = California 94538

Re: ATIS White Paper on = Calling Party Anti Spoofing

Dear Mr. = Housley:

On behalf of the Alliance for = Telecommunications Industry Solutions (ATIS), I am pleased to announce = the publication of ATIS=E2=80=99 White Paper on Calling Party Spoofing = Mechanisms and Mitigation Techniques. This white paper provides = information on caller ID spoofing mitigation techniques and is available = via the ATIS White Paper Library at: http://www.atis.= org/01_resources/whitepapers.asp.

Both = existing and proposed caller ID mitigation techniques are examined, = including technical specifications and standards that would allow phone = numbers to be =E2=80=9Csigned=E2=80=9D at the origin and =E2=80=9Cverified= =E2=80=9D at the termination. The paper concludes that Caller ID = spoofing is not a problem that can be fixed with a single solution and, = as an alternative, proposes a layered approach, similar to that used in = cybersecurity efforts.

This white paper is just = one of several ATIS work programs aimed at examining and mitigating = challenges associated with caller ID spoofing. Other relevant work is = being completed in ATIS=E2=80=99 Next Generation Interconnection = Interoperability Forum (NGIIF), which has recently published its Next = Generation Network (NGN) Reference Document, outlining Caller ID issues = and their impacts to consumers and to the network. The ATIS Packet = Technologies and Systems Committee (PTSC) is working on a Technical = Report on Originating Party Spoofing in IP Communication Networks. = Additionally, ATIS is working with the SIP Forum on proposed = enhancements to Secure Telephone Identity Revisited (STIR). We would be = happy to provide further information on its Caller ID spoofing = mitigation work programs.
=EF=BF=BC
If you have any = questions or would like further information, please do not hesitate to = contact me at smiller@atis.org = or (202) 434-8828.

Sincerely,
Susan = Miller President and = CEO
=EF=BF=BC=EF=BF=BC
= --Apple-Mail=_42401B55-FB48-429F-AA86-F61B5705BB69-- From nobody Fri Apr 22 15:31:01 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8A512E3BF; Fri, 22 Apr 2016 15:30:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: "Russ Housley" , "Robert Sparks" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160422223059.7706.91344.idtracker@ietfa.amsl.com> Date: Fri, 22 Apr 2016 15:30:59 -0700 Archived-At: Cc: Ben Campbell , Alexey Melnikov , Alissa Cooper , Russ Housley , Secure Telephone Identity Revisited Discussion List , Robert Sparks Subject: [stir] New Liaison Statement, "Re: ATIS White Paper on Calling Party Anti Spoofing" X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 22:30:59 -0000 Title: Re: ATIS White Paper on Calling Party Anti Spoofing Submission Date: 2016-04-22 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1469/ From: "Susan Miller" To: Robert Sparks , Russ Housley Cc: Russ Housley ,Ben Campbell ,Alissa Cooper ,Robert Sparks ,Alexey Melnikov ,Secure Telephone Identity Revisited Discussion List , Response Contacts: Technical Contacts: Purpose: For information Body: Dear Mr. Housley: On behalf of the Alliance for Telecommunications Industry Solutions (ATIS), I am pleased to announce the publication of ATIS’ White Paper on Calling Party Spoofing Mechanisms and Mitigation Techniques. This white paper provides information on caller ID spoofing mitigation techniques and is available via the ATIS White Paper Library at: http://www.atis.org/01_resources/whitepapers.asp. Both existing and proposed caller ID mitigation techniques are examined, including technical specifications and standards that would allow phone numbers to be “signed” at the origin and “verified” at the termination. The paper concludes that Caller ID spoofing is not a problem that can be fixed with a single solution and, as an alternative, proposes a layered approach, similar to that used in cybersecurity efforts. This white paper is just one of several ATIS work programs aimed at examining and mitigating challenges associated with caller ID spoofing. Other relevant work is being completed in ATIS’ Next Generation Interconnection Interoperability Forum (NGIIF), which has recently published its Next Generation Network (NGN) Reference Document, outlining Caller ID issues and their impacts to consumers and to the network. The ATIS Packet Technologies and Systems Committee (PTSC) is working on a Technical Report on Originating Party Spoofing in IP Communication Networks. Additionally, ATIS is working with the SIP Forum on proposed enhancements to Secure Telephone Identity Revisited (STIR). We would be happy to provide further information on its Caller ID spoofing mitigation work programs. If you have any questions or would like further information, please do not hesitate to contact me at smiller@atis.org or (202) 434-8828. Sincerely, Susan Miller President and CEO Attachments: Re: ATIS White Paper on Calling Party Anti Spoofing https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-04-22-atis-stir-re-atis-white-paper-on-calling-party-anti-spoofing-attachment-1.pdf From nobody Mon Apr 25 14:02:27 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C1A12B071; Mon, 25 Apr 2016 14:02:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160425210223.30218.90191.idtracker@ietfa.amsl.com> Date: Mon, 25 Apr 2016 14:02:23 -0700 Archived-At: Cc: stir@ietf.org, alissa@cooperw.in, stir-chairs@ietf.org, rjsparks@nostrum.com Subject: [stir] stir - New Meeting Session Request for IETF 96 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 21:02:24 -0000 A new meeting session request has just been submitted by Robert Sparks, a Chair of the stir working group. --------------------------------------------------------- Working Group Name: Secure Telephone Identity Revisited Area Name: Applications and Real-Time Area Session Requester: Robert Sparks Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: acme tls ecrit avtcore dane siprec p2psip rtcweb mmusic sipcore dispatch appsawg ice modern Second Priority: perc slim netvc clue tcpinc cose uta ace saag jose oauth Special Requests: --------------------------------------------------------- From nobody Wed Apr 27 11:18:53 2016 Return-Path: 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 AC3C712DB7F for ; Wed, 27 Apr 2016 11:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no 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 erJaT4iPmn8y for ; Wed, 27 Apr 2016 11:18:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7CB12D53F for ; Wed, 27 Apr 2016 11:18:50 -0700 (PDT) Received: from unnumerable.local ([173.57.167.89]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3RIIncC004453 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Wed, 27 Apr 2016 13:18:50 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.57.167.89] claimed to be unnumerable.local To: stir@ietf.org References: <5706C011.6040905@nostrum.com> From: Robert Sparks Message-ID: <57210289.7080403@nostrum.com> Date: Wed, 27 Apr 2016 13:18:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5706C011.6040905@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [stir] Update: Interim meeting. X-BeenThere: stir@ietf.org 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: Wed, 27 Apr 2016 18:18:51 -0000 I've gotten enough direct feedback from folks asking for the 27th rather than the 26th to try and make that change. We'll set a virtual interim for May 27 at 10 am Pacific US / 1pm Eastern US for 2 hours. Watch for the announcement from the secretariat for additional details. RjS On 4/7/16 3:16 PM, Robert Sparks wrote: > We are planning to have a virtual interim in the late may timeframe. > > Please hold May 26 for now (and let us know if that's problematic). > > More details will follow. > > RjS > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Apr 27 11:19:45 2016 Return-Path: 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 7609A12DB7F for ; Wed, 27 Apr 2016 11:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.897 X-Spam-Level: X-Spam-Status: No, score=-7.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 1gtQxOQj6k9F for ; Wed, 27 Apr 2016 11:19:43 -0700 (PDT) Received: from sjmda09.webex.com (sjmda09.webex.com [64.68.122.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A6B12DB8C for ; Wed, 27 Apr 2016 11:19:43 -0700 (PDT) Received: from jva2tc111.webex.com (sjc02-wxp00-lbace03-core-vl120-np10b-5.webex.com [64.68.121.240]) by sjmda09.webex.com (Postfix) with ESMTP id 9C083216C4 for ; Wed, 27 Apr 2016 18:19:42 +0000 (GMT) Received: from jva2tc111.webex.com (localhost [127.0.0.1]) by jva2tc111.webex.com (Postfix) with ESMTP id 565EB1BF23D for ; Wed, 27 Apr 2016 18:19:42 +0000 (GMT) Date: Wed, 27 Apr 2016 18:19:42 +0000 (GMT) From: Robert Sparks To: stir@ietf.org Message-ID: <1013656783.35186.1461781182351.JavaMail.nobody@jva2tc111.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_35184_2006784911.1461781182351" X-Priority: 3 Importance: normal Archived-At: Subject: [stir] WebEx meeting invitation: STIR Virtual Interim X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: rjsparks@nostrum.com List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 18:19:44 -0000 ------=_Part_35184_2006784911.1461781182351 Content-Type: multipart/Alternative; boundary="----=_Part_35185_1803323042.1461781182351" ------=_Part_35185_1803323042.1461781182351 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKUm9iZXJ0IFNwYXJrcyBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVl dGluZy4KCgpTVElSIFZpcnR1YWwgSW50ZXJpbQpGcmlkYXksIE1heSAyNywgMjAxNgoxMjowMCBw bSAgfCAgQ2VudHJhbCBEYXlsaWdodCBUaW1lIChDaGljYWdvLCBHTVQtMDU6MDApICB8ICAyIGhy cwoKCkpPSU4gV0VCRVggTUVFVElORwpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/ TVRJRD1tNmYzM2I0NjU5ODA0M2I3ZDVjMjgwOGJhMTUwOWI5MGUKTWVldGluZyBudW1iZXI6IDY0 NCAxMDkgMDA2Ck1lZXRpbmcgcGFzc3dvcmQ6IDZ2UW1YVDhyCgoNCkpPSU4gQlkgUEhPTkUNCjEt ODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKSAKMS02NTAt NDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKQpBY2Nlc3MgY29kZTogNjQ0 IDEwOSAwMDYKClRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9uczogCmh0dHBzOi8vd3d3Lndl YmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZg0KDQoKQWRkIHRoaXMgbWVldGlu ZyB0byB5b3VyIGNhbGVuZGFyIChDYW5ub3QgYWRkIGZyb20gbW9iaWxlIGRldmljZXMpOgpodHRw czovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tYmY3MTYwODAxMmVkMWFjOTgwYWFm ZWVhMWVjMzQ2YzMNCg0KCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBo ZXJlOgpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMKCgpJTVBPUlRBTlQgTk9USUNFOiBQ bGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVy IGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGlj aCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMg c2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElm IHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNl cm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uCg== ------=_Part_35185_1803323042.1461781182351 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBSb2Jl cnQgU3BhcmtzIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJFeCBtZWV0aW5nLgogICAgICAg ICAgICAgICAgCSAgICAgICAgICAgPC90ZD4KICAgICAgPC90cj4KPC90YWJsZT4KCgoKCjx0YWJs ZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+ Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZSAgd2lkdGg9IjEwMCUiPgoJCQkJ CQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0iZm9udC1zaXplOjE2cHg7IGNvbG9yOiM0RDRENEQi PgoJCQkJCQkJCQk8Yj5TVElSIFZpcnR1YWwgSW50ZXJpbTwvYj4KCQkJCQkJCQk8L3RkPgoJCQkJ CQkJPC90cj4KCQkJCQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkPkZyaWRh eSwgTWF5IDI3LCAyMDE2CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8dHIgc3R5 bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD4xMjowMCBwbSZuYnNwOyZuYnNwO3wmbmJzcDsm bmJzcDtDZW50cmFsIERheWxpZ2h0IFRpbWUgKENoaWNhZ28sIEdNVC0wNTowMCkmbmJzcDsmbmJz cDt8Jm5ic3A7Jm5ic3A7MiBocnMKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90 YWJsZT4KCjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJo ZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0i d2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQiPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0 ZCBzdHlsZT0iY29sb3I6IzAwQUZGOTtmb250LXNpemU6MTZweCI+CgkJCQkJCQkJCTxhIGhyZWY9 Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW02ZjMzYjQ2NTk4MDQzYjdk NWMyODA4YmExNTA5YjkwZSIKCQkJCQkJCQkJCXN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtm b250LXNpemU6MTZweDtjb2xvcjojMDBBRkY5Ij4KCQkJCQkJCQkJCTxiPkpvaW4gV2ViRXggbWVl dGluZzwvYj4KCQkJCQkJCQkJPC9hPgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8 L3RhYmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0 YW50Ij4KCQkJCQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkIHN0eWxlPSJw YWRkaW5nLXJpZ2h0OiA1cHg7Ij4KCQkJCQkJCQkJTWVldGluZyBudW1iZXI6CgkJCQkJCQkJPC90 ZD4KCQkJCQkJCQk8dGQ+NjQ0IDEwOSAwMDYKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJ CQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9InBhZGRpbmctcmlnaHQ6IDVweDsiPk1lZXRpbmcg cGFzc3dvcmQ6PC90ZD4KCQkJCQkJCQk8dGQ+NnZRbVhUOHI8L3RkPgoJCQkJCQkJPC90cj4KCQkJ CQkJPC90YWJsZT4KCgoKCQoKCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiPjx0 ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPjx0YWJsZT48dHI+ PHRkIHN0eWxlPSJmb250LXNpemU6MTZweCI+PGI+Sm9pbiBieSBwaG9uZTwvYj48L3RkPjwvdHI+ PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+PGI+MS04NzctNjY4LTQ0OTM8L2I+Jm5ic3A7Q2Fs bC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpPC90ZD48L3RyPjx0ciBzdHlsZT0ibWFy Z2luOjBweCI+PHRkPjxiPjEtNjUwLTQ3OS0zMjA4PC9iPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+QWNjZXNz IGNvZGU6Jm5ic3A7NjQ0IDEwOSAwMDY8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48 dGQ+PGEgaHJlZj0iaHR0cHM6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlv bnMucGRmIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjEzcHg7Y29sb3I6 IzAwQUZGOTsiPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvYT48L3RkPjwvdHI+PC90 YWJsZT4KCgkJCQkJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+PHRkIHN0eWxl PSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48dGQgc3R5 bGU9ImZvbnQtc2l6ZToxM3B4Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYv ai5waHA/TVRJRD1tYmY3MTYwODAxMmVkMWFjOTgwYWFmZWVhMWVjMzQ2YzMiIHN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5OyBmb250LXNpemU6MTNweCI+QWRkIHRoaXMg bWVldGluZzwvYT4gdG8geW91ciBjYWxlbmRhci4gKENhbm5vdCBhZGQgZnJvbSBtb2JpbGUgZGV2 aWNlcy4pPC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAy MHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+Cjx0 YWJsZT4KICAgIDx0cj4KICAgICAgIDx0ZCBzdHlsZT0iZm9udC1zaXplOiAxM3B4O2ZvbnQtZmFt aWx5OiBBcmlhbDtjb2xvcjogIzY2NjY2NjsiPgogICAgICAgIENhbid0IGpvaW4gdGhlIG1lZXRp bmc/CiAgICAgCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYyIgc3R5bGU9 InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxM3B4O2ZvbnQtZmFtaWx5OkFyaWFsO2Nv bG9yOiMwMEFGRjk7Zm9udC1jb2xvcjojMDBBRkY5OyI+CiAgICAgICAgCUNvbnRhY3Qgc3VwcG9y dC48L2E+CgkJPC90ZD4KICAgIDwvdHI+CjwvdGFibGU+Cjx0YWJsZT48dHIgc3R5bGU9ImxpbmUt aGVpZ2h0OiAxMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MTBweCI+Jm5ic3A7PC90ZD48L3RyPjwv dGFibGU+CgkJCQkJCTx0YWJsZT4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQt c2l6ZToxMnB4O2NvbG9yOiAjQTBBMEEwOyI+CgkJCQkJCQkJCUlNUE9SVEFOVCBOT1RJQ0U6IFBs ZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIg aW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNo IG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBz ZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYg eW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2Vy bnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48L3RkPgoJCQkJCQkJ PC90cj4KCQkJCQkJPC90YWJsZT4KCQkJCTwvdGQ+CgkJCTwvdHI+CgkJPC90YWJsZT4KCTwvdGQ+ CiAgIDwvdHI+CjwvdGFibGU+Cgo8L2JvZHk+ ------=_Part_35185_1803323042.1461781182351-- ------=_Part_35184_2006784911.1461781182351 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpDZW50cmFsIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDE0MTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA1MDAKVFpPRkZTRVRUTzotMDYwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE0MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDYw MApUWk9GRlNFVFRPOi0wNTAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86c3RpckBpZXRmLm9yZwpPUkdBTklaRVI7Q049IlJv YmVydCBTcGFya3MiOk1BSUxUTzpyanNwYXJrc0Bub3N0cnVtLmNvbQpEVFNUQVJUO1RaSUQ9IkNl bnRyYWwgVGltZSI6MjAxNjA1MjdUMTIwMDAwCkRURU5EO1RaSUQ9IkNlbnRyYWwgVGltZSI6MjAx NjA1MjdUMTQwMDAwCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0ZgpUUkFOU1A6 T1BBUVVFClNFUVVFTkNFOjE0NjE3ODExODEKVUlEOmUzMmIzZjRmLTBiNzYtNDdlNC04Yzk0LTI5 ZmU3NWNiYjg3OQpEVFNUQU1QOjIwMTYwNTI3VDE3MDAwMFoKREVTQ1JJUFRJT046XG5cblxuSk9J TiBXRUJFWCBNRUVUSU5HXG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1t YWViZDdkODAzMmYyNjU3YjY4YzcwODQwYjUxNWI3MjNcbk1lZXRpbmcgbnVtYmVyOiA2NDQgMTA5 IDAwNlxuTWVldGluZyBwYXNzd29yZDogNnZRbVhUOHJcblxuXG5KT0lOIEJZIFBIT05FXG4xLTg3 Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkgXG4xLTY1MC00 NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5BY2Nlc3MgY29kZTogNjQ0 IDEwOSAwMDZcblxuVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiBcbmh0dHBzOi8vd3d3 LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxuXG5cblxuQ2FuJ3Qgam9p biB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRwczovL2lldGYud2ViZXgu Y29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMg V2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVy aW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxl IGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRp Y2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0 byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3Ig ZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRUWVBFPXRleHQvaHRtbDoJ PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4gPEZPTlQgU0laRT0iNCIgRkFD RT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW1hZWJkN2Q4MDMyZjI2NTdiNjhjNzA4NDBiNTE1YjcyMyI+PEZPTlQgU0laRT0iMyIg Q09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1lZXRpbmc8L0ZPTlQ+PC9h PgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9GT05UPgkJCQkJPC90ZD4JCQkJ CTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjY0 NCAxMDkgMDA2PC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxlPgkJCTx0YWJsZT48 dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGlu ZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIgIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+NnZRbVhUOHI8L0ZPTlQ+PC90ZD48L3RyPjwvdGFibGU+CQk8L0ZPTlQ+ PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPjxG T05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+MS04NzctNjY4LTQ0OTM8L3N0 cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5i c3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJv bmc+MS02NTAtNDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9D YW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZB Q0U9ImFyaWFsIj5BY2Nlc3MgY29kZTogNjQ0IDEwOSAwMDY8L0ZPTlQ+Jm5ic3A7IDxCUj48YSBo cmVmPSJodHRwczovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYi PjxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+VG9sbC1mcmVlIGNh bGxpbmcgcmVzdHJpY3Rpb25zPC9GT05UPjwvYT4gJm5ic3A7IDxCUj48L0ZPTlQ+PEJSPjxCUj4J Jm5ic3A7PEJSPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPgkJ CQlDYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD4JPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndl YmV4LmNvbS9pZXRmL21jIj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFy aWFsIj5Db250YWN0IHN1cHBvcnQuPC9GT05UPjwvYT4JJm5ic3A7PEJSPiZuYnNwOzxCUj48Rk9O VCBDT0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9SVEFOVCBOT1RJQ0U6 IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3Ro ZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdo aWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhp cyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4g SWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29u Y2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48L0ZPTlQ+PC9G T05UPgpTVU1NQVJZOlNUSVIgVmlydHVhbCBJbnRlcmltClBSSU9SSVRZOjUKQ0xBU1M6UFVCTElD CkJFR0lOOlZBTEFSTQpUUklHR0VSOi1QVDVNCkFDVElPTjpESVNQTEFZCkRFU0NSSVBUSU9OOlJl bWluZGVyCkVORDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg== ------=_Part_35184_2006784911.1461781182351-- From nobody Wed Apr 27 11:44:19 2016 Return-Path: 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 23F0512D53B for ; Wed, 27 Apr 2016 11:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no 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 UJghnRMHwaQP for ; Wed, 27 Apr 2016 11:44:16 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C6212D534 for ; Wed, 27 Apr 2016 11:44:16 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u3RIhtO4002336; Wed, 27 Apr 2016 14:44:13 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 22k2th07xm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Apr 2016 14:44:13 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u3RIiCm2016373; Wed, 27 Apr 2016 14:44:13 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u3RIi48e016204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 Apr 2016 14:44:06 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 27 Apr 2016 18:43:49 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.23]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0248.002; Wed, 27 Apr 2016 14:43:49 -0400 From: "DOLLY, MARTIN C" To: Robert Sparks , "stir@ietf.org" Thread-Topic: [stir] Update: Interim meeting. Thread-Index: AQHRoLFGMuAkJHbg3EirErXT463aTp+eJ/aQ Date: Wed, 27 Apr 2016 18:43:48 +0000 Message-ID: References: <5706C011.6040905@nostrum.com> <57210289.7080403@nostrum.com> In-Reply-To: <57210289.7080403@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.246.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-27_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604270288 Archived-At: Subject: Re: [stir] Update: Interim meeting. X-BeenThere: stir@ietf.org 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: Wed, 27 Apr 2016 18:44:18 -0000 I have a conflict.... -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Wednesday, April 27, 2016 2:19 PM To: stir@ietf.org Subject: [stir] Update: Interim meeting. I've gotten enough direct feedback from folks asking for the 27th rather th= an the 26th to try and make that change. We'll set a virtual interim for May 27 at 10 am Pacific US / 1pm Eastern US= for 2 hours. Watch for the announcement from the secretariat for additional details. RjS On 4/7/16 3:16 PM, Robert Sparks wrote: > We are planning to have a virtual interim in the late may timeframe. > > Please hold May 26 for now (and let us know if that's problematic). > > More details will follow. > > RjS > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From nobody Thu Apr 28 09:42:24 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DDD12D1D6; Thu, 28 Apr 2016 09:42:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160428164222.5530.69828.idtracker@ietfa.amsl.com> Date: Thu, 28 Apr 2016 09:42:22 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] STIR WG Virtual Interim Meeting: May 27, 2016 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 16:42:22 -0000 The Secure Telephone Identity Revisited (STIR) WG will hold a virtual interim meeting on May 27th at 10am Pacific US/ 1pm Eastern US/ 1700 UTC for two hours. Call in details are available on the STIR WG list here: The interim will focus on finishing the group's work on these three drafts: Please watch the STIR list for finer agenda detail. From nobody Sat Apr 30 13:35:16 2016 Return-Path: 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 F000512D17F for ; Sat, 30 Apr 2016 13:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 U6X5JGhxfSST for ; Sat, 30 Apr 2016 13:35:12 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78D9012D128 for ; Sat, 30 Apr 2016 13:35:12 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id g17so86065818wme.1 for ; Sat, 30 Apr 2016 13:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:date:message-id:to :mime-version; bh=J7opXv9JmV3CiTrYoQY9BedaLL2sd4cYS+KVo63dFCM=; b=vmWCZbjLBjJFQJviv+fmeJrqF+Dn0AGAspTXYMVRWjGWvqCaQC7ZpWEUnLxvYPYvek 3vZ+lJYDk3/DAHWxWbQf9n5p0q7Vf1u7KQE/7lKhQFBCQvdfj/taB21t4Oa8+YkzRqYm R7qkhL8Is+DzWQ6V4AMXxS9c51l8W98agL0tsN/p2KHgFcxrHJZyVWiLbTGjuk8iVoxw Mcota8gOVi0fGzix9qAN4WPrG/LoCby8vA0m0pMi7rAPcSD4LwMBnidvPXgFCNisG/Rd dGqf1381QKQhjI5KgPH4b7gyMcikflEule8f8lOq6D4j3KueaSJQSsxZ25VuQ1mFDIae ry/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:to:mime-version; bh=J7opXv9JmV3CiTrYoQY9BedaLL2sd4cYS+KVo63dFCM=; b=e943Mjk89aYPWITs80gQXOOOJvg7JqFhol8vyqeOv67/sPSedsMzXGXLN9JREahLWs Te9XR3tu6DOdryuRmtPPuTyEeV1VwYgo1ZXDydblkbTN0fTZ7h/uYWb/pT6cGYoguwj5 pEmVlY/Aj4qMEGOO8Ja6QWU7lvQduRR9eRzv3d2x0GPqftJr7hqgJVckCNhxwASdNCv6 mROClh+fum5RwGidkIc5htgVKLCnIN3Z3PdrLPumryVn5OUanu8qRs8gX3Ne2Q8ZebeH nrkbLB7pdW2clVOQ93xAMBS6aEm0WyAZ+B0z0K/GL13dh8nOUgeSKomoe+DB9cbF2p4b I+Vg== X-Gm-Message-State: AOPr4FUU9yuvaYOar9gyR2a5u9nPSKpczoXFSlMfJjGHDUtnBFOtvUB3z9Am0M/rNCMhCA== X-Received: by 10.28.109.86 with SMTP id i83mr11274488wmc.75.1462048510948; Sat, 30 Apr 2016 13:35:10 -0700 (PDT) Received: from triton.lan (156.110.114.87.dyn.plus.net. [87.114.110.156]) by smtp.gmail.com with ESMTPSA id w77sm9967971wmw.10.2016.04.30.13.35.10 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 30 Apr 2016 13:35:10 -0700 (PDT) From: Alan Ford Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 30 Apr 2016 21:35:07 +0100 Message-Id: To: stir@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Archived-At: Subject: [stir] Brief review of draft-ietf-stir-rfc4474bis-08 X-BeenThere: stir@ietf.org 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: Sat, 30 Apr 2016 20:35:15 -0000 Hi all, At IETF95, Robert suggested I should review draft-ietf-stir-rfc4474bis = from an implementer's point-of-view... So I have :) I was coming at = this completely fresh - I had never read any of the document before and = had very limited background on this topic... And I must first say it's a = really accessible document, very easy to follow and understand. I have = only a few very minor comments on clarity: - Section 4, it took me a while to realise that the authentication = service typically sat as a component of Alice's home SIP proxy. Whilst = obvious once a bit more context was available, I'd suggest adding a = sentence at the end of paragraph 5 (The proxy, ...) that reads something = like "The proxy then forwards the request under normal to Bob's domain". - Section 5.1, Step 4, paragraph 3... Similarly, just insert "at the = receiver" after "In some cases, a request sent through an authentication = service will be rejected by the verification service" - helps make the = process a little clearer. - Section 5.2, it is not clear if there should be anything different in = the 488 for no Identity header, and unsupported ppt? - Section 6.3, typo "bae64" - Section 6.3, "result of the JSON object construction process", would = it not be clearer to say "the PASSporT object" or similar? There is a = clear definition of "canon" in the last paragraph of Section 8 which = could be used earlier too. - Section 6.4, "URL of the form" ? Is form the right word for = content-type here? - Section 6.4 references "this registry" -> what registry? Maybe this = should reference IANA section? Also the ref to RFC7519 to define "RS256" = should probably occur here. - Section 7.2 - could the use of the key not in some way be restricted = purely for use with SIP Identity? Therefore removing issues with giving = it to a third-party service provider? - Section 12.1, paragraph 4: "The To helps" and "over the To" -> insert = "header" after "To" for clarity since it scans really strangely = otherwise! Cheers, Alan