From nobody Mon Mar 3 02:32:04 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5B61A0E86 for ; Mon, 3 Mar 2014 02:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 LBH0cVYn-HUQ for ; Mon, 3 Mar 2014 02:31:56 -0800 (PST) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id BCD371A0E71 for ; Mon, 3 Mar 2014 02:31:56 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id i7so5257150oag.19 for ; Mon, 03 Mar 2014 02:31:54 -0800 (PST) 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 :content-type; bh=DozsxCb97g65YgsZyPhT4GdDpSW19/4y/xat4FUKf0k=; b=hKymUxghR0ngYyO8WlVfL7Jvz0b4SCtVE1pqlWKgvh/WqjPXF7ubXVa2lN0Jplrq5v g5aC9lkPlE9tM4yNGrh5A49Yq+ZwfmeZq6vXrFgphc+ymHhyWcLpnJIvLybpmGcj1i2p XkiPOqK4jlHl4ucAw3UhEGAWRt4w6GqZ1g3X2n0zHqZ49KKLu7Ot2uO2hJDCPKnkpWci G1XMa54LI7nBc5pW8LG4b+CXufecCAjFc819R3N5EGWJ3EMV5ip9IsbbNFA0ixzlASDu P5r9vxZuku/K16dfQ5gAu1srOeSzjUBkJmziD1bko02mobpjSiSx50JrNve3RqadKlXQ PkYQ== X-Gm-Message-State: ALoCoQkFsG3KABU2Pm6YE3NGtAk7gRGjXl+StriOH9xEB14myYugSLdfGKel6Ko1v4lbof/VkOZo MIME-Version: 1.0 X-Received: by 10.182.213.166 with SMTP id nt6mr1555923obc.53.1393842713931; Mon, 03 Mar 2014 02:31:53 -0800 (PST) Received: by 10.60.69.102 with HTTP; Mon, 3 Mar 2014 02:31:53 -0800 (PST) Date: Mon, 3 Mar 2014 10:31:53 +0000 Message-ID: From: Richard Barnes To: "stir@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2e60ad6461704f3b14bbf Archived-At: http://mailarchive.ietf.org/arch/msg/stir/nFcgPtspbOi504vR3hLZSBYIeIc Subject: [stir] Canonicalization vs. Comparison X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 10:32:03 -0000 --001a11c2e60ad6461704f3b14bbf Content-Type: text/plain; charset=ISO-8859-1 Just wanted to start a thread on this with an explanation of what I mean by canonicalization vs. comparison approaches. This message has a neutral explanation of the idea, without discussion of pros and cons. (I'm sure we'll get to that soon :) ) In bullet point form: Canonicalize: -- Signer receives SIP message -- Signer constructs "golden object" from information in SIP message -- Signer computes signature over golden object -- Signer inserts signature into SIP message -- ... -- Verifier receives SIP message -- Verifier reconstructs golden object from information in SIP message -- Verifier verifies signature over reconstructed golden object Compare: -- Signer receives SIP message -- Signer constructs "golden object" describing information in SIP object -- Signer computes signature over golden object -- Signer inserts golden object and signature into SIP message -- ... -- Verifier extracts golden object and signature from SIP message -- Verifier verifies signature over golden object -- Verifier verifies that SIP message matches golden object So for one example, suppose the signing algorithm defined a signature over a string of the following form (following the format of the current draft): +12125551212|+12025551212|INVITE|Thu, 21 Feb 2002 13:02:03 GMT| We'll call this string the "golden object", in the sense that it describes the signer's view of how the message should look. In the canonicalization context, the signer would build the golden object based on a SIP message, sign it, and insert the signature into an Identity header Identity: "cQhGRmuh8M...YgyQxv7NdyXz" The verifier, on receiving the SIP message, would reconstruct the golden object based on the received SIP message, and verify the signature over the reconstructed golden object. If the signature is valid, then the verifier knows that the reconstructed golden object is the same as the signed golden object, and thus the call matches the signer's description. If the signature is invalid, the verifier knows that the reconstructed golden object is different from the signed one, but does not know what the difference is. In the comparison context, the signer constructs the golden object and signature in the same way, but instead of inserting just the signature into the SIP message, inserts both the golden object and the signature. Identity: "+12125551212|+12025551212|INVITE|Thu, 21 Feb 2002 13:02:03 GMT|" "cQhGRmuh8M...YgyQxv7NdyXz" When the verifier receives the SIP message, he first verifies that the Identity header is good, by verifying the signature over the golden object in the header. If the signature is invalid, there is no basis for authenticating the call, so authentication fails. If the signature is valid, then the verifier compares the information in the golden object to the corresponding information in the SIP message. If the information matches, then the call is authenticated; if not, not. (Note: The syntax above is entirely illustrative and notional.) Hope this helps, --Richard --001a11c2e60ad6461704f3b14bbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Just wanted to start a thread on this with an explanation = of what I mean by canonicalization vs. comparison approaches. =A0This messa= ge has a neutral explanation of the idea, without discussion of pros and co= ns. =A0(I'm sure we'll get to that soon :) )

In bullet point form:

Canonica= lize:
-- Signer receives SIP message
-- Signer construc= ts "golden object" from information in SIP message
-- Signer computes signature over golden object
-- Signer inserts= signature into SIP message
-- ...
-- Verifier receives= SIP message
-- Verifier reconstructs golden object from informat= ion in SIP message
-- Verifier verifies signature over reconstructed golden object
<= div>
Compare:
-- Signer receives SIP message
<= div>-- Signer constructs "golden object" describing information i= n SIP object
-- Signer computes signature over golden object
-- Signer in= serts golden object and signature into SIP message
-- ...
-- Verifier extracts golden object and signature from SIP message
-- Verifier verifies signature over golden object
-- Verifie= r verifies that SIP message matches golden object

= So for one example, suppose the signing algorithm defined a signature over = a string of the following form (following the format of the current draft):= =A0

=A0 +12125551212|+12025551212|INVITE|Thu, 21 Feb 2002 1= 3:02:03 GMT|

We'll call this string the "= golden object", in the sense that it describes the signer's view o= f how the message should look. =A0 In the canonicalization context, the sig= ner would build the golden object based on a SIP message, sign it, and inse= rt the signature into an Identity header

=A0 Identity: "cQhGRmuh8M...YgyQxv7NdyXz"

The verifier, on receiving the SIP message, would rec= onstruct the golden object based on the received SIP message, and verify th= e signature over the reconstructed golden object. =A0If the signature is va= lid, then the verifier knows that the reconstructed golden object is the sa= me as the signed golden object, and thus the call matches the signer's = description. =A0If the signature is invalid, the verifier knows that the re= constructed golden object is different from the signed one, but does not kn= ow what the difference is.

In the comparison context, the signer constructs the go= lden object and signature in the same way, but instead of inserting just th= e signature into the SIP message, inserts both the golden object and the si= gnature.

=A0 Identity: "+12125551212|+12025551212|INVITE|Th= u, 21 Feb 2002 13:02:03 GMT|" "cQhGRmuh8M...YgyQxv7NdyXz"

When the verifier receives the SIP message, he first= verifies that the Identity header is good, by verifying the signature over= the golden object in the header. =A0If the signature is invalid, there is = no basis for authenticating the call, so authentication fails. =A0If the si= gnature is valid, then the verifier compares the information in the golden = object to the corresponding information in the SIP message. =A0If the infor= mation matches, then the call is authenticated; if not, not.

(Note: The syntax above is entirely illustrative and no= tional.)

Hope this helps,
--Richard

--001a11c2e60ad6461704f3b14bbf-- From nobody Mon Mar 3 02:51:54 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0E31A0C20 for ; Mon, 3 Mar 2014 02:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 WsUxOAJMafEn for ; Mon, 3 Mar 2014 02:51:47 -0800 (PST) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id A67261A0E9C for ; Mon, 3 Mar 2014 02:51:45 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id x3so1261586qcv.25 for ; Mon, 03 Mar 2014 02:51:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=U+kp5yK/0sRuynKsaPkogtRQU+0NxdNiOqE9NMVeRgY=; b=nOmLXRxRstLJVRbWQB3EDPEts9Y968kx4pPSOBT+gbbf2SG1gqwni6oTQm0AGoSq5m rohiTKviZqFoEzAskfefGDSqkaQo9dxx+7gMTrvtPcXZsdaL/ogRiUD+NSBJ6BSEx+7S B3xbPTgL/5b/YzTFCdn/YzkL+mSwi4AABcSlD4Rv8K4zN7e3h7yJygGiAfBSk3i03XJW 3Do8hO+P4FgT0iMJ7aDfZKHBpUwsPdVglfJ0nANMEpcIuwbJ9eOfh4+1zagxkGYT00oi Bz+GLTiFKvvDvDSNhutszKOrDNM2Ra5M6mHTdCRg0VgPxFsE+flNinuXrFzMyrBVe/GL 9oYA== X-Gm-Message-State: ALoCoQkFDX5MwN7312OCTynJgdEaQ1LhzDCgvR+BZ4DtUIQhHatoH/se38+uJLz0p8TqDBL/omPh X-Received: by 10.140.109.228 with SMTP id l91mr21298042qgf.72.1393843902637; Mon, 03 Mar 2014 02:51:42 -0800 (PST) Received: from jsch-lt510.cis.neustar.com (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id d15sm37392761qaq.4.2014.03.03.02.51.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Mar 2014 02:51:42 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Brian Rosen In-Reply-To: Date: Mon, 3 Mar 2014 10:41:48 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Richard Barnes X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/tVqg-IZtEkyZuYDcuXSKSi9uxhQ Cc: "stir@ietf.org" Subject: Re: [stir] Canonicalization vs. Comparison X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 10:51:52 -0000 This looks pretty much like what Hadriel proposed. I worry that the = forces that cause intermediaries to change =46rom will want to change = the =93golden object=94. =20 I think we should have this be optional. =20 Brian On Mar 3, 2014, at 10:31 AM, Richard Barnes wrote: > Just wanted to start a thread on this with an explanation of what I = mean by canonicalization vs. comparison approaches. This message has a = neutral explanation of the idea, without discussion of pros and cons. = (I'm sure we'll get to that soon :) ) >=20 > In bullet point form: >=20 > Canonicalize: > -- Signer receives SIP message > -- Signer constructs "golden object" from information in SIP message > -- Signer computes signature over golden object > -- Signer inserts signature into SIP message > -- ... > -- Verifier receives SIP message > -- Verifier reconstructs golden object from information in SIP message > -- Verifier verifies signature over reconstructed golden object >=20 > Compare: > -- Signer receives SIP message > -- Signer constructs "golden object" describing information in SIP = object > -- Signer computes signature over golden object > -- Signer inserts golden object and signature into SIP message > -- ... > -- Verifier extracts golden object and signature from SIP message > -- Verifier verifies signature over golden object > -- Verifier verifies that SIP message matches golden object >=20 > So for one example, suppose the signing algorithm defined a signature = over a string of the following form (following the format of the current = draft):=20 >=20 > +12125551212|+12025551212|INVITE|Thu, 21 Feb 2002 13:02:03 GMT| >=20 > We'll call this string the "golden object", in the sense that it = describes the signer's view of how the message should look. In the = canonicalization context, the signer would build the golden object based = on a SIP message, sign it, and insert the signature into an Identity = header >=20 > Identity: "cQhGRmuh8M...YgyQxv7NdyXz" >=20 > The verifier, on receiving the SIP message, would reconstruct the = golden object based on the received SIP message, and verify the = signature over the reconstructed golden object. If the signature is = valid, then the verifier knows that the reconstructed golden object is = the same as the signed golden object, and thus the call matches the = signer's description. If the signature is invalid, the verifier knows = that the reconstructed golden object is different from the signed one, = but does not know what the difference is. >=20 > In the comparison context, the signer constructs the golden object and = signature in the same way, but instead of inserting just the signature = into the SIP message, inserts both the golden object and the signature. >=20 > Identity: "+12125551212|+12025551212|INVITE|Thu, 21 Feb 2002 = 13:02:03 GMT|" "cQhGRmuh8M...YgyQxv7NdyXz" >=20 > When the verifier receives the SIP message, he first verifies that the = Identity header is good, by verifying the signature over the golden = object in the header. If the signature is invalid, there is no basis = for authenticating the call, so authentication fails. If the signature = is valid, then the verifier compares the information in the golden = object to the corresponding information in the SIP message. If the = information matches, then the call is authenticated; if not, not. >=20 > (Note: The syntax above is entirely illustrative and notional.) >=20 > Hope this helps, > --Richard >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Mon Mar 3 03:16:01 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD7C1A0CC6 for ; Mon, 3 Mar 2014 03:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 qeMCYEx-fDVc for ; Mon, 3 Mar 2014 03:15:57 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7E11A0CB7 for ; Mon, 3 Mar 2014 03:15:57 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id a6464135.2ac4d1421940.871281.00-2434.2337502.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 03 Mar 2014 11:15:54 +0000 (UTC) X-MXL-Hash: 5314646a6f51c8de-30985dd2da7cf8833240ac06e24aad5caf61cbae Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 86464135.0.871271.00-2345.2337476.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 03 Mar 2014 11:15:54 +0000 (UTC) X-MXL-Hash: 5314646a0233a84f-af0747bcad244e6817e80bf588cb2ab207bf1043 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 s23BFqko030284; Mon, 3 Mar 2014 06:15:52 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s23BFj9Q030248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2014 06:15:46 -0500 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (MISOUT7MSGHUB9A.itservices.sbc.com [144.151.223.62]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 3 Mar 2014 11:15:33 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.03.0174.001; Mon, 3 Mar 2014 06:15:33 -0500 From: "DOLLY, MARTIN C" To: Brian Rosen , Richard Barnes Thread-Topic: [stir] Canonicalization vs. Comparison Thread-Index: AQHPNsvWZLYiy4mh60+4yoZHjD/9s5rPgJUA//+0S7A= Date: Mon, 3 Mar 2014 11:15:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.94.188] 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-AnalysisOut: [v=2.0 cv=Odkv+GvY c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=QekHZKTs7PAA:10 a=ofMgfj31e3cA:10 a=VRWM_EnomncA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=GOxNYVjzF3MZFTO8-0YA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/stir/d3kiiuFo7qGY_CIVtpzpq4mD_f4 Cc: "stir@ietf.org" Subject: Re: [stir] Canonicalization vs. Comparison X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 11:15:59 -0000 To be clear (yet another time), you need to sign in a matter that our SBC's= will not change. To that end, a separate SIP header is the cleanest approa= ch. This is because certain individuals are not trustworthy, WRT the type of in= formation communicated. :) -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, March 03, 2014 5:42 AM To: Richard Barnes Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison This looks pretty much like what Hadriel proposed. I worry that the forces= that cause intermediaries to change From will want to change the "golden o= bject". =20 I think we should have this be optional. =20 Brian On Mar 3, 2014, at 10:31 AM, Richard Barnes wrote: > Just wanted to start a thread on this with an explanation of what I mean = by canonicalization vs. comparison approaches. This message has a neutral = explanation of the idea, without discussion of pros and cons. (I'm sure we= 'll get to that soon :) ) >=20 > In bullet point form: >=20 > Canonicalize: > -- Signer receives SIP message > -- Signer constructs "golden object" from information in SIP message > -- Signer computes signature over golden object > -- Signer inserts signature into SIP message > -- ... > -- Verifier receives SIP message > -- Verifier reconstructs golden object from information in SIP message > -- Verifier verifies signature over reconstructed golden object >=20 > Compare: > -- Signer receives SIP message > -- Signer constructs "golden object" describing information in SIP object > -- Signer computes signature over golden object > -- Signer inserts golden object and signature into SIP message > -- ... > -- Verifier extracts golden object and signature from SIP message > -- Verifier verifies signature over golden object > -- Verifier verifies that SIP message matches golden object >=20 > So for one example, suppose the signing algorithm defined a signature ove= r a string of the following form (following the format of the current draft= ):=20 >=20 > +12125551212|+12025551212|INVITE|Thu, 21 Feb 2002 13:02:03 GMT| >=20 > We'll call this string the "golden object", in the sense that it describe= s the signer's view of how the message should look. In the canonicalizati= on context, the signer would build the golden object based on a SIP message= , sign it, and insert the signature into an Identity header >=20 > Identity: "cQhGRmuh8M...YgyQxv7NdyXz" >=20 > The verifier, on receiving the SIP message, would reconstruct the golden = object based on the received SIP message, and verify the signature over the= reconstructed golden object. If the signature is valid, then the verifier= knows that the reconstructed golden object is the same as the signed golde= n object, and thus the call matches the signer's description. If the signa= ture is invalid, the verifier knows that the reconstructed golden object is= different from the signed one, but does not know what the difference is. >=20 > In the comparison context, the signer constructs the golden object and si= gnature in the same way, but instead of inserting just the signature into t= he SIP message, inserts both the golden object and the signature. >=20 > Identity: "+12125551212|+12025551212|INVITE|Thu, 21 Feb 2002 13:02:03 G= MT|" "cQhGRmuh8M...YgyQxv7NdyXz" >=20 > When the verifier receives the SIP message, he first verifies that the Id= entity header is good, by verifying the signature over the golden object in= the header. If the signature is invalid, there is no basis for authentica= ting the call, so authentication fails. If the signature is valid, then th= e verifier compares the information in the golden object to the correspondi= ng information in the SIP message. If the information matches, then the ca= ll is authenticated; if not, not. >=20 > (Note: The syntax above is entirely illustrative and notional.) >=20 > Hope this helps, > --Richard >=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 Mon Mar 3 06:50:38 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F67A1A0051 for ; Mon, 3 Mar 2014 06:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 yXNeljPCwiqP for ; Mon, 3 Mar 2014 06:50:34 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id B39181A002B for ; Mon, 3 Mar 2014 06:50:34 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 06:50:31 -0800 From: Michael Hammer To: "md3135@att.com" , "br@brianrosen.net" , "rlb@ipv.sx" Thread-Topic: [stir] Canonicalization vs. Comparison Thread-Index: AQHPNsvSiZrFz4GKYEmqZY//jftbrJrPsuAAgAAJbAD//7VOIA== Date: Mon, 3 Mar 2014 14:50:31 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF3AF02@sc9-ex2k10mb1.corp.yaanatech.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.3] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005E_01CF36C6.032C4090" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/xluvxn_A1FzHRaK0IlvzqMtzcPU Cc: "stir@ietf.org" Subject: Re: [stir] Canonicalization vs. Comparison X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 14:50:37 -0000 ------=_NextPart_000_005E_01CF36C6.032C4090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Richard, The inclusion of the golden object in the message is a waste, since the receiver must re-generate it anyway. The receiver cannot rely on just the golden object, since that could be spoofed. It can rely only on the one it generates itself, and can pretty much ignore the one in the message. So, this really devolves to just one case. Also, there is a danger that someone takes a short cut and does not validate the included golden object. Mike ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C Sent: Monday, March 03, 2014 6:16 AM To: Brian Rosen; Richard Barnes Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison To be clear (yet another time), you need to sign in a matter that our SBC's will not change. To that end, a separate SIP header is the cleanest approach. This is because certain individuals are not trustworthy, WRT the type of information communicated. :) -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, March 03, 2014 5:42 AM To: Richard Barnes Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison This looks pretty much like what Hadriel proposed. I worry that the forces that cause intermediaries to change From will want to change the "golden object". I think we should have this be optional. Brian On Mar 3, 2014, at 10:31 AM, Richard Barnes wrote: > Just wanted to start a thread on this with an explanation of what I mean by canonicalization vs. comparison approaches. This message has a neutral explanation of the idea, without discussion of pros and cons. (I'm sure we'll get to that soon :) ) > > In bullet point form: > > Canonicalize: > -- Signer receives SIP message > -- Signer constructs "golden object" from information in SIP message > -- Signer computes signature over golden object > -- Signer inserts signature into SIP message > -- ... > -- Verifier receives SIP message > -- Verifier reconstructs golden object from information in SIP message > -- Verifier verifies signature over reconstructed golden object > > Compare: > -- Signer receives SIP message > -- Signer constructs "golden object" describing information in SIP object > -- Signer computes signature over golden object > -- Signer inserts golden object and signature into SIP message > -- ... > -- Verifier extracts golden object and signature from SIP message > -- Verifier verifies signature over golden object > -- Verifier verifies that SIP message matches golden object > > So for one example, suppose the signing algorithm defined a signature over a string of the following form (following the format of the current draft): > > +12125551212|+12025551212|INVITE|Thu, 21 Feb 2002 13:02:03 GMT| > > We'll call this string the "golden object", in the sense that it describes the signer's view of how the message should look. In the canonicalization context, the signer would build the golden object based on a SIP message, sign it, and insert the signature into an Identity header > > Identity: "cQhGRmuh8M...YgyQxv7NdyXz" > > The verifier, on receiving the SIP message, would reconstruct the golden object based on the received SIP message, and verify the signature over the reconstructed golden object. If the signature is valid, then the verifier knows that the reconstructed golden object is the same as the signed golden object, and thus the call matches the signer's description. If the signature is invalid, the verifier knows that the reconstructed golden object is different from the signed one, but does not know what the difference is. > > In the comparison context, the signer constructs the golden object and signature in the same way, but instead of inserting just the signature into the SIP message, inserts both the golden object and the signature. > > Identity: "+12125551212|+12025551212|INVITE|Thu, 21 Feb 2002 13:02:03 GMT|" "cQhGRmuh8M...YgyQxv7NdyXz" > > When the verifier receives the SIP message, he first verifies that the Identity header is good, by verifying the signature over the golden object in the header. If the signature is invalid, there is no basis for authenticating the call, so authentication fails. If the signature is valid, then the verifier compares the information in the golden object to the corresponding information in the SIP message. If the information matches, then the call is authenticated; if not, not. > > (Note: The syntax above is entirely illustrative and notional.) > > Hope this helps, > --Richard > > _______________________________________________ > 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 ------=_NextPart_000_005E_01CF36C6.032C4090 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDMw MzE0NTAzMFowIwYJKoZIhvcNAQkEMRYEFLnjxfd23EL5CPLbBs3Ijj6Ifp4jMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAOD+/Mcm24cf6OKXaI4x5+n2hznDF4+5pMXPsk5Dx YzWlOJlRvu6JWH66CopaqMSK893qd3mhLc1pFEsJd/NGAS9IowdpFl3mLIAf77wTyTo+0eR1j30O hV2Op1A49lnc/ebES6qd/SS0D0vXuqFchw0SvfhBbZvuhKkSET1b7bx1Bh1hcECjSFDDhdyAkpyO 0h9jb7hDNQ9SCqDwhpcMushQUtN9Nzst3wkv/+mWTAon+nQP6ry5XTfYlfFlehK4suxlFDb4ZrC+ +3J6qP82ROzpWX4wmTo5JK2XDqvGn0ew+33H3pt1g/E4sbBEgNei0c7xCf7D2yfwQf77BKxYYwAA AAAAAA== ------=_NextPart_000_005E_01CF36C6.032C4090-- From nobody Mon Mar 3 11:09:02 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408781A01C1 for ; Mon, 3 Mar 2014 11:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 PPALsOgvxbYZ for ; Mon, 3 Mar 2014 11:08:58 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9491A02C7 for ; Mon, 3 Mar 2014 11:08:58 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s23J8nUE008962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Mar 2014 19:08:51 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s23J8kkD024716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2014 19:08:47 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s23J8k69024710; Mon, 3 Mar 2014 19:08:46 GMT Received: from [10.207.198.25] (/31.55.56.195) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 Mar 2014 11:08:46 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Hadriel Kaplan In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF3AF02@sc9-ex2k10mb1.corp.yaanatech.com> Date: Mon, 3 Mar 2014 14:08:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00C069FD01E0324C9FFCADF539701DB3BBF3AF02@sc9-ex2k10mb1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1827) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/stir/-5qKij6lsBp1Zi8xJhWt4yef60w Cc: "rlb@ipv.sx" , "stir@ietf.org" , "md3135@att.com" , "br@brianrosen.net" Subject: Re: [stir] Canonicalization vs. Comparison X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 19:09:00 -0000 On Mar 3, 2014, at 9:50 AM, Michael Hammer = wrote: > Richard, >=20 > The inclusion of the golden object in the message is a waste, since = the > receiver must re-generate it anyway. > The receiver cannot rely on just the golden object, since that could = be > spoofed. > It can rely only on the one it generates itself, and can pretty much = ignore > the one in the message. > So, this really devolves to just one case. Actually there were three benefits to it, identified in = draft-kaplan-stir-ikes-out-00: 1) It lets the verifier perform a very quick fail check using just = strcmp(). In other words, if the golden object it generates from the = To/=46rom don't string-match the one in the Identity-X header, then it = can go ahead and fail the verification immediately without bothering to = get the cert, do the crypto, etc. IF the strings match, then it has to = keep doing the rest of the work to verify it. 2) It helps debug problems for the folks running the systems. 3) It provides a way to do a "if-then-else" conditional, in case there = are multiple potential golden objects. I raised that at the mic today, = but kinda forgot when exactly that might happen; I just re-read the IKES = draft and it points out that in call-forwarding scenarios the verifier = may well have multiple To/=46rom canonical numbers to choose from. > Also, there is a danger that someone takes a short cut and does not = validate > the included golden object. Yup. The implementor has to follow the MUSTs. Not much we can do about = them not doing so. :( -hadriel From nobody Mon Mar 3 11:20:40 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8E31A0170 for ; Mon, 3 Mar 2014 11:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 ow4-qZ_L00FE for ; Mon, 3 Mar 2014 11:20:36 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 49EF81A00FA for ; Mon, 3 Mar 2014 11:20:36 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s23JKVS5021614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Mar 2014 19:20:32 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s23JKVku023739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2014 19:20:31 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s23JKUbk018074; Mon, 3 Mar 2014 19:20:30 GMT Received: from [10.207.198.25] (/31.55.56.195) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 Mar 2014 11:20:30 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Hadriel Kaplan In-Reply-To: Date: Mon, 3 Mar 2014 14:20:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Rosen X-Mailer: Apple Mail (2.1827) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/stir/IZZSHejfVdsOHnTYvXCPJEdCjVs Cc: Richard Barnes , "stir@ietf.org" Subject: Re: [stir] Canonicalization vs. Comparison X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 19:20:38 -0000 On Mar 3, 2014, at 5:41 AM, Brian Rosen wrote: > This looks pretty much like what Hadriel proposed. I worry that the = forces that cause intermediaries to change =46rom will want to change = the =93golden object=94. =20 If you mean change the copy in the Identity-X, I don't think they'll do = that. All that would accomplish is to fail the verification, and if = they want to do that they can just reject the message themselves; and if = they just wanted to avoid verification (Rather than fail it), they can = simply remove all Identity-* headers. The reason they change the To/=46rom user portions today is to make = calls *SUCCEED*. (there are other reasons they change the other portions = of the To/=46rom URIs, but we're really only talking about the user = portion here) > I think we should have this be optional. =20 I think it should be optional to use/check the received golden-copy (or = whatever we call the copy in the Identity-X header), but not optional to = send it. Imho, debugging and proof-of-failure is going to be really important, if = we ever hope to actually reject failed call requests. -hadriel From nobody Tue Mar 4 09:07:09 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30941A0232 for ; Tue, 4 Mar 2014 09:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=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 WgY6ac8yG1UM for ; Tue, 4 Mar 2014 09:07:06 -0800 (PST) Received: from oproxy6-pub.mail.unifiedlayer.com (oproxy6-pub.mail.unifiedlayer.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 107871A0257 for ; Tue, 4 Mar 2014 09:07:06 -0800 (PST) Received: (qmail 13350 invoked by uid 0); 4 Mar 2014 17:07:01 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.mail.unifiedlayer.com with SMTP; 4 Mar 2014 17:07:01 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=eUToaNwxL32hV36vG/NWGmu37GwxNwwERZQ3fBhfwwM=; b=Yj7S3531kfLtezMKnxo1uCyhQ+T8NJ1O0f66egOzTdifafbD2yQAmzITPSBicZRBwdGk7DMOq2yTdJDWhzYXHHYeu28lmpTGUPVWd/ncrsEN06XKG0LB3QEhlBnYMn5L; Received: from [173.79.179.104] (port=54209 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1WKso0-0001Gg-PI; Tue, 04 Mar 2014 10:07:00 -0700 From: "Richard Shockey" To: "'DOLLY, MARTIN C'" , "'Brian Rosen'" , "'Richard Barnes'" References: In-Reply-To: Date: Tue, 4 Mar 2014 12:06:56 -0500 Message-ID: <011e01cf37cc$27db1900$77914b00$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQI3Cm1PcDtnRaGaoGnANJensC/OfgIPiz9rAd2DyeCZ4hriQA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/JcjZgW7vWUxk5A2tvIzelfw0Y3k Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:07:08 -0000 +1 -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C Sent: Monday, March 03, 2014 6:16 AM To: Brian Rosen; Richard Barnes Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison To be clear (yet another time), you need to sign in a matter that our SBC's will not change. To that end, a separate SIP header is the cleanest approach. This is because certain individuals are not trustworthy, WRT the type of information communicated. :) -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, March 03, 2014 5:42 AM To: Richard Barnes Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison This looks pretty much like what Hadriel proposed. I worry that the forces that cause intermediaries to change From will want to change the "golden object". I think we should have this be optional. Brian On Mar 3, 2014, at 10:31 AM, Richard Barnes wrote: > Just wanted to start a thread on this with an explanation of what I mean by canonicalization vs. comparison approaches. This message has a neutral explanation of the idea, without discussion of pros and cons. (I'm sure we'll get to that soon :) ) > > In bullet point form: > > Canonicalize: > -- Signer receives SIP message > -- Signer constructs "golden object" from information in SIP message > -- Signer computes signature over golden object > -- Signer inserts signature into SIP message > -- ... > -- Verifier receives SIP message > -- Verifier reconstructs golden object from information in SIP message > -- Verifier verifies signature over reconstructed golden object > > Compare: > -- Signer receives SIP message > -- Signer constructs "golden object" describing information in SIP object > -- Signer computes signature over golden object > -- Signer inserts golden object and signature into SIP message > -- ... > -- Verifier extracts golden object and signature from SIP message > -- Verifier verifies signature over golden object > -- Verifier verifies that SIP message matches golden object > > So for one example, suppose the signing algorithm defined a signature over a string of the following form (following the format of the current draft): > > +12125551212|+12025551212|INVITE|Thu, 21 Feb 2002 13:02:03 GMT| > > We'll call this string the "golden object", in the sense that it describes the signer's view of how the message should look. In the canonicalization context, the signer would build the golden object based on a SIP message, sign it, and insert the signature into an Identity header > > Identity: "cQhGRmuh8M...YgyQxv7NdyXz" > > The verifier, on receiving the SIP message, would reconstruct the golden object based on the received SIP message, and verify the signature over the reconstructed golden object. If the signature is valid, then the verifier knows that the reconstructed golden object is the same as the signed golden object, and thus the call matches the signer's description. If the signature is invalid, the verifier knows that the reconstructed golden object is different from the signed one, but does not know what the difference is. > > In the comparison context, the signer constructs the golden object and signature in the same way, but instead of inserting just the signature into the SIP message, inserts both the golden object and the signature. > > Identity: "+12125551212|+12025551212|INVITE|Thu, 21 Feb 2002 13:02:03 GMT|" "cQhGRmuh8M...YgyQxv7NdyXz" > > When the verifier receives the SIP message, he first verifies that the Identity header is good, by verifying the signature over the golden object in the header. If the signature is invalid, there is no basis for authenticating the call, so authentication fails. If the signature is valid, then the verifier compares the information in the golden object to the corresponding information in the SIP message. If the information matches, then the call is authenticated; if not, not. > > (Note: The syntax above is entirely illustrative and notional.) > > Hope this helps, > --Richard > > _______________________________________________ > 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 Tue Mar 4 10:12:58 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4ACF1A02EF for ; Tue, 4 Mar 2014 10:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 vRKpUM3sREbK for ; Tue, 4 Mar 2014 10:12:50 -0800 (PST) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id E5EAA1A0187 for ; Tue, 4 Mar 2014 10:12:35 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 04 Mar 2014 18:12:01 +0000 From: "Mishra, Sanjay" X-IronPort-AV: E=Sophos;i="4.97,586,1389744000"; d="scan'208";a="665818141" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi02.verizon.com with ESMTP; 04 Mar 2014 18:12:00 +0000 Received: from fhdp1lumxc7v23.us.one.verizon.com ([166.68.59.159]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Tue, 4 Mar 2014 13:12:00 -0500 To: "stir@ietf.org" Date: Tue, 4 Mar 2014 13:11:59 -0500 Thread-Topic: Certificates for STIR Thread-Index: AQI3Cm1PcDtnRaGaoGnANJensC/OfgIPiz9rAd2DyeCZ4hriQIAAEP+Q Message-ID: <900A1E2059ADB149B905E3C8FA0046A62C8AE8514E@FHDP1LUMXC7V23.us.one.verizon.com> References: <011e01cf37cc$27db1900$77914b00$@shockey.us> In-Reply-To: <011e01cf37cc$27db1900$77914b00$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/rH7N3AKqS8L2W9P5eLxvPSAKmpo Subject: [stir] Certificates for STIR X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 18:12:52 -0000 Jon -- In the certificates for STIR presentation, on slide 3, the last bull= et is "Proof of possession"; would this be, in any way, can be abused? That= is, illegally obtained and then used? Thanks Sanjay From nobody Tue Mar 4 10:20:56 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DA91A025E for ; Tue, 4 Mar 2014 10:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=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 8n5qHq30qpVc for ; Tue, 4 Mar 2014 10:20:46 -0800 (PST) Received: from alt-proxy13.mail.unifiedlayer.com (alt-proxy13.mail.unifiedlayer.com [67.222.34.81]) by ietfa.amsl.com (Postfix) with SMTP id A79C61A01F1 for ; Tue, 4 Mar 2014 10:20:46 -0800 (PST) Received: (qmail 8411 invoked by uid 0); 4 Mar 2014 18:19:42 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy13.mail.unifiedlayer.com with SMTP; 4 Mar 2014 18:19:42 -0000 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:Message-ID:Date:Subject:To:From; bh=80II1zCIDoSvosqZ4nSpi7wjrrnntQiQlSy2FkmPW7A=; b=YYL/MgwdzyD3oKfaRzuKonZ8dIt05QVanIm68CvmBe4JBtVqPBEO3FmxVFDOkR4+8Fzpwz2F4+S1yrL+lzpWloIYwYH4b10juSwoQ2WGBh/4jaIFaYQB0X/7PRz0zyLs; Received: from [173.79.179.104] (port=49701 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1WKtwL-0004rE-Tr for stir@ietf.org; Tue, 04 Mar 2014 11:19:42 -0700 From: "Richard Shockey" To: Date: Tue, 4 Mar 2014 13:19:37 -0500 Message-ID: <001901cf37d6$4ed6c220$ec844660$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac830z7J9nSYaSMpQJS6873Urm1tww== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/7PlzoCGeZHX8NTH7x1KnBVt2x8A Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 18:20:48 -0000 > I think we should have this be optional. I think it should be optional to use/check the received golden-copy (or whatever we call the copy in the Identity-X header), but not optional to send it. Imho, debugging and proof-of-failure is going to be really important, if we ever hope to actually reject failed call requests. [RS> ] This is an excellent point. I might point out that in various national regulatory contexts the verification service (aka the terminating carrier) cannot now drop the call under any circumstances. This is the law. The intersection of the STIR method and refinements to NRA regulations will need sufficient proof the verification method is sound. This is telephony and not "the Internet". It is regulated in every nation state. It is increasingly clear that the WG needs to consider two additional constraints. Can it actually be deployed in contexts where there is a great deal of SIP already out there? This goes to Jon points and Hadrial's rebuttal in the meeting about "Well its shouldn't be too hard to deal with canonicalization in FROM:" Ya right. And costs. I'm spending a great deal of time trying to find any reasonable data on what the theoretical costs of a RPKI mechanism for phone numbers would look like. The data is all over the place and if anyone has any hints and resources they would pass along to me I'd appreciate it. We have some models out there SIDR certainly, 509 in chip and pin credit cards, HMDI video interfaces, we know the problems in SSL etc. Certs can go from .01 cent to $200. It's one thing to give a cert to the 1500 US carriers or 500 Canadian it's another thing if this drills down into a requirement that each phone number be directly signed. As an exercise in scale I typically use 2.5 times total population to estimate numbers allocated and available for service so that generally looks like 700M or so in the US, 120 M or so in the UK and 90 or so million for Canada. I agree with Alex that the probable first use case for STIR is carrier to carrier where the SBC is probably both the Authentication service at the Originating carrier and Verification Service at the Terminating carrier. It is probably easier to support the mechanism there than at the CSCF. I just don't see this being deployed directly on smartphones for the foreseeable future, Cullen may be right and I'm often wrong but that is what I think. I'd certainly like to see an effort on an enhanced CNAM display mechanism from the mobile operators and handset manufacturers first but I'm told 3GPP is looking at this but maybe I'll have a problem statement ready by Toronto. Design decisions drive costs and there are limits on what, I believe, the global telecom industry or consumers of phone numbers will tolerate. For instance I'm not sure some consumers will appreciate a PKI line item on their phone bills. There are three moving parts here first the actually mechanism on the wire and modifications to the SBC here, second the actually cost of the PKI infrastructure and last but not least the OSS/BSS systems used in telecom systems worldwide. Anyone who know what I'm talking about will realize that that is where the sink hole of money will ultimately fall into. The additional cost must be fractional to the existing cost of National Number administration and above all LNP etc. I might point out we are at a relatively unique point here especially with regards to the underlying national numbering databases. The PSTN Transition is forcing the issue of URI/NS record inclusion and clearly it would be helpful if the STIR mechanism could be grafted in as well. Also effect on post dial delay. This is not email this is real-time. The SIP headers should be renamed the SIP short story since the size is now roughly similar if History-Info is included. I just don't know here and in the immortal words of Donald Rumsfield it's the "unknown unknowns" that worry me. -hadriel _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From nobody Tue Mar 4 10:42:44 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D401A026B for ; Tue, 4 Mar 2014 10:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 BMMY8kJaLeIS for ; Tue, 4 Mar 2014 10:42:35 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 31BCD1A0002 for ; Tue, 4 Mar 2014 10:42:34 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Tue, 4 Mar 2014 10:42:32 -0800 From: Michael Hammer To: "richard@shockey.us" , "stir@ietf.org" Thread-Topic: [stir] Canonicalization vs. Comparison & now Costs Thread-Index: Ac830z7J9nSYaSMpQJS6873Urm1twwABQaYA Date: Tue, 4 Mar 2014 18:42:30 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF3BD22@sc9-ex2k10mb1.corp.yaanatech.com> References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> In-Reply-To: <001901cf37d6$4ed6c220$ec844660$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.10] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_016E_01CF37AF.96737FF0" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/Q5JDxYGgfVPlKzeouQlUaXTpIRs Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 18:42:42 -0000 ------=_NextPart_000_016E_01CF37AF.96737FF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Given the computational power of smartphones and the economy of scale of smart phones [cost=($development+$reasonable profit)/#smartphones) = pennies], it would be short-sighted to not have Internet-scale solutions as a primary solution, along with network-based legacy-oriented solutions. Else we are just designing for my grandfather's telephone network, that may soon be gone. The longer this goes on, network-based will be the exception not the rule. ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, March 04, 2014 1:20 PM To: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs > I think we should have this be optional. I think it should be optional to use/check the received golden-copy (or whatever we call the copy in the Identity-X header), but not optional to send it. Imho, debugging and proof-of-failure is going to be really important, if we ever hope to actually reject failed call requests. [RS> ] This is an excellent point. I might point out that in various national regulatory contexts the verification service (aka the terminating carrier) cannot now drop the call under any circumstances. This is the law. The intersection of the STIR method and refinements to NRA regulations will need sufficient proof the verification method is sound. This is telephony and not "the Internet". It is regulated in every nation state. It is increasingly clear that the WG needs to consider two additional constraints. Can it actually be deployed in contexts where there is a great deal of SIP already out there? This goes to Jon points and Hadrial's rebuttal in the meeting about "Well its shouldn't be too hard to deal with canonicalization in FROM:" Ya right. And costs. I'm spending a great deal of time trying to find any reasonable data on what the theoretical costs of a RPKI mechanism for phone numbers would look like. The data is all over the place and if anyone has any hints and resources they would pass along to me I'd appreciate it. We have some models out there SIDR certainly, 509 in chip and pin credit cards, HMDI video interfaces, we know the problems in SSL etc. Certs can go from .01 cent to $200. It's one thing to give a cert to the 1500 US carriers or 500 Canadian it's another thing if this drills down into a requirement that each phone number be directly signed. As an exercise in scale I typically use 2.5 times total population to estimate numbers allocated and available for service so that generally looks like 700M or so in the US, 120 M or so in the UK and 90 or so million for Canada. I agree with Alex that the probable first use case for STIR is carrier to carrier where the SBC is probably both the Authentication service at the Originating carrier and Verification Service at the Terminating carrier. It is probably easier to support the mechanism there than at the CSCF. I just don't see this being deployed directly on smartphones for the foreseeable future, Cullen may be right and I'm often wrong but that is what I think. I'd certainly like to see an effort on an enhanced CNAM display mechanism from the mobile operators and handset manufacturers first but I'm told 3GPP is looking at this but maybe I'll have a problem statement ready by Toronto. Design decisions drive costs and there are limits on what, I believe, the global telecom industry or consumers of phone numbers will tolerate. For instance I'm not sure some consumers will appreciate a PKI line item on their phone bills. There are three moving parts here first the actually mechanism on the wire and modifications to the SBC here, second the actually cost of the PKI infrastructure and last but not least the OSS/BSS systems used in telecom systems worldwide. Anyone who know what I'm talking about will realize that that is where the sink hole of money will ultimately fall into. The additional cost must be fractional to the existing cost of National Number administration and above all LNP etc. I might point out we are at a relatively unique point here especially with regards to the underlying national numbering databases. The PSTN Transition is forcing the issue of URI/NS record inclusion and clearly it would be helpful if the STIR mechanism could be grafted in as well. Also effect on post dial delay. This is not email this is real-time. The SIP headers should be renamed the SIP short story since the size is now roughly similar if History-Info is included. I just don't know here and in the immortal words of Donald Rumsfield it's the "unknown unknowns" that worry me. -hadriel _______________________________________________ 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 ------=_NextPart_000_016E_01CF37AF.96737FF0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDMw NDE4NDIyOVowIwYJKoZIhvcNAQkEMRYEFN09dpjRjlPNZmxCWsOo8km9i5gyMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAYcYyN4JmmH4UzfKlqoEp7vA2BuRVE0TPwMpfk+Kt A9V0bHkNjBLPY/XQ3wKc2HJ7dmPP2nC7+nNt+O13Gd/zr1Cank5xqZg9bEtbzCrBBh3hB9Ovn2CD qlMoUxha7x/3ehonvwbgzXeBHkxXvR5A3eVW2U1H9XR66dSFstrUxsj0AEuoUKQiV22qV3XOkuTd S3kq3THMm3blbiCjksx1B5evus4enF4BdEVlvCOykqBLLta29xv1qWznaBjAvTydzVW6zXW9H6xq H+d/74PBnB+/iz4Ky+/J8cl2ZfG8qqqS39S625YLkziZOuEXAi8uwp+mxfDDCb8INsYMQXVwYgAA AAAAAA== ------=_NextPart_000_016E_01CF37AF.96737FF0-- From nobody Tue Mar 4 10:44:02 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB571A026B for ; Tue, 4 Mar 2014 10:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 xAqJpQo4Xu8p for ; Tue, 4 Mar 2014 10:43:57 -0800 (PST) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) by ietfa.amsl.com (Postfix) with ESMTP id EF0DE1A0227 for ; Tue, 4 Mar 2014 10:43:56 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id hl1so8667070igb.4 for ; Tue, 04 Mar 2014 10:43:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Bu6hgTAKCXafAFy12kyyEnsFyVpQNSEnqX4vv4AcPBI=; b=CpbMccDQKD4W4UGDz9tUnlw8OcIAdQEo7JiBS9plHO4i4IY/rDMjzceDWoI/DNIx5X YQKmK+i4twjyXvLkogxBtRd++7oToIgccRIL090KuGWMosvgpQoB9pjCdLUstoKiuvWv PgKTjxLH9zkNxYk+vIWI9SlvR1cs1YGFuta6ArPoXJ9hxilTg4Gf0+AQ7xD2As8xP2XB xJv5Dmzedzf7Ecrmt96RzP2s1cWGv8SNf2UHnatVDFhbMOSZyL8bfhM0xEtIQSjrQEqY DQi+qJKq+FuPt2rgzwY8KGNLW1LDgw1Hd6v9Es/SnfLogXD4ln1t2uSdsZWhW1MPQy22 wPfQ== X-Gm-Message-State: ALoCoQlYzcrMubliAQeyjrSJ/wo+ARgiA5KVxWGuFkYpLzC6fIk+DKw9Q0SfPTCVwtBozhRE237F X-Received: by 10.43.61.206 with SMTP id wx14mr872972icb.43.1393958633565; Tue, 04 Mar 2014 10:43:53 -0800 (PST) Received: from wireless-a-v6.meeting.ietf.org ([2001:67c:370:176:289a:ef94:50e0:facb]) by mx.google.com with ESMTPSA id dz8sm52444972igb.5.2014.03.04.10.43.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 10:43:52 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Brian Rosen In-Reply-To: <001901cf37d6$4ed6c220$ec844660$@shockey.us> Date: Tue, 4 Mar 2014 18:43:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7CF4268D-2E96-4B5A-880A-D8F57936D897@brianrosen.net> References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/2kG5o8KTbZrM9SVRFDIcZkwKFV8 Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 18:44:01 -0000 This is the IETF, and we=92re not really into business models. We do want our work deployed, so we need to believe that it could = happen, and thus usually we tolerate a bit of discussion on how it would = work. I personally favor a =93peering requirement=94 model. Here, a service = provider puts a new requirement in its peering relationship agreements = that provide a date/percentage goal. By such-and-such a date, good = signed calling party number must be provided for X percent of calls = sent. If the peer can=92t meet this requirement, peering won=92t be = allowed. This takes at least a regulatory interpretation, maybe more. IANAL. But = a carrier can impose a number of requirements on peering (protocol, = number of trunks, =85) already. =20 The really interesting characteristic of this model is that it=92s not = real time. You can run statistics later over the log. Over time, we=92ll certainly want to get to real time checking, but we = don=92t need to be there to get a whole lot of usefulness. It doesn=92t = even take any changes at all in the terminating carrier other than = letting the new header through and logging it. The originating carrier = has to put the header on, of course. We=92re all agreeing that the service provider can decide how many certs = it has. The number can range from one per service provider to one per = TN. So, cost per cert is probably meaningless. We do want to get to a cert on each device. But we can ease into that = too. Brian On Mar 4, 2014, at 6:19 PM, Richard Shockey wrote: >=20 >=20 >> I think we should have this be optional. =20 >=20 > I think it should be optional to use/check the received golden-copy = (or > whatever we call the copy in the Identity-X header), but not optional = to > send it. >=20 > Imho, debugging and proof-of-failure is going to be really important, = if we > ever hope to actually reject failed call requests. >=20 > [RS> ] This is an excellent point. I might point out that in various > national regulatory contexts the verification service (aka the = terminating > carrier) cannot now drop the call under any circumstances. This is = the law. > The intersection of the STIR method and refinements to NRA regulations = will > need sufficient proof the verification method is sound. This is = telephony > and not "the Internet". It is regulated in every nation state.=20 >=20 > It is increasingly clear that the WG needs to consider two additional > constraints. Can it actually be deployed in contexts where there is a = great > deal of SIP already out there? This goes to Jon points and Hadrial's > rebuttal in the meeting about "Well its shouldn't be too hard to deal = with > canonicalization in FROM:" Ya right.=20 >=20 > And costs. I'm spending a great deal of time trying to find any = reasonable > data on what the theoretical costs of a RPKI mechanism for phone = numbers > would look like. The data is all over the place and if anyone has any = hints > and resources they would pass along to me I'd appreciate it. We have = some > models out there SIDR certainly, 509 in chip and pin credit cards, = HMDI > video interfaces, we know the problems in SSL etc. Certs can go from = .01 > cent to $200. =20 >=20 > It's one thing to give a cert to the 1500 US carriers or 500 Canadian = it's > another thing if this drills down into a requirement that each phone = number > be directly signed. As an exercise in scale I typically use 2.5 times = total > population to estimate numbers allocated and available for service so = that > generally looks like 700M or so in the US, 120 M or so in the UK and = 90 or > so million for Canada. I agree with Alex that the probable first use = case > for STIR is carrier to carrier where the SBC is probably both the > Authentication service at the Originating carrier and Verification = Service > at the Terminating carrier. It is probably easier to support the = mechanism > there than at the CSCF. I just don't see this being deployed directly = on > smartphones for the foreseeable future, Cullen may be right and I'm = often > wrong but that is what I think. I'd certainly like to see an effort on = an > enhanced CNAM display mechanism from the mobile operators and handset > manufacturers first but I'm told 3GPP is looking at this but maybe = I'll have > a problem statement ready by Toronto.=20 >=20 > Design decisions drive costs and there are limits on what, I believe, = the > global telecom industry or consumers of phone numbers will tolerate. = For > instance I'm not sure some consumers will appreciate a PKI line item = on > their phone bills. There are three moving parts here first the = actually > mechanism on the wire and modifications to the SBC here, second the = actually > cost of the PKI infrastructure and last but not least the OSS/BSS = systems > used in telecom systems worldwide. Anyone who know what I'm talking = about > will realize that that is where the sink hole of money will ultimately = fall > into. The additional cost must be fractional to the existing cost of > National Number administration and above all LNP etc.=20 >=20 > I might point out we are at a relatively unique point here especially = with > regards to the underlying national numbering databases. The PSTN = Transition > is forcing the issue of URI/NS record inclusion and clearly it would = be > helpful if the STIR mechanism could be grafted in as well.=20 >=20 > Also effect on post dial delay. This is not email this is real-time. = The > SIP headers should be renamed the SIP short story since the size is = now > roughly similar if History-Info is included. I just don't know here = and in > the immortal words of Donald Rumsfield it's the "unknown unknowns" = that > worry me.=20 >=20 >=20 >=20 >=20 > -hadriel >=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 Mar 4 11:27:23 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10711A0227 for ; Tue, 4 Mar 2014 11:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=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 XxE8pmVCXKpU for ; Tue, 4 Mar 2014 11:27:18 -0800 (PST) Received: from oproxy18-pub.mail.unifiedlayer.com (oproxy18-pub.mail.unifiedlayer.com [69.89.17.20]) by ietfa.amsl.com (Postfix) with SMTP id 2067E1A00F9 for ; Tue, 4 Mar 2014 11:27:18 -0800 (PST) Received: (qmail 2984 invoked by uid 0); 4 Mar 2014 19:27:08 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy18.mail.unifiedlayer.com with SMTP; 4 Mar 2014 19:27:08 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=ZEd7NiE+gMtZvBv33wCFDVj6iUi1bNyI6IMzh4bd+yU=; b=BHCioT54TVipg1VepsLbSL61xHY5ew+yHqDih+8mblpc1uytKoGM1PclIbRioYTNpQiXy+r5lXdKvx0Iv4A8vH+nlkP4o5jK8pOgNu7zgAGZQ4rW3NhH9KDhcBYsK+7m; Received: from [173.79.179.104] (port=50468 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1WKuzb-0002t9-0l; Tue, 04 Mar 2014 12:27:07 -0700 From: "Richard Shockey" To: "'Michael Hammer'" , References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBF3BD22@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF3BD22@sc9-ex2k10mb1.corp.yaanatech.com> Date: Tue, 4 Mar 2014 14:27:02 -0500 Message-ID: <003701cf37df$b9fca250$2df5e6f0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMM+v8p2Zf/9wiklc7kKQbJqsyO1AJ+9YGgmEHPJOA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/e8wHGt5ymGAFsV8fweOfQuJxUJg Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 19:27:22 -0000 -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Tuesday, March 04, 2014 1:43 PM To: richard@shockey.us; stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Given the computational power of smartphones and the economy of scale of smart phones [cost=($development+$reasonable profit)/#smartphones) = pennies], it would be short-sighted to not have Internet-scale solutions as a primary solution, along with network-based legacy-oriented solutions. [RS> ] Well we will just have to disagree wont we. If you actually believe an "internet scale solution" needs to be put in place first before you "run up the flag" IMHO the effort is doomed to failure. I seem to recall another effort at some "internet scale solution" involving telephone numbers. .. e164.arpa. I think we know what happened to that. If you can apply the solution inside a national carrier network under its CC, which I think is possible and would have the support of the NRA's then Brian Rosen may be correct that you can apply some "Forest Guide" for international traffic. I just don't understand how you think a "internet scale" solution would work. Some almighty golden apex run by Geneva? Oh that's not going to happen either. I know everyone hates ATT VZ BT DT etc but they are a fact of life. Else we are just designing for my grandfather's telephone network that may soon be gone. [RS> ] Well it's certainly transforming but its not going away and since the first part of this effort involves real E.164 then there are some constraints national law tends to impose. You can talk all you want about URI based realtime but for now I have not seen SIP:reston@dominos.com on the side of any delivery trucks. The longer this goes on, network-based will be the exception not the rule. ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, March 04, 2014 1:20 PM To: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs > I think we should have this be optional. I think it should be optional to use/check the received golden-copy (or whatever we call the copy in the Identity-X header), but not optional to send it. Imho, debugging and proof-of-failure is going to be really important, if we ever hope to actually reject failed call requests. [RS> ] This is an excellent point. I might point out that in various national regulatory contexts the verification service (aka the terminating carrier) cannot now drop the call under any circumstances. This is the law. The intersection of the STIR method and refinements to NRA regulations will need sufficient proof the verification method is sound. This is telephony and not "the Internet". It is regulated in every nation state. It is increasingly clear that the WG needs to consider two additional constraints. Can it actually be deployed in contexts where there is a great deal of SIP already out there? This goes to Jon points and Hadrial's rebuttal in the meeting about "Well its shouldn't be too hard to deal with canonicalization in FROM:" Ya right. And costs. I'm spending a great deal of time trying to find any reasonable data on what the theoretical costs of a RPKI mechanism for phone numbers would look like. The data is all over the place and if anyone has any hints and resources they would pass along to me I'd appreciate it. We have some models out there SIDR certainly, 509 in chip and pin credit cards, HMDI video interfaces, we know the problems in SSL etc. Certs can go from .01 cent to $200. It's one thing to give a cert to the 1500 US carriers or 500 Canadian it's another thing if this drills down into a requirement that each phone number be directly signed. As an exercise in scale I typically use 2.5 times total population to estimate numbers allocated and available for service so that generally looks like 700M or so in the US, 120 M or so in the UK and 90 or so million for Canada. I agree with Alex that the probable first use case for STIR is carrier to carrier where the SBC is probably both the Authentication service at the Originating carrier and Verification Service at the Terminating carrier. It is probably easier to support the mechanism there than at the CSCF. I just don't see this being deployed directly on smartphones for the foreseeable future, Cullen may be right and I'm often wrong but that is what I think. I'd certainly like to see an effort on an enhanced CNAM display mechanism from the mobile operators and handset manufacturers first but I'm told 3GPP is looking at this but maybe I'll have a problem statement ready by Toronto. Design decisions drive costs and there are limits on what, I believe, the global telecom industry or consumers of phone numbers will tolerate. For instance I'm not sure some consumers will appreciate a PKI line item on their phone bills. There are three moving parts here first the actually mechanism on the wire and modifications to the SBC here, second the actually cost of the PKI infrastructure and last but not least the OSS/BSS systems used in telecom systems worldwide. Anyone who know what I'm talking about will realize that that is where the sink hole of money will ultimately fall into. The additional cost must be fractional to the existing cost of National Number administration and above all LNP etc. I might point out we are at a relatively unique point here especially with regards to the underlying national numbering databases. The PSTN Transition is forcing the issue of URI/NS record inclusion and clearly it would be helpful if the STIR mechanism could be grafted in as well. Also effect on post dial delay. This is not email this is real-time. The SIP headers should be renamed the SIP short story since the size is now roughly similar if History-Info is included. I just don't know here and in the immortal words of Donald Rumsfield it's the "unknown unknowns" that worry me. -hadriel _______________________________________________ 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 Mar 4 12:00:08 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B48E1A0214 for ; Tue, 4 Mar 2014 12:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=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 njjgwNvR2Gqr for ; Tue, 4 Mar 2014 12:00:01 -0800 (PST) Received: from oproxy6-pub.mail.unifiedlayer.com (oproxy6-pub.mail.unifiedlayer.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 822AE1A01C1 for ; Tue, 4 Mar 2014 12:00:01 -0800 (PST) Received: (qmail 5790 invoked by uid 0); 4 Mar 2014 19:59:57 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.mail.unifiedlayer.com with SMTP; 4 Mar 2014 19:59:57 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=CqcPWnktfvRUpZkebM6pAzWiN0iWHbFUeMm0YBQUjT8=; b=bcvjbiCtjxfbz2lm7rv8K8nVgtJzF7Xkou72TqKMuIzW4yYSR7rNYlhS4YI7CUuhKBLh1eGglZ0OqWuUAMfvWHU2nXCZrj1MRNiDPatJzIIY3A5PyL44gvM+S1Qtry/u; Received: from [173.79.179.104] (port=50696 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1WKvVM-0004gN-Tz; Tue, 04 Mar 2014 12:59:57 -0700 From: "Richard Shockey" To: "'Brian Rosen'" References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <7CF4268D-2E96-4B5A-880A-D8F57936D897@brianrosen.net> In-Reply-To: <7CF4268D-2E96-4B5A-880A-D8F57936D897@brianrosen.net> Date: Tue, 4 Mar 2014 14:59:52 -0500 Message-ID: <003f01cf37e4$50046450$f00d2cf0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMM+v8p2Zf/9wiklc7kKQbJqsyO1AEmRtuqmEyXPqA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/UJ-dJTecxiBoeZs2H23MHElJ4UI Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 20:00:04 -0000 -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, March 04, 2014 1:44 PM To: Richard Shockey Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs This is the IETF, and we're not really into business models. [RS> ] Oh Brian ..please. Don't patronize me. Its beneath you. We do want our work deployed, so we need to believe that it could happen, and thus usually we tolerate a bit of discussion on how it would work. [RS> ] Bit?? Well the IETF has a mixed record on PKI at scale. DNSSEC come to mind? SIDR? It's certainly worth noting what has been done to avoid the mistakes of the past and the SSL issues certainly come to mind. But you cannot ignore costs to deploy. I personally favor a "peering requirement" model. Here, a service provider puts a new requirement in its peering relationship agreements that provide a date/percentage goal. By such-and-such a date, good signed calling party number must be provided for X percent of calls sent. If the peer can't meet this requirement, peering won't be allowed. [RS> ] Certainly voluntary agreements are preferred as we have seen now rolling out in the US but you are not going to make that decision. The carriers will and under the terms of applicable law which means SIP peering using E.164 may or may not come under the auspices of say 47 USC 251 (c) the CRTC actually imposes a single uniform voice Interconnection agreement as a counter example. That sticky wicket of "this is not the internet" keeps coming back to haunt us doesn't it. This takes at least a regulatory interpretation, maybe more. IANAL. But a carrier can impose a number of requirements on peering (protocol, number of trunks, .) already. The really interesting characteristic of this model is that it's not real time. You can run statistics later over the log. [RS> ] Huh I don't understand. Over time, we'll certainly want to get to real time checking, but we don't need to be there to get a whole lot of usefulness. It doesn't even take any changes at all in the terminating carrier other than letting the new header through and logging it. The originating carrier has to put the header on, of course. We're all agreeing that the service provider can decide how many certs it has. The number can range from one per service provider to one per TN. So, cost per cert is probably meaningless. [RS> ] Meaningless compared to what LNP in the US? Ok then you are at least targeting a range of acceptability. There would be a big difference between trying to impose 120M pounds on UK number holders or 1 pound per TN per year vs .05 pence would imply an operational cost of 6 M pounds a year if in fact that is what it could cost. Excluding startup costs and plunder the OSS vendors will impose. Now you can at least make rational design decisions based on what the customer here..the TN number holder and by inference the NRA is prepared to accept. Again the numbers are "owned" by the nation state. We do want to get to a cert on each device. But we can ease into that too. [RS> ] I agree. Though I'm skeptical. Brian On Mar 4, 2014, at 6:19 PM, Richard Shockey wrote: > > >> I think we should have this be optional. > > I think it should be optional to use/check the received golden-copy > (or whatever we call the copy in the Identity-X header), but not > optional to send it. > > Imho, debugging and proof-of-failure is going to be really important, > if we ever hope to actually reject failed call requests. > > [RS> ] This is an excellent point. I might point out that in various > national regulatory contexts the verification service (aka the > terminating > carrier) cannot now drop the call under any circumstances. This is the law. > The intersection of the STIR method and refinements to NRA regulations > will need sufficient proof the verification method is sound. This is telephony > and not "the Internet". It is regulated in every nation state. > > It is increasingly clear that the WG needs to consider two additional > constraints. Can it actually be deployed in contexts where there is a > great deal of SIP already out there? This goes to Jon points and > Hadrial's rebuttal in the meeting about "Well its shouldn't be too > hard to deal with canonicalization in FROM:" Ya right. > > And costs. I'm spending a great deal of time trying to find any > reasonable data on what the theoretical costs of a RPKI mechanism for > phone numbers would look like. The data is all over the place and if > anyone has any hints and resources they would pass along to me I'd > appreciate it. We have some models out there SIDR certainly, 509 in > chip and pin credit cards, HMDI video interfaces, we know the problems > in SSL etc. Certs can go from .01 cent to $200. > > It's one thing to give a cert to the 1500 US carriers or 500 Canadian > it's another thing if this drills down into a requirement that each > phone number be directly signed. As an exercise in scale I typically > use 2.5 times total population to estimate numbers allocated and > available for service so that generally looks like 700M or so in the > US, 120 M or so in the UK and 90 or so million for Canada. I agree > with Alex that the probable first use case for STIR is carrier to > carrier where the SBC is probably both the Authentication service at > the Originating carrier and Verification Service at the Terminating > carrier. It is probably easier to support the mechanism there than at > the CSCF. I just don't see this being deployed directly on > smartphones for the foreseeable future, Cullen may be right and I'm > often wrong but that is what I think. I'd certainly like to see an > effort on an enhanced CNAM display mechanism from the mobile operators > and handset manufacturers first but I'm told 3GPP is looking at this but maybe I'll have a problem statement ready by Toronto. > > Design decisions drive costs and there are limits on what, I believe, > the global telecom industry or consumers of phone numbers will > tolerate. For instance I'm not sure some consumers will appreciate a > PKI line item on their phone bills. There are three moving parts here > first the actually mechanism on the wire and modifications to the SBC > here, second the actually cost of the PKI infrastructure and last but > not least the OSS/BSS systems used in telecom systems worldwide. > Anyone who know what I'm talking about will realize that that is where the sink hole of money will ultimately fall > into. The additional cost must be fractional to the existing cost of > National Number administration and above all LNP etc. > > I might point out we are at a relatively unique point here especially > with regards to the underlying national numbering databases. The PSTN > Transition is forcing the issue of URI/NS record inclusion and > clearly it would be helpful if the STIR mechanism could be grafted in as well. > > Also effect on post dial delay. This is not email this is real-time. > The SIP headers should be renamed the SIP short story since the size > is now roughly similar if History-Info is included. I just don't know > here and in the immortal words of Donald Rumsfield it's the "unknown > unknowns" that worry me. > > > > > -hadriel > > _______________________________________________ > 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 Tue Mar 4 13:38:18 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6011A02D6 for ; Tue, 4 Mar 2014 13:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 Za-aqt0vGfMB for ; Tue, 4 Mar 2014 13:38:10 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id C56501A0316 for ; Tue, 4 Mar 2014 13:38:09 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Tue, 4 Mar 2014 13:38:05 -0800 From: Michael Hammer To: "richard@shockey.us" , "stir@ietf.org" Thread-Topic: [stir] Canonicalization vs. Comparison & now Costs Thread-Index: Ac830z7J9nSYaSMpQJS6873Urm1twwABQaYAABKgKwAADMUisA== Date: Tue, 4 Mar 2014 21:38:04 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF3BF50@sc9-ex2k10mb1.corp.yaanatech.com> References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBF3BD22@sc9-ex2k10mb1.corp.yaanatech.com> <003701cf37df$b9fca250$2df5e6f0$@shockey.us> In-Reply-To: <003701cf37df$b9fca250$2df5e6f0$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.10] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0223_01CF37C8.1CD85440" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/bkuzVrSNKTRzdXfOqIuXNm4wDdY Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 21:38:15 -0000 ------=_NextPart_000_0223_01CF37C8.1CD85440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Richard, I was reacting to the notion that the solution had to be expensive and that everything would be done in nodes like SBC and CSCF. I am not saying that carriers won't be involved, or that this won't involve E.164 numbering resources, and associated authority delegations. Or, that proxies for dumb phones won't be needed. But, let's not make this so that phones must be dumb in the STIR design. This just started to feel like an ITU-T meeting than an IETF discussion. :) Didn't mean to stir up a hornets nest, but also don't fall into old habits. Mike ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Tuesday, March 04, 2014 2:27 PM To: Michael Hammer; stir@ietf.org Subject: RE: [stir] Canonicalization vs. Comparison & now Costs -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Tuesday, March 04, 2014 1:43 PM To: richard@shockey.us; stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Given the computational power of smartphones and the economy of scale of smart phones [cost=($development+$reasonable profit)/#smartphones) = pennies], it would be short-sighted to not have Internet-scale solutions as a primary solution, along with network-based legacy-oriented solutions. [RS> ] Well we will just have to disagree wont we. If you actually believe an "internet scale solution" needs to be put in place first before you "run up the flag" IMHO the effort is doomed to failure. I seem to recall another effort at some "internet scale solution" involving telephone numbers. .. e164.arpa. I think we know what happened to that. If you can apply the solution inside a national carrier network under its CC, which I think is possible and would have the support of the NRA's then Brian Rosen may be correct that you can apply some "Forest Guide" for international traffic. I just don't understand how you think a "internet scale" solution would work. Some almighty golden apex run by Geneva? Oh that's not going to happen either. I know everyone hates ATT VZ BT DT etc but they are a fact of life. Else we are just designing for my grandfather's telephone network that may soon be gone. [RS> ] Well it's certainly transforming but its not going away and since the first part of this effort involves real E.164 then there are some constraints national law tends to impose. You can talk all you want about URI based realtime but for now I have not seen SIP:reston@dominos.com on the side of any delivery trucks. The longer this goes on, network-based will be the exception not the rule. ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, March 04, 2014 1:20 PM To: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs > I think we should have this be optional. I think it should be optional to use/check the received golden-copy (or whatever we call the copy in the Identity-X header), but not optional to send it. Imho, debugging and proof-of-failure is going to be really important, if we ever hope to actually reject failed call requests. [RS> ] This is an excellent point. I might point out that in various national regulatory contexts the verification service (aka the terminating carrier) cannot now drop the call under any circumstances. This is the law. The intersection of the STIR method and refinements to NRA regulations will need sufficient proof the verification method is sound. This is telephony and not "the Internet". It is regulated in every nation state. It is increasingly clear that the WG needs to consider two additional constraints. Can it actually be deployed in contexts where there is a great deal of SIP already out there? This goes to Jon points and Hadrial's rebuttal in the meeting about "Well its shouldn't be too hard to deal with canonicalization in FROM:" Ya right. And costs. I'm spending a great deal of time trying to find any reasonable data on what the theoretical costs of a RPKI mechanism for phone numbers would look like. The data is all over the place and if anyone has any hints and resources they would pass along to me I'd appreciate it. We have some models out there SIDR certainly, 509 in chip and pin credit cards, HMDI video interfaces, we know the problems in SSL etc. Certs can go from .01 cent to $200. It's one thing to give a cert to the 1500 US carriers or 500 Canadian it's another thing if this drills down into a requirement that each phone number be directly signed. As an exercise in scale I typically use 2.5 times total population to estimate numbers allocated and available for service so that generally looks like 700M or so in the US, 120 M or so in the UK and 90 or so million for Canada. I agree with Alex that the probable first use case for STIR is carrier to carrier where the SBC is probably both the Authentication service at the Originating carrier and Verification Service at the Terminating carrier. It is probably easier to support the mechanism there than at the CSCF. I just don't see this being deployed directly on smartphones for the foreseeable future, Cullen may be right and I'm often wrong but that is what I think. I'd certainly like to see an effort on an enhanced CNAM display mechanism from the mobile operators and handset manufacturers first but I'm told 3GPP is looking at this but maybe I'll have a problem statement ready by Toronto. Design decisions drive costs and there are limits on what, I believe, the global telecom industry or consumers of phone numbers will tolerate. For instance I'm not sure some consumers will appreciate a PKI line item on their phone bills. There are three moving parts here first the actually mechanism on the wire and modifications to the SBC here, second the actually cost of the PKI infrastructure and last but not least the OSS/BSS systems used in telecom systems worldwide. Anyone who know what I'm talking about will realize that that is where the sink hole of money will ultimately fall into. The additional cost must be fractional to the existing cost of National Number administration and above all LNP etc. I might point out we are at a relatively unique point here especially with regards to the underlying national numbering databases. The PSTN Transition is forcing the issue of URI/NS record inclusion and clearly it would be helpful if the STIR mechanism could be grafted in as well. Also effect on post dial delay. This is not email this is real-time. The SIP headers should be renamed the SIP short story since the size is now roughly similar if History-Info is included. I just don't know here and in the immortal words of Donald Rumsfield it's the "unknown unknowns" that worry me. -hadriel _______________________________________________ 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 ------=_NextPart_000_0223_01CF37C8.1CD85440 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDMw NDIxMzgwM1owIwYJKoZIhvcNAQkEMRYEFAl4qrNNFK6b6/+vx9yR2tXNjkpcMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAW0tKfLdWOcfRxxu4gseHccJeuDn0LVaF13lhfho3 QVng0aejrBgN0B4RlC7QTY6eJThYL3q4VP3TlcsNijXbvqxQ8vRJHpfMN91GFnScKTBFjKHM9B1T LCF3IFfsU8/NOeK9bCOeJJbiFkk5SUTLOUAms1GJ3eQplcFsBVbzrNrTimk9xz6ikl6V6A51W5pl 2pu83NYfxZeD9wI0254U4MdJj6DxSSIf5UkuC6ytMkPz2Bd4h4tB/NilQ18FwWB+gt5rAh5k1hSh S+rQCh6+vZ3+74F/RbRIsUvNy6v/A3tIQC0vOS4FKrwXYypIJRVXJ/B8Cjvuva50tig/cvbNmAAA AAAAAA== ------=_NextPart_000_0223_01CF37C8.1CD85440-- From nobody Tue Mar 4 14:15:47 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879EA1A0329 for ; Tue, 4 Mar 2014 14:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, LOTS_OF_MONEY=0.001] autolearn=ham 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 edDCb2Xh2YMv for ; Tue, 4 Mar 2014 14:15:40 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id C668A1A0164 for ; Tue, 4 Mar 2014 14:15:40 -0800 (PST) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta03.emeryville.ca.mail.comcast.net with comcast id ZX1n1n0041HpZEsA3aFddd; Tue, 04 Mar 2014 22:15:37 +0000 Received: from BOBO1A.bobotek.net ([76.22.113.196]) by omta14.emeryville.ca.mail.comcast.net with comcast id ZaFc1n0084EJ4tY8aaFcHQ; Tue, 04 Mar 2014 22:15:37 +0000 Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Tue, 4 Mar 2014 14:09:35 -0800 From: Alex Bobotek To: Richard Shockey Date: Tue, 4 Mar 2014 14:09:34 -0800 Thread-Topic: [stir] Canonicalization vs. Comparison & now Costs Thread-Index: Ac839m0pFwe4bJ+QR7e/0Solljqaaw== Message-ID: <0031BB56-FCF9-443C-8105-9CB4153AF18B@bobotek.net> References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <7CF4268D-2E96-4B5A-880A-D8F57936D897@brianrosen.net> <003f01cf37e4$50046450$f00d2cf0$@shockey.us> In-Reply-To: <003f01cf37e4$50046450$f00d2cf0$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393971337; bh=QY3pfeWrf99nxIvYIGL9JuRDrqjnzJ+zS5yxmOY7lY8=; h=Received:Received:Received:From:To:Date:Subject:Message-ID: Content-Type:MIME-Version; b=AjjkxDfqnJCYuyfOzDS1LQtZ7c2YYW/OmqooNdGZExZQvLquIYD6tOGbTPeJFJapY Lvr9uKNH8Z+SUT91ok2fmEtj2wlPkm15DsegnW129kdCUK4JmuhTw5Juvlsr9YtbcZ CLWv/QDk3oZQ6rh5J+JiXzYKGHDj3XXWq0hi3bFdfwkpjq9xm4pvjzV0cX58K7Lx28 CB/IAiY5BHeaguO82XUhSgRWt8aXXyeeviqqPPXGuzi1MDIw4Ga0jWjOsW6bwahTrG 2EJ4N+IItjkw1PO5twsXaINvlJXXaxE8bdaW5zqo0+IENDy/aMc+S2baPpZocJF75c v9z/zOafWQifQ== Archived-At: http://mailarchive.ietf.org/arch/msg/stir/F0qm-CIjYk8cgKllNuwOYtEdMys Cc: "stir@ietf.org" , Brian Rosen Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 22:15:44 -0000 > [RS> ] Bit?? Well the IETF has a mixed record on PKI at scale. DNSSEC c= ome > to mind? SIDR? It's certainly worth noting what has been done to avoid t= he > mistakes of the past and the SSL issues certainly come to mind. But you > cannot ignore costs to deploy.=20 +1 Large scale certificate management presents operational issues that may del= ay, complicate and prevent deployments, and post-deployment system issues t= hat may degrade call completion. =20 Which candidate mechanisms have operational experience that supports their = operability? =20 DKIM deployments (public keys in DNS) have been successful, but there, even= scheduled key rotation has been surprisingly more operationally complex th= an expected. One model that may reduce operational complexity that I've been pondering i= nvolves leveraging ENUM for public key storage and/or selection in schemes = where the originating service provider authenticates and signs. Based on t= he assumption that ENUM is more secure than DNS, this may provide adequate = security with less onerous operational complexity. Regards, Alex=20 On Mar 4, 2014, at 8:54 PM, "Richard Shockey" wrote: >=20 >=20 > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Tuesday, March 04, 2014 1:44 PM > To: Richard Shockey > Cc: stir@ietf.org > Subject: Re: [stir] Canonicalization vs. Comparison & now Costs >=20 > This is the IETF, and we're not really into business models. >=20 > [RS> ] Oh Brian ..please. Don't patronize me. Its beneath you. >=20 >=20 > We do want our work deployed, so we need to believe that it could happen, > and thus usually we tolerate a bit of discussion on how it would work. >=20 > [RS> ] Bit?? Well the IETF has a mixed record on PKI at scale. DNSSEC c= ome > to mind? SIDR? It's certainly worth noting what has been done to avoid t= he > mistakes of the past and the SSL issues certainly come to mind. But you > cannot ignore costs to deploy.=20 >=20 > I personally favor a "peering requirement" model. Here, a service provid= er > puts a new requirement in its peering relationship agreements that provid= e a > date/percentage goal. By such-and-such a date, good signed calling party > number must be provided for X percent of calls sent. If the peer can't m= eet > this requirement, peering won't be allowed. >=20 > [RS> ] Certainly voluntary agreements are preferred as we have seen now > rolling out in the US but you are not going to make that decision. The > carriers will and under the terms of applicable law which means SIP peeri= ng > using E.164 may or may not come under the auspices of say 47 USC 251 (c) = the > CRTC actually imposes a single uniform voice Interconnection agreement as= a > counter example. That sticky wicket of "this is not the internet" keeps > coming back to haunt us doesn't it. =20 >=20 > This takes at least a regulatory interpretation, maybe more. IANAL. But = a > carrier can impose a number of requirements on peering (protocol, number = of > trunks, .) already. =20 >=20 > The really interesting characteristic of this model is that it's not real > time. You can run statistics later over the log. > [RS> ] Huh I don't understand.=20 >=20 > Over time, we'll certainly want to get to real time checking, but we don'= t > need to be there to get a whole lot of usefulness. It doesn't even take = any > changes at all in the terminating carrier other than letting the new head= er > through and logging it. The originating carrier has to put the header on= , > of course. >=20 > We're all agreeing that the service provider can decide how many certs it > has. The number can range from one per service provider to one per TN. = So, > cost per cert is probably meaningless. >=20 > [RS> ] Meaningless compared to what LNP in the US? Ok then you > are at least targeting a range of acceptability. There would be a big > difference between trying to impose 120M pounds on UK number holders or 1 > pound per TN per year vs .05 pence would imply an operational cost of 6 M > pounds a year if in fact that is what it could cost. Excluding startup > costs and plunder the OSS vendors will impose. Now you can at least make > rational design decisions based on what the customer here..the TN number > holder and by inference the NRA is prepared to accept. Again the numbers > are "owned" by the nation state. =20 >=20 > We do want to get to a cert on each device. But we can ease into that to= o. > [RS> ] I agree. Though I'm skeptical.=20 >=20 > Brian >=20 >=20 > On Mar 4, 2014, at 6:19 PM, Richard Shockey wrote: >=20 >>=20 >>=20 >>> I think we should have this be optional. =20 >>=20 >> I think it should be optional to use/check the received golden-copy=20 >> (or whatever we call the copy in the Identity-X header), but not=20 >> optional to send it. >>=20 >> Imho, debugging and proof-of-failure is going to be really important,=20 >> if we ever hope to actually reject failed call requests. >>=20 >> [RS> ] This is an excellent point. I might point out that in various=20 >> national regulatory contexts the verification service (aka the=20 >> terminating >> carrier) cannot now drop the call under any circumstances. This is the > law. >> The intersection of the STIR method and refinements to NRA regulations=20 >> will need sufficient proof the verification method is sound. This is > telephony >> and not "the Internet". It is regulated in every nation state.=20 >>=20 >> It is increasingly clear that the WG needs to consider two additional=20 >> constraints. Can it actually be deployed in contexts where there is a=20 >> great deal of SIP already out there? This goes to Jon points and=20 >> Hadrial's rebuttal in the meeting about "Well its shouldn't be too=20 >> hard to deal with canonicalization in FROM:" Ya right. >>=20 >> And costs. I'm spending a great deal of time trying to find any=20 >> reasonable data on what the theoretical costs of a RPKI mechanism for=20 >> phone numbers would look like. The data is all over the place and if=20 >> anyone has any hints and resources they would pass along to me I'd=20 >> appreciate it. We have some models out there SIDR certainly, 509 in=20 >> chip and pin credit cards, HMDI video interfaces, we know the problems=20 >> in SSL etc. Certs can go from .01 cent to $200. >>=20 >> It's one thing to give a cert to the 1500 US carriers or 500 Canadian=20 >> it's another thing if this drills down into a requirement that each=20 >> phone number be directly signed. As an exercise in scale I typically=20 >> use 2.5 times total population to estimate numbers allocated and=20 >> available for service so that generally looks like 700M or so in the=20 >> US, 120 M or so in the UK and 90 or so million for Canada. I agree=20 >> with Alex that the probable first use case for STIR is carrier to=20 >> carrier where the SBC is probably both the Authentication service at=20 >> the Originating carrier and Verification Service at the Terminating=20 >> carrier. It is probably easier to support the mechanism there than at=20 >> the CSCF. I just don't see this being deployed directly on=20 >> smartphones for the foreseeable future, Cullen may be right and I'm=20 >> often wrong but that is what I think. I'd certainly like to see an=20 >> effort on an enhanced CNAM display mechanism from the mobile operators=20 >> and handset manufacturers first but I'm told 3GPP is looking at this but > maybe I'll have a problem statement ready by Toronto. >>=20 >> Design decisions drive costs and there are limits on what, I believe,=20 >> the global telecom industry or consumers of phone numbers will=20 >> tolerate. For instance I'm not sure some consumers will appreciate a=20 >> PKI line item on their phone bills. There are three moving parts here=20 >> first the actually mechanism on the wire and modifications to the SBC=20 >> here, second the actually cost of the PKI infrastructure and last but=20 >> not least the OSS/BSS systems used in telecom systems worldwide. =20 >> Anyone who know what I'm talking about will realize that that is where t= he > sink hole of money will ultimately fall >> into. The additional cost must be fractional to the existing cost of >> National Number administration and above all LNP etc.=20 >>=20 >> I might point out we are at a relatively unique point here especially=20 >> with regards to the underlying national numbering databases. The PSTN=20 >> Transition is forcing the issue of URI/NS record inclusion and=20 >> clearly it would be helpful if the STIR mechanism could be grafted in as > well. >>=20 >> Also effect on post dial delay. This is not email this is real-time. =20 >> The SIP headers should be renamed the SIP short story since the size=20 >> is now roughly similar if History-Info is included. I just don't know=20 >> here and in the immortal words of Donald Rumsfield it's the "unknown=20 >> unknowns" that worry me. >>=20 >>=20 >>=20 >>=20 >> -hadriel >>=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 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Tue Mar 4 14:54:22 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA231A0022 for ; Tue, 4 Mar 2014 14:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=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 tSwd2b-bbHXC for ; Tue, 4 Mar 2014 14:54:16 -0800 (PST) Received: from oproxy7-pub.mail.unifiedlayer.com (oproxy7-pub.mail.unifiedlayer.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 737241A001A for ; Tue, 4 Mar 2014 14:54:16 -0800 (PST) Received: (qmail 23745 invoked by uid 0); 4 Mar 2014 22:53:11 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.mail.unifiedlayer.com with SMTP; 4 Mar 2014 22:53:11 -0000 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:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=cjW2BU3aBCGki4s2L17XqOOssjmcsVm4YXbv9MsHZPA=; b=Ov5Fg5snwWD80DybJ+JgTMvFBU5yJw6SPBgL1yBGLpsVv84G56ZU+eitFeoUcDyyBzXkyaFHvVfO7E9327+kAPcXpJkIZAvBgxwOhBv1BgD5Iu9FCHskyifXU6pXZpEA; Received: from [173.79.179.104] (port=52459 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1WKyD0-00067s-Io; Tue, 04 Mar 2014 15:53:10 -0700 From: "Richard Shockey" To: "'Michael Hammer'" , References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBF3BD22@sc9-ex2k10mb1.corp.yaanatech.com> <003701cf37df$b9fca250$2df5e6f0$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBF3BF50@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF3BF50@sc9-ex2k10mb1.corp.yaanatech.com> Date: Tue, 4 Mar 2014 17:53:05 -0500 Message-ID: <00b401cf37fc$8317b910$89472b30$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMM+v8p2Zf/9wiklc7kKQbJqsyO1AJ+9YGgAadEGtoB9PuxC5glIjIQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/DQHUtRUHELMHw6SfLK3jbIOS7y8 Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 22:54:20 -0000 -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Tuesday, March 04, 2014 4:38 PM To: richard@shockey.us; stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Richard, I was reacting to the notion that the solution had to be expensive and that everything would be done in nodes like SBC and CSCF. [RS> ] Well then I should apologize. I certainly didn't mean that, only that given the realities and the extreme pressure NRA's and the legislative types are looking at from real people looking for real answers to real and literally life threating scenarios its entirely probable that it is within carriers networks where it would be deployed first. I could be wrong. I am not saying that carriers won't be involved, or that this won't involve E.164 numbering resources, and associated authority delegations. Or, that proxies for dumb phones won't be needed. But, let's not make this so that phones must be dumb in the STIR design. [RS> ] Of course not. It would eventually help to see the "Usual Suspects" Apple Samsung etal and 3GPP weigh in on this but there is time enough for that. Certainly on the display CNIT side. This just started to feel like an ITU-T meeting than an IETF discussion. :) [RS> ] Well been there done that as you well know. Some of it is actually inevitable. Its real telephony now, not the "Internet" there are real laws involved and real delegated authority against the namespace in question. The Public SIP Telephone Network. I do spend a fair amount of time actually trying to explain to regulatory legal types the difference between VoIP and VuIP Voice Using IP. These are actually different constructs due to the nature of the service and the public policy issues and requirements associated with them. Didn't mean to stir up a hornets nest, but also don't fall into old habits. [RS> ] It's inevitable. It can't be avoided now any more than when I was Co-Chairing ENUM. It's the nature of the beast at this point. That said this work MUST be done and done correctly and in a manner that can actually be explained to both number holders and the regulators. Of that I have no doubt. As a side bar to a NRA, this is simply one of a series of tools they have to look at. Look at the UK .. the UK tabloids are still pumping out stories of caller ID spoofing to hack voice mail boxes. Inquiries Commissions etc. You don't think OFCOM has noticed? :-) It is political. People are pissed off and the message has been circurlated. Mike ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Tuesday, March 04, 2014 2:27 PM To: Michael Hammer; stir@ietf.org Subject: RE: [stir] Canonicalization vs. Comparison & now Costs -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Tuesday, March 04, 2014 1:43 PM To: richard@shockey.us; stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Given the computational power of smartphones and the economy of scale of smart phones [cost=($development+$reasonable profit)/#smartphones) = pennies], it would be short-sighted to not have Internet-scale solutions as a primary solution, along with network-based legacy-oriented solutions. [RS> ] Well we will just have to disagree wont we. If you actually believe an "internet scale solution" needs to be put in place first before you "run up the flag" IMHO the effort is doomed to failure. I seem to recall another effort at some "internet scale solution" involving telephone numbers. .. e164.arpa. I think we know what happened to that. If you can apply the solution inside a national carrier network under its CC, which I think is possible and would have the support of the NRA's then Brian Rosen may be correct that you can apply some "Forest Guide" for international traffic. I just don't understand how you think a "internet scale" solution would work. Some almighty golden apex run by Geneva? Oh that's not going to happen either. I know everyone hates ATT VZ BT DT etc but they are a fact of life. Else we are just designing for my grandfather's telephone network that may soon be gone. [RS> ] Well it's certainly transforming but its not going away and since the first part of this effort involves real E.164 then there are some constraints national law tends to impose. You can talk all you want about URI based realtime but for now I have not seen SIP:reston@dominos.com on the side of any delivery trucks. The longer this goes on, network-based will be the exception not the rule. ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, March 04, 2014 1:20 PM To: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs > I think we should have this be optional. I think it should be optional to use/check the received golden-copy (or whatever we call the copy in the Identity-X header), but not optional to send it. Imho, debugging and proof-of-failure is going to be really important, if we ever hope to actually reject failed call requests. [RS> ] This is an excellent point. I might point out that in various national regulatory contexts the verification service (aka the terminating carrier) cannot now drop the call under any circumstances. This is the law. The intersection of the STIR method and refinements to NRA regulations will need sufficient proof the verification method is sound. This is telephony and not "the Internet". It is regulated in every nation state. It is increasingly clear that the WG needs to consider two additional constraints. Can it actually be deployed in contexts where there is a great deal of SIP already out there? This goes to Jon points and Hadrial's rebuttal in the meeting about "Well its shouldn't be too hard to deal with canonicalization in FROM:" Ya right. And costs. I'm spending a great deal of time trying to find any reasonable data on what the theoretical costs of a RPKI mechanism for phone numbers would look like. The data is all over the place and if anyone has any hints and resources they would pass along to me I'd appreciate it. We have some models out there SIDR certainly, 509 in chip and pin credit cards, HMDI video interfaces, we know the problems in SSL etc. Certs can go from .01 cent to $200. It's one thing to give a cert to the 1500 US carriers or 500 Canadian it's another thing if this drills down into a requirement that each phone number be directly signed. As an exercise in scale I typically use 2.5 times total population to estimate numbers allocated and available for service so that generally looks like 700M or so in the US, 120 M or so in the UK and 90 or so million for Canada. I agree with Alex that the probable first use case for STIR is carrier to carrier where the SBC is probably both the Authentication service at the Originating carrier and Verification Service at the Terminating carrier. It is probably easier to support the mechanism there than at the CSCF. I just don't see this being deployed directly on smartphones for the foreseeable future, Cullen may be right and I'm often wrong but that is what I think. I'd certainly like to see an effort on an enhanced CNAM display mechanism from the mobile operators and handset manufacturers first but I'm told 3GPP is looking at this but maybe I'll have a problem statement ready by Toronto. Design decisions drive costs and there are limits on what, I believe, the global telecom industry or consumers of phone numbers will tolerate. For instance I'm not sure some consumers will appreciate a PKI line item on their phone bills. There are three moving parts here first the actually mechanism on the wire and modifications to the SBC here, second the actually cost of the PKI infrastructure and last but not least the OSS/BSS systems used in telecom systems worldwide. Anyone who know what I'm talking about will realize that that is where the sink hole of money will ultimately fall into. The additional cost must be fractional to the existing cost of National Number administration and above all LNP etc. I might point out we are at a relatively unique point here especially with regards to the underlying national numbering databases. The PSTN Transition is forcing the issue of URI/NS record inclusion and clearly it would be helpful if the STIR mechanism could be grafted in as well. Also effect on post dial delay. This is not email this is real-time. The SIP headers should be renamed the SIP short story since the size is now roughly similar if History-Info is included. I just don't know here and in the immortal words of Donald Rumsfield it's the "unknown unknowns" that worry me. -hadriel _______________________________________________ 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 Mar 4 15:12:05 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E0D1A0079 for ; Tue, 4 Mar 2014 15:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 loiT0pTOgFwI for ; Tue, 4 Mar 2014 15:11:57 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id B271E1A007F for ; Tue, 4 Mar 2014 15:11:56 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 9bd56135.0.649204.00-2277.1824781.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 04 Mar 2014 23:11:53 +0000 (UTC) X-MXL-Hash: 53165db9120bcef2-98232465d55fb6d6c4b1ec4f2765933986936c86 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 s24NBrjd002086; Tue, 4 Mar 2014 18:11:53 -0500 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 s24NBitY001941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2014 18:11:49 -0500 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 4 Mar 2014 23:11:22 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0174.001; Tue, 4 Mar 2014 18:11:21 -0500 From: "DOLLY, MARTIN C" To: Michael Hammer , "richard@shockey.us" , "stir@ietf.org" Thread-Topic: [stir] Canonicalization vs. Comparison & now Costs Thread-Index: Ac830z7J9nSYaSMpQJS6873Urm1twwABQaYAAAxW2AAABJOHAAAHUhKA Date: Tue, 4 Mar 2014 23:11:21 +0000 Message-ID: References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBF3BD22@sc9-ex2k10mb1.corp.yaanatech.com> <003701cf37df$b9fca250$2df5e6f0$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBF3BF50@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF3BF50@sc9-ex2k10mb1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.80.104] 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-AnalysisOut: [v=2.0 cv=N4Oe4RBB c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=rwhCyAUayqcA:10 a=ofMgfj31e3cA:10 a=SYMxVWJXx5IA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=scBmumm3AAAA:8 a=BZKT7aY6AAAA:8 ] X-AnalysisOut: [a=ujOFeGflCJ3gNem91jYA:9 a=CjuIK1q_8ugA:10 a=_Fszbdv8evYA:] X-AnalysisOut: [10 a=iw2rBIYVBUAA:10 a=lZB815dzVvQA:10 a=vRAbILRZcFsA:10 a] X-AnalysisOut: [=E7MB4TUEIZIA:10 a=2l_sA4PumR8A:10 a=4HxaA6dWzeO3RirG:21 a] X-AnalysisOut: [=OxwByFHWqTYqp0YF:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/stir/2w1a7ZFNLkdwAsx9sMZ0t22SzXU Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 23:12:04 -0000 Mike, While smartphones are mini computers, the dialer app is one of the secure a= pps on a phone, and therefore unlikely to have an API access to it. So, please explain to me how a smartphone solution would work, across all p= hones? Thank you, Martin -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Tuesday, March 04, 2014 4:38 PM To: richard@shockey.us; stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Richard, I was reacting to the notion that the solution had to be expensive and that everything would be done in nodes like SBC and CSCF. I am not saying that carriers won't be involved, or that this won't involve E.164 numbering resources, and associated authority delegations. Or, that proxies for dumb phones won't be needed. But, let's not make this so that phones must be dumb in the STIR design. This just started to feel like an ITU-T meeting than an IETF discussion. := ) Didn't mean to stir up a hornets nest, but also don't fall into old habits= . Mike ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: Tuesday, March 04, 2014 2:27 PM To: Michael Hammer; stir@ietf.org Subject: RE: [stir] Canonicalization vs. Comparison & now Costs -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Tuesday, March 04, 2014 1:43 PM To: richard@shockey.us; stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Given the computational power of smartphones and the economy of scale of smart phones [cost=3D($development+$reasonable profit)/#smartphones) =3D pennies], it would be short-sighted to not have Internet-scale solutions as a primary solution, along with network-based legacy-oriented solutions. [RS> ] Well we will just have to disagree wont we. If you actually believe an "internet scale solution" needs to be put in place first before you "run up the flag" IMHO the effort is doomed to failure. I seem to recall another effort at some "internet scale solution" involving telephone numbers. .. e164.arpa. I think we know what happened to that. If you can apply the solution inside a national carrier network under its CC, which I think is possible and would have the support of the NRA's then Brian Rosen may be correct that you can apply some "Forest Guide" for international traffic. I just don't understand how you think a "internet scale" solution would work. Some almighty golden apex run by Geneva? Oh that's not going to happen either. I know everyone hates ATT VZ BT DT etc but the= y are a fact of life.=20 Else we are just designing for my grandfather's telephone network that may soon be gone. [RS> ] Well it's certainly transforming but its not going away and since th= e first part of this effort involves real E.164 then there are some constraints national law tends to impose. You can talk all you want about URI based realtime but for now I have not seen SIP:reston@dominos.com on th= e side of any delivery trucks.=20 The longer this goes on, network-based will be the exception not the rule. ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, March 04, 2014 1:20 PM To: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs > I think we should have this be optional. =20 I think it should be optional to use/check the received golden-copy (or whatever we call the copy in the Identity-X header), but not optional to send it. Imho, debugging and proof-of-failure is going to be really important, if we ever hope to actually reject failed call requests. [RS> ] This is an excellent point. I might point out that in various national regulatory contexts the verification service (aka the terminating carrier) cannot now drop the call under any circumstances. This is the law= . The intersection of the STIR method and refinements to NRA regulations will need sufficient proof the verification method is sound. This is telephony and not "the Internet". It is regulated in every nation state.=20 It is increasingly clear that the WG needs to consider two additional constraints. Can it actually be deployed in contexts where there is a great deal of SIP already out there? This goes to Jon points and Hadrial's rebuttal in the meeting about "Well its shouldn't be too hard to deal with canonicalization in FROM:" Ya right.=20 And costs. I'm spending a great deal of time trying to find any reasonable data on what the theoretical costs of a RPKI mechanism for phone numbers would look like. The data is all over the place and if anyone has any hint= s and resources they would pass along to me I'd appreciate it. We have some models out there SIDR certainly, 509 in chip and pin credit cards, HMDI video interfaces, we know the problems in SSL etc. Certs can go from .01 cent to $200. =20 It's one thing to give a cert to the 1500 US carriers or 500 Canadian it's another thing if this drills down into a requirement that each phone number be directly signed. As an exercise in scale I typically use 2.5 times tota= l population to estimate numbers allocated and available for service so that generally looks like 700M or so in the US, 120 M or so in the UK and 90 o= r so million for Canada. I agree with Alex that the probable first use case for STIR is carrier to carrier where the SBC is probably both the Authentication service at the Originating carrier and Verification Service at the Terminating carrier. It is probably easier to support the mechanism there than at the CSCF. I just don't see this being deployed directly on smartphones for the foreseeable future, Cullen may be right and I'm often wrong but that is what I think. I'd certainly like to see an effort on an enhanced CNAM display mechanism from the mobile operators and handset manufacturers first but I'm told 3GPP is looking at this but maybe I'll hav= e a problem statement ready by Toronto.=20 Design decisions drive costs and there are limits on what, I believe, the global telecom industry or consumers of phone numbers will tolerate. For instance I'm not sure some consumers will appreciate a PKI line item on their phone bills. There are three moving parts here first the actually mechanism on the wire and modifications to the SBC here, second the actuall= y cost of the PKI infrastructure and last but not least the OSS/BSS systems used in telecom systems worldwide. Anyone who know what I'm talking about will realize that that is where the sink hole of money will ultimately fall into. The additional cost must be fractional to the existing cost of National Number administration and above all LNP etc.=20 I might point out we are at a relatively unique point here especially with regards to the underlying national numbering databases. The PSTN Transitio= n is forcing the issue of URI/NS record inclusion and clearly it would be helpful if the STIR mechanism could be grafted in as well.=20 Also effect on post dial delay. This is not email this is real-time. The SIP headers should be renamed the SIP short story since the size is now roughly similar if History-Info is included. I just don't know here and in the immortal words of Donald Rumsfield it's the "unknown unknowns" that worry me.=20 -hadriel _______________________________________________ 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 Mar 4 15:16:12 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925271A0091 for ; Tue, 4 Mar 2014 15:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 Mmh_Q2kBXQoQ for ; Tue, 4 Mar 2014 15:16:06 -0800 (PST) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 520111A0090 for ; Tue, 4 Mar 2014 15:16:06 -0800 (PST) Message-ID: From: Henning Schulzrinne To: "'DOLLY, MARTIN C'" , Michael Hammer , "richard@shockey.us" , "stir@ietf.org" Thread-Topic: [stir] Canonicalization vs. Comparison & now Costs Thread-Index: Ac830z7J9nSYaSMpQJS6873Urm1twwABQaYAAAxW2AAABJOHAAAHUhKAAA57XCA= Date: Tue, 4 Mar 2014 23:16:00 +0000 References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBF3BD22@sc9-ex2k10mb1.corp.yaanatech.com> <003701cf37df$b9fca250$2df5e6f0$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBF3BF50@sc9-ex2k10mb1.corp.yaanatech.com> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/WIl5qu9_cSJ0IZmgU_QJQf28dgI Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 23:16:09 -0000 As far as I know, for one fairly common OS [Android], there is an API for t= he dialer, as that's used for the various filtering apps that you can downl= oad today from Google Play. It doesn't get access to SIP headers at the mom= ent and obviously doesn't work on all phones, but Mike mentions "proxies fo= r dumb phones", so I suspect nobody is contemplating this as the only solut= ion. -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C Sent: Tuesday, March 04, 2014 6:11 PM To: Michael Hammer; richard@shockey.us; stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Mike, While smartphones are mini computers, the dialer app is one of the secure a= pps on a phone, and therefore unlikely to have an API access to it. So, please explain to me how a smartphone solution would work, across all p= hones? Thank you, Martin -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Tuesday, March 04, 2014 4:38 PM To: richard@shockey.us; stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Richard, I was reacting to the notion that the solution had to be expensive and that= everything would be done in nodes like SBC and CSCF. I am not saying that carriers won't be involved, or that this won't involve E.164 numbering resources, and associated authority delegations. Or, that proxies for dumb phones won't be needed. But, let's not make this so that phones must be dumb in the STIR design. This just started to feel like an ITU-T meeting than an IETF discussion. := ) Didn't mean to stir up a hornets nest, but also don't fall into old habits= . Mike ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Tuesday, March 04, 2014 2:27 PM To: Michael Hammer; stir@ietf.org Subject: RE: [stir] Canonicalization vs. Comparison & now Costs -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Tuesday, March 04, 2014 1:43 PM To: richard@shockey.us; stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Given the computational power of smartphones and the economy of scale of smart phones [cost=3D($development+$reasonable profit)/#smartphones) =3D pennies], it would be short-sighted to not have Internet-scale solutions as a primary solution, along with network-based legacy-oriented solutions. [RS> ] Well we will just have to disagree wont we. If you actually believe an "internet scale solution" needs to be put in place first before you "run up the flag" IMHO the effort is doomed to failure. I seem to recall another effort at some "internet scale solution" involving telephone numbers. .. e164.arpa. I think we know what happened to that. If you can apply the solution inside a national carrier network under its CC, which I think is possible and would have the support of the NRA's then Brian Rosen may be correct that you can apply some "Forest Guide" for international traffic. I just don't understand how you think a "internet scale" solution would work. Some almighty golden apex run by Geneva? Oh that's not going to happen either. I know everyone hates ATT VZ BT DT etc but the= y are a fact of life.=20 Else we are just designing for my grandfather's telephone network that may soon be gone. [RS> ] Well it's certainly transforming but its not going away and since th= e first part of this effort involves real E.164 then there are some constraints national law tends to impose. You can talk all you want about URI based realtime but for now I have not seen SIP:reston@dominos.com on th= e side of any delivery trucks.=20 The longer this goes on, network-based will be the exception not the rule. ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, March 04, 2014 1:20 PM To: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs > I think we should have this be optional. =20 I think it should be optional to use/check the received golden-copy (or whatever we call the copy in the Identity-X header), but not optional to send it. Imho, debugging and proof-of-failure is going to be really important, if we ever hope to actually reject failed call requests. [RS> ] This is an excellent point. I might point out that in various national regulatory contexts the verification service (aka the terminating carrier) cannot now drop the call under any circumstances. This is the law= . The intersection of the STIR method and refinements to NRA regulations will need sufficient proof the verification method is sound. This is telephony and not "the Internet". It is regulated in every nation state.=20 It is increasingly clear that the WG needs to consider two additional constraints. Can it actually be deployed in contexts where there is a great deal of SIP already out there? This goes to Jon points and Hadrial's rebuttal in the meeting about "Well its shouldn't be too hard to deal with canonicalization in FROM:" Ya right.=20 And costs. I'm spending a great deal of time trying to find any reasonable data on what the theoretical costs of a RPKI mechanism for phone numbers would look like. The data is all over the place and if anyone has any hint= s and resources they would pass along to me I'd appreciate it. We have some models out there SIDR certainly, 509 in chip and pin credit cards, HMDI video interfaces, we know the problems in SSL etc. Certs can go from .01 cent to $200. =20 It's one thing to give a cert to the 1500 US carriers or 500 Canadian it's another thing if this drills down into a requirement that each phone number be directly signed. As an exercise in scale I typically use 2.5 times tota= l population to estimate numbers allocated and available for service so that generally looks like 700M or so in the US, 120 M or so in the UK and 90 o= r so million for Canada. I agree with Alex that the probable first use case for STIR is carrier to carrier where the SBC is probably both the Authentication service at the Originating carrier and Verification Service at the Terminating carrier. It is probably easier to support the mechanism there than at the CSCF. I just don't see this being deployed directly on smartphones for the foreseeable future, Cullen may be right and I'm often wrong but that is what I think. I'd certainly like to see an effort on an enhanced CNAM display mechanism from the mobile operators and handset manufacturers first but I'm told 3GPP is looking at this but maybe I'll hav= e a problem statement ready by Toronto.=20 Design decisions drive costs and there are limits on what, I believe, the global telecom industry or consumers of phone numbers will tolerate. For instance I'm not sure some consumers will appreciate a PKI line item on their phone bills. There are three moving parts here first the actually mechanism on the wire and modifications to the SBC here, second the actuall= y cost of the PKI infrastructure and last but not least the OSS/BSS systems used in telecom systems worldwide. Anyone who know what I'm talking about will realize that that is where the sink hole of money will ultimately fall into. The additional cost must be fractional to the existing cost of National Number administration and above all LNP etc.=20 I might point out we are at a relatively unique point here especially with regards to the underlying national numbering databases. The PSTN Transitio= n is forcing the issue of URI/NS record inclusion and clearly it would be helpful if the STIR mechanism could be grafted in as well.=20 Also effect on post dial delay. This is not email this is real-time. The SIP headers should be renamed the SIP short story since the size is now roughly similar if History-Info is included. I just don't know here and in the immortal words of Donald Rumsfield it's the "unknown unknowns" that worry me.=20 -hadriel _______________________________________________ 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 Tue Mar 4 15:40:31 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6391A0074 for ; Tue, 4 Mar 2014 15:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 BxqQyJUKIZY6 for ; Tue, 4 Mar 2014 15:40:27 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id A849D1A0059 for ; Tue, 4 Mar 2014 15:40:26 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 76466135.2b856189b940.2020240.00-2460.5646713.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 04 Mar 2014 23:40:23 +0000 (UTC) X-MXL-Hash: 53166467017f70ff-c029ea0c321b770a96da1da9e8a19a76a388cd7a Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 66466135.0.2020234.00-2185.5646690.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 04 Mar 2014 23:40:23 +0000 (UTC) X-MXL-Hash: 5316646749489a1c-5360a4348a47c00524c23e1bf88f19182140310e 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 s24NeLE9026286; Tue, 4 Mar 2014 18:40:22 -0500 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 s24Ne4WV026115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2014 18:40:06 -0500 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (MISOUT7MSGHUB9F.itservices.sbc.com [144.151.223.71]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 4 Mar 2014 23:39:43 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.03.0174.001; Tue, 4 Mar 2014 18:39:43 -0500 From: "DOLLY, MARTIN C" To: Henning Schulzrinne , Michael Hammer , "richard@shockey.us" , "stir@ietf.org" Thread-Topic: [stir] Canonicalization vs. Comparison & now Costs Thread-Index: Ac830z7J9nSYaSMpQJS6873Urm1twwABQaYAAAxW2AAABJOHAAAHUhKAAA57XCAAHDp8kA== Date: Tue, 4 Mar 2014 23:39:43 +0000 Message-ID: References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBF3BD22@sc9-ex2k10mb1.corp.yaanatech.com> <003701cf37df$b9fca250$2df5e6f0$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBF3BF50@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.80.104] 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-AnalysisOut: [v=2.0 cv=PetIcFdd c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=rwhCyAUayqcA:10 a=ofMgfj31e3cA:10 a=SYMxVWJXx5IA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=scBmumm3AAAA:8 a=BZKT7aY6AAAA:8 ] X-AnalysisOut: [a=f7AiygT3nc8fSOwBQyQA:9 a=CjuIK1q_8ugA:10 a=_Fszbdv8evYA:] X-AnalysisOut: [10 a=iw2rBIYVBUAA:10 a=vRAbILRZcFsA:10 a=lZB815dzVvQA:10 a] X-AnalysisOut: [=E7MB4TUEIZIA:10 a=2l_sA4PumR8A:10 a=hiw8bjWe_u2GfLHX:21 a] X-AnalysisOut: [=QZY5Fcz3ZtZZv_26:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/stir/nWJm3txIkzWeN8GzK-i-SzN3iTg Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 23:40:30 -0000 That is why I asked all phones, and did not highlight the one that leads th= e industry in malware. There is a good reason why the dialer app is secure = on MOST phones. And isn't ironic that the least secure has an API for the d= ialer....Hmmm -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Tuesday, March 04, 2014 6:16 PM To: DOLLY, MARTIN C; Michael Hammer; richard@shockey.us; stir@ietf.org Subject: RE: [stir] Canonicalization vs. Comparison & now Costs As far as I know, for one fairly common OS [Android], there is an API for t= he dialer, as that's used for the various filtering apps that you can downl= oad today from Google Play. It doesn't get access to SIP headers at the mom= ent and obviously doesn't work on all phones, but Mike mentions "proxies fo= r dumb phones", so I suspect nobody is contemplating this as the only solut= ion. -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C Sent: Tuesday, March 04, 2014 6:11 PM To: Michael Hammer; richard@shockey.us; stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Mike, While smartphones are mini computers, the dialer app is one of the secure a= pps on a phone, and therefore unlikely to have an API access to it. So, please explain to me how a smartphone solution would work, across all p= hones? Thank you, Martin -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Tuesday, March 04, 2014 4:38 PM To: richard@shockey.us; stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Richard, I was reacting to the notion that the solution had to be expensive and that= everything would be done in nodes like SBC and CSCF. I am not saying that carriers won't be involved, or that this won't involve E.164 numbering resources, and associated authority delegations. Or, that proxies for dumb phones won't be needed. But, let's not make this so that phones must be dumb in the STIR design. This just started to feel like an ITU-T meeting than an IETF discussion. := ) Didn't mean to stir up a hornets nest, but also don't fall into old habits= . Mike ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Tuesday, March 04, 2014 2:27 PM To: Michael Hammer; stir@ietf.org Subject: RE: [stir] Canonicalization vs. Comparison & now Costs -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Tuesday, March 04, 2014 1:43 PM To: richard@shockey.us; stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Given the computational power of smartphones and the economy of scale of smart phones [cost=3D($development+$reasonable profit)/#smartphones) =3D pennies], it would be short-sighted to not have Internet-scale solutions as a primary solution, along with network-based legacy-oriented solutions. [RS> ] Well we will just have to disagree wont we. If you actually believe an "internet scale solution" needs to be put in place first before you "run up the flag" IMHO the effort is doomed to failure. I seem to recall another effort at some "internet scale solution" involving telephone numbers. .. e164.arpa. I think we know what happened to that. If you can apply the solution inside a national carrier network under its CC, which I think is possible and would have the support of the NRA's then Brian Rosen may be correct that you can apply some "Forest Guide" for international traffic. I just don't understand how you think a "internet scale" solution would work. Some almighty golden apex run by Geneva? Oh that's not going to happen either. I know everyone hates ATT VZ BT DT etc but the= y are a fact of life.=20 Else we are just designing for my grandfather's telephone network that may soon be gone. [RS> ] Well it's certainly transforming but its not going away and since th= e first part of this effort involves real E.164 then there are some constraints national law tends to impose. You can talk all you want about URI based realtime but for now I have not seen SIP:reston@dominos.com on th= e side of any delivery trucks.=20 The longer this goes on, network-based will be the exception not the rule. ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, March 04, 2014 1:20 PM To: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs > I think we should have this be optional. =20 I think it should be optional to use/check the received golden-copy (or whatever we call the copy in the Identity-X header), but not optional to send it. Imho, debugging and proof-of-failure is going to be really important, if we ever hope to actually reject failed call requests. [RS> ] This is an excellent point. I might point out that in various national regulatory contexts the verification service (aka the terminating carrier) cannot now drop the call under any circumstances. This is the law= . The intersection of the STIR method and refinements to NRA regulations will need sufficient proof the verification method is sound. This is telephony and not "the Internet". It is regulated in every nation state.=20 It is increasingly clear that the WG needs to consider two additional constraints. Can it actually be deployed in contexts where there is a great deal of SIP already out there? This goes to Jon points and Hadrial's rebuttal in the meeting about "Well its shouldn't be too hard to deal with canonicalization in FROM:" Ya right.=20 And costs. I'm spending a great deal of time trying to find any reasonable data on what the theoretical costs of a RPKI mechanism for phone numbers would look like. The data is all over the place and if anyone has any hint= s and resources they would pass along to me I'd appreciate it. We have some models out there SIDR certainly, 509 in chip and pin credit cards, HMDI video interfaces, we know the problems in SSL etc. Certs can go from .01 cent to $200. =20 It's one thing to give a cert to the 1500 US carriers or 500 Canadian it's another thing if this drills down into a requirement that each phone number be directly signed. As an exercise in scale I typically use 2.5 times tota= l population to estimate numbers allocated and available for service so that generally looks like 700M or so in the US, 120 M or so in the UK and 90 o= r so million for Canada. I agree with Alex that the probable first use case for STIR is carrier to carrier where the SBC is probably both the Authentication service at the Originating carrier and Verification Service at the Terminating carrier. It is probably easier to support the mechanism there than at the CSCF. I just don't see this being deployed directly on smartphones for the foreseeable future, Cullen may be right and I'm often wrong but that is what I think. I'd certainly like to see an effort on an enhanced CNAM display mechanism from the mobile operators and handset manufacturers first but I'm told 3GPP is looking at this but maybe I'll hav= e a problem statement ready by Toronto.=20 Design decisions drive costs and there are limits on what, I believe, the global telecom industry or consumers of phone numbers will tolerate. For instance I'm not sure some consumers will appreciate a PKI line item on their phone bills. There are three moving parts here first the actually mechanism on the wire and modifications to the SBC here, second the actuall= y cost of the PKI infrastructure and last but not least the OSS/BSS systems used in telecom systems worldwide. Anyone who know what I'm talking about will realize that that is where the sink hole of money will ultimately fall into. The additional cost must be fractional to the existing cost of National Number administration and above all LNP etc.=20 I might point out we are at a relatively unique point here especially with regards to the underlying national numbering databases. The PSTN Transitio= n is forcing the issue of URI/NS record inclusion and clearly it would be helpful if the STIR mechanism could be grafted in as well.=20 Also effect on post dial delay. This is not email this is real-time. The SIP headers should be renamed the SIP short story since the size is now roughly similar if History-Info is included. I just don't know here and in the immortal words of Donald Rumsfield it's the "unknown unknowns" that worry me.=20 -hadriel _______________________________________________ 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 Tue Mar 4 16:01:10 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3611A0084 for ; Tue, 4 Mar 2014 16:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 mbEDfSQRbegS for ; Tue, 4 Mar 2014 16:01:02 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 595AB1A0011 for ; Tue, 4 Mar 2014 16:01:01 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Tue, 4 Mar 2014 16:00:58 -0800 From: Michael Hammer To: "md3135@att.com" , "Henning.Schulzrinne@fcc.gov" , "richard@shockey.us" , "stir@ietf.org" Thread-Topic: [stir] Canonicalization vs. Comparison & now Costs Thread-Index: Ac830z7J9nSYaSMpQJS6873Urm1twwABQaYAABKgKwAADMUisP//2IOAgAABTACAAAahgIAAg3VQ Date: Wed, 5 Mar 2014 00:00:57 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF3C0C1@sc9-ex2k10mb1.corp.yaanatech.com> References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBF3BD22@sc9-ex2k10mb1.corp.yaanatech.com> <003701cf37df$b9fca250$2df5e6f0$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBF3BF50@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.10] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02C4_01CF37DC.12C11410" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/y2m9kX-ndo2NQg_MeutJuZwSwfY Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 00:01:07 -0000 ------=_NextPart_000_02C4_01CF37DC.12C11410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Martin et al, My concern about fighting the last war comes from things like: "WhatsApp's global success has been nothing short of epic, of course, By now, the app is hitting 450 million monthly active users." Now bought by Facebook: Total number of monthly active Facebook users 1,310,000,000 Total number of mobile Facebook users 680,000,000 Increase in Facebook users from 2012 to 2013 22 % As to how it would work across all smartphones? Mobile operators are very good about ensuring that mobile platforms support the features needed to make their service offering better than an OTT application. If they do this better than FB, then they will have a leg up. I am just hoping that the infrastructure to serve the analog line market is minimal. (I count on recent FCC allowed trials to make that throw-away.) Mike ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: DOLLY, MARTIN C [mailto:md3135@att.com] Sent: Tuesday, March 04, 2014 6:40 PM To: Henning Schulzrinne; Michael Hammer; richard@shockey.us; stir@ietf.org Subject: RE: [stir] Canonicalization vs. Comparison & now Costs That is why I asked all phones, and did not highlight the one that leads the industry in malware. There is a good reason why the dialer app is secure on MOST phones. And isn't ironic that the least secure has an API for the dialer....Hmmm -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Tuesday, March 04, 2014 6:16 PM To: DOLLY, MARTIN C; Michael Hammer; richard@shockey.us; stir@ietf.org Subject: RE: [stir] Canonicalization vs. Comparison & now Costs As far as I know, for one fairly common OS [Android], there is an API for the dialer, as that's used for the various filtering apps that you can download today from Google Play. It doesn't get access to SIP headers at the moment and obviously doesn't work on all phones, but Mike mentions "proxies for dumb phones", so I suspect nobody is contemplating this as the only solution. -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C Sent: Tuesday, March 04, 2014 6:11 PM To: Michael Hammer; richard@shockey.us; stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Mike, While smartphones are mini computers, the dialer app is one of the secure apps on a phone, and therefore unlikely to have an API access to it. So, please explain to me how a smartphone solution would work, across all phones? Thank you, Martin -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Tuesday, March 04, 2014 4:38 PM To: richard@shockey.us; stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Richard, I was reacting to the notion that the solution had to be expensive and that everything would be done in nodes like SBC and CSCF. I am not saying that carriers won't be involved, or that this won't involve E.164 numbering resources, and associated authority delegations. Or, that proxies for dumb phones won't be needed. But, let's not make this so that phones must be dumb in the STIR design. This just started to feel like an ITU-T meeting than an IETF discussion. :) Didn't mean to stir up a hornets nest, but also don't fall into old habits. Mike ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Tuesday, March 04, 2014 2:27 PM To: Michael Hammer; stir@ietf.org Subject: RE: [stir] Canonicalization vs. Comparison & now Costs -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Tuesday, March 04, 2014 1:43 PM To: richard@shockey.us; stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Given the computational power of smartphones and the economy of scale of smart phones [cost=($development+$reasonable profit)/#smartphones) = pennies], it would be short-sighted to not have Internet-scale solutions as a primary solution, along with network-based legacy-oriented solutions. [RS> ] Well we will just have to disagree wont we. If you actually believe an "internet scale solution" needs to be put in place first before you "run up the flag" IMHO the effort is doomed to failure. I seem to recall another effort at some "internet scale solution" involving telephone numbers. .. e164.arpa. I think we know what happened to that. If you can apply the solution inside a national carrier network under its CC, which I think is possible and would have the support of the NRA's then Brian Rosen may be correct that you can apply some "Forest Guide" for international traffic. I just don't understand how you think a "internet scale" solution would work. Some almighty golden apex run by Geneva? Oh that's not going to happen either. I know everyone hates ATT VZ BT DT etc but they are a fact of life. Else we are just designing for my grandfather's telephone network that may soon be gone. [RS> ] Well it's certainly transforming but its not going away and since the first part of this effort involves real E.164 then there are some constraints national law tends to impose. You can talk all you want about URI based realtime but for now I have not seen SIP:reston@dominos.com on the side of any delivery trucks. The longer this goes on, network-based will be the exception not the rule. ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Tuesday, March 04, 2014 1:20 PM To: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs > I think we should have this be optional. I think it should be optional to use/check the received golden-copy (or whatever we call the copy in the Identity-X header), but not optional to send it. Imho, debugging and proof-of-failure is going to be really important, if we ever hope to actually reject failed call requests. [RS> ] This is an excellent point. I might point out that in various national regulatory contexts the verification service (aka the terminating carrier) cannot now drop the call under any circumstances. This is the law. The intersection of the STIR method and refinements to NRA regulations will need sufficient proof the verification method is sound. This is telephony and not "the Internet". It is regulated in every nation state. It is increasingly clear that the WG needs to consider two additional constraints. Can it actually be deployed in contexts where there is a great deal of SIP already out there? This goes to Jon points and Hadrial's rebuttal in the meeting about "Well its shouldn't be too hard to deal with canonicalization in FROM:" Ya right. And costs. I'm spending a great deal of time trying to find any reasonable data on what the theoretical costs of a RPKI mechanism for phone numbers would look like. The data is all over the place and if anyone has any hints and resources they would pass along to me I'd appreciate it. We have some models out there SIDR certainly, 509 in chip and pin credit cards, HMDI video interfaces, we know the problems in SSL etc. Certs can go from .01 cent to $200. It's one thing to give a cert to the 1500 US carriers or 500 Canadian it's another thing if this drills down into a requirement that each phone number be directly signed. As an exercise in scale I typically use 2.5 times total population to estimate numbers allocated and available for service so that generally looks like 700M or so in the US, 120 M or so in the UK and 90 or so million for Canada. I agree with Alex that the probable first use case for STIR is carrier to carrier where the SBC is probably both the Authentication service at the Originating carrier and Verification Service at the Terminating carrier. It is probably easier to support the mechanism there than at the CSCF. I just don't see this being deployed directly on smartphones for the foreseeable future, Cullen may be right and I'm often wrong but that is what I think. I'd certainly like to see an effort on an enhanced CNAM display mechanism from the mobile operators and handset manufacturers first but I'm told 3GPP is looking at this but maybe I'll have a problem statement ready by Toronto. Design decisions drive costs and there are limits on what, I believe, the global telecom industry or consumers of phone numbers will tolerate. For instance I'm not sure some consumers will appreciate a PKI line item on their phone bills. There are three moving parts here first the actually mechanism on the wire and modifications to the SBC here, second the actually cost of the PKI infrastructure and last but not least the OSS/BSS systems used in telecom systems worldwide. Anyone who know what I'm talking about will realize that that is where the sink hole of money will ultimately fall into. The additional cost must be fractional to the existing cost of National Number administration and above all LNP etc. I might point out we are at a relatively unique point here especially with regards to the underlying national numbering databases. The PSTN Transition is forcing the issue of URI/NS record inclusion and clearly it would be helpful if the STIR mechanism could be grafted in as well. Also effect on post dial delay. This is not email this is real-time. The SIP headers should be renamed the SIP short story since the size is now roughly similar if History-Info is included. I just don't know here and in the immortal words of Donald Rumsfield it's the "unknown unknowns" that worry me. -hadriel _______________________________________________ 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 ------=_NextPart_000_02C4_01CF37DC.12C11410 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDMw NTAwMDA1NlowIwYJKoZIhvcNAQkEMRYEFAGWKZtF83Dkj8byBJP+7VUrZRnwMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAH/SN6y6vqlQhZaQVEKOFrR/cyYwLpS1w7slb/h2O nhyB67TxMLdMseIS3UYj8KrCCtxuvj4H5PZjfVrvy4DU4LMtfngH0UMa7bCbhbNLi6xrqd6YtuZo 6AZbbzR72pOilqFuekeTFDNeQTTLgYvYPI7gm3Y/DXKNOn+sQYjthwuAaHHkSBN13PKKMXhpvoP7 QeT+iNd/l8pVGCIgkKjOCNCXy/vj4ERQsZgwltfxoIM2nOS3xUhEatlcP8NCH/yBhratTj5S7r+W RC8/grkYTQqH2gAb82OutmbJp7+QDLqnWuYzi1Kg2CL8D1Mj//+xtuffRm9+UtJAHQKkLVuwlwAA AAAAAA== ------=_NextPart_000_02C4_01CF37DC.12C11410-- From nobody Wed Mar 5 01:00:53 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DF41A0388 for ; Wed, 5 Mar 2014 01:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=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 7RDO2rJ_9Hry for ; Wed, 5 Mar 2014 01:00:49 -0800 (PST) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by ietfa.amsl.com (Postfix) with ESMTP id B34CD1A0255 for ; Wed, 5 Mar 2014 01:00:49 -0800 (PST) Received: by mail-qg0-f49.google.com with SMTP id z60so2138315qgd.8 for ; Wed, 05 Mar 2014 01:00:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=A8/gKuuO/aZ2Gqwv00LkqtEhnwYb9JpC/1VCsv99vyE=; b=Zbx3D7SsjcOVHKXskD6sQZ6qKhVFv/qxf2F0hb45boUVDQzQQdNwxe1HBnuOATzoSU JxUvrP7jk+QZyS+z2wYpThjYtdXUgIntBQ/UFenrAkDvlLWpcsLG3vmyfDZTY129Uk5t kxTEpYBPFIYU1crWGnydNhqhrApH09t3xD4ftuHRqwxnIvk0i0hRSHnH+upPnMOFbv+d K3cfdc2G+xAAHSSBrmI/S0iebbnFwCeNy9NuFZz1dr8lyis9hMwTc6VQ8BR36UiZed5F rCQaMLOIKH/+qN7OPdn3r2InISooLmJ/J03n8m5tazKLMgZL+WCZOWaXIm7vXYO0grOU ou0w== X-Gm-Message-State: ALoCoQnO87hMHghO6/LjQ8yru33hSVRVi49HIjACEn66P8w3YSCIAGz0oOHztl5KnIDyZ0PDC1t4 X-Received: by 10.140.100.240 with SMTP id s103mr5027199qge.38.1394010045914; Wed, 05 Mar 2014 01:00:45 -0800 (PST) Received: from wireless-a-v6.meeting.ietf.org ([2001:67c:370:176:9414:f156:9635:1ae8]) by mx.google.com with ESMTPSA id 73sm2345671qgg.22.2014.03.05.01.00.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 01:00:44 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C2FB11BA-341B-49C1-A9B8-447D7251E6CB" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Brian Rosen In-Reply-To: <003f01cf37e4$50046450$f00d2cf0$@shockey.us> Date: Wed, 5 Mar 2014 09:00:36 +0000 Message-Id: <46A5903A-EEF0-4418-BA4A-FABD259C7AE9@brianrosen.net> References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <7CF4268D-2E96-4B5A-880A-D8F57936D897@brianrosen.net> <003f01cf37e4$50046450$f00d2cf0$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/0Dzu2IzbG1wRCcCUS6Xlnw39gs8 Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 09:00:52 -0000 --Apple-Mail=_C2FB11BA-341B-49C1-A9B8-447D7251E6CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > The really interesting characteristic of this model is that it's not = real > time. You can run statistics later over the log. > [RS> ] Huh I don't understand.=20 >=20 The signature needs to be put on the call in the way everyone = understands. However the verification can be done off line, on the log. You have a = batch process that runs through the log computing the verification. We=92re not trying to determine if an individual call verifies at the = time of the call. We=92re computing the percentage of calls from a particular peer that = verify on a, say, weekly basis. I=92m not suggesting this is the end solution. I=92m suggesting it=92s = a good first step because it doesn=92t require as much infrastructure to = be deployed. --Apple-Mail=_C2FB11BA-341B-49C1-A9B8-447D7251E6CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
The really interesting characteristic = of this model is that it's not real
time.  You can run = statistics later over the log.
[RS> ] Huh   I don't = understand. 

The signature needs to be put on the call in the way everyone = understands.

However the verification can be done off = line, on the log.  You have a batch process that runs through the = log computing the verification.
We=92re not trying to = determine if an individual call verifies at the time of the = call.
We=92re computing the percentage of calls from a = particular peer that verify on a, say, weekly = basis.

I=92m not suggesting this is the end = solution.  I=92m suggesting it=92s a good first step because it = doesn=92t require as much infrastructure to be = deployed.


= --Apple-Mail=_C2FB11BA-341B-49C1-A9B8-447D7251E6CB-- From nobody Wed Mar 5 02:47:32 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746671A0407 for ; Wed, 5 Mar 2014 02:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.746 X-Spam-Level: X-Spam-Status: No, score=-4.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 UpNtlrTDO5cq for ; Wed, 5 Mar 2014 02:47:28 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 457151A0400 for ; Wed, 5 Mar 2014 02:47:28 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id db007135.2ac4d0a20940.2130570.00-2416.5639485.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 05 Mar 2014 10:47:25 +0000 (UTC) X-MXL-Hash: 531700bd15c05ec9-aee8d45ab9f37f145302765d0136e28030d73c38 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id bb007135.0.2130568.00-2305.5639469.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 05 Mar 2014 10:47:24 +0000 (UTC) X-MXL-Hash: 531700bc0367d400-707211645ecca12f3d9400bd18127f0d54a6f88d 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 s25AlNpT020701; Wed, 5 Mar 2014 05:47:23 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s25AlIXl020680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Mar 2014 05:47:20 -0500 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 5 Mar 2014 10:47:07 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0174.001; Wed, 5 Mar 2014 05:47:07 -0500 From: "DOLLY, MARTIN C" To: Brian Rosen Thread-Topic: [stir] Canonicalization vs. Comparison & now Costs Thread-Index: AQHPOFFf9nSYaSMpQJS6873Urm1tw5rST91J Date: Wed, 5 Mar 2014 10:47:06 +0000 Message-ID: <10C82B1D-415F-4A7D-A27F-B8576FA6CF1B@att.com> References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <7CF4268D-2E96-4B5A-880A-D8F57936D897@brianrosen.net> <003f01cf37e4$50046450$f00d2cf0$@shockey.us>, <46A5903A-EEF0-4418-BA4A-FABD259C7AE9@brianrosen.net> In-Reply-To: <46A5903A-EEF0-4418-BA4A-FABD259C7AE9@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_10C82B1D415F4A7DA27FB8576FA6CF1Battcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Odkv+GvY c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=rwhCyAUayqcA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=HLLxP2VMAAAA:8 a=48vgC7mUAAAA:8 a=eGiq2W_ZEe] X-AnalysisOut: [t0SRkkE1IA:9 a=pILNOxqGKmIA:10 a=qM39cor4HRgA:10 a=Hz7IrDY] X-AnalysisOut: [lS0cA:10 a=-zy3ex45pM4A:10 a=lZB815dzVvQA:10 a=U7lzfFV49Iv] X-AnalysisOut: [G6w5PLHUA:9 a=_W_S_7VecoQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/stir/ggjFxBnDrhWyQugJ6I8Ozk8l_hQ Cc: "stir@ietf.org" , Richard Shockey Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 10:47:30 -0000 --_000_10C82B1D415F4A7DA27FB8576FA6CF1Battcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Please explain this peering business model ? Martin Dolly Lead Member of Technical Staff Core Network & Gov't/Regulatory Standards AT&T Standards and Industry Alliances +1-609-903-3360 md3135@att.com On Mar 5, 2014, at 4:01 AM, "Brian Rosen" > wrote: The really interesting characteristic of this model is that it's not real time. You can run statistics later over the log. [RS> ] Huh I don't understand. The signature needs to be put on the call in the way everyone understands. However the verification can be done off line, on the log. You have a batc= h process that runs through the log computing the verification. We=92re not trying to determine if an individual call verifies at the time = of the call. We=92re computing the percentage of calls from a particular peer that verif= y on a, say, weekly basis. I=92m not suggesting this is the end solution. I=92m suggesting it=92s a g= ood first step because it doesn=92t require as much infrastructure to be de= ployed. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_10C82B1D415F4A7DA27FB8576FA6CF1Battcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Please explain this peering business model ?

Martin Dolly
Lead Member of Technical Staff
Core Network & Gov't/Regulatory Standards  
AT&T Standards and Industry Alliances
+1-609-903-3360

On Mar 5, 2014, at 4:01 AM, "Brian Rosen" <br@brianrosen.net> wrote:

The really interesting characteristic of this model is that it's not real time.  You can run statistics later over the log.
[RS> ] Huh   I don't understand. 

The signature needs to be put on the call in the way everyone understands.

However the verification can be done off line, on the log.  You h= ave a batch process that runs through the log computing the verification.
We=92re not trying to determine if an individual call verifies at the = time of the call.
We=92re computing the percentage of calls from a particular peer that = verify on a, say, weekly basis.

I=92m not suggesting this is the end solution.  I=92m suggesting = it=92s a good first step because it doesn=92t require as much infrastructur= e to be deployed.


_______________________________________________
stir mailing list
stir@ietf.org
https://www.ie= tf.org/mailman/listinfo/stir
--_000_10C82B1D415F4A7DA27FB8576FA6CF1Battcom_-- From nobody Wed Mar 5 03:05:05 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5DF1A044D for ; Wed, 5 Mar 2014 03:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=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 RGRAu_gi0ZTc for ; Wed, 5 Mar 2014 03:05:00 -0800 (PST) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) by ietfa.amsl.com (Postfix) with ESMTP id E06D81A044A for ; Wed, 5 Mar 2014 03:04:59 -0800 (PST) Received: by mail-qg0-f47.google.com with SMTP id 63so2475712qgz.6 for ; Wed, 05 Mar 2014 03:04:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=0bO5tFWLYGqNp5A/VoUlUkFn+lP9S+5JXb/FX5Jr1b0=; b=HhnlbNkEpMYsl/AR+euJ3MmZHcJz7Rgq3NqqQJkYJE2WT7DWHdUgQqaryN3Cun+xNN VEoY2vMj14CN1/5PsPpK5++GuZZdBJTpTre8/OpgjVugddEmDB7sj7Oee1L0MyxBp1iM vpl1/xkawN37OnlBNTMLH24MOg3oP8Shxb7B3T6yMthxed6q5yIRIGIQxumVZzQFv3B/ V4tQusEoucrnuFKFJV2bAlRuIWdP8aOo8vQHnosAN22vKqNeKfKjAYbKU7scfTDuvoNz mEyrYYD7dxWme8bOrIpxo0gj35QnaB8mZaNez+vqxWmhok1ollKYvWBGTm4KNrC/0nee lZ6g== X-Gm-Message-State: ALoCoQmRHsOSgfQMK7aZ/NBlxZxr8vcsL9ZN0KikY+pd6pWBEsWkNTZEClQF21W8OtDgBNm8Cc12 X-Received: by 10.224.36.129 with SMTP id t1mr5563765qad.88.1394017496230; Wed, 05 Mar 2014 03:04:56 -0800 (PST) Received: from wireless-a-v6.meeting.ietf.org ([2001:67c:370:176:9414:f156:9635:1ae8]) by mx.google.com with ESMTPSA id i7sm6720992qan.0.2014.03.05.03.04.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 03:04:55 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_305189D1-2FB9-4F4D-A4FE-2E246BE88B7D" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Brian Rosen In-Reply-To: <10C82B1D-415F-4A7D-A27F-B8576FA6CF1B@att.com> Date: Wed, 5 Mar 2014 11:04:52 +0000 Message-Id: References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <7CF4268D-2E96-4B5A-880A-D8F57936D897@brianrosen.net> <003f01cf37e4$50046450$f00d2cf0$@shockey.us>, <46A5903A-EEF0-4418-BA4A-FABD259C7AE9@brianrosen.net> <10C82B1D-415F-4A7D-A27F-B8576FA6CF1B@att.com> To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/MFQ_JpLO0TGm8gJxK1gxqlbALkU Cc: "stir@ietf.org" , Richard Shockey Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 11:05:02 -0000 --Apple-Mail=_305189D1-2FB9-4F4D-A4FE-2E246BE88B7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Service Providers have explicit peering agreements. They don=92t just = take calls from anyone. Peering agreements have terms. The peers agree = to exchange traffic under certain terms and conditions. Any service provider could negotiate with a peer to include a = requirement to have valid, signed identity on some percentage of calls. =93The parties agree that by January 1, 2017, 50% of calls presented by = either party to the other will have valid, signed identity. By January = 1, 2018, 75% of calls presented will have valid, signed identity=85=94 Service providers who are on the receiving end of a lot of bad calls = might want to impose such a requirement on its peers. This avoids any = issue of dropping calls. It might mean that at some point an SP would = be in violation of the peering agreement, and some remedy would be = imposed. It would be nice if the regulator would state that refusing to = peer due to extended violation of such an agreement was acceptable. It=92s not really a =93business model=94, as much as a way to encourage = deployment without a flat regulatory imperative. I certainly don=92t think any service provider is going to be charging = any other service provider for any of this mechanism. The database itself has some cost that has to be passed on, directly or = indirectly to consumers. Each provider has to have some element in the = origination path that will insert the header. In the peering agreement = idea I=92m describing, the terminating service provider needs a back-end = checker that could be batch oriented, off line, non-real time, that = computes the percentage of calls with validly signed identity. = Eventually, the termination side will want on line, real time checking. = The costs of deploying that infrastructure is going to be passed = directly or indirectly to consumers. Brian On Mar 5, 2014, at 10:47 AM, DOLLY, MARTIN C wrote: > Please explain this peering business model ? >=20 > Martin Dolly > Lead Member of Technical Staff > Core Network & Gov't/Regulatory Standards =20 > AT&T Standards and Industry Alliances > +1-609-903-3360 > md3135@att.com >=20 > On Mar 5, 2014, at 4:01 AM, "Brian Rosen" wrote: >=20 >>> The really interesting characteristic of this model is that it's not = real >>> time. You can run statistics later over the log. >>> [RS> ] Huh I don't understand.=20 >>>=20 >> The signature needs to be put on the call in the way everyone = understands. >>=20 >> However the verification can be done off line, on the log. You have = a batch process that runs through the log computing the verification. >> We=92re not trying to determine if an individual call verifies at the = time of the call. >> We=92re computing the percentage of calls from a particular peer that = verify on a, say, weekly basis. >>=20 >> I=92m not suggesting this is the end solution. I=92m suggesting it=92s= a good first step because it doesn=92t require as much infrastructure = to be deployed. >>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_305189D1-2FB9-4F4D-A4FE-2E246BE88B7D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Service Providers have explicit peering agreements. =  They don=92t just take calls from anyone.  Peering agreements = have terms.  The peers agree to exchange traffic under certain = terms and conditions.

Any service provider could = negotiate with a peer to include a requirement to have valid, signed = identity on some percentage of calls.

=93The = parties agree that by January 1, 2017, 50% of calls presented by either = party to the other will have valid, signed identity.  By January 1, = 2018, 75% of calls presented will have valid, signed = identity=85=94

Service providers who are on the = receiving end of a lot of bad calls might want to impose such a = requirement on its peers.  This avoids any issue of dropping calls. =  It might mean that at some point an SP would be in violation of = the peering agreement, and some remedy would be imposed.  It would = be nice if the regulator would state that refusing to peer due to = extended violation of such an agreement was = acceptable.

It=92s not really a =93business = model=94, as much as a way to encourage deployment without a flat = regulatory imperative.
I certainly don=92t think any service = provider is going to be charging any other service provider for any of = this mechanism.
The database itself has some cost that has to = be passed on, directly or indirectly to consumers.  Each provider = has to have some element in the origination path that will insert the = header.  In the peering agreement idea I=92m describing, the = terminating service provider needs a back-end checker that could be = batch oriented, off line, non-real time, that computes the percentage of = calls with validly signed identity.  Eventually, the termination = side will want on line, real time checking.  The costs of deploying = that infrastructure is going to be passed directly or indirectly to = consumers.

Brian


On Mar 5, 2014, at 10:47 AM, DOLLY, MARTIN C <md3135@att.com> wrote:

Please explain this peering business model ?

Martin Dolly
Lead Member of Technical Staff
Core Network & Gov't/Regulatory Standards  
AT&T Standards and Industry Alliances
+1-609-903-3360

On Mar 5, 2014, at 4:01 AM, "Brian Rosen" <br@brianrosen.net> wrote:

The really interesting characteristic of this model is that it's not = real
time.  You can run statistics later over the log.
[RS> ] Huh   I don't understand. 

The signature needs to be put on the call in the way everyone = understands.

However the verification can be done off line, on the log. =  You have a batch process that runs through the log computing the = verification.
We=92re not trying to determine if an individual call verifies at = the time of the call.
We=92re computing the percentage of calls from a particular peer = that verify on a, say, weekly basis.

I=92m not suggesting this is the end solution.  I=92m = suggesting it=92s a good first step because it doesn=92t require as much = infrastructure to be deployed.


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

= --Apple-Mail=_305189D1-2FB9-4F4D-A4FE-2E246BE88B7D-- From nobody Wed Mar 5 09:36:07 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9F61A0191 for ; Wed, 5 Mar 2014 09:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 oFc84LppWzTy for ; Wed, 5 Mar 2014 09:36:00 -0800 (PST) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 11E261A00BB for ; Wed, 5 Mar 2014 09:36:00 -0800 (PST) Received: (qmail 23908 invoked by uid 0); 5 Mar 2014 17:35:54 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by qproxy1.mail.unifiedlayer.com with SMTP; 5 Mar 2014 17:35:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=/trRMVKRGhpmwPijXtYUyOSIH7NitN7YO2EB/7SYdpk=; b=WRxfTdFTzEWK0p15FX73p4Dcs0s1Y+GPzu3uX4BX6O4xov464Z3i8iYaE+tEFzpXIAXu+yshpbFMhDbaqN/RWgVnAtTGB6uUqPvcQJHqROcIaneGOIJ6+YLwMppj3H/H; Received: from [173.79.179.104] (port=50294 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1WLFjW-00026r-0R; Wed, 05 Mar 2014 10:35:54 -0700 From: "Richard Shockey" To: "'Brian Rosen'" , "'DOLLY, MARTIN C'" References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <7CF4268D-2E96-4B5A-880A-D8F57936D897@brianrosen.net> <003f01cf37e4$50046450$f00d2cf0$@shockey.us>, <46A5903A-EEF0-4418-BA4A-FABD259C7AE9@brianrosen.net> <10C82B1D-415F-4A7D-A27F-B8576FA6CF1B@att.com> In-Reply-To: Date: Wed, 5 Mar 2014 12:35:49 -0500 Message-ID: <018a01cf3899$5b5e4450$121accf0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018B_01CF386F.7292EAB0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMM+v8p2Zf/9wiklc7kKQbJqsyO1AEmRtuqAaE85pUCAzbxZwKwuh1/AnnSS5uYB3/egA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/5EaGbXE0PUg23t8qDy7GRiurvks Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 17:36:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_018B_01CF386F.7292EAB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit First . If we can't ultimately block the calls in real time what's the point? From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, March 05, 2014 6:05 AM To: DOLLY, MARTIN C Cc: stir@ietf.org; Richard Shockey Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Service Providers have explicit peering agreements. They don't just take calls from anyone. Peering agreements have terms. The peers agree to exchange traffic under certain terms and conditions. [RS> ] This is NOT the Internet. Its telephony. In my experience SIP peering agreements are entirely different from classic IP Transit Peering. In most cases you are not even using BGP routing. The call MUST go through in the TDM world and there is a huge food fight in the US on whether SIP Peering is covered under 47 USC 251 (c) on the mandate to interconnect. It's the same in other jurisdictions. I'm happy to provide a seminar on international telecom law and rights of nation states for their numbering plan administration but I suspect no one really wants that. http://www.gpo.gov/fdsys/pkg/USCODE-2011-title47/html/USCODE-2011-title47-ch ap5-subchapII-partII-sec251.htm http://laws-lois.justice.gc.ca/eng/acts/T-3.4/page-16.html#s-46.1 http://www.legislation.gov.uk/ukpga/2003/21/part/2/chapter/1/crossheading/ge neral-conditions-telephone-numbers Any service provider could negotiate with a peer to include a requirement to have valid, signed identity on some percentage of calls. [RS> ] Could maybe might . were not even close to that point. "The parties agree that by January 1, 2017, 50% of calls presented by either party to the other will have valid, signed identity. By January 1, 2018, 75% of calls presented will have valid, signed identity." Service providers who are on the receiving end of a lot of bad calls might want to impose such a requirement on its peers. This avoids any issue of dropping calls. It might mean that at some point an SP would be in violation of the peering agreement, and some remedy would be imposed. It would be nice if the regulator would state that refusing to peer due to extended violation of such an agreement was acceptable. It's not really a "business model", as much as a way to encourage deployment without a flat regulatory imperative. I certainly don't think any service provider is going to be charging any other service provider for any of this mechanism. The database itself has some cost that has to be passed on, directly or indirectly to consumers. Each provider has to have some element in the origination path that will insert the header. In the peering agreement idea I'm describing, the terminating service provider needs a back-end checker that could be batch oriented, off line, non-real time, that computes the percentage of calls with validly signed identity. Eventually, the termination side will want on line, real time checking. The costs of deploying that infrastructure is going to be passed directly or indirectly to consumers. Brian On Mar 5, 2014, at 10:47 AM, DOLLY, MARTIN C > wrote: Please explain this peering business model ? Martin Dolly Lead Member of Technical Staff Core Network & Gov't/Regulatory Standards AT&T Standards and Industry Alliances +1-609-903-3360 md3135@att.com On Mar 5, 2014, at 4:01 AM, "Brian Rosen" > wrote: The really interesting characteristic of this model is that it's not real time. You can run statistics later over the log. [RS> ] Huh I don't understand. The signature needs to be put on the call in the way everyone understands. However the verification can be done off line, on the log. You have a batch process that runs through the log computing the verification. We're not trying to determine if an individual call verifies at the time of the call. We're computing the percentage of calls from a particular peer that verify on a, say, weekly basis. I'm not suggesting this is the end solution. I'm suggesting it's a good first step because it doesn't require as much infrastructure to be deployed. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ------=_NextPart_000_018B_01CF386F.7292EAB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

First … If we can’t ultimately block the calls in real = time what’s the point?  

 

 

From: stir = [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Wednesday, March 05, 2014 6:05 AM
To: = DOLLY, MARTIN C
Cc: stir@ietf.org; Richard = Shockey
Subject: Re: [stir] Canonicalization vs. Comparison = & now Costs

 

Service = Providers have explicit peering agreements.  They don’t just = take calls from anyone.  Peering agreements have terms.  The = peers agree to exchange traffic under certain terms and = conditions.

 

[RS> ] This is NOT the Internet.  Its telephony.  In my = experience SIP peering agreements are entirely different from classic IP = Transit Peering. In most cases you are not even using BGP routing. =

 

The call MUST go through in the TDM world and there is a huge food = fight in the US on whether SIP Peering is covered under 47 USC 251 = (c)  on the mandate to interconnect.  It’s the same in = other jurisdictions. I’m happy to provide a seminar on = international telecom law and rights of nation states for their = numbering plan administration but I suspect no one really wants = that. 

 

 

http://www.gpo.gov/fdsys/pkg/= USCODE-2011-title47/html/USCODE-2011-title47-chap5-subchapII-partII-sec25= 1.htm

 

 

http://laws-lois.justice.gc.ca/eng/acts/T-3.4/page-16.html#s-46.1=

 

 

http://www.legislation.gov.uk/ukpga/2003/21/part/2/chapter/1/crosshead= ing/general-conditions-telephone-numbers

 

 

Any service provider could negotiate with a peer to = include a requirement to have valid, signed identity on some percentage = of calls.

 

[RS> ]   Could maybe might … were not even close = to that point.

 

“The parties agree that by January 1, 2017, 50% = of calls presented by either party to the other will have valid, signed = identity.  By January 1, 2018, 75% of calls presented will have = valid, signed identity…”

 

Service providers who are on the receiving end of a = lot of bad calls might want to impose such a requirement on its peers. =  This avoids any issue of dropping calls.  It might mean that = at some point an SP would be in violation of the peering agreement, and = some remedy would be imposed.  It would be nice if the regulator = would state that refusing to peer due to extended violation of such an = agreement was acceptable.

 

It’s not really a “business model”, = as much as a way to encourage deployment without a flat regulatory = imperative.

I certainly = don’t think any service provider is going to be charging any other = service provider for any of this mechanism.

The database itself has some cost that has to be = passed on, directly or indirectly to consumers.  Each provider has = to have some element in the origination path that will insert the = header.  In the peering agreement idea I’m describing, the = terminating service provider needs a back-end checker that could be = batch oriented, off line, non-real time, that computes the percentage of = calls with validly signed identity.  Eventually, the termination = side will want on line, real time checking.  The costs of deploying = that infrastructure is going to be passed directly or indirectly to = consumers.

 

Brian

 

 

On Mar 5, 2014, at 10:47 AM, DOLLY, MARTIN C <md3135@att.com> = wrote:



Please explain this = peering business model ?

Martin = Dolly

Lead Member of = Technical Staff

Core = Network & Gov't/Regulatory Standards =  

AT&T Standards = and Industry Alliances

+1-609-903-3360


On Mar = 5, 2014, at 4:01 AM, "Brian Rosen" <br@brianrosen.net> = wrote:

The = really interesting characteristic of this model is that it's not = real
time.  You can run statistics later over the = log.
[RS> ] Huh   I don't understand. 

The signature needs to be put on = the call in the way everyone understands.

 

However the verification can be done off line, on the = log.  You have a batch process that runs through the log computing = the verification.

We’re not trying to determine if an individual = call verifies at the time of the call.

We’re computing the percentage of calls from a = particular peer that verify on a, say, weekly = basis.

 

I’m not suggesting this is the end solution. =  I’m suggesting it’s a good first step because it = doesn’t require as much infrastructure to be = deployed.

 

 

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

 

------=_NextPart_000_018B_01CF386F.7292EAB0-- From nobody Wed Mar 5 10:27:43 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46D71A0247 for ; Wed, 5 Mar 2014 10:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 ofd48jDuhe6K for ; Wed, 5 Mar 2014 10:27:33 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id C870A1A01A8 for ; Wed, 5 Mar 2014 10:27:32 -0800 (PST) Received: from mail241-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Wed, 5 Mar 2014 18:27:28 +0000 Received: from mail241-tx2 (localhost [127.0.0.1]) by mail241-tx2-R.bigfish.com (Postfix) with ESMTP id 7C791E038E; Wed, 5 Mar 2014 18:27:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.230.168.25; KIP:(null); UIP:(null); IPV:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz98dI9371I8d0Ic85fh168aJzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1de098h1033IL17326ah8275bh30d1K8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh25f6h2605h9a9j1155h) Received-SPF: pass (mail241-tx2: domain of sprint.com designates 144.230.168.25 as permitted sender) client-ip=144.230.168.25; envelope-from=Pierce.Gorman@sprint.com; helo=plsasdm1.corp.sprint.com ; p.sprint.com ; Received: from mail241-tx2 (localhost.localdomain [127.0.0.1]) by mail241-tx2 (MessageSwitch) id 1394044044742219_31141; Wed, 5 Mar 2014 18:27:24 +0000 (UTC) Received: from TX2EHSMHS028.bigfish.com (unknown [10.9.14.250]) by mail241-tx2.bigfish.com (Postfix) with ESMTP id A63C860071; Wed, 5 Mar 2014 18:27:24 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by TX2EHSMHS028.bigfish.com (10.9.99.128) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 5 Mar 2014 18:27:23 +0000 Received: from PDAWEH05.ad.sprint.com (pdaweh05.corp.sprint.com [144.226.110.92]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s25IRMI0031179 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 5 Mar 2014 12:27:22 -0600 Received: from PLSWE13M08.ad.sprint.com (144.229.214.27) by PDAWEH05.ad.sprint.com (144.226.110.92) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 5 Mar 2014 12:27:21 -0600 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.775.38; Wed, 5 Mar 2014 12:27:20 -0600 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.0775.031; Wed, 5 Mar 2014 12:27:20 -0600 From: "Gorman, Pierce A [NTK]" To: Richard Shockey , 'Brian Rosen' , "'DOLLY, MARTIN C'" Thread-Topic: [stir] Canonicalization vs. Comparison & now Costs Thread-Index: AQHPOJloWpHDY6ROiki3aIVzpO13N5rSyohg Date: Wed, 5 Mar 2014 18:27:20 +0000 Message-ID: References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <7CF4268D-2E96-4B5A-880A-D8F57936D897@brianrosen.net> <003f01cf37e4$50046450$f00d2cf0$@shockey.us>, <46A5903A-EEF0-4418-BA4A-FABD259C7AE9@brianrosen.net> <10C82B1D-415F-4A7D-A27F-B8576FA6CF1B@att.com> <018a01cf3899$5b5e4450$121accf0$@shockey.us> In-Reply-To: <018a01cf3899$5b5e4450$121accf0$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.22] Content-Type: multipart/alternative; boundary="_000_fbf9e53f538b46f992110565f8c68516PLSWE13M08adsprintcom_" MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/stir/EtjE3VdqTk7VSUQXhiCMpqEa49Q Cc: "stir@ietf.org" Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 18:27:39 -0000 --_000_fbf9e53f538b46f992110565f8c68516PLSWE13M08adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Interesting remark(s) Richard. As usual. Blocking calls has been implicitly and explicitly discussed here, but I wil= l say I assumed that would rarely happen, other than by the consumer of the= termination (just like what happens today). Do we need to define the tangible benefits of signing calls? Is signing a call... * a source of evidence when suing for relief (or in criminal prosec= ution)? * a hint of the trustworthiness of the originator? (Can we assume = people are more trustworthy if they know they can be more easily tracked an= d identified?) * a token for CNAM (see CNIT)? Since the list likes to make assumptions about business models and regulato= ry enforcement I'll throw out an assumption and some questions too. I assume capturing signatures in Call Detail Records is implied. Are custo= mers going to be willing to pay more for calls which are signed? Should th= ere be a choice? Should the (all) government(s) mandate that customers mus= t have signed calls? Are un-signed calls worth less? Should signing regula= tions extend to carrier-based and Over-The-Top coversational applications b= eyond voice, such as video, text, IM? Best regards, Pierce Gorman Voice Architecture Core Planning/Sprint 913-439-4368 (Desk) From: Richard Shockey [mailto:richard@shockey.us] Sent: March 05, 2014 11:36 AM To: 'Brian Rosen'; 'DOLLY, MARTIN C' Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs First ... If we can't ultimately block the calls in real time what's the po= int? From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, March 05, 2014 6:05 AM To: DOLLY, MARTIN C Cc: stir@ietf.org; Richard Shockey Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Service Providers have explicit peering agreements. They don't just take c= alls from anyone. Peering agreements have terms. The peers agree to excha= nge traffic under certain terms and conditions. [RS> ] This is NOT the Internet. Its telephony. In my experience SIP peer= ing agreements are entirely different from classic IP Transit Peering. In m= ost cases you are not even using BGP routing. The call MUST go through in the TDM world and there is a huge food fight in= the US on whether SIP Peering is covered under 47 USC 251 (c) on the mand= ate to interconnect. It's the same in other jurisdictions. I'm happy to pr= ovide a seminar on international telecom law and rights of nation states fo= r their numbering plan administration but I suspect no one really wants tha= t. http://www.gpo.gov/fdsys/pkg/USCODE-2011-title47/html/USCODE-2011-title47-c= hap5-subchapII-partII-sec251.htm http://laws-lois.justice.gc.ca/eng/acts/T-3.4/page-16.html#s-46.1 http://www.legislation.gov.uk/ukpga/2003/21/part/2/chapter/1/crossheading/g= eneral-conditions-telephone-numbers Any service provider could negotiate with a peer to include a requirement t= o have valid, signed identity on some percentage of calls. [RS> ] Could maybe might ... were not even close to that point. "The parties agree that by January 1, 2017, 50% of calls presented by eithe= r party to the other will have valid, signed identity. By January 1, 2018,= 75% of calls presented will have valid, signed identity..." Service providers who are on the receiving end of a lot of bad calls might = want to impose such a requirement on its peers. This avoids any issue of d= ropping calls. It might mean that at some point an SP would be in violatio= n of the peering agreement, and some remedy would be imposed. It would be = nice if the regulator would state that refusing to peer due to extended vio= lation of such an agreement was acceptable. It's not really a "business model", as much as a way to encourage deploymen= t without a flat regulatory imperative. I certainly don't think any service provider is going to be charging any ot= her service provider for any of this mechanism. The database itself has some cost that has to be passed on, directly or ind= irectly to consumers. Each provider has to have some element in the origin= ation path that will insert the header. In the peering agreement idea I'm = describing, the terminating service provider needs a back-end checker that = could be batch oriented, off line, non-real time, that computes the percent= age of calls with validly signed identity. Eventually, the termination sid= e will want on line, real time checking. The costs of deploying that infra= structure is going to be passed directly or indirectly to consumers. Brian On Mar 5, 2014, at 10:47 AM, DOLLY, MARTIN C > wrote: Please explain this peering business model ? Martin Dolly Lead Member of Technical Staff Core Network & Gov't/Regulatory Standards AT&T Standards and Industry Alliances +1-609-903-3360 md3135@att.com On Mar 5, 2014, at 4:01 AM, "Brian Rosen" > wrote: The really interesting characteristic of this model is that it's not real time. You can run statistics later over the log. [RS> ] Huh I don't understand. The signature needs to be put on the call in the way everyone understands. However the verification can be done off line, on the log. You have a batc= h process that runs through the log computing the verification. We're not trying to determine if an individual call verifies at the time of= the call. We're computing the percentage of calls from a particular peer that verify = on a, say, weekly basis. I'm not suggesting this is the end solution. I'm suggesting it's a good fi= rst step because it doesn't require as much infrastructure to be deployed. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ________________________________ 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. --_000_fbf9e53f538b46f992110565f8c68516PLSWE13M08adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Interesting remark(s) Ric= hard.  As usual.

 

Blocking calls has been i= mplicitly and explicitly discussed here, but I will say I assumed that woul= d rarely happen, other than by the consumer of the termination (just like what happens today).

 

Do we need to define the = tangible benefits of signing calls?

 

Is signing a call…<= /span>

 

&middo= t;   =       a source of evidence when s= uing for relief (or in criminal prosecution)?

&middo= t;   =       a hint of the trustworthine= ss of the originator?  (Can we assume people are more trustworthy if t= hey know they can be more easily tracked and identified?)

&middo= t;   =       a token for CNAM (see CNIT)= ?

 

Since the list likes to m= ake assumptions about business models and regulatory enforcement I’ll= throw out an assumption and some questions too.

 

I assume capturing signat= ures in Call Detail Records is implied.  Are customers going to be wil= ling to pay more for calls which are signed?  Should there be a choice?  Should the (all) government(s) mandate that customers must= have signed calls? Are un-signed calls worth less?  Should signing re= gulations extend to carrier-based and Over-The-Top coversational applicatio= ns beyond voice, such as video, text, IM?

 

Best regards,

 

 

Pierce Gorman

Voice Architecture=

Core Planning/Sprint

913-439-4368 (Desk)

 

From: Richar= d Shockey [mailto:richard@shockey.us]
Sent: March 05, 2014 11:36 AM
To: 'Brian Rosen'; 'DOLLY, MARTIN C'
Cc: stir@ietf.org
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs<= /span>

 

First … If we can= ’t ultimately block the calls in real time what’s the point?&nb= sp; 

 

 

From: stir= [mailto:stir-bounces@ietf.org= ] On Behalf Of Brian Rosen
Sent: Wednesday, March 05, 2014 6:05 AM
To: DOLLY, MARTIN C
Cc: stir@ietf.org; Richard Shoc= key
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs<= /span>

 

Service Providers have explicit peering agreements. =  They don’t just take calls from anyone.  Peering agreement= s have terms.  The peers agree to exchange traffic under certain terms= and conditions.

 =

[RS> ] This is= NOT the Internet.  Its telephony.  In my experience SIP peering = agreements are entirely different from classic IP Transit Peering. In most cases you are not even using BGP routing.

 =

The call MUST go = through in the TDM world and there is a huge food fight in the US on whethe= r SIP Peering is covered under 47 USC 251 (c)  on the mandate to interconnect.  It’s the same in other jurisdictions. I’= ;m happy to provide a seminar on international telecom law and rights of na= tion states for their numbering plan administration but I suspect no one re= ally wants that. 

 =

 =

http://www.gpo.gov/fdsys/pkg/USCODE-2011-title4= 7/html/USCODE-2011-title47-chap5-subchapII-partII-sec251.htm=

 =

 =

http://laws-lo= is.justice.gc.ca/eng/acts/T-3.4/page-16.html#s-46.1

 =

 =

http://www.legislation.gov.uk/ukpga/2003/21/= part/2/chapter/1/crossheading/general-conditions-telephone-numbers

 

 

Any service provider could negotiate with a peer to = include a requirement to have valid, signed identity on some percentage of = calls.

 

[RS> ] &n= bsp; Could maybe might … were not even close to that point.

 

“The parties agree that by January 1, 2017, 50= % of calls presented by either party to the other will have valid, signed i= dentity.  By January 1, 2018, 75% of calls presented will have valid, = signed identity…”

 

Service providers who are on the receiving end of a = lot of bad calls might want to impose such a requirement on its peers. &nbs= p;This avoids any issue of dropping calls.  It might mean that at some= point an SP would be in violation of the peering agreement, and some remedy would be imposed.  It would be nice if the= regulator would state that refusing to peer due to extended violation of s= uch an agreement was acceptable.

 

It’s not really a “business model”= , as much as a way to encourage deployment without a flat regulatory impera= tive.

I certainly don’t think any service provider i= s going to be charging any other service provider for any of this mechanism= .

The database itself has some cost that has to be pas= sed on, directly or indirectly to consumers.  Each provider has to hav= e some element in the origination path that will insert the header.  I= n the peering agreement idea I’m describing, the terminating service provider needs a back-end checker that could be ba= tch oriented, off line, non-real time, that computes the percentage of call= s with validly signed identity.  Eventually, the termination side will= want on line, real time checking.  The costs of deploying that infrastructure is going to be passed directly or i= ndirectly to consumers.

 

Brian

 

 

On Mar 5, 2014, at 10:47 AM, DOLLY, MARTIN C <md3135@att.com> wrote:

 

Please explain this p= eering business model ?

Martin Dolly

Lead Member of Technical Staff

Core Network & Gov't/Regulatory Standards  =

AT&T Standards and Industry Alliances

+1-609-903-3360


On Mar 5, 2014, at 4:01 AM, "Brian Rosen" <br@brianrosen.net> wrote:

The really interesting characteristic of this model is that it's= not real
time.  You can run statistics later over the log.
[RS> ] Huh   I don't understand. 

The signature needs to be put on the call in the way= everyone understands.

 

However the verification can be done off line, on th= e log.  You have a batch process that runs through the log computing t= he verification.

We’re not trying to determine if an individual= call verifies at the time of the call.

We’re computing the percentage of calls from a= particular peer that verify on a, say, weekly basis.

 

I’m not suggesting this is the end solution. &= nbsp;I’m suggesting it’s a good first step because it doesnR= 17;t require as much infrastructure to be deployed.

 

 

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

 



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.
 --_000_fbf9e53f538b46f992110565f8c68516PLSWE13M08adsprintcom_-- From nobody Wed Mar 5 10:36:27 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CEA1A0183 for ; Wed, 5 Mar 2014 10:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 g5wDCRXtpomL for ; Wed, 5 Mar 2014 10:36:15 -0800 (PST) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 94E1B1A00F5 for ; Wed, 5 Mar 2014 10:36:14 -0800 (PST) Message-ID: From: Henning Schulzrinne To: "'Gorman, Pierce A [NTK]'" , Richard Shockey , 'Brian Rosen' , "'DOLLY, MARTIN C'" Thread-Topic: [stir] Canonicalization vs. Comparison & now Costs Thread-Index: Ac830z7J9nSYaSMpQJS6873Urm1twwAMFkEAAAKnygAAG0RNAAADuC8AAACe2QAADadegAABzJgAAApfQlA= Date: Wed, 5 Mar 2014 18:36:09 +0000 References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <7CF4268D-2E96-4B5A-880A-D8F57936D897@brianrosen.net> <003f01cf37e4$50046450$f00d2cf0$@shockey.us>, <46A5903A-EEF0-4418-BA4A-FABD259C7AE9@brianrosen.net> <10C82B1D-415F-4A7D-A27F-B8576FA6CF1B@att.com> <018a01cf3899$5b5e4450$121accf0$@shockey.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D02A477240p2pxmb13fccnetw_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/_BcvDUb5V762T0lN0oIyS1HEKFk Cc: "stir@ietf.org" Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 18:36:22 -0000 --_000_E6A16181E5FD2F46B962315BB05962D02A477240p2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There's also the possibility of a third-party provider of caller reputation= and handling services. We see beginnings of that (e.g.,) in the Nomorobo s= ervice. A carrier can simply pass on the STIR SIP header(s) to the third party or a= n indication that the caller-ID has been validated (or failed validation). Beyond blocking, such services can provide a number of other call treatment= s, such as CAPTCHA-style tests to separate humans from bots or redirection = to voicemail or redirection to a third party (for example, maybe dubious ca= lls to elderly parents can be sent to a child acting with power of attorney= that decides whether the charity or financial services offer should be pas= sed on to the parent). From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce A [NT= K] Sent: Wednesday, March 05, 2014 1:27 PM To: Richard Shockey; 'Brian Rosen'; 'DOLLY, MARTIN C' Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Interesting remark(s) Richard. As usual. Blocking calls has been implicitly and explicitly discussed here, but I wil= l say I assumed that would rarely happen, other than by the consumer of the= termination (just like what happens today). Do we need to define the tangible benefits of signing calls? Is signing a call... * a source of evidence when suing for relief (or in criminal prosec= ution)? * a hint of the trustworthiness of the originator? (Can we assume = people are more trustworthy if they know they can be more easily tracked an= d identified?) * a token for CNAM (see CNIT)? Since the list likes to make assumptions about business models and regulato= ry enforcement I'll throw out an assumption and some questions too. I assume capturing signatures in Call Detail Records is implied. Are custo= mers going to be willing to pay more for calls which are signed? Should th= ere be a choice? Should the (all) government(s) mandate that customers mus= t have signed calls? Are un-signed calls worth less? Should signing regula= tions extend to carrier-based and Over-The-Top coversational applications b= eyond voice, such as video, text, IM? Best regards, Pierce Gorman Voice Architecture Core Planning/Sprint 913-439-4368 (Desk) From: Richard Shockey [mailto:richard@shockey.us] Sent: March 05, 2014 11:36 AM To: 'Brian Rosen'; 'DOLLY, MARTIN C' Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs First ... If we can't ultimately block the calls in real time what's the po= int? From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, March 05, 2014 6:05 AM To: DOLLY, MARTIN C Cc: stir@ietf.org; Richard Shockey Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Service Providers have explicit peering agreements. They don't just take c= alls from anyone. Peering agreements have terms. The peers agree to excha= nge traffic under certain terms and conditions. [RS> ] This is NOT the Internet. Its telephony. In my experience SIP peer= ing agreements are entirely different from classic IP Transit Peering. In m= ost cases you are not even using BGP routing. The call MUST go through in the TDM world and there is a huge food fight in= the US on whether SIP Peering is covered under 47 USC 251 (c) on the mand= ate to interconnect. It's the same in other jurisdictions. I'm happy to pr= ovide a seminar on international telecom law and rights of nation states fo= r their numbering plan administration but I suspect no one really wants tha= t. http://www.gpo.gov/fdsys/pkg/USCODE-2011-title47/html/USCODE-2011-title47-c= hap5-subchapII-partII-sec251.htm http://laws-lois.justice.gc.ca/eng/acts/T-3.4/page-16.html#s-46.1 http://www.legislation.gov.uk/ukpga/2003/21/part/2/chapter/1/crossheading/g= eneral-conditions-telephone-numbers Any service provider could negotiate with a peer to include a requirement t= o have valid, signed identity on some percentage of calls. [RS> ] Could maybe might ... were not even close to that point. "The parties agree that by January 1, 2017, 50% of calls presented by eithe= r party to the other will have valid, signed identity. By January 1, 2018,= 75% of calls presented will have valid, signed identity..." Service providers who are on the receiving end of a lot of bad calls might = want to impose such a requirement on its peers. This avoids any issue of d= ropping calls. It might mean that at some point an SP would be in violatio= n of the peering agreement, and some remedy would be imposed. It would be = nice if the regulator would state that refusing to peer due to extended vio= lation of such an agreement was acceptable. It's not really a "business model", as much as a way to encourage deploymen= t without a flat regulatory imperative. I certainly don't think any service provider is going to be charging any ot= her service provider for any of this mechanism. The database itself has some cost that has to be passed on, directly or ind= irectly to consumers. Each provider has to have some element in the origin= ation path that will insert the header. In the peering agreement idea I'm = describing, the terminating service provider needs a back-end checker that = could be batch oriented, off line, non-real time, that computes the percent= age of calls with validly signed identity. Eventually, the termination sid= e will want on line, real time checking. The costs of deploying that infra= structure is going to be passed directly or indirectly to consumers. Brian On Mar 5, 2014, at 10:47 AM, DOLLY, MARTIN C > wrote: Please explain this peering business model ? Martin Dolly Lead Member of Technical Staff Core Network & Gov't/Regulatory Standards AT&T Standards and Industry Alliances +1-609-903-3360 md3135@att.com On Mar 5, 2014, at 4:01 AM, "Brian Rosen" > wrote: The really interesting characteristic of this model is that it's not real time. You can run statistics later over the log. [RS> ] Huh I don't understand. The signature needs to be put on the call in the way everyone understands. However the verification can be done off line, on the log. You have a batc= h process that runs through the log computing the verification. We're not trying to determine if an individual call verifies at the time of= the call. We're computing the percentage of calls from a particular peer that verify = on a, say, weekly basis. I'm not suggesting this is the end solution. I'm suggesting it's a good fi= rst step because it doesn't require as much infrastructure to be deployed. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ________________________________ 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. --_000_E6A16181E5FD2F46B962315BB05962D02A477240p2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There’s also the po= ssibility of a third-party provider of caller reputation and handling servi= ces. We see beginnings of that (e.g.,) in the Nomorobo service.<= /span>

 <= /p>

A carrier can simply pass= on the STIR SIP header(s) to the third party or an indication that the cal= ler-ID has been validated (or failed validation).

 <= /p>

Beyond blocking, such ser= vices can provide a number of other call treatments, such as CAPTCHA-style = tests to separate humans from bots or redirection to voicemail or redirection to a third party (for example, maybe dubious calls to elder= ly parents can be sent to a child acting with power of attorney that decide= s whether the charity or financial services offer should be passed on to th= e parent).

 <= /p>

From: stir [ma= ilto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce A [NTK]
Sent: Wednesday, March 05, 2014 1:27 PM
To: Richard Shockey; 'Brian Rosen'; 'DOLLY, MARTIN C'
Cc: stir@ietf.org
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs<= o:p>

 

Interesting remark(s) Richa= rd.  As usual.

 

Blocking calls has been imp= licitly and explicitly discussed here, but I will say I assumed that would = rarely happen, other than by the consumer of the termination (just like what happens today).

 

Do we need to define the ta= ngible benefits of signing calls?

 

Is signing a call…

 

·      &nb= sp;  a source of evidence when suing for relief = (or in criminal prosecution)?

·      &nb= sp;  a hint of the trustworthiness of the origin= ator?  (Can we assume people are more trustworthy if they know they ca= n be more easily tracked and identified?)

·      &nb= sp;  a token for CNAM (see CNIT)?

 

Since the list likes to mak= e assumptions about business models and regulatory enforcement I’ll t= hrow out an assumption and some questions too.

 

I assume capturing signatur= es in Call Detail Records is implied.  Are customers going to be willi= ng to pay more for calls which are signed?  Should there be a choice?  Should the (all) government(s) mandate that customers must h= ave signed calls? Are un-signed calls worth less?  Should signing regu= lations extend to carrier-based and Over-The-Top coversational applications= beyond voice, such as video, text, IM?

 

Best regards,

 

 

Pierce Gorman

Voice Architecture

Core Planning/Sprint=

913-439-4368 (Desk)<= o:p>

 

From: Richard = Shockey [mailto:richard@shockey.us]
Sent: March 05, 2014 11:36 AM
To: 'Brian Rosen'; 'DOLLY, MARTIN C'
Cc: stir@ietf.org
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs<= /span>

 

First … If we can&#= 8217;t ultimately block the calls in real time what’s the point? = ; 

 <= /p>

 <= /p>

From: stir [= mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Wednesday, March 05, 2014 6:05 AM
To: DOLLY, MARTIN C
Cc: stir@ietf.org; Richard Shoc= key
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs<= /span>

 

Service Providers have explicit peering agreements. =  They don’t just take calls from anyone.  Peering agreement= s have terms.  The peers agree to exchange traffic under certain terms= and conditions.

 

[RS> ] This is N= OT the Internet.  Its telephony.  In my experience SIP peering ag= reements are entirely different from classic IP Transit Peering. In most cases you are not even using BGP routing.

 

The call MUST go th= rough in the TDM world and there is a huge food fight in the US on whether = SIP Peering is covered under 47 USC 251 (c)  on the mandate to interconnect.  It’s the same in other jurisdictions. I’= ;m happy to provide a seminar on international telecom law and rights of na= tion states for their numbering plan administration but I suspect no one re= ally wants that. 

 

 

http://www.gpo.gov/fdsys/pkg/USCODE-2011-title47/= html/USCODE-2011-title47-chap5-subchapII-partII-sec251.htm

 

 

http://laws-lois= .justice.gc.ca/eng/acts/T-3.4/page-16.html#s-46.1

 

 

http://www.legislation.gov.uk/ukpga/2003/21/pa= rt/2/chapter/1/crossheading/general-conditions-telephone-numbers=

 <= /p>

 

Any service provider could negotiate with a peer to = include a requirement to have valid, signed identity on some percentage of = calls.

 <= /p>

[RS> ] &nbs= p; Could maybe might … were not even close to that point.

 

“The parties agree that by January 1, 2017, 50= % of calls presented by either party to the other will have valid, signed i= dentity.  By January 1, 2018, 75% of calls presented will have valid, = signed identity…”

 

Service providers who are on the receiving end of a = lot of bad calls might want to impose such a requirement on its peers. &nbs= p;This avoids any issue of dropping calls.  It might mean that at some= point an SP would be in violation of the peering agreement, and some remedy would be imposed.  It would be nice if the= regulator would state that refusing to peer due to extended violation of s= uch an agreement was acceptable.

 

It’s not really a “business model”= , as much as a way to encourage deployment without a flat regulatory impera= tive.

I certainly don’t think any service provider i= s going to be charging any other service provider for any of this mechanism= .

The database itself has some cost that has to be pas= sed on, directly or indirectly to consumers.  Each provider has to hav= e some element in the origination path that will insert the header.  I= n the peering agreement idea I’m describing, the terminating service provider needs a back-end checker that could be ba= tch oriented, off line, non-real time, that computes the percentage of call= s with validly signed identity.  Eventually, the termination side will= want on line, real time checking.  The costs of deploying that infrastructure is going to be passed directly or i= ndirectly to consumers.

 

Brian

 

 

On Mar 5, 2014, at 10:47 AM, DOLLY, MARTIN C <md3135@att.com> wrote:

 

Please explain this p= eering business model ?

Martin Dolly

Lead Member of Technical Staff

Core Network & Gov't/Regulatory Standards  =

AT&T Standards and Industry Alliances=

+1-609-903-3360


On Mar 5, 2014, at 4:01 AM, "Brian Rosen" <br@brianrosen.net> wrote:

The really interesting characteristic of this model is that it's= not real
time.  You can run statistics later over the log.
[RS> ] Huh   I don't understand. 

The signature needs to be put on the call in the way= everyone understands.

 

However the verification can be done off line, on th= e log.  You have a batch process that runs through the log computing t= he verification.

We’re not trying to determine if an individual= call verifies at the time of the call.

We’re computing the percentage of calls from a= particular peer that verify on a, say, weekly basis.

 

I’m not suggesting this is the end solution. &= nbsp;I’m suggesting it’s a good first step because it doesnR= 17;t require as much infrastructure to be deployed.

 

 

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

 

 


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.

--_000_E6A16181E5FD2F46B962315BB05962D02A477240p2pxmb13fccnetw_-- From nobody Wed Mar 5 11:41:55 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60671A01D1 for ; Wed, 5 Mar 2014 11:41:51 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 8Y-ICQavzugx for ; Wed, 5 Mar 2014 11:41:45 -0800 (PST) Received: from oproxy19-pub.mail.unifiedlayer.com (oproxy19-pub.mail.unifiedlayer.com [70.40.200.33]) by ietfa.amsl.com (Postfix) with SMTP id 498A21A02CE for ; Wed, 5 Mar 2014 11:41:45 -0800 (PST) Received: (qmail 2038 invoked by uid 0); 5 Mar 2014 19:41:40 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy19.mail.unifiedlayer.com with SMTP; 5 Mar 2014 19:41:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=En7vo/15ar05U2/bWOklVWdrZipbCcJ4M55LfU02+vE=; b=Wg5rgs1EryEIuynJKa1qHqNSi/iKeMi6YLEt9rvFV3oKSlgvtli8tG0R58EEg232IZTamQ8yepJ1iM78C3rRUWd4D2A76wBnV4xZlPhuu3fWLeWaunB19/NDdJiK33iq; Received: from [173.79.179.104] (port=51138 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1WLHhD-0007Sp-U6; Wed, 05 Mar 2014 12:41:40 -0700 From: "Richard Shockey" To: "'Gorman, Pierce A [NTK]'" References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <7CF4268D-2E96-4B5A-880A-D8F57936D897@brianrosen.net> <003f01cf37e4$50046450$f00d2cf0$@shockey.us>, <46A5903A-EEF0-4418-BA4A-FABD259C7AE9@brianrosen.net> <10C82B1D-415F-4A7D-A27F-B8576FA6CF1B@att.com> <018a01cf3899$5b5e4450$121accf0$@shockey.us> In-Reply-To: Date: Wed, 5 Mar 2014 14:41:35 -0500 Message-ID: <021001cf38aa$ed113f40$c733bdc0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0211_01CF3881.04432680" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMM+v8p2Zf/9wiklc7kKQbJqsyO1AEmRtuqAaE85pUCAzbxZwKwuh1/AnnSS5sBtma6dgHJGJE8l+u0QnA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/uXG0eqSU8mdAkCDQV1HcralgJDc Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 19:41:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0211_01CF3881.04432680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce A [NTK] Sent: Wednesday, March 05, 2014 1:27 PM To: Richard Shockey; 'Brian Rosen'; 'DOLLY, MARTIN C' Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Interesting remark(s) Richard. As usual. Blocking calls has been implicitly and explicitly discussed here, but I will say I assumed that would rarely happen, other than by the consumer of the termination (just like what happens today). [RS> ] I just don't know at this point there may be circumstances where the network itself does the call blocking but that would take a sea change in the regulatory environment and some new safe harbor provision the NRA would ultimately put forward. The case in point is a TDOS against the Public Safety infrastructure. As we both know rural carriers in the US would go nuts. They already have enough problems with least cost routing engines and call completion. Do we need to define the tangible benefits of signing calls? Is signing a call. * a source of evidence when suing for relief (or in criminal prosecution)? [RS> ] Sure if the legislative critters give consumers a private cause of action for abuse as we saw for junk fax. * a hint of the trustworthiness of the originator? (Can we assume people are more trustworthy if they know they can be more easily tracked and identified?) * a token for CNAM (see CNIT)? [RS> ] Again this is a display issue. The IETF needs to so some things but eventually this probably needs to be addressed by 3GPP and the handset folks. Which is why it might be useful to have a BOF on CNIT in Toronto now that we see the rough parameters of where STIR is going. Since the list likes to make assumptions about business models and regulatory enforcement I'll throw out an assumption and some questions too. I assume capturing signatures in Call Detail Records is implied. Are customers going to be willing to pay more for calls which are signed? [RS> ] To kill off "This is Rachel from Card member services." I would guess yes. At the very least the investment is a protection for the existing voice revenue streams or as a competitive advantage. "Yes we sign calls and very calls to protect you from that bitxx Rachel." See pin drop :) Should there be a choice? Should the (all) government(s) mandate that customers must have signed calls? [RS> ] If this situation gets any worse it wouldn't surprise me. But it has to start somewhere. Better here than the ITU. http://www.mccaskill.senate.gov/?p=press_release &id=1969 http://media.ofcom.org.uk/2013/10/21/ofcom-joins-international-taskforce-to- tackle-number-%E2%80%98spoofing%E2%80%99/ Are un-signed calls worth less? Should signing regulations extend to carrier-based and Over-The-Top coversational applications beyond voice, such as video, text, IM? [RS> ] Is Facebook the new phone company? :) I would say if we want to see point to point video using E.164 addressing an any access device we have to fix this stuff and provide adequate consumer display of some verification data. 15 character ASCII is not going to cut it. Best regards, Pierce Gorman Voice Architecture Core Planning/Sprint 913-439-4368 (Desk) From: Richard Shockey [mailto:richard@shockey.us] Sent: March 05, 2014 11:36 AM To: 'Brian Rosen'; 'DOLLY, MARTIN C' Cc: stir@ietf.org Subject: Re: [stir] Canonicalization vs. Comparison & now Costs First . If we can't ultimately block the calls in real time what's the point? From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, March 05, 2014 6:05 AM To: DOLLY, MARTIN C Cc: stir@ietf.org ; Richard Shockey Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Service Providers have explicit peering agreements. They don't just take calls from anyone. Peering agreements have terms. The peers agree to exchange traffic under certain terms and conditions. [RS> ] This is NOT the Internet. Its telephony. In my experience SIP peering agreements are entirely different from classic IP Transit Peering. In most cases you are not even using BGP routing. The call MUST go through in the TDM world and there is a huge food fight in the US on whether SIP Peering is covered under 47 USC 251 (c) on the mandate to interconnect. It's the same in other jurisdictions. I'm happy to provide a seminar on international telecom law and rights of nation states for their numbering plan administration but I suspect no one really wants that. http://www.gpo.gov/fdsys/pkg/USCODE-2011-title47/html/USCODE-2011-title47-ch ap5-subchapII-partII-sec251.htm http://laws-lois.justice.gc.ca/eng/acts/T-3.4/page-16.html#s-46.1 http://www.legislation.gov.uk/ukpga/2003/21/part/2/chapter/1/crossheading/ge neral-conditions-telephone-numbers Any service provider could negotiate with a peer to include a requirement to have valid, signed identity on some percentage of calls. [RS> ] Could maybe might . were not even close to that point. "The parties agree that by January 1, 2017, 50% of calls presented by either party to the other will have valid, signed identity. By January 1, 2018, 75% of calls presented will have valid, signed identity." Service providers who are on the receiving end of a lot of bad calls might want to impose such a requirement on its peers. This avoids any issue of dropping calls. It might mean that at some point an SP would be in violation of the peering agreement, and some remedy would be imposed. It would be nice if the regulator would state that refusing to peer due to extended violation of such an agreement was acceptable. It's not really a "business model", as much as a way to encourage deployment without a flat regulatory imperative. I certainly don't think any service provider is going to be charging any other service provider for any of this mechanism. The database itself has some cost that has to be passed on, directly or indirectly to consumers. Each provider has to have some element in the origination path that will insert the header. In the peering agreement idea I'm describing, the terminating service provider needs a back-end checker that could be batch oriented, off line, non-real time, that computes the percentage of calls with validly signed identity. Eventually, the termination side will want on line, real time checking. The costs of deploying that infrastructure is going to be passed directly or indirectly to consumers. Brian On Mar 5, 2014, at 10:47 AM, DOLLY, MARTIN C > wrote: Please explain this peering business model ? Martin Dolly Lead Member of Technical Staff Core Network & Gov't/Regulatory Standards AT&T Standards and Industry Alliances +1-609-903-3360 md3135@att.com On Mar 5, 2014, at 4:01 AM, "Brian Rosen" > wrote: The really interesting characteristic of this model is that it's not real time. You can run statistics later over the log. [RS> ] Huh I don't understand. The signature needs to be put on the call in the way everyone understands. However the verification can be done off line, on the log. You have a batch process that runs through the log computing the verification. We're not trying to determine if an individual call verifies at the time of the call. We're computing the percentage of calls from a particular peer that verify on a, say, weekly basis. I'm not suggesting this is the end solution. I'm suggesting it's a good first step because it doesn't require as much infrastructure to be deployed. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _____ 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. ------=_NextPart_000_0211_01CF3881.04432680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: stir = [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce A = [NTK]
Sent: Wednesday, March 05, 2014 1:27 PM
To: = Richard Shockey; 'Brian Rosen'; 'DOLLY, MARTIN C'
Cc: = stir@ietf.org
Subject: Re: [stir] Canonicalization vs. = Comparison & now Costs

 

Interesting remark(s) Richard.  As usual.

 

Blocking calls has been implicitly and explicitly discussed here, but I = will say I assumed that would rarely happen, other than by the consumer = of the termination (just like what happens today).

 

[RS> ]  I just don’t know at this point there may be = circumstances where the network itself does the call blocking but that = would take a sea change in the regulatory environment and some new safe = harbor provision the NRA would ultimately put forward. The case in point = is a TDOS against the Public Safety infrastructure.  As we both = know rural carriers in the US would go nuts. They already have enough = problems with least cost routing engines and call = completion.

 

 

Do we need to define the tangible benefits of signing = calls?

 

Is signing a call…

 

·     &nb= sp;   a source of evidence when suing for relief (or in criminal = prosecution)?

 

[RS> ]  Sure if the legislative critters give consumers a = private cause of action for abuse as we saw for junk fax. =

 

·     &nb= sp;   a hint of the trustworthiness of the originator?  (Can we assume = people are more trustworthy if they know they can be more easily tracked = and identified?)

·     &nb= sp;   a token for CNAM (see CNIT)?

 

[RS> ] Again this is a display issue.  The IETF needs to so = some things but eventually this probably needs to be addressed by 3GPP = and the handset folks. Which is why it might be useful to have a BOF on = CNIT in Toronto now that we see the rough parameters of where STIR is = going. 

 

 

 

Since the list likes to make assumptions about business models and = regulatory enforcement I’ll throw out an assumption and some = questions too.

 

I assume capturing signatures in Call Detail Records is implied.  = Are customers going to be willing to pay more for calls which are = signed? 

[RS> ]  To kill off “This is Rachel from Card member = services…” I would guess yes. At the very least the = investment is a protection for the existing voice revenue streams or as = a competitive advantage. “Yes we sign calls and very calls to = protect you from that bitxx Rachel.” See pin drop = J    

 

Should there be a choice?  Should the (all) government(s) mandate = that customers must have signed calls?

[RS> ] If this situation gets any worse it wouldn’t surprise = me. But it has to start somewhere. Better here than the ITU.  =

 

http://www.mccaskill.senate.gov/?p=3Dpress_release&id=3D1969

 

http://media.ofcom.org.uk/2013/10/21/ofcom-joins-international-taskfor= ce-to-tackle-number-%E2%80%98spoofing%E2%80%99/=

 

Are un-signed calls worth less?  Should signing regulations extend = to carrier-based and Over-The-Top coversational applications beyond = voice, such as video, text, IM?

 

[RS> ]  Is Facebook the new phone company? =  J  I would say if we want to see point to point video using E.164 = addressing an any access device we have to fix this stuff and provide = adequate consumer display of some verification data. 15 character ASCII = is not going to cut it.

 

 

Best regards,

 

 

Pierce Gorman

Voice Architecture

Core Planning/Sprint

913-439-4368 (Desk)

 

From:= = Richard Shockey [mailto:richard@shockey.us] =
Sent: March 05, 2014 11:36 AM
To: 'Brian Rosen'; = 'DOLLY, MARTIN C'
Cc: stir@ietf.org
Subject: Re: = [stir] Canonicalization vs. Comparison & now = Costs

 

First … If we can’t ultimately block the calls in real = time what’s the point?  

 

 

From: stir [mailto:stir-bounces@ietf.org] = On Behalf Of Brian Rosen
Sent: Wednesday, March 05, = 2014 6:05 AM
To: DOLLY, MARTIN C
Cc: stir@ietf.org; Richard = Shockey
Subject: Re: [stir] Canonicalization vs. Comparison = & now Costs

 

Service = Providers have explicit peering agreements.  They don’t just = take calls from anyone.  Peering agreements have terms.  The = peers agree to exchange traffic under certain terms and = conditions.

 

[RS> ] This is NOT the Internet.  Its telephony.  In my = experience SIP peering agreements are entirely different from classic IP = Transit Peering. In most cases you are not even using BGP routing. =

 

The call MUST go through in the TDM world and there is a huge food = fight in the US on whether SIP Peering is covered under 47 USC 251 = (c)  on the mandate to interconnect.  It’s the same in = other jurisdictions. I’m happy to provide a seminar on = international telecom law and rights of nation states for their = numbering plan administration but I suspect no one really wants = that. 

 

 

http://www.gpo.gov/fdsys/pkg/= USCODE-2011-title47/html/USCODE-2011-title47-chap5-subchapII-partII-sec25= 1.htm

 

 

http://laws-lois.justice.gc.ca/eng/acts/T-3.4/page-16.html#s-46.1

 

 

http://www.legislation.gov= .uk/ukpga/2003/21/part/2/chapter/1/crossheading/general-conditions-teleph= one-numbers

 

 

Any service provider could negotiate with a peer to = include a requirement to have valid, signed identity on some percentage = of calls.

 

[RS> ]   Could maybe might … were not even close = to that point.

 

“The parties agree that by January 1, 2017, 50% = of calls presented by either party to the other will have valid, signed = identity.  By January 1, 2018, 75% of calls presented will have = valid, signed identity…”

 

Service providers who are on the receiving end of a = lot of bad calls might want to impose such a requirement on its peers. =  This avoids any issue of dropping calls.  It might mean that = at some point an SP would be in violation of the peering agreement, and = some remedy would be imposed.  It would be nice if the regulator = would state that refusing to peer due to extended violation of such an = agreement was acceptable.

 

It’s not really a “business model”, = as much as a way to encourage deployment without a flat regulatory = imperative.

I certainly = don’t think any service provider is going to be charging any other = service provider for any of this mechanism.

The database itself has some cost that has to be = passed on, directly or indirectly to consumers.  Each provider has = to have some element in the origination path that will insert the = header.  In the peering agreement idea I’m describing, the = terminating service provider needs a back-end checker that could be = batch oriented, off line, non-real time, that computes the percentage of = calls with validly signed identity.  Eventually, the termination = side will want on line, real time checking.  The costs of deploying = that infrastructure is going to be passed directly or indirectly to = consumers.

 

Brian

 

 

On Mar 5, 2014, at 10:47 AM, DOLLY, MARTIN C <md3135@att.com> = wrote:

 

Please explain this = peering business model ?

Martin = Dolly

Lead Member of = Technical Staff

Core = Network & Gov't/Regulatory Standards =  

AT&T Standards = and Industry Alliances

+1-609-903-3360


On Mar = 5, 2014, at 4:01 AM, "Brian Rosen" <br@brianrosen.net> = wrote:

The = really interesting characteristic of this model is that it's not = real
time.  You can run statistics later over the = log.
[RS> ] Huh   I don't understand. 

The signature needs to be put on = the call in the way everyone understands.

 

However the verification can be done off line, on the = log.  You have a batch process that runs through the log computing = the verification.

We’re not trying to determine if an individual = call verifies at the time of the call.

We’re computing the percentage of calls from a = particular peer that verify on a, say, weekly = basis.

 

I’m not suggesting this is the end solution. =  I’m suggesting it’s a good first step because it = doesn’t require as much infrastructure to be = deployed.

 

 

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

 

 

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.

------=_NextPart_000_0211_01CF3881.04432680-- From nobody Thu Mar 6 01:23:31 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405AD1A018A for ; Thu, 6 Mar 2014 01:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 NkdsKwx3TxLS for ; Thu, 6 Mar 2014 01:23:26 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB05E1A0178 for ; Thu, 6 Mar 2014 01:23:25 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id f11so2220710qae.3 for ; Thu, 06 Mar 2014 01:23:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=YTuSwtqUMF8BShCMN/BO4hGYBoB1KEndptz3drziQwU=; b=FFm6fSgREkALp3IAZ9rOIzreCz/+7Yv+duxk8airXK+WtaIamtxTD0Wog74+Ts83AB 4lKW6dqIxfS7JRXFKO/2jKfcnAE7yyxjzOCGMNYkzzU1sq+hYuflDzJ9+fyZIXiWTqm3 5a7t2yZzeH5TKdZGycQwffXnCE3jg9QfFBwte90vFyEWgedJckdNtvza4fnsJqB2dCPD O6G7HfvYw3mayVCgeJGsYe/Vveqd3tMrK4YYkXXQ1tm40HylTR4Y1nRwkJPnD4iKkEUJ r2QjZ5mORGJ4SfAgVxh8Cpv4JpnQeTahETL/BdUyA6MeAd5XAAeqTxhBxYWPz++UgMbA 2GBg== X-Gm-Message-State: ALoCoQnpmApKSOzzdG6xcrCq6Jxk9uLYsxtMkHUdwwym73A+ILFRUu1DNuKsDpzpZys/SneHDK45 X-Received: by 10.140.51.170 with SMTP id u39mr11831326qga.69.1394097801661; Thu, 06 Mar 2014 01:23:21 -0800 (PST) Received: from wireless-a-v6.meeting.ietf.org ([2001:67c:370:176:5d1a:c72d:6785:6347]) by mx.google.com with ESMTPSA id k61sm6943742qge.12.2014.03.06.01.23.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 01:23:20 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_A5C14431-20DB-4983-B102-1B02C60D5291" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Brian Rosen In-Reply-To: <018a01cf3899$5b5e4450$121accf0$@shockey.us> Date: Thu, 6 Mar 2014 09:23:18 +0000 Message-Id: <4AEFDE5B-E6AA-419D-8EAF-2B76B8422880@brianrosen.net> References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <7CF4268D-2E96-4B5A-880A-D8F57936D897@brianrosen.net> <003f01cf37e4$50046450$f00d2cf0$@shockey.us>, <46A5903A-EEF0-4418-BA4A-FABD259C7AE9@brianrosen.net> <10C82B1D-415F-4A7D-A27F-B8576FA6CF1B@att.com> <018a01cf3899$5b5e4450$121accf0$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/AJa5CSwomwhsMSmdPp0oNlCNO-Q Cc: stir@ietf.org, "DOLLY, MARTIN C" Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:23:30 -0000 --Apple-Mail=_A5C14431-20DB-4983-B102-1B02C60D5291 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ultimately, some one can block calls. the endpoint for example. That requires a fair amount of mechanism to be implemented, but I hope = we can get there pretty soon in smartphones. Hopefully, regulations will evolve so that unsigned or invalid calls can = be rejected earlier. I don=92t need a tutorial on regulations Rich. I don=92t think most = people on this list need your expositions on the subject. Peering at the call level occurs in SIP interconnect, independent of any = IP peering. I=92m referring to exchange of calls, not packets. I=92ve suggested a way to deploy stir in a manner that does not require = the whole world to change. It requires some B2BUA in the origination = side to add the header and some back end batch process in the = termination side to verify and compute statistics. If you have a better = idea, suggest one. =20 Brian On Mar 5, 2014, at 5:35 PM, Richard Shockey wrote: > First =85 If we can=92t ultimately block the calls in real time what=92s= the point? =20 > =20 > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Wednesday, March 05, 2014 6:05 AM > To: DOLLY, MARTIN C > Cc: stir@ietf.org; Richard Shockey > Subject: Re: [stir] Canonicalization vs. Comparison & now Costs > =20 > Service Providers have explicit peering agreements. They don=92t just = take calls from anyone. Peering agreements have terms. The peers agree = to exchange traffic under certain terms and conditions. > =20 > [RS> ] This is NOT the Internet. Its telephony. In my experience SIP = peering agreements are entirely different from classic IP Transit = Peering. In most cases you are not even using BGP routing. > =20 > The call MUST go through in the TDM world and there is a huge food = fight in the US on whether SIP Peering is covered under 47 USC 251 (c) = on the mandate to interconnect. It=92s the same in other jurisdictions. = I=92m happy to provide a seminar on international telecom law and rights = of nation states for their numbering plan administration but I suspect = no one really wants that.=20 > =20 > =20 > = http://www.gpo.gov/fdsys/pkg/USCODE-2011-title47/html/USCODE-2011-title47-= chap5-subchapII-partII-sec251.htm > =20 > =20 > http://laws-lois.justice.gc.ca/eng/acts/T-3.4/page-16.html#s-46.1 > =20 > =20 > = http://www.legislation.gov.uk/ukpga/2003/21/part/2/chapter/1/crossheading/= general-conditions-telephone-numbers > =20 > =20 > Any service provider could negotiate with a peer to include a = requirement to have valid, signed identity on some percentage of calls. > =20 > [RS> ] Could maybe might =85 were not even close to that point. > =20 > =93The parties agree that by January 1, 2017, 50% of calls presented = by either party to the other will have valid, signed identity. By = January 1, 2018, 75% of calls presented will have valid, signed = identity=85=94 > =20 > Service providers who are on the receiving end of a lot of bad calls = might want to impose such a requirement on its peers. This avoids any = issue of dropping calls. It might mean that at some point an SP would = be in violation of the peering agreement, and some remedy would be = imposed. It would be nice if the regulator would state that refusing to = peer due to extended violation of such an agreement was acceptable. > =20 > It=92s not really a =93business model=94, as much as a way to = encourage deployment without a flat regulatory imperative. > I certainly don=92t think any service provider is going to be charging = any other service provider for any of this mechanism. > The database itself has some cost that has to be passed on, directly = or indirectly to consumers. Each provider has to have some element in = the origination path that will insert the header. In the peering = agreement idea I=92m describing, the terminating service provider needs = a back-end checker that could be batch oriented, off line, non-real = time, that computes the percentage of calls with validly signed = identity. Eventually, the termination side will want on line, real time = checking. The costs of deploying that infrastructure is going to be = passed directly or indirectly to consumers. > =20 > Brian > =20 > =20 > On Mar 5, 2014, at 10:47 AM, DOLLY, MARTIN C wrote: >=20 >=20 > Please explain this peering business model ? >=20 > Martin Dolly > Lead Member of Technical Staff > Core Network & Gov't/Regulatory Standards =20 > AT&T Standards and Industry Alliances > +1-609-903-3360 > md3135@att.com >=20 > On Mar 5, 2014, at 4:01 AM, "Brian Rosen" wrote: >=20 > The really interesting characteristic of this model is that it's not = real > time. You can run statistics later over the log. > [RS> ] Huh I don't understand.=20 >=20 > The signature needs to be put on the call in the way everyone = understands. > =20 > However the verification can be done off line, on the log. You have a = batch process that runs through the log computing the verification. > We=92re not trying to determine if an individual call verifies at the = time of the call. > We=92re computing the percentage of calls from a particular peer that = verify on a, say, weekly basis. > =20 > I=92m not suggesting this is the end solution. I=92m suggesting it=92s = a good first step because it doesn=92t require as much infrastructure to = be deployed. > =20 > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > =20 --Apple-Mail=_A5C14431-20DB-4983-B102-1B02C60D5291 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Ultimately, some one can block calls. the endpoint = for example.
That requires a fair amount of mechanism to be = implemented, but I hope we can get there pretty soon in = smartphones.

Hopefully, regulations will evolve so = that unsigned or invalid calls can be rejected = earlier.

I don=92t need a tutorial on = regulations Rich.  I don=92t think most people on this list need = your expositions on the subject.

Peering at the = call level occurs in SIP interconnect, independent of any IP peering. =  I=92m referring to exchange of calls, not = packets.

I=92ve suggested a way to deploy stir = in a manner that does not require the whole world to change.  It = requires some B2BUA in the origination side to add the header and some = back end batch process in the termination side to verify and compute = statistics.  If you have a better idea, suggest one. =  

Brian

<= div>On Mar 5, 2014, at 5:35 PM, Richard Shockey <richard@shockey.us> = wrote:

First =85 If we can=92t ultimately block the calls in = real time what=92s the point?  
 
 
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Wednesday, March 05, 2014 = 6:05 AM
To: DOLLY, MARTIN = C
Cc: stir@ietf.org; Richard Shockey
Subject: Re: [stir] Canonicalization = vs. Comparison & now Costs
 
Service Providers have explicit peering agreements.  They = don=92t just take calls from anyone.  Peering agreements have = terms.  The peers agree to exchange traffic under certain terms and = conditions.
 
[RS> ] This is NOT the = Internet.  Its telephony.  In my experience SIP peering = agreements are entirely different from classic IP Transit Peering. In = most cases you are not even using BGP = routing.
 
The call MUST go through = in the TDM world and there is a huge food fight in the US on whether SIP = Peering is covered under 47 USC 251 (c)  on the mandate to = interconnect.  It=92s the same in other jurisdictions. I=92m happy = to provide a seminar on international telecom law and rights of nation = states for their numbering plan administration but I suspect no one = really wants that. 
 
 
 
 
 
 
 
 
Any = service provider could negotiate with a peer to include a requirement to = have valid, signed identity on some percentage of = calls.
 
[RS> ]   Could maybe = might =85 were not even close to that point.
 
=93The parties agree that by January 1, 2017, 50% of = calls presented by either party to the other will have valid, signed = identity.  By January 1, 2018, 75% of calls presented will have = valid, signed identity=85=94
 
Service providers who are on the receiving end of a = lot of bad calls might want to impose such a requirement on its peers. =  This avoids any issue of dropping calls.  It might mean that = at some point an SP would be in violation of the peering agreement, and = some remedy would be imposed.  It would be nice if the regulator = would state that refusing to peer due to extended violation of such an = agreement was acceptable.
 
It=92s = not really a =93business model=94, as much as a way to encourage = deployment without a flat regulatory = imperative.
I = certainly don=92t think any service provider is going to be charging any = other service provider for any of this = mechanism.
The = database itself has some cost that has to be passed on, directly or = indirectly to consumers.  Each provider has to have some element in = the origination path that will insert the header.  In the peering = agreement idea I=92m describing, the terminating service provider needs = a back-end checker that could be batch oriented, off line, non-real = time, that computes the percentage of calls with validly signed = identity.  Eventually, the termination side will want on line, real = time checking.  The costs of deploying that infrastructure is going = to be passed directly or indirectly to = consumers.
 
Brian
 
 
On Mar 5, 2014, at 10:47 AM, DOLLY, MARTIN C <md3135@att.com> wrote:


Please explain this peering business model = ?

Martin = Dolly
Lead Member of = Technical Staff
Core = Network & Gov't/Regulatory Standards =  
AT&T Standards and Industry = Alliances
+1-609-903-3360


On Mar 5, 2014, at 4:01 AM, = "Brian Rosen" <br@brianrosen.net> = wrote:

The really interesting characteristic of this = model is that it's not real
time.  You can run statistics later = over the log.
[RS> ] Huh   I don't understand. 

The signature needs to be put on = the call in the way everyone understands.
 
However the verification can be done off line, on = the log.  You have a batch process that runs through the log = computing the verification.
We=92re not trying to determine if an individual = call verifies at the time of the call.
We=92re computing the percentage of calls from a = particular peer that verify on a, say, weekly = basis.
 
I=92m = not suggesting this is the end solution.  I=92m suggesting it=92s a = good first step because it doesn=92t require as much infrastructure to = be deployed.
 
 
_______________________________________________
stir mailing = list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir
 

= --Apple-Mail=_A5C14431-20DB-4983-B102-1B02C60D5291-- From nobody Thu Mar 6 01:35:04 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EEE1A019D for ; Thu, 6 Mar 2014 01:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 VvcacEXY2hTJ for ; Thu, 6 Mar 2014 01:34:59 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 483391A01AF for ; Thu, 6 Mar 2014 01:34:59 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id w8so2201086qac.41 for ; Thu, 06 Mar 2014 01:34:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=rNbN8y1G2cKy5atvh6nqjVbtVm3xDcd8I1jT0hIESA8=; b=gPflIcp7YlfZ65dArThv2VHL3FjryTx6sCM9Ce8Nqgc6O9NQ4SWD7Ik0SI0HIu+/jn wAzEcopsvMrWfhEU6uv7pzkwMGMvyymcAUjmKU3HMBROEzSRj6T+4Yjn9bX7x+w5Uloo 6gSX4kOaFpv4J+H0XJ1336VvJC8Of6OiTm2EcNEJKsV8YuEBXgqv4TWF0OzgAONJzoti JpjfrScvAUhMaZFB43fGtOMgigC5qUP3DCQBkBXkXyh6f7Rd2pTwqavbvwqD+bFrIzVs cnqfYjXFFbSILroambtLnv2+QFkXMjBiZRRCYiaa0cNuEHJuIX3DnpAcwVX5dzdLPz3D ZhbQ== X-Gm-Message-State: ALoCoQnDyVerxIa65VuVKWwODUOSGTlgY+W+kGeNyXNcM365yTPfdx7ESANCERyNQ8ZgIOjkfBvo X-Received: by 10.224.30.70 with SMTP id t6mr8480223qac.30.1394098495192; Thu, 06 Mar 2014 01:34:55 -0800 (PST) Received: from wireless-a-v6.meeting.ietf.org ([2001:67c:370:176:5d1a:c72d:6785:6347]) by mx.google.com with ESMTPSA id h46sm6975790qgd.10.2014.03.06.01.34.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 01:34:53 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4634F2A9-60F7-4194-BCD4-81637C4A62C6" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Brian Rosen In-Reply-To: Date: Thu, 6 Mar 2014 09:34:50 +0000 Message-Id: <16E4CB3B-3BAE-4629-8D6F-4FC410ED2B5F@brianrosen.net> References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <7CF4268D-2E96-4B5A-880A-D8F57936D897@brianrosen.net> <003f01cf37e4$50046450$f00d2cf0$@shockey.us>, <46A5903A-EEF0-4418-BA4A-FABD259C7AE9@brianrosen.net> <10C82B1D-415F-4A7D-A27F-B8576FA6CF1B@att.com> <018a01cf3899$5b5e4450$121accf0$@shockey.us> To: "Gorman, Pierce A [NTK]" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/K_w3vPNYEnFLJDMtR6o0fEs-kYg Cc: "stir@ietf.org" , "DOLLY, MARTIN C" , Richard Shockey Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:35:01 -0000 --Apple-Mail=_4634F2A9-60F7-4194-BCD4-81637C4A62C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Inline On Mar 5, 2014, at 6:27 PM, Gorman, Pierce A [NTK] = wrote: > Interesting remark(s) Richard. As usual. > =20 > Blocking calls has been implicitly and explicitly discussed here, but = I will say I assumed that would rarely happen, other than by the = consumer of the termination (just like what happens today). Yes, that=92s my view. I think it will be hard for service providers to = actually block calls. > =20 > Do we need to define the tangible benefits of signing calls? > =20 > Is signing a call=85 > =20 > =B7 a source of evidence when suing for relief (or in criminal = prosecution)? Yes, at least the idea that if you place scummy calls, the authorities = will be able to find you because you can=92t hide behind a spoofed = telephone number. > =B7 a hint of the trustworthiness of the originator? (Can we = assume people are more trustworthy if they know they can be more easily = tracked and identified?) Not sure how =93trustworthy=94 some scammer that has a legitimate phone = number is, but see above > =B7 a token for CNAM (see CNIT)? Yeah, I think for phones that only have traditional CNAM, yes. A prefix = perhaps. Hopefully SIP phones can have better displays, but I do see = this as a benefit > =20 > Since the list likes to make assumptions about business models and = regulatory enforcement I=92ll throw out an assumption and some questions = too. > =20 > I assume capturing signatures in Call Detail Records is implied.=20 Yes. That=92s my idea. Capture it in the log, and compute validity off = line, none-real time, hold peering partners to a standard. > Are customers going to be willing to pay more for calls which are = signed?=20 Maybe, but I think the benefits of not getting bad calls would drive = consumers to service providers who don=92t send them such calls. That = might be a premium service for a while at least > Should there be a choice? Who wants bad calls? But, sure, there should be a choice.=20 > Should the (all) government(s) mandate that customers must have = signed calls? We might get there. If this mechanism works, then we might get it = mandated. I don=92t want to assume that happens. > Are un-signed calls worth less? Yes, but see above > Should signing regulations extend to carrier-based and Over-The-Top = coversational applications beyond voice, such as video, text, IM? Clearly a tricky subject. I have opinions, but I don=92t think they = matter with respect to this discussion. Let=92s say that if you are = using a delegated telephone number associated with a service, then = probably whatever regulations apply to the service could be extended to = cover stir at some point. --Apple-Mail=_4634F2A9-60F7-4194-BCD4-81637C4A62C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Inline
On Mar 5, 2014, at 6:27 PM, = Gorman, Pierce A [NTK] <Pierce.Gorman@sprint.com> = wrote:

Interesting remark(s) Richard.  = As usual.

 

Blocking calls has been implicitly and explicitly discussed = here, but I will say I assumed that would rarely happen, other than by = the consumer of the termination (just like what happens = today).
Yes, that=92s my view. =  I think it will be hard for service providers to actually block = calls.

 

Do we need to define the tangible benefits of signing = calls?

 

Is signing a call=85

 

=B7         a source of evidence when suing for relief (or in criminal = prosecution)?
Yes, at least the = idea that if you place scummy calls, the authorities will be able to = find you because you can=92t hide behind a spoofed telephone = number.

=B7         a hint of the trustworthiness of the originator?  (Can we = assume people are more trustworthy if they know they can be more easily = tracked and identified?)
Not sure = how =93trustworthy=94 some scammer that has a legitimate phone number = is, but see above

=B7         a token for CNAM (see = CNIT)?
Yeah, I think for phones = that only have traditional CNAM, yes.  A prefix perhaps. =  Hopefully SIP phones can have better displays, but I do see this = as a benefit

 

Since the list likes to make assumptions about business models = and regulatory enforcement I=92ll throw out an assumption and some = questions too.

 

I assume capturing signatures in Call Detail Records is = implied. 
Yes.  That=92s = my idea.  Capture it in the log, and compute validity off line, = none-real time, hold peering partners to a = standard.

Are customers going to be willing to pay more for calls which = are signed? 
Maybe, but I = think the benefits of not getting bad calls would drive consumers to = service providers who don=92t send them such calls.  That might be = a premium service for a while at least

Should there be a = choice?
Who wants bad calls? =  But, sure, there should be a = choice. 

  Should the (all) government(s) mandate that customers = must have signed calls?
We might = get there.  If this mechanism works, then we might get it mandated. =  I don=92t want to assume that happens.

Are un-signed calls worth = less?
Yes, but see = above

  Should signing regulations extend to carrier-based and = Over-The-Top coversational applications beyond voice, such as video, = text, IM?
Clearly a tricky subject. =  I have opinions, but I don=92t think they matter with respect to = this discussion.  Let=92s say that if you are using a delegated = telephone number associated with a service, then probably whatever = regulations apply to the service could be extended to cover stir at some = point.


= --Apple-Mail=_4634F2A9-60F7-4194-BCD4-81637C4A62C6-- From nobody Thu Mar 6 03:18:28 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F691A0272 for ; Thu, 6 Mar 2014 03:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham 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 c0GocVj89UDN for ; Thu, 6 Mar 2014 03:18:23 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7351A025F for ; Thu, 6 Mar 2014 03:18:23 -0800 (PST) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta02.emeryville.ca.mail.comcast.net with comcast id aBGp1n0011Y3wxoA2BJKKu; Thu, 06 Mar 2014 11:18:19 +0000 Received: from BOBO1A.bobotek.net ([76.22.113.196]) by omta15.emeryville.ca.mail.comcast.net with comcast id aBJH1n0054EJ4tY8bBJJde; Thu, 06 Mar 2014 11:18:18 +0000 Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Thu, 6 Mar 2014 03:12:58 -0800 From: Alex Bobotek To: Brian Rosen , "Gorman, Pierce A [NTK]" Date: Thu, 6 Mar 2014 03:12:57 -0800 Thread-Topic: [stir] Canonicalization vs. Comparison & now Costs Thread-Index: Ac85HpxEM4zuoGwdQ0KFtNqi3OIkxwACCb2g Message-ID: <4B1956260CD29F4A9622F00322FE0531EC8F0D508B@BOBO1A.bobotek.net> References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <7CF4268D-2E96-4B5A-880A-D8F57936D897@brianrosen.net> <003f01cf37e4$50046450$f00d2cf0$@shockey.us>, <46A5903A-EEF0-4418-BA4A-FABD259C7AE9@brianrosen.net> <10C82B1D-415F-4A7D-A27F-B8576FA6CF1B@att.com> <018a01cf3899$5b5e4450$121accf0$@shockey.us> <16E4CB3B-3BAE-4629-8D6F-4FC410ED2B5F@brianrosen.net> In-Reply-To: <16E4CB3B-3BAE-4629-8D6F-4FC410ED2B5F@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4B1956260CD29F4A9622F00322FE0531EC8F0D508BBOBO1Abobotek_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1394104699; bh=sZtpx1Tgtk+KbefxYDwOIY2zPbTQgNsi+yK+beRY/po=; h=Received:Received:Received:From:To:Date:Subject:Message-ID: Content-Type:MIME-Version; b=LLww1UXo9QrFst0lK2C0u8/bGCViOa7YFnhVkXc3tEQyU7FvyHlG/IlUrJvG6I3Jw trOotMO+ENvJGnlgbfqf9kILAk3ggs1CarWlMjK/uJ1hvcB7kUa/Dod6CtVkc7n3Pr qA+xeX8ajMc8IwqsqVM+1mGHs9QND7FS1YvZzJd3icApOPtWLPVumQBXooxkLi2kAQ XwcXZPBy4VUKD0sbSb/LpVNQLXSZQqQVhUy2HaDN9553ZGUBzxIUqwvfeiMkA7bpIx PLqcoFujm1bnm2sMWZv+xpqFENopuF5fk43RD9v9W+dPQZ3oGoS1WAmI7xVihIJ3xi d3k7RWaDrVK9A== Archived-At: http://mailarchive.ietf.org/arch/msg/stir/E5XVsNWNHUIX-4YtDQr9y-6N0B8 Cc: "stir@ietf.org" , "DOLLY, MARTIN C" , Richard Shockey Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 11:18:27 -0000 --_000_4B1956260CD29F4A9622F00322FE0531EC8F0D508BBOBO1Abobotek_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What can be done once a source of abusive calls is identified? In other c= ommunications services a set of tools and processes is used to mitigate abu= sive communications. These go beyond simple automated blocking filters, an= d include account restriction, end-user reporting mechanisms, reputation da= tabases (content/fingerprint, source, service provider, ...) and feedback l= oops. In voice, one might expect enforcement activities (based at least in part o= n calling party phone numbers) to include: * Call blocking by terminating telco with consent of recipient * Call blocking by terminating telco in extreme situations in defen= se of networks * Call blocking by 3rd party app with consent of recipient * Account restriction by originating telco * Feedback from terminating parties (end user, terminating telco, .= ..) to upstream telcos and security vendors * Civil and/or criminal enforcement action against originator and/o= r originating telco It should also be noted that selective blocking of text messages (e.g., spa= m) and shutdown of anonymously-obtained accounts that appear to have been c= reated with the purpose of originating abusive text messages is a common se= rvice provider practice in North America and several other regions. This i= s not to suggest that voice call blocking is subject to the same policies a= nd regulations as blocking of data calls such as text messages in many juri= sdictions. Regards, Alex From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, March 06, 2014 1:35 AM To: Gorman, Pierce A [NTK] Cc: stir@ietf.org; DOLLY, MARTIN C; Richard Shockey Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Inline On Mar 5, 2014, at 6:27 PM, Gorman, Pierce A [NTK] > wrote: Interesting remark(s) Richard. As usual. Blocking calls has been implicitly and explicitly discussed here, but I wil= l say I assumed that would rarely happen, other than by the consumer of the= termination (just like what happens today). Yes, that's my view. I think it will be hard for service providers to actu= ally block calls. Do we need to define the tangible benefits of signing calls? Is signing a call... * a source of evidence when suing for relief (or in criminal prosec= ution)? Yes, at least the idea that if you place scummy calls, the authorities will= be able to find you because you can't hide behind a spoofed telephone numb= er. * a hint of the trustworthiness of the originator? (Can we assume = people are more trustworthy if they know they can be more easily tracked an= d identified?) Not sure how "trustworthy" some scammer that has a legitimate phone number = is, but see above * a token for CNAM (see CNIT)? Yeah, I think for phones that only have traditional CNAM, yes. A prefix pe= rhaps. Hopefully SIP phones can have better displays, but I do see this as= a benefit Since the list likes to make assumptions about business models and regulato= ry enforcement I'll throw out an assumption and some questions too. I assume capturing signatures in Call Detail Records is implied. Yes. That's my idea. Capture it in the log, and compute validity off line= , none-real time, hold peering partners to a standard. Are customers going to be willing to pay more for calls which are signed? Maybe, but I think the benefits of not getting bad calls would drive consum= ers to service providers who don't send them such calls. That might be a p= remium service for a while at least Should there be a choice? Who wants bad calls? But, sure, there should be a choice. Should the (all) government(s) mandate that customers must have signed ca= lls? We might get there. If this mechanism works, then we might get it mandated= . I don't want to assume that happens. Are un-signed calls worth less? Yes, but see above Should signing regulations extend to carrier-based and Over-The-Top cover= sational applications beyond voice, such as video, text, IM? Clearly a tricky subject. I have opinions, but I don't think they matter w= ith respect to this discussion. Let's say that if you are using a delegate= d telephone number associated with a service, then probably whatever regula= tions apply to the service could be extended to cover stir at some point. --_000_4B1956260CD29F4A9622F00322FE0531EC8F0D508BBOBO1Abobotek_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What can = be done once a source of abusive calls is identified?   In other = communications services a set of tools and processes is used to mitigate ab= usive communications.  These go beyond simple automated blocking filte= rs, and include account restriction, end-user reporting mechanisms, reputat= ion databases (content/fingerprint, source, service provider, …) and = feedback loops. 

 

In voice, one might ex= pect enforcement activities (based at least in part on calling party phone = numbers) to include:

 

&= middot;    = ;     Call blocki= ng by terminating telco with consent of recipient

·         Call blocking by terminating telco in e= xtreme situations in defense of networks

·         Call blocking by 3rd party app with = consent of recipient

· = ;        = Account restriction by originating telco

= ·         Feedback from terminating parties (end us= er, terminating telco, …) to upstream telcos and security vendors

·= ;     = ;    Civil and/or crim= inal enforcement action against originator and/or originating telco

 

It should also be noted that selective= blocking of text messages (e.g., spam) and shutdown of anonymously-obtaine= d accounts that appear to have been created with the purpose of originating= abusive text messages is a common service provider practice in North Ameri= ca and several other regions.  This is not to suggest that voice call = blocking is subject to the same policies and regulations as blocking of dat= a calls such as text messages in many jurisdictions. 

 

Regards,

 

= Alex

 

From: stir [mailto:= stir-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Thur= sday, March 06, 2014 1:35 AM
To: Gorman, Pierce A [NTK]
Cc:= stir@ietf.org; DOLLY, MARTIN C; Richard Shockey
Subject: Re:= [stir] Canonicalization vs. Comparison & now Costs

 

Inline

On Mar 5, 2014, at 6:= 27 PM, Gorman, Pierce A [NTK] <Pierce.Gorman@sprint.com> wrote:



Interesting remark= (s) Richard.  As usual.

 

Blocking = calls has been implicitly and explicitly discussed here, but I will say I a= ssumed that would rarely happen, other than by the consumer of the terminat= ion (just like what happens today).

=

Yes, that’s my view.  I think = it will be hard for service providers to actually block calls.



 

Do we need to= define the tangible benefits of signing calls?

=

 

Is signing a call…

 

·         a source of evid= ence when suing for relief (or in criminal prosecution)?<= /p>

Yes, at least the id= ea that if you place scummy calls, the authorities will be able to find you= because you can’t hide behind a spoofed telephone number.=



·      &n= bsp;  a hi= nt of the trustworthiness of the originator?  (Can we assume people ar= e more trustworthy if they know they can be more easily tracked and identif= ied?)

Not sure how “trustworthy” some scammer that has a legitima= te phone number is, but see above



·         a token for CNAM (see CNIT)?=

Yeah, I = think for phones that only have traditional CNAM, yes.  A prefix perha= ps.  Hopefully SIP phones can have better displays, but I do see this = as a benefit



 

Since the list likes to make assumptions about business models a= nd regulatory enforcement I’ll throw out an assumption and some quest= ions too.

 

I assume capturing signature= s in Call Detail Records is implied. 

Yes.  That’s my idea. =  Capture it in the log, and compute validity off line, none-real time,= hold peering partners to a standard.



Are customers goin= g to be willing to pay more for calls which are signed?  <= /o:p>

Maybe, but I t= hink the benefits of not getting bad calls would drive consumers to service= providers who don’t send them such calls.  That might be a prem= ium service for a while at least



Should there be a choic= e?

Who wants bad calls?  But, sure, there should be a choice. =



  Should the (all) government(s) mandate that customers= must have signed calls?

We might get there.  If this mechanism works, t= hen we might get it mandated.  I don’t want to assume that happe= ns.



Are un-signed calls worth less?

Yes, but see above



  Should signing regulations extend to carrier-based= and Over-The-Top coversational applications beyond voice, such as video, t= ext, IM?

Clearly a tricky subject.  I have opinions, but I don’t t= hink they matter with respect to this discussion.  Let’s say tha= t if you are using a delegated telephone number associated with a service, = then probably whatever regulations apply to the service could be extended t= o cover stir at some point.

<= o:p> 

 

<= /div>= --_000_4B1956260CD29F4A9622F00322FE0531EC8F0D508BBOBO1Abobotek_-- From nobody Thu Mar 6 03:25:09 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A994E1A0297 for ; Thu, 6 Mar 2014 03:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=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 eM_XpYVNlSHP for ; Thu, 6 Mar 2014 03:25:05 -0800 (PST) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7659C1A0272 for ; Thu, 6 Mar 2014 03:25:05 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id j107so6763305qga.7 for ; Thu, 06 Mar 2014 03:25:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=d67Q/3sE1+dbu9DKLDfiuqI23mVgb9AOn2xp/55nuHs=; b=mHemlzmr2QwFZRyquGkYF/MmdMIwvWVY2wNgHt8p7/xBSjjVPMyQpiSkKT1aY04PNf 4gHiNnk+OSTBKDGm6+t4+awmML9cDXuZrZMJMfR9tQ80el7oVVWmFAOstiq2m35oUJGa jvozR1GPOGUNGTb+PSpjU5x5mOkPFnLohexY/DJ5lvM12emdtOUk1lG1x2pGKhnW7koS y01e1ju3gyS8yePEISbE9YU4KCnBqTrAQawmbPg7tIWJsnS9NFgBtwzoaU5lqNuOEuwd 1WLmeqaMjmj8J4rNafusD7AoVnnIz/gD90+azFWUO47j4AW7pfTGnm2H0JchG8qc30SS aGJA== X-Gm-Message-State: ALoCoQlI5xRaz5sRUy0SFjuWVlTu/ERaDdH9RaPcchOfXsPs+0aDzwOS9QrVsV5JmDWPaBkfJNmQ X-Received: by 10.140.107.10 with SMTP id g10mr9266029qgf.63.1394105101414; Thu, 06 Mar 2014 03:25:01 -0800 (PST) Received: from [192.168.128.127] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id p67sm7261493qgd.8.2014.03.06.03.24.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 03:25:00 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1B31584A-40B3-4D26-8289-242B316F7F15" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Brian Rosen In-Reply-To: <4B1956260CD29F4A9622F00322FE0531EC8F0D508B@BOBO1A.bobotek.net> Date: Thu, 6 Mar 2014 11:24:56 +0000 Message-Id: References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <7CF4268D-2E96-4B5A-880A-D8F57936D897@brianrosen.net> <003f01cf37e4$50046450$f00d2cf0$@shockey.us>, <46A5903A-EEF0-4418-BA4A-FABD259C7AE9@brianrosen.net> <10C82B1D-415F-4A7D-A27F-B8576FA6CF1B@att.com> <018a01cf3899$5b5e4450$121accf0$@shockey.us> <16E4CB3B-3BAE-4629-8D6F-4FC410ED2B5F@brianrosen.net> <4B1956260CD29F4A9622F00322FE0531EC8F0D508B@BOBO1A.bobotek.net> To: Alex Bobotek X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/h3TW5Uga4jaLlXYqZY3rllR-ens Cc: "stir@ietf.org" , "Gorman, Pierce A \[NTK\]" , "DOLLY, MARTIN C" , Richard Shockey Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 11:25:07 -0000 --Apple-Mail=_1B31584A-40B3-4D26-8289-242B316F7F15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Good list. I think all of these are possible although, remembering that = IANAL, I=92m not sure how far enforcement action on originating telcos = could be taken. I suspect that if stir is widely deployed, and some = small set of service providers are still sending lots of garbage calls, = that it will become easier to prosecute them. Having met some of the regulators in both the FCC and FTC who deal with = this stuff, they are VERY eager to get tools to identify and prosecute = the bad guys. Brian On Mar 6, 2014, at 11:12 AM, Alex Bobotek wrote: > What can be done once a source of abusive calls is identified? In = other communications services a set of tools and processes is used to = mitigate abusive communications. These go beyond simple automated = blocking filters, and include account restriction, end-user reporting = mechanisms, reputation databases (content/fingerprint, source, service = provider, =85) and feedback loops.=20 > =20 > In voice, one might expect enforcement activities (based at least in = part on calling party phone numbers) to include: > =20 > =B7 Call blocking by terminating telco with consent of = recipient > =B7 Call blocking by terminating telco in extreme situations = in defense of networks > =B7 Call blocking by 3rd party app with consent of recipient > =B7 Account restriction by originating telco > =B7 Feedback from terminating parties (end user, terminating = telco, =85) to upstream telcos and security vendors > =B7 Civil and/or criminal enforcement action against = originator and/or originating telco > =20 > It should also be noted that selective blocking of text messages = (e.g., spam) and shutdown of anonymously-obtained accounts that appear = to have been created with the purpose of originating abusive text = messages is a common service provider practice in North America and = several other regions. This is not to suggest that voice call blocking = is subject to the same policies and regulations as blocking of data = calls such as text messages in many jurisdictions.=20 > =20 > Regards, > =20 > Alex > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Thursday, March 06, 2014 1:35 AM > To: Gorman, Pierce A [NTK] > Cc: stir@ietf.org; DOLLY, MARTIN C; Richard Shockey > Subject: Re: [stir] Canonicalization vs. Comparison & now Costs > =20 > Inline > On Mar 5, 2014, at 6:27 PM, Gorman, Pierce A [NTK] = wrote: >=20 >=20 > Interesting remark(s) Richard. As usual. > =20 > Blocking calls has been implicitly and explicitly discussed here, but = I will say I assumed that would rarely happen, other than by the = consumer of the termination (just like what happens today). > Yes, that=92s my view. I think it will be hard for service providers = to actually block calls. >=20 >=20 > =20 > Do we need to define the tangible benefits of signing calls? > =20 > Is signing a call=85 > =20 > =B7 a source of evidence when suing for relief (or in criminal = prosecution)? > Yes, at least the idea that if you place scummy calls, the authorities = will be able to find you because you can=92t hide behind a spoofed = telephone number. >=20 >=20 > =B7 a hint of the trustworthiness of the originator? (Can we = assume people are more trustworthy if they know they can be more easily = tracked and identified?) > Not sure how =93trustworthy=94 some scammer that has a legitimate = phone number is, but see above >=20 >=20 > =B7 a token for CNAM (see CNIT)? > Yeah, I think for phones that only have traditional CNAM, yes. A = prefix perhaps. Hopefully SIP phones can have better displays, but I do = see this as a benefit >=20 >=20 > =20 > Since the list likes to make assumptions about business models and = regulatory enforcement I=92ll throw out an assumption and some questions = too. > =20 > I assume capturing signatures in Call Detail Records is implied.=20 > Yes. That=92s my idea. Capture it in the log, and compute validity = off line, none-real time, hold peering partners to a standard. >=20 >=20 > Are customers going to be willing to pay more for calls which are = signed?=20 > Maybe, but I think the benefits of not getting bad calls would drive = consumers to service providers who don=92t send them such calls. That = might be a premium service for a while at least >=20 >=20 > Should there be a choice? > Who wants bad calls? But, sure, there should be a choice.=20 >=20 >=20 > Should the (all) government(s) mandate that customers must have = signed calls? > We might get there. If this mechanism works, then we might get it = mandated. I don=92t want to assume that happens. >=20 >=20 > Are un-signed calls worth less? > Yes, but see above >=20 >=20 > Should signing regulations extend to carrier-based and Over-The-Top = coversational applications beyond voice, such as video, text, IM? > Clearly a tricky subject. I have opinions, but I don=92t think they = matter with respect to this discussion. Let=92s say that if you are = using a delegated telephone number associated with a service, then = probably whatever regulations apply to the service could be extended to = cover stir at some point. --Apple-Mail=_1B31584A-40B3-4D26-8289-242B316F7F15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Good = list.  I think all of these are possible although, remembering that = IANAL, I=92m not sure how far enforcement action on originating telcos = could be taken.  I suspect that if stir is widely deployed, and = some small set of service providers are still sending lots of garbage = calls, that it will become easier to prosecute = them.

Having met some of the regulators in both the = FCC and FTC who deal with this stuff, they are VERY eager to get tools = to identify and prosecute the bad = guys.

Brian
On Mar 6, = 2014, at 11:12 AM, Alex Bobotek <alex@bobotek.net> = wrote:

What can be done once a source of abusive calls is = identified?   In other communications services a set of tools = and processes is used to mitigate abusive communications.  These go = beyond simple automated blocking filters, and include account = restriction, end-user reporting mechanisms, reputation databases = (content/fingerprint, source, service provider, =85) and feedback = loops. 
 
In voice, one might expect enforcement activities = (based at least in part on calling party phone numbers) to = include:
 
=B7         Call blocking by terminating telco with consent of = recipient
=B7         Call blocking by terminating telco in extreme = situations in defense of networks
=B7         Call blocking by 3rd party app with consent of = recipient
=B7         Account restriction by originating = telco
=B7         Feedback from terminating parties (end user, = terminating telco, =85) to upstream telcos and security = vendors
=B7         Civil and/or criminal enforcement action against = originator and/or originating telco
 
It should also be noted = that selective blocking of text messages (e.g., spam) and shutdown of = anonymously-obtained accounts that appear to have been created with the = purpose of originating abusive text messages is a common service = provider practice in North America and several other regions.  This = is not to suggest that voice call blocking is subject to the same = policies and regulations as blocking of data calls such as text messages = in many jurisdictions. 
 
Regards,
 
Alex
 
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Thursday, March 06, 2014 = 1:35 AM
To: Gorman, Pierce A = [NTK]
Cc: stir@ietf.org; DOLLY, MARTIN C; = Richard Shockey
Subject: Re: [stir] Canonicalization = vs. Comparison & now Costs
 
Inline
On = Mar 5, 2014, at 6:27 PM, Gorman, Pierce A [NTK] <Pierce.Gorman@sprint.com> = wrote:


Interesting remark(s) Richard.  As = usual.
 
Blocking calls has been implicitly and = explicitly discussed here, but I will say I assumed that would rarely = happen, other than by the consumer of the termination (just like what = happens today).
Yes, that=92s my view.  I think it will be hard = for service providers to actually block = calls.


 
Do we need to define the tangible benefits of signing = calls?
 
Is signing a = call=85
 
=B7         a source of evidence when suing for relief (or in criminal = prosecution)?
Yes, at least the idea that if you place scummy = calls, the authorities will be able to find you because you can=92t hide = behind a spoofed telephone number.


=B7         a hint of the trustworthiness of the originator?  (Can we = assume people are more trustworthy if they know they can be more easily = tracked and identified?)
Not sure how =93trustworthy=94 some scammer that has = a legitimate phone number is, but see = above


=B7         a token for CNAM (see = CNIT)?
Yeah, I think for phones that only have traditional CNAM, yes. =  A prefix perhaps.  Hopefully SIP phones can have better = displays, but I do see this as a benefit


 
Since the list likes to make = assumptions about business models and regulatory enforcement I=92ll = throw out an assumption and some questions = too.
 
I assume capturing signatures in Call Detail = Records is implied. 
Yes.  That=92s my idea.  Capture it in the = log, and compute validity off line, none-real time, hold peering = partners to a standard.


Are = customers going to be willing to pay more for calls which are = signed? 
Maybe, but I think the benefits of not getting bad calls would = drive consumers to service providers who don=92t send them such calls. =  That might be a premium service for a while at = least


Should = there be a choice?
Who wants bad calls?  But, sure, there should = be a choice. 


  = Should the (all) government(s) mandate that customers must have signed = calls?
We = might get there.  If this mechanism works, then we might get it = mandated.  I don=92t want to assume that = happens.


Are = un-signed calls worth less?
Yes, but see above


  Should signing regulations extend to = carrier-based and Over-The-Top coversational applications beyond voice, = such as video, text, IM?
Clearly a tricky subject.  I have opinions, but = I don=92t think they matter with respect to this discussion.  Let=92s= say that if you are using a delegated telephone number associated with = a service, then probably whatever regulations apply to the service could = be extended to cover stir at some = point.

= --Apple-Mail=_1B31584A-40B3-4D26-8289-242B316F7F15-- From nobody Thu Mar 6 09:37:13 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6380E1A00F4 for ; Thu, 6 Mar 2014 09:37:12 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 Vxtad7NiA7HW for ; Thu, 6 Mar 2014 09:37:07 -0800 (PST) Received: from oproxy17-pub.mail.unifiedlayer.com (oproxy17-pub.mail.unifiedlayer.com [74.220.201.171]) by ietfa.amsl.com (Postfix) with SMTP id 5B1941A0051 for ; Thu, 6 Mar 2014 09:37:07 -0800 (PST) Received: (qmail 10733 invoked by uid 0); 6 Mar 2014 17:36:55 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy17.mail.unifiedlayer.com with SMTP; 6 Mar 2014 17:36:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=Hb8maCyylieP1azweu/7rONPLeqzQziND98DlkSq/w0=; b=ZKK5j+f3cWJ96cUKrvX6s1e83LizgsxqX4phVyPuQ8m9Vwe+7Pq0YlXqAJBxOQKlR4UfIer73zE06tONg54prJWJTLN5ng3VZKlvjY57U6abpROjKCl1YDzB14BE58XR; Received: from [173.79.179.104] (port=50604 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1WLcE2-0005cK-Dk; Thu, 06 Mar 2014 10:36:54 -0700 From: "Richard Shockey" To: "'Brian Rosen'" , References: <001901cf37d6$4ed6c220$ec844660$@shockey.us> <7CF4268D-2E96-4B5A-880A-D8F57936D897@brianrosen.net> <003f01cf37e4$50046450$f00d2cf0$@shockey.us>, <46A5903A-EEF0-4418-BA4A-FABD259C7AE9@brianrosen.net> <10C82B1D-415F-4A7D-A27F-B8576FA6CF1B@att.com> <018a01cf3899$5b5e4450$121accf0$@shockey.us> <16E4CB3B-3BAE-4629-8D6F-4FC410ED2B5F@brianrosen.net> <4B1956260CD29F4A9622F00322FE0531EC8F0D508B@BOBO1A.bobotek.net> In-Reply-To: Date: Thu, 6 Mar 2014 12:36:50 -0500 Message-ID: <004701cf3962$a9a8bd60$fcfa3820$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01CF3938.C0D5E9B0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMM+v8p2Zf/9wiklc7kKQbJqsyO1AEmRtuqAaE85pUCAzbxZwKwuh1/AnnSS5sBtma6dgHJGJE8AsvvR/8CBjVjDwFjEAPul7t7mXA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/495UH0GD9-ItWGkNqRsb7TcEO3g Subject: Re: [stir] Canonicalization vs. Comparison & now Costs X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 17:37:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0048_01CF3938.C0D5E9B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, March 06, 2014 6:25 AM To: Alex Bobotek Cc: stir@ietf.org; Gorman, Pierce A [NTK]; DOLLY, MARTIN C; Richard Shockey Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Good list. I think all of these are possible although, remembering that IANAL, I'm not sure how far enforcement action on originating telcos could be taken. [RS> ] Oh its real easy. Look at the German Bundesnetzagentur they simply ban the practice of Call Spoofing totally and annually take a recalcitrant carrier fine them 15-20 M Euros and somebody gets the message. I suspect that if stir is widely deployed, and some small set of service providers are still sending lots of garbage calls, that it will become easier to prosecute them. Having met some of the regulators in both the FCC and FTC who deal with this stuff, they are VERY eager to get tools to identify and prosecute the bad guys. [RS> ] As have I and a lot more as well. But if we can agree on anything STIR is not the total answer. Track and Trace at the gateways using some Pseudo ANI identifier. CNIT. I'm not sure about *50. I'm not sure if the code is even supported in the legacy C5's Certainly not the Nortel DMS platforms and the UK has still got a lot of SIEMENS sitting around and if it isn't there is no way on earth it's going to get reprogrammed. I cant get a straight answer about the Ericsson CSCF's. So Brian If I recall the last person to ever see 911 code in a 5ESS retired how many years ago? Brian On Mar 6, 2014, at 11:12 AM, Alex Bobotek > wrote: What can be done once a source of abusive calls is identified? In other communications services a set of tools and processes is used to mitigate abusive communications. These go beyond simple automated blocking filters, and include account restriction, end-user reporting mechanisms, reputation databases (content/fingerprint, source, service provider, .) and feedback loops. In voice, one might expect enforcement activities (based at least in part on calling party phone numbers) to include: * Call blocking by terminating telco with consent of recipient * Call blocking by terminating telco in extreme situations in defense of networks * Call blocking by 3rd party app with consent of recipient * Account restriction by originating telco * Feedback from terminating parties (end user, terminating telco, .) to upstream telcos and security vendors * Civil and/or criminal enforcement action against originator and/or originating telco It should also be noted that selective blocking of text messages (e.g., spam) and shutdown of anonymously-obtained accounts that appear to have been created with the purpose of originating abusive text messages is a common service provider practice in North America and several other regions. This is not to suggest that voice call blocking is subject to the same policies and regulations as blocking of data calls such as text messages in many jurisdictions. Regards, Alex From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, March 06, 2014 1:35 AM To: Gorman, Pierce A [NTK] Cc: stir@ietf.org ; DOLLY, MARTIN C; Richard Shockey Subject: Re: [stir] Canonicalization vs. Comparison & now Costs Inline On Mar 5, 2014, at 6:27 PM, Gorman, Pierce A [NTK] < Pierce.Gorman@sprint.com> wrote: Interesting remark(s) Richard. As usual. Blocking calls has been implicitly and explicitly discussed here, but I will say I assumed that would rarely happen, other than by the consumer of the termination (just like what happens today). Yes, that's my view. I think it will be hard for service providers to actually block calls. Do we need to define the tangible benefits of signing calls? Is signing a call. * a source of evidence when suing for relief (or in criminal prosecution)? Yes, at least the idea that if you place scummy calls, the authorities will be able to find you because you can't hide behind a spoofed telephone number. * a hint of the trustworthiness of the originator? (Can we assume people are more trustworthy if they know they can be more easily tracked and identified?) Not sure how "trustworthy" some scammer that has a legitimate phone number is, but see above * a token for CNAM (see CNIT)? Yeah, I think for phones that only have traditional CNAM, yes. A prefix perhaps. Hopefully SIP phones can have better displays, but I do see this as a benefit Since the list likes to make assumptions about business models and regulatory enforcement I'll throw out an assumption and some questions too. I assume capturing signatures in Call Detail Records is implied. Yes. That's my idea. Capture it in the log, and compute validity off line, none-real time, hold peering partners to a standard. Are customers going to be willing to pay more for calls which are signed? Maybe, but I think the benefits of not getting bad calls would drive consumers to service providers who don't send them such calls. That might be a premium service for a while at least Should there be a choice? Who wants bad calls? But, sure, there should be a choice. Should the (all) government(s) mandate that customers must have signed calls? We might get there. If this mechanism works, then we might get it mandated. I don't want to assume that happens. Are un-signed calls worth less? Yes, but see above Should signing regulations extend to carrier-based and Over-The-Top coversational applications beyond voice, such as video, text, IM? Clearly a tricky subject. I have opinions, but I don't think they matter with respect to this discussion. Let's say that if you are using a delegated telephone number associated with a service, then probably whatever regulations apply to the service could be extended to cover stir at some point. ------=_NextPart_000_0048_01CF3938.C0D5E9B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: stir = [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Thursday, March 06, 2014 6:25 AM
To: = Alex Bobotek
Cc: stir@ietf.org; Gorman, Pierce A [NTK]; DOLLY, = MARTIN C; Richard Shockey
Subject: Re: [stir] Canonicalization = vs. Comparison & now Costs

 

Good list. =  I think all of these are possible although, remembering that = IANAL, I’m not sure how far enforcement action on originating = telcos could be taken.  

 

[RS> ] Oh its real easy.  Look at the German = Bundesnetzagentur they simply ban the practice of Call Spoofing totally = and annually take a recalcitrant carrier fine them 15-20 M Euros and = somebody gets the message.

 

I suspect = that if stir is widely deployed, and some small set of service providers = are still sending lots of garbage calls, that it will become easier to = prosecute them.

 

Having met some of the regulators in both the FCC and = FTC who deal with this stuff, they are VERY eager to get tools to = identify and prosecute the bad guys.

 

[RS> ]  As have I and a lot more as well. But if we can agree = on anything STIR is not the total answer. Track and Trace at the = gateways using some Pseudo ANI identifier. CNIT.  I’m not = sure about *50. I’m not sure if the code is even supported in the = legacy C5’s Certainly not the Nortel DMS platforms and the UK has = still got a lot of SIEMENS sitting around and if it isn’t there is = no way on earth it’s going to get reprogrammed.  I cant get a = straight answer about the Ericsson CSCF’s.   So Brian If = I recall the last person to ever see 911 code in a 5ESS retired how many = years ago?

 

 

Brian

On Mar 6, 2014, at 11:12 AM, Alex Bobotek <alex@bobotek.net> = wrote:



What can be done once a source of abusive calls is = identified?   In other communications services a set of tools = and processes is used to mitigate abusive communications.  These go = beyond simple automated blocking filters, and include account = restriction, end-user reporting mechanisms, reputation databases = (content/fingerprint, source, service provider, …) and feedback = loops. 

 

In voice, one might expect enforcement activities (based at least in = part on calling party phone numbers) to = include:

 

·     &nb= sp;   Call blocking by terminating telco with consent of = recipient

·     &nb= sp;   Call blocking by terminating telco in extreme situations in defense = of networks

·     &nb= sp;   Call blocking by 3rd party app with consent of = recipient

·     &nb= sp;   Account restriction by originating = telco

·     &nb= sp;   Feedback from terminating parties (end user, terminating telco, = …) to upstream telcos and security = vendors

·     &nb= sp;   Civil and/or criminal enforcement action against originator and/or = originating telco

 

It should also be noted that selective blocking of text messages = (e.g., spam) and shutdown of anonymously-obtained accounts that appear = to have been created with the purpose of originating abusive text = messages is a common service provider practice in North America and = several other regions.  This is not to suggest that voice call = blocking is subject to the same policies and regulations as blocking of = data calls such as text messages in many = jurisdictions. 

 

Regards,

 

Alex

 

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian = Rosen
Sent: Thursday, March 06, 2014 1:35 = AM
To: Gorman, = Pierce A [NTK]
Cc: stir@ietf.org; DOLLY, MARTIN C; = Richard Shockey
Subject: Re: [stir] Canonicalization = vs. Comparison & now = Costs

 

Inline

On Mar 5, 2014, at 6:27 PM, Gorman, Pierce A [NTK] = <Pierce.Gorman@sprint.com> = wrote:




Interesting remark(s) Richard.  As = usual.

 

Blocking calls has been implicitly and explicitly discussed here, but I = will say I assumed that would rarely happen, other than by the consumer = of the termination (just like what happens = today).

Yes, that’s my view.  I think it will be = hard for service providers to actually block = calls.




 

Do we need to define the tangible benefits of signing = calls?

 

Is signing a call…

 

·     &nb= sp;   a source of evidence when suing for relief (or in criminal = prosecution)?

Yes, at least the idea that if you place scummy calls, = the authorities will be able to find you because you can’t hide = behind a spoofed telephone = number.




·     &nb= sp;   a hint of the trustworthiness of the originator?  (Can we assume = people are more trustworthy if they know they can be more easily tracked = and identified?)

Not sure how “trustworthy” some scammer = that has a legitimate phone number is, but see = above




·     &nb= sp;   a token for CNAM (see = CNIT)?

Yeah, I think for phones that only have traditional = CNAM, yes.  A prefix perhaps.  Hopefully SIP phones can have = better displays, but I do see this as a = benefit




 

Since the list likes to make assumptions about business models and = regulatory enforcement I’ll throw out an assumption and some = questions too.

 

I assume capturing signatures in Call Detail Records is = implied. 

Yes.  That’s my idea.  Capture it in = the log, and compute validity off line, none-real time, hold peering = partners to a standard.




Are customers going to be willing to pay more for calls which are = signed? 

Maybe, but I think the benefits of not getting bad = calls would drive consumers to service providers who don’t send = them such calls.  That might be a premium service for a while at = least




Should there be a = choice?

Who wants bad calls?  But, sure, there should be = a choice. 




  Should the (all) government(s) mandate that customers must have = signed calls?

We might get there.  If this mechanism works, = then we might get it mandated.  I don’t want to assume that = happens.




Are un-signed calls worth = less?

Yes, but see = above




  Should signing regulations extend to carrier-based and = Over-The-Top coversational applications beyond voice, such as video, = text, IM?

Clearly a tricky subject.  I have opinions, but I = don’t think they matter with respect to this discussion. =  Let’s say that if you are using a delegated telephone number = associated with a service, then probably whatever regulations apply to = the service could be extended to cover stir at some = point.

 

------=_NextPart_000_0048_01CF3938.C0D5E9B0-- From nobody Fri Mar 7 15:46:02 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A787D1A020D for ; Fri, 7 Mar 2014 15:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=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 h38vT5nTUr-j for ; Fri, 7 Mar 2014 15:45:58 -0800 (PST) Received: from oproxy9-pub.mail.unifiedlayer.com (oproxy9-pub.mail.unifiedlayer.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 9B1CF1A01C0 for ; Fri, 7 Mar 2014 15:45:58 -0800 (PST) Received: (qmail 18329 invoked by uid 0); 7 Mar 2014 23:45:53 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.mail.unifiedlayer.com with SMTP; 7 Mar 2014 23:45:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=UcAGpxee/2R2vZHt3r6z6tvuembAYfoJkvaQPocWbvA=; b=lH6AcxeRuZd31gQ8KM/hcK9v4aE9UkbIzJqL8L7GX6XL5b1RHnYqtw9qCL1B5mLNsa2YbJ3LvmqLsGdk4qNnjYgaiG6rHJQKu5zq5+C97Exm8VMluPe8yJ3tpSGpNZUK; Received: from [173.79.179.104] (port=55876 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1WM4Se-0005zf-Tu for stir@ietf.org; Fri, 07 Mar 2014 16:45:53 -0700 From: "Richard Shockey" To: Date: Fri, 7 Mar 2014 18:45:48 -0500 Message-ID: <013e01cf3a5f$5f8416f0$1e8c44d0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013F_01CF3A35.76AE0EF0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac86XCZaCosgojpHSp6tdol694LQAQ== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/A746Lb5HqzLY7dtkY9xZAD-d5iA Subject: [stir] On the issue of next steps. X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 23:46:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_013F_01CF3A35.76AE0EF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In the end of the meeting the chairs asked the question of whether the 4474bis document should be adopted as WG item and, with some trepidation, I think it should. We have to know what goes on the wire. I hope this does not end up being a one sided discussion. 4474bis is the core document. I'm hesitant to suggest the WG go too much further into the PKI here until we understand the implications of NRA views and costs. Even in the case of SIDR you had to understand these issues as part of the design process. As an "expert body" I think we can/maybe/should recommend TN level certs at some point in time. I'm open minded here. There might be some real innovation we could enable here if we look beyond simple Number block level delegation. That said I still have zero confidence in enabling this in CUA's before we can do it within carrier networks first. Get someone at Apple or Google in the room and I might be convinced. And the Out of Band solution is a nonstarter. Just saying! Richard Shockey Shockey Consulting LLC http://www.shockey.us Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http://www.sipforum.org "Money is the answer, what is the question?" tm ------=_NextPart_000_013F_01CF3A35.76AE0EF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

In the end = of the meeting the chairs asked the question of whether the 4474bis = document should be adopted as WG item and, with some trepidation, I = think it should.

 

We have to = know what goes on the wire.  I hope this does not end up being a = one sided discussion. 

 

4474bis is =  the core document.

 

I’m = hesitant to suggest the WG go too much further into the PKI here until = we understand the implications of NRA views and costs.  Even in the = case of SIDR you had to understand these issues as part of the design = process.

 

As an “expert body” I think we = can/maybe/should recommend TN level certs at some point in time. = I’m open minded here.  There might be some real innovation we = could enable here if we look beyond simple Number block level = delegation.

 

That said I still have zero confidence in enabling = this in CUA’s before we can do it within carrier networks first. = Get someone at Apple or Google in the room and I might be convinced. =

 

And the Out of Band solution is a nonstarter.  =

 

Just saying! 

Richard = Shockey
Shockey Consulting LLC

http://www.shockey.us
Chairman of the Board of = Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype= -linkedin-facebook: = rshockey101
http://www.sipforum.org

"Money is the answer, what is the question?" = tm

 

 

------=_NextPart_000_013F_01CF3A35.76AE0EF0-- From nobody Wed Mar 12 00:44:41 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C721A0900 for ; Wed, 12 Mar 2014 00:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.97 X-Spam-Level: X-Spam-Status: No, score=0.97 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] autolearn=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 64MdbtCiJ1t5 for ; Wed, 12 Mar 2014 00:44:38 -0700 (PDT) Received: from leaf.named.informdeskmedia.ru (leaf.named.informdeskmedia.ru [85.17.236.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5109C1A08EB for ; Wed, 12 Mar 2014 00:44:37 -0700 (PDT) Received: from [2a02:578:5002:1a::2] (account postmaster@leaf.named.informdeskmedia.ru HELO firepaw) by leaf.named.informdeskmedia.ru (CommuniGate Pro SMTP 6.0.4 _community_) with ESMTPSA id 2313778; Wed, 12 Mar 2014 11:44:30 +0400 Date: Wed, 12 Mar 2014 09:44:25 +0200 From: Anton Baskov To: Hadriel Kaplan Message-Id: <20140312094425.726cab3e4df68f35eee23f5b@ministry.int.ru> In-Reply-To: References: <00C069FD01E0324C9FFCADF539701DB3BBF3AF02@sc9-ex2k10mb1.corp.yaanatech.com> X-Mailer: Sylpheed 3.3.1 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/stir/F9apZooRABULKBV3o_4vZpo4zeg Cc: "rlb@ipv.sx" , "stir@ietf.org" , Michael Hammer , "md3135@att.com" , "br@brianrosen.net" Subject: Re: [stir] Canonicalization vs. Comparison X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 07:44:40 -0000 Agree with Hadriel, inclusion of golden object in a message is very useful, mostly in case of multiple To/From to choose because we have approximately 4*(N To)*(N From) variants of golden object (4 – because each To/From can appear in golden object in canonized or not canonized form). Anton On Mon, 3 Mar 2014 14:08:43 -0500 Hadriel Kaplan wrote: > > On Mar 3, 2014, at 9:50 AM, Michael Hammer wrote: > > > Richard, > > > > The inclusion of the golden object in the message is a waste, since the > > receiver must re-generate it anyway. > > The receiver cannot rely on just the golden object, since that could be > > spoofed. > > It can rely only on the one it generates itself, and can pretty much ignore > > the one in the message. > > So, this really devolves to just one case. > > Actually there were three benefits to it, identified in draft-kaplan-stir-ikes-out-00: > > 1) It lets the verifier perform a very quick fail check using just strcmp(). In other words, if the golden object it generates from the To/From don't string-match the one in the Identity-X header, then it can go ahead and fail the verification immediately without bothering to get the cert, do the crypto, etc. IF the strings match, then it has to keep doing the rest of the work to verify it. > > 2) It helps debug problems for the folks running the systems. > > 3) It provides a way to do a "if-then-else" conditional, in case there are multiple potential golden objects. I raised that at the mic today, but kinda forgot when exactly that might happen; I just re-read the IKES draft and it points out that in call-forwarding scenarios the verifier may well have multiple To/From canonical numbers to choose from.Agree with Hadriel, inclusion of golden object in a message is very useful, mostly in case of multiple To/From to choose because we have approximately 4*(N To)*(N From) variants of golden object (4 – because each To/From field can be canonized or not). > > > > Also, there is a danger that someone takes a short cut and does not validate > > the included golden object. > > Yup. The implementor has to follow the MUSTs. Not much we can do about them not doing so. :( > > -hadriel > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir -- Anton Baskov +7 (911) 254-77-92, +7 (916) 716-89-46 From nobody Wed Mar 12 14:49:56 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EB81A0685 for ; Wed, 12 Mar 2014 14:49:53 -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 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 fyQJlILUFhf1 for ; Wed, 12 Mar 2014 14:49:52 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7EC1A0479 for ; Wed, 12 Mar 2014 14:49:52 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 685339A4392 for ; Wed, 12 Mar 2014 17:49:36 -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 9gNpMQALvOQo for ; Wed, 12 Mar 2014 17:49:15 -0400 (EDT) Received: from [192.168.2.100] (pool-96-241-160-129.washdc.fios.verizon.net [96.241.160.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 955249A438B for ; Wed, 12 Mar 2014 17:49:15 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Mar 2014 17:49:04 -0400 Message-Id: <1570FF06-AE02-4D32-AEBA-52E892588602@vigilsec.com> To: IETF STIR Mail List Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/hPUBJWPJFN5HxyNZzUF8MoGKPAM Subject: [stir] draft-jennings-stir-rfc4474bis-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 21:49:53 -0000 http://www.ietf.org/id/draft-jennings-stir-rfc4474bis-01.txt Should the working group adopt this I-D as the basis for the STIR WG = document on authenticated identity management? Russ From nobody Wed Mar 12 15:54:50 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7BB1A07A8 for ; Wed, 12 Mar 2014 15:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 hOLZs3JELjqv for ; Wed, 12 Mar 2014 15:54:46 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5597D1A07A5 for ; Wed, 12 Mar 2014 15:54:46 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id e16so262285qcx.6 for ; Wed, 12 Mar 2014 15:54:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=3557Jjr6i84ETG8O3LQUaTaHSmxlL58Gquj1RJq7tJ8=; b=ddvfTJUiFQW/r/AhqG1zx3MzMKq3nn3rJ/TgU3/PUTWZu2wSe5Kn679k+XB6Qo8WGN xvpoJwLESdwSo13MofcoJg6328q6OpMyM4pFHbYTwsOzb7IPwUO93DAyaoLFcUzKakn5 KsxoI4wf4FoxN5cEVbHbLOQD/Ru5G6819Z8zXL/hKltfjoxeoAkcxBZEf05dGrlPWli+ p9czJHQXQGQ1akQbq2FAF9TMocIqUCPt/AojJyi3xD83Uo1ijvehDb2dWoKjIvsjvz8X t+rCzA+Jv4r9rteU0r+XPgPHWDfBHvBK/P26fpNOeiOoMuftD0cz2Po3+g5GPL2MiSDb ImBA== X-Gm-Message-State: ALoCoQmDlh/5wjZ5jBFmwoIRZfTj5IypNByTydN4AWmYihDInZ4jNpwwmHLr2xHHCMbE5usHQak4 X-Received: by 10.140.85.35 with SMTP id m32mr199809qgd.40.1394664879837; Wed, 12 Mar 2014 15:54:39 -0700 (PDT) Received: from [10.33.192.36] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id v2sm1072590qat.3.2014.03.12.15.54.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Mar 2014 15:54:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Brian Rosen In-Reply-To: <1570FF06-AE02-4D32-AEBA-52E892588602@vigilsec.com> Date: Wed, 12 Mar 2014 18:54:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4F6B77BB-48B8-4DBC-97C6-1A51006D726B@brianrosen.net> References: <1570FF06-AE02-4D32-AEBA-52E892588602@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/CQMa1Ole8z4WwJEnNV7qtFwIGOg Cc: IETF STIR Mail List Subject: Re: [stir] draft-jennings-stir-rfc4474bis-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 22:54:48 -0000 I have reviewed this document and would like to see it adopted. Brian On Mar 12, 2014, at 5:49 PM, Russ Housley wrote: > http://www.ietf.org/id/draft-jennings-stir-rfc4474bis-01.txt >=20 > Should the working group adopt this I-D as the basis for the STIR WG = document on authenticated identity management? >=20 > Russ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Mon Mar 17 08:15:32 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7C11A0413 for ; Mon, 17 Mar 2014 08:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 vzFzxoTwnBCn for ; Mon, 17 Mar 2014 08:15:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A301A0401 for ; Mon, 17 Mar 2014 08:15:26 -0700 (PDT) Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2HFFHUo063501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Mon, 17 Mar 2014 10:15:18 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88] claimed to be unnumerable.local Message-ID: <53271188.1020203@nostrum.com> Date: Mon, 17 Mar 2014 10:15:20 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: stir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/stir/kxTHUl-SfOqrmclACyvvmqAIUTc Subject: [stir] STIR Minutes from IETF89 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 15:15:29 -0000 Are available at Thanks again to Peter Yee and Jean Mahoney for capturing the notes. Please send any corrections to the list or the chairs ASAP, but no later than Apr 11 please. RjS From nobody Tue Mar 18 09:29:21 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7A51A0714 for ; Tue, 18 Mar 2014 09:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ufSg6RvLdg4O for ; Tue, 18 Mar 2014 09:29:19 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7C81A042E for ; Tue, 18 Mar 2014 09:29:19 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi5so3937857wib.17 for ; Tue, 18 Mar 2014 09:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JWNs0srGm4S5uOD3qw+nu9n9CD7aQ573yvIGPnFnR6A=; b=DQBLImeiXTHuj8BBx5isZ9lOTl/0D4Fb2OXPFwEJ1jLYJaM4lSV4sG5WFGzoN7cx/k tXFj7tqlP34mTwG/2xtZ1ycoFNpclGUHm2bTKAmSPKfHAiBkxU5vHUMnUOwait4XO9ca n7BSQVd+jJ+4U0H2rKNvaT7JCtgwQuLsY2Ea9tJg3aLM4Ra+n/r129NKIVAmLSQXtrhD /GthLIczgspWD5o20OZBG1oTKXYK6lgUh1crHquxZYwQKDzwgR9ntKWps7MWyOROGD9f hEFmPS3YupokjazzLOPQ2ejxsi9AC+FmxT6xzIdsZ/JsXyTB20dtB5fqd11x9DOVsIK8 bhdg== MIME-Version: 1.0 X-Received: by 10.194.202.230 with SMTP id kl6mr24955074wjc.9.1395160150396; Tue, 18 Mar 2014 09:29:10 -0700 (PDT) Received: by 10.216.10.6 with HTTP; Tue, 18 Mar 2014 09:29:10 -0700 (PDT) In-Reply-To: <4F6B77BB-48B8-4DBC-97C6-1A51006D726B@brianrosen.net> References: <1570FF06-AE02-4D32-AEBA-52E892588602@vigilsec.com> <4F6B77BB-48B8-4DBC-97C6-1A51006D726B@brianrosen.net> Date: Tue, 18 Mar 2014 11:29:10 -0500 Message-ID: From: Mary Barnes To: Brian Rosen Content-Type: multipart/alternative; boundary=047d7b873a102b563f04f4e40903 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/LhM6_Erj8QSE2g2io1GuQ4Q6aAA Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] draft-jennings-stir-rfc4474bis-01.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 16:29:21 -0000 --047d7b873a102b563f04f4e40903 Content-Type: text/plain; charset=ISO-8859-1 Ditto. On Wed, Mar 12, 2014 at 5:54 PM, Brian Rosen wrote: > I have reviewed this document and would like to see it adopted. > > Brian > > On Mar 12, 2014, at 5:49 PM, Russ Housley wrote: > > > http://www.ietf.org/id/draft-jennings-stir-rfc4474bis-01.txt > > > > Should the working group adopt this I-D as the basis for the STIR WG > document on authenticated identity management? > > > > Russ > > > > _______________________________________________ > > 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 > --047d7b873a102b563f04f4e40903 Content-Type: text/html; charset=ISO-8859-1
Ditto.


On Wed, Mar 12, 2014 at 5:54 PM, Brian Rosen <br@brianrosen.net> wrote:
I have reviewed this document and would like to see it adopted.

Brian

On Mar 12, 2014, at 5:49 PM, Russ Housley <housley@vigilsec.com> wrote:

> http://www.ietf.org/id/draft-jennings-stir-rfc4474bis-01.txt
>
> Should the working group adopt this I-D as the basis for the STIR WG document on authenticated identity management?
>
> Russ
>
> _______________________________________________
> 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

--047d7b873a102b563f04f4e40903--