From nobody Tue Nov 1 06:35:07 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8481296E8; Tue, 1 Nov 2016 06:35:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> Date: Tue, 01 Nov 2016 06:35:02 -0700 Archived-At: Cc: draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, stir@ietf.org, rjsparks@nostrum.com Subject: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 13:35:03 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-stir-certificates-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have one small issue that I would like to discuss before recommending approval of this document: Reading Section 8 I was unable to figure out what are "claim", "permitted" and "excluded" and what exact syntaxes they use. I think this is underspecified. You are probably missing some references, examples or both. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- URI (RFC 3986), HTTP (RFC 7230) and HTTPS (RFC 2818) need to be Normative References. From nobody Tue Nov 1 07:43:45 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D5512973E; Tue, 1 Nov 2016 07:43:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147801142397.23904.2715782511883042181.idtracker@ietfa.amsl.com> Date: Tue, 01 Nov 2016 07:43:43 -0700 Archived-At: Cc: stir@ietf.org, rjsparks@nostrum.com, stir-chairs@ietf.org, draft-ietf-stir-passport@ietf.org Subject: [stir] Alexey Melnikov's No Objection on draft-ietf-stir-passport-10: (with COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 14:43:44 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-stir-passport-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is generally a well written and detailed document. Thank you. I have some minor comments: 5.1.1. "iat" - Issued At claim The JSON claim MUST include the "iat" [RFC7519] Section 4.1.6 defined claim Issued At. As defined the "iat" should be set to the date and time of issuance of the JWT and MUST the origination I think a verb is missing between "MUST" and "the origination" of the personal communications. 5.2.2. "mky" - Media Key claim 2. Sort the lines based on the UTF8 encoding UTF-8 needs a normative reference (RFC 3629). of the concatenation of the "alg" and "dig" claim value strings. 7.1. Example Compact form PASSporT Token eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9 I decoded this and it looks reasonable: {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/passport.cer"} . eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI 6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0 OpenSSL produced the following: {"dest":{"uri":["sip:alice@example.com"]},"iat": this looks like a truncated value. Is something wrong with the value or is this an OpenSSL bug? From nobody Tue Nov 1 08:15:22 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3990C129A9D for ; Tue, 1 Nov 2016 08:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ubkVWrui0RL for ; Tue, 1 Nov 2016 08:15:05 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117A512995E for ; Tue, 1 Nov 2016 08:15:05 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id o68so203016515qkf.3 for ; Tue, 01 Nov 2016 08:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=04fw47eihFvGZkdwcEUpFjF0X6BR0I0aOmblECoAOi4=; b=JwW+JsiMqSEY0CJX9SyxwR/33kLdpVCxDnumS6aV4oIqDCDurSCDT0F7e8X619lj8N LuBb33dfxPV3z/ZS/d8VmSL/knOGA+TWqFIEACpRYyrYv1mAP7xd2oIqguy+/ZgQsdEM ETuu4raEd+k81NAAx975MocFhB9IMy4dBDL3s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=04fw47eihFvGZkdwcEUpFjF0X6BR0I0aOmblECoAOi4=; b=QfTqvUPZE+z5eTNJOUN0srH6tJ+9ffxMO0kYawf/QiwAlZbHXpCTE9K0bMGLegCE9P 4wqVuwFkfGNt+uXIvEqiv1CGE40Gnroqn2iBCOWIpPF4jgbwgsxSLMJkqogPmeozLAO7 v5nod4Enbv+hYfJUOlSUyaevVAtiNRLwmmLJ+/ouVslpyBSp+8HNgeb384sE3Y23q9pj ApT4vvoZKqDgpAZxoUQqg+cKhziDbhmcKUFlLgQXYdI2bNFXLpiONuWmOn/8lo8+MgyN kUa9I4kVloS81c5QwlAhG6JWS5nUtPl/wHGmjkV9Wo/eVpPZvbrq3VkHwBpvc0PV4Is6 TRZg== X-Gm-Message-State: ABUngvdeVe8WoH8hrFC7CppZ2BsdB3elCDJ2rIyZFJqkzp4sLDk4MsLM+07UlDrMidQGLg== X-Received: by 10.55.166.77 with SMTP id p74mr29080385qke.113.1478013304140; Tue, 01 Nov 2016 08:15:04 -0700 (PDT) Received: from [172.16.0.92] ([96.231.230.70]) by smtp.gmail.com with ESMTPSA id u44sm16013699qtu.5.2016.11.01.08.15.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Nov 2016 08:15:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> Date: Tue, 1 Nov 2016 11:15:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, The IESG , stir@ietf.org, Robert Sparks Subject: Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 15:15:20 -0000 > On Nov 01, 2016, at 09:35, Alexey Melnikov = wrote: >=20 > Alexey Melnikov has entered the following ballot position for > draft-ietf-stir-certificates-11: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I have one small issue that I would like to discuss before = recommending > approval of this document: >=20 > Reading Section 8 I was unable to figure out what are "claim", > "permitted" and "excluded" and what exact syntaxes they use. I think = this > is underspecified. > You are probably missing some references, examples or both. =46rom s5.1: The public key in the certificate is used to validate the signature on a JSON Web Token (JWT) [RFC7519] that conforms to the conventions specified in PASSporT [I-D.ietf-stir-passport]. This specification supports constraints on the JWT claims, which allows the CA to differentiate those enrolled from proof-of-possession versus delegation. the JWT claims for STIR are found in s5 of [I-D.ietf-stir-passport]. We = define our own but also use some existing ones so we could add a = reference as follows to clear this up: =E2=80=A6, This specification supports constraints on the JWT claims [I-D.ietf-stir-passport], which allows the CA to differentiate those enrolled from proof-of-possession versus delegation. Permitted and excluded are in s8 (they=E2=80=99re just IA5Strings): JWTClaimConstraint ::=3D SEQUENCE { claim IA5String, -> permitted [1] SEQUENCE OF IA5String OPTIONAL, -> excluded [2] SEQUENCE OF IA5String OPTIONAL } ( WITH COMPONENTS { ..., permitted PRESENT } | WITH COMPONENTS { ..., excluded PRESENT } ) These are analogous to the permitted and excluded name and policy = constraints in X.509/RFC 5280. spt > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > URI (RFC 3986), HTTP (RFC 7230) and HTTPS (RFC 2818) need to be = Normative > References. >=20 >=20 From nobody Tue Nov 1 11:29:41 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A905F1293F5; Tue, 1 Nov 2016 11:29:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147802497964.23916.2747297219351826234.idtracker@ietfa.amsl.com> Date: Tue, 01 Nov 2016 11:29:39 -0700 Archived-At: Cc: stir@ietf.org, draft-ietf-stir-rfc4474bis@ietf.org, stir-chairs@ietf.org, rjsparks@nostrum.com Subject: [stir] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-stir-rfc4474bis-15=3A_=28with_COMMENT=29?= X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 18:29:40 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-stir-rfc4474bis-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One minor comment: Not sure how the solution with "ppt" field came up for extensibility. Wouldn't it make sense to have a version field instead that always has to be presented (or if not present is assumed to be 0); just to reduce implementation complexity. Or am I missing something? Just wondering... btw. what does 'ppt' stand for? From nobody Tue Nov 1 12:08:14 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BD31294DB; Tue, 1 Nov 2016 12:08:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147802728986.23900.9003042292839164604.idtracker@ietfa.amsl.com> Date: Tue, 01 Nov 2016 12:08:09 -0700 Archived-At: Cc: stir@ietf.org, draft-ietf-stir-rfc4474bis@ietf.org, stir-chairs@ietf.org, rjsparks@nostrum.com Subject: [stir] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-stir-rfc4474bis-15=3A_=28with_COMMENT=29?= X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 19:08:10 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-stir-rfc4474bis-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One minor comment: Not sure how the solution with "ppt" field came up for extensibility. Wouldn't it make sense to have a version field instead that always has to be presented (or if not present is assumed to be 0); just to reduce implementation complexity. Or am I missing something? Just wondering... btw. what does 'ppt' stand for? (Added later) Now I have read draft-ietf-stir-passport. So it clear why this method is used. Didn't realize that the following sentence means 'please check PASSporT for further questions...': "this specification specifies an optional "ppt" parameter of the Identity header field, which mirrors the "ppt" header in PASSporT." Maybe just give a more specific reference including the section refernce. From nobody Tue Nov 1 12:11:02 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAB6129872; Tue, 1 Nov 2016 12:10:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147802745708.23908.9775522438591486750.idtracker@ietfa.amsl.com> Date: Tue, 01 Nov 2016 12:10:57 -0700 Archived-At: Cc: stir@ietf.org, rjsparks@nostrum.com, stir-chairs@ietf.org, draft-ietf-stir-passport@ietf.org Subject: [stir] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-stir-passport-10=3A_=28with_COMMENT=29?= X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 19:10:57 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-stir-passport-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "The claim value for the "tn" claim is the telephone number and MUST be canonicalized according to the procedures specified in [I-D.ietf-stir-rfc4474bis] Section 8.3." This indicated that's section 8.3 of ietf-stir-rfc4474bis belongs in this doc. Is there are reason why it is in ietf-stir-rfc4474bis instead? From nobody Tue Nov 1 14:51:36 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9B51295FA; Tue, 1 Nov 2016 14:51:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147803709486.23916.4800493776778276475.idtracker@ietfa.amsl.com> Date: Tue, 01 Nov 2016 14:51:34 -0700 Archived-At: Cc: stir@ietf.org, rjsparks@nostrum.com, stir-chairs@ietf.org, bwietf@bwijnen.net, draft-ietf-stir-passport@ietf.org Subject: [stir] Benoit Claise's No Objection on draft-ietf-stir-passport-10: (with COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 21:51:35 -0000 Benoit Claise has entered the following ballot position for draft-ietf-stir-passport-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial feedback from Bert Wijnen, our OPS-DIR reviewer: While I was at it, I found someNits and/or typos: The abstract states: The PASSporT token is cryptographically signed to protect the integrity of the identity the originator and to verify the assertion of the identity information at the destination. s/the identity the originator/the identity of the originator/ Or so I think. section 5.1.1 states: As defined the "iat" should be set to the date and time of issuance of the JWT and MUST the origination of the personal communications. The time value should be of the format defined in [RFC7519] Section 2 NumericDate. Is that a correct sentence? or is the a verb missing around "the JWT and MUST the origination" ??? Section 5.2.2 5.2.2. "mky" - Media Key claim Why such a cryptic "mky". Why not "mkey" ?? I can live with it. I just wonder why we make it more cryptic than needed. Section 10.2 2nd bullet In many applications, the end user represented by the asserted identity represents and signer may not be one in the same I do/did not know the term "one in the same". I do know "one and the same". I guess other people may have the same knowledge as I do (as non native English speaker) Bert From nobody Wed Nov 2 08:48:54 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCC612950D; Wed, 2 Nov 2016 08:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=WPLamXnW; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=tdFzvicf 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 aeNEqL3hxPPV; Wed, 2 Nov 2016 08:48:46 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A4B128874; Wed, 2 Nov 2016 08:48:46 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D4C8A209BF; Wed, 2 Nov 2016 11:48:45 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute1.internal (MEProxy); Wed, 02 Nov 2016 11:48:45 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= x-me-sender:message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:references:in-reply-to :subject:date; s=mesmtp; bh=TQbU6kfkrxza4YnwRInTx5kl3ZY=; b=WPLa mXnWL6piU6kMMs1ln/fJvq3LvQQ5Z0ZEnB155R5PgVQ2w2RboAeUBx0QfdOQhYuG QLh225xybU4Ox7x0odhIlaenXlCKf4KUM/LP02neveYNF3r9YWkI1lYBUki5/XmD d1iYzg3jmqNNQTU66j85Qvp/FGSTSFiSZidBpS0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-me-sender:message-id:from:to:cc :mime-version:content-transfer-encoding:content-type:references :in-reply-to:subject:date; s=smtpout; bh=TQbU6kfkrxza4YnwRInTx5k l3ZY=; b=tdFzvicfxjrzmLC+Y8GoUzOPz0Kys6l/shlDOEztPvDabFoZd6fQ217 gqeo/5e+DCusqHkCwRbuaCx1AqWcpMeTTIj0yD8042WlYc0JIOQZf/+DDXZxuL0U hUdBVS96BWbWmwG8fB0FKgmYaDPjt9MsfbnX0Fp09xyZbjFDCtFY= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A877A5A678; Wed, 2 Nov 2016 11:48:45 -0400 (EDT) Message-Id: <1478101725.216255.775166569.1BD2E379@webmail.messagingengine.com> From: Alexey Melnikov To: Sean Turner MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-037c6db9 References: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> In-Reply-To: Date: Wed, 02 Nov 2016 15:48:45 +0000 Archived-At: Cc: draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, The IESG , stir@ietf.org, Robert Sparks Subject: Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 15:48:47 -0000 Hi Sean, On Tue, Nov 1, 2016, at 03:15 PM, Sean Turner wrote: >=20 > > On Nov 01, 2016, at 09:35, Alexey Melnikov wro= te: (snip) > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > >=20 > > I have one small issue that I would like to discuss before recommending > > approval of this document: > >=20 > > Reading Section 8 I was unable to figure out what are "claim", > > "permitted" and "excluded" and what exact syntaxes they use. I think th= is > > is underspecified. > > You are probably missing some references, examples or both. >=20 > From s5.1: >=20 > The public key in the certificate is used to validate the signature > on a JSON Web Token (JWT) [RFC7519] that conforms to the conventions > specified in PASSporT [I-D.ietf-stir-passport]. This specification > supports constraints on the JWT claims, which allows the CA to > differentiate those enrolled from proof-of-possession versus > delegation. >=20 > the JWT claims for STIR are found in s5 of [I-D.ietf-stir-passport]. We > define our own but also use some existing ones so we could add a > reference as follows to clear this up: >=20 > =E2=80=A6, This specification > supports constraints on the JWT claims [I-D.ietf-stir-passport], > which allows the CA to differentiate those enrolled from > proof-of-possession versus delegation. Adding this somewhere in section 8 would help. > Permitted and excluded are in s8 (they=E2=80=99re just IA5Strings): >=20 > JWTClaimConstraint ::=3D SEQUENCE { > claim IA5String, > -> permitted [1] SEQUENCE OF IA5String OPTIONAL, > -> excluded [2] SEQUENCE OF IA5String OPTIONAL } > ( WITH COMPONENTS { ..., permitted PRESENT } | > WITH COMPONENTS { ..., excluded PRESENT } ) >=20 > These are analogous to the permitted and excluded name and policy > constraints in X.509/RFC 5280. I am sorry if I am being thick, but I still don't get what is this all about. Doing a quick scan of RFC 5280 I only found permittedSubtrees. Can you give me an example or two on how this is going to be used? From nobody Wed Nov 2 08:54:25 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1AD128874 for ; Wed, 2 Nov 2016 08:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WBb5591yDpI for ; Wed, 2 Nov 2016 08:54:18 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8EB12950D for ; Wed, 2 Nov 2016 08:54:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 53753300A42 for ; Wed, 2 Nov 2016 11:54:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6EVlW0RJIwKq for ; Wed, 2 Nov 2016 11:54:15 -0400 (EDT) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id BBE09300259; Wed, 2 Nov 2016 11:54:14 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <1478101725.216255.775166569.1BD2E379@webmail.messagingengine.com> Date: Wed, 2 Nov 2016 11:54:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <58F5F6BD-02E0-4DC9-8A69-D918AB5A4B65@vigilsec.com> References: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> <1478101725.216255.775166569.1BD2E379@webmail.messagingengine.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, IESG , IETF STIR Mail List , Robert Sparks Subject: Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 15:54:23 -0000 On Nov 2, 2016, at 11:48 AM, Alexey Melnikov = wrote: > Hi Sean, >=20 > On Tue, Nov 1, 2016, at 03:15 PM, Sean Turner wrote: >>=20 >>> On Nov 01, 2016, at 09:35, Alexey Melnikov = wrote: >=20 > (snip) >=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> I have one small issue that I would like to discuss before = recommending >>> approval of this document: >>>=20 >>> Reading Section 8 I was unable to figure out what are "claim", >>> "permitted" and "excluded" and what exact syntaxes they use. I think = this >>> is underspecified. >>> You are probably missing some references, examples or both. >>=20 >> =46rom s5.1: >>=20 >> The public key in the certificate is used to validate the signature >> on a JSON Web Token (JWT) [RFC7519] that conforms to the = conventions >> specified in PASSporT [I-D.ietf-stir-passport]. This specification >> supports constraints on the JWT claims, which allows the CA to >> differentiate those enrolled from proof-of-possession versus >> delegation. >>=20 >> the JWT claims for STIR are found in s5 of [I-D.ietf-stir-passport]. = We >> define our own but also use some existing ones so we could add a >> reference as follows to clear this up: >>=20 >> =85, This specification >> supports constraints on the JWT claims [I-D.ietf-stir-passport], >> which allows the CA to differentiate those enrolled from >> proof-of-possession versus delegation. >=20 > Adding this somewhere in section 8 would help. >=20 >> Permitted and excluded are in s8 (they=92re just IA5Strings): >>=20 >> JWTClaimConstraint ::=3D SEQUENCE { >> claim IA5String, >> -> permitted [1] SEQUENCE OF IA5String OPTIONAL, >> -> excluded [2] SEQUENCE OF IA5String OPTIONAL } >> ( WITH COMPONENTS { ..., permitted PRESENT } | >> WITH COMPONENTS { ..., excluded PRESENT } ) >>=20 >> These are analogous to the permitted and excluded name and policy >> constraints in X.509/RFC 5280. >=20 > I am sorry if I am being thick, but I still don't get what is this all > about. Doing a quick scan of RFC 5280 I only found permittedSubtrees. > Can you give me an example or two on how this is going to be used? Alexey: For a named claim, the extension limits the possible values that can = appear. If the permitted SEQUENCE is populated, then the listed claim MUST = contain one of the listed values. If the excluded SEQUENCE is populated, then the listed claim MUST NOT = contain one of the listed values. Russ= From nobody Wed Nov 2 10:26:45 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA2C129446; Wed, 2 Nov 2016 10:26:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147810760400.24029.4754110451794105928.idtracker@ietfa.amsl.com> Date: Wed, 02 Nov 2016 10:26:44 -0700 Archived-At: Cc: stir@ietf.org, draft-ietf-stir-rfc4474bis@ietf.org, stir-chairs@ietf.org, rjsparks@nostrum.com Subject: [stir] Alexey Melnikov's No Objection on draft-ietf-stir-rfc4474bis-15: (with COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 17:26:44 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-stir-rfc4474bis-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is a well written document (despite giving too many deployment choices in some areas). I have a short list of small issues/nits: In Section 4: ABNF for the signed-identity-digest allows empty string? Is this intentional? If not, maybe use "1*" in front? In Section 5.1: are you missing an empty line between the header and the SDP payload? In Section 6.2.2: is it customary in SIP to use the human readable portion of error responses? In Section 7.4: HTTP URIs need a reference. In Section 8.4: URI-ID from RFC 6125 can be used for the subdomain case as well? From nobody Wed Nov 2 11:41:55 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE85A129B34; Wed, 2 Nov 2016 11:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=ECDawxpl; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=NG1+EyNT 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 i0wZygh8rl85; Wed, 2 Nov 2016 11:41:44 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E046B129B2E; Wed, 2 Nov 2016 11:41:43 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4D0A220945; Wed, 2 Nov 2016 14:41:43 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 02 Nov 2016 14:41:43 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=1lAhir2GpOBhZ5N Tuvd+iKIfxMc=; b=ECDawxplOX7BRHDGuDAvlX0RfzS4bAAFN1Th9/B4Dx2T1aV 7w4gT+NvVtU3Ih7Mw/q+9S3G64grXi7eivG3g/Lka+DY2oQX9kUppxiO35c25jd9 mwAOacRZO2rnoxyvIw+n+gFC9Zb5AH8TPkTjvFOVPqnX1okCAAPdb9Ld9Xlc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=1lAhir2GpOBhZ5NTuvd+iKIfxMc=; b=NG1+EyNT1D4kGQjOjTOp PbHzZQdrgMFBP79LbxYTTYbr40uK5dG9sEaZ3b3fbg9x7+syrJARip7Zp3NFtsdq T8HMhlvjjcYc+7wz6sM0dp3WuhIQ1513OlyIoJX8QvPbqInerURhcxFac8zkJcUd s7qFCvLM9btGkLU/9HQM5/s= X-ME-Sender: X-Sasl-enc: 2vr4/izWa/m1AM232dr79+68PtPlqFAMeULcEmm+vLPE 1478112102 Received: from dhcp-10-150-9-163.cisco.com (unknown [173.38.117.66]) by mail.messagingengine.com (Postfix) with ESMTPA id 3FE58CC02A; Wed, 2 Nov 2016 14:41:41 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <58F5F6BD-02E0-4DC9-8A69-D918AB5A4B65@vigilsec.com> Date: Wed, 2 Nov 2016 14:41:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <26856EBB-3272-4D70-A60E-2714E8B1FB15@cooperw.in> References: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> <1478101725.216255.775166569.1BD2E379@webmail.messagingengine.com> <58F5F6BD-02E0-4DC9-8A69-D918AB5A4B65@vigilsec.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Russ Housley , IETF STIR Mail List , IESG , draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, Robert Sparks Subject: Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 18:41:46 -0000 Alexey, My understanding of the JWT Claim Constraints is that a CA can use them = to constrain which claims it expects to receive when asked to validate a = cert. Let=92s imagine a context in which the base set of claims defined = in this spec has been extended to include a =93confidence=94 claim that = allows a carrier to differentiate between cases where a number block is = fully operated by a customer (e.g., Carrier X assigns a block to = Enterprise Y), delegated to a wholesaler, or operating via an SBC. = Imagine that the =93full,=94 =93delegated,=94 and =93sbc=94 claims about = a =93confidence=94 claim have all been specified. The permitted and = excluded constraints could be used to limit claims to one of these = categories, e.g., permitted would be set to =93full=94 for the claim = =93confidence=94 for numbers in the block used by Enterprise Y. The syntax for expressing permitted and excluded is analogous to the = syntax used for name constraints and policy constraints in RFC 5280 = (sections 4.2.1.10 and 4.2.1.11). I realize this is a little hard to grasp because it is defining a = constraint mechanism largely for use cases involving claims that have = yet to be specified. Does it make sense conceptually, though? If so, = hopefully the authors can figure out some text to add that would clarify = it, if necessary. Thanks, Alissa > On Nov 2, 2016, at 11:54 AM, Russ Housley = wrote: >=20 >=20 > On Nov 2, 2016, at 11:48 AM, Alexey Melnikov = wrote: >=20 >> Hi Sean, >>=20 >> On Tue, Nov 1, 2016, at 03:15 PM, Sean Turner wrote: >>>=20 >>>> On Nov 01, 2016, at 09:35, Alexey Melnikov = wrote: >>=20 >> (snip) >>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> I have one small issue that I would like to discuss before = recommending >>>> approval of this document: >>>>=20 >>>> Reading Section 8 I was unable to figure out what are "claim", >>>> "permitted" and "excluded" and what exact syntaxes they use. I = think this >>>> is underspecified. >>>> You are probably missing some references, examples or both. >>>=20 >>> =46rom s5.1: >>>=20 >>> The public key in the certificate is used to validate the signature >>> on a JSON Web Token (JWT) [RFC7519] that conforms to the = conventions >>> specified in PASSporT [I-D.ietf-stir-passport]. This specification >>> supports constraints on the JWT claims, which allows the CA to >>> differentiate those enrolled from proof-of-possession versus >>> delegation. >>>=20 >>> the JWT claims for STIR are found in s5 of [I-D.ietf-stir-passport]. = We >>> define our own but also use some existing ones so we could add a >>> reference as follows to clear this up: >>>=20 >>> =85, This specification >>> supports constraints on the JWT claims [I-D.ietf-stir-passport], >>> which allows the CA to differentiate those enrolled from >>> proof-of-possession versus delegation. >>=20 >> Adding this somewhere in section 8 would help. >>=20 >>> Permitted and excluded are in s8 (they=92re just IA5Strings): >>>=20 >>> JWTClaimConstraint ::=3D SEQUENCE { >>> claim IA5String, >>> -> permitted [1] SEQUENCE OF IA5String OPTIONAL, >>> -> excluded [2] SEQUENCE OF IA5String OPTIONAL } >>> ( WITH COMPONENTS { ..., permitted PRESENT } | >>> WITH COMPONENTS { ..., excluded PRESENT } ) >>>=20 >>> These are analogous to the permitted and excluded name and policy >>> constraints in X.509/RFC 5280. >>=20 >> I am sorry if I am being thick, but I still don't get what is this = all >> about. Doing a quick scan of RFC 5280 I only found permittedSubtrees. >> Can you give me an example or two on how this is going to be used? >=20 > Alexey: >=20 > For a named claim, the extension limits the possible values that can = appear. >=20 > If the permitted SEQUENCE is populated, then the listed claim MUST = contain one of the listed values. >=20 > If the excluded SEQUENCE is populated, then the listed claim MUST NOT = contain one of the listed values. >=20 > Russ > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Nov 2 11:46:39 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CC7129B3C; Wed, 2 Nov 2016 11:46:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147811238449.24049.15096118662101871394.idtracker@ietfa.amsl.com> Date: Wed, 02 Nov 2016 11:46:24 -0700 Archived-At: Cc: draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, stir@ietf.org, rjsparks@nostrum.com Subject: [stir] Kathleen Moriarty's No Objection on draft-ietf-stir-certificates-11: (with COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 18:46:26 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-stir-certificates-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Introduction: nit, Robocallers use impersonation as a means of obscuring identity; while robocallers can, in the ordinary PSTN, block (that is, withhold) their caller identity, callees are less likely to pick up calls from blocked identities, and therefore appearing to calling from some number, any number, is preferable. s/appearing to calling/appearing to call/ Section 10.2.1: I'm wondering why SHA-1 is described as follows instaed of discouraged/not allowed ... o There is no requirement to support SHA-1, RSA with SHA-1, or DSA with SHA-1. I don't see any references to RFCs that update RFC5280, like RFC6818. It would be good to include these when 5280 is used for revocation methods mentioned. 6818 is for CRLs. From nobody Wed Nov 2 11:52:15 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4BA129B4F; Wed, 2 Nov 2016 11:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1y0WB3tG3vv; Wed, 2 Nov 2016 11:52:12 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B0A129B45; Wed, 2 Nov 2016 11:52:12 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id n85so16410778pfi.1; Wed, 02 Nov 2016 11:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:reply-to:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=pYxnXTPvUiHG051BHEZ+pOYMAjpdudQf/974cTUDsJM=; b=tRZcP7AbOYPTP/4TuxE26L1zTiQxk75OXtla1D5bEVRy15yEUJxDDnpWTb4MnQKWKW zEwVa35s7neLK5fbIbMVYlEF7/uxoUNJLtB5NtJSlFL0usCyTcM5eXrP7sEpiqL3w8ji qrcxQINEke6X3eAIqK+8EdCqjcvPLaxmFWWIsIySIDhMQGqBxdyLSUAZ0i1tIaDuM6t6 QhGWMjOi9ikkBNhELSb3Kl/kuUbBIfA9PsRcOSLZiCy0w6rG3jkppca63122qcS8qskf pYIFsf9h5tulALYVQClVASC3g5wPD4SYOTpCksXBuNVGZmczEGw3uFyduk9uzjSnEjrJ DB/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:reply-to :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=pYxnXTPvUiHG051BHEZ+pOYMAjpdudQf/974cTUDsJM=; b=IzY1jk5aTqpz1Gyoa4am7TjDBpH5IxnLbQAFeLrQv/+9D48CoXl04f1HxN94BX3OUh j+/E7xBT0fjg/VFVwwapYECTAd+OKaaydCctupNZ65gn9TcuNDdQnsa8JaPV/QqlHC7V CNGa0tv949gbuZU/ptVhFRzmrOZkr5KrtDJSkhwpB6fKbLdnkHSppx06mgGmpV+mC23f kqGtpVEZ7qjU1hk5L+R3BWivYFRls+Gu6U9bPcZeEeWbxHxN3MAk+leTBGX4XfHnZvxk zk+2nRrjhdRQ+vpZkbAiyp+iYPquPeuEGBbbkcDUtKiLUywRbjdYaq4qbuZvjjVs+y0d qxuw== X-Gm-Message-State: ABUngvcLlEEAgF3WDn/gElJnRWTywfM0WL6RjU29ZAf6FxYkxZ9eYwiczWZJSePAmxQMRg== X-Received: by 10.98.23.88 with SMTP id 85mr9453607pfx.21.1478112731992; Wed, 02 Nov 2016 11:52:11 -0700 (PDT) Received: from [10.71.12.45] ([8.25.222.2]) by smtp.gmail.com with ESMTPSA id l7sm6464415pfk.80.2016.11.02.11.52.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 11:52:11 -0700 (PDT) From: Dave Crocker X-Google-Original-From: Dave Crocker To: Alissa Cooper , Alexey Melnikov References: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> <1478101725.216255.775166569.1BD2E379@webmail.messagingengine.com> <58F5F6BD-02E0-4DC9-8A69-D918AB5A4B65@vigilsec.com> <26856EBB-3272-4D70-A60E-2714E8B1FB15@cooperw.in> Organization: Brandenburg InternetWorking Message-ID: <5bf2eeec-e634-f4f6-2f61-9494dcb20ce0@dcrocker.net> Date: Wed, 2 Nov 2016 11:52:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <26856EBB-3272-4D70-A60E-2714E8B1FB15@cooperw.in> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Russ Housley , IETF STIR Mail List , IESG , draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, Robert Sparks Subject: Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 18:52:13 -0000 On 11/2/2016 11:41 AM, Alissa Cooper wrote: > My understanding of the JWT Claim Constraints is that a CA can use them to constrain which claims it expects to receive when asked to validate a cert. Let’s imagine a context in which the base set of claims defined in this spec has been extended to include a “confidence” claim that allows a carrier to differentiate between cases where a number block is fully operated by a customer (e.g., Carrier X assigns a block to Enterprise Y), delegated to a wholesaler, or operating via an SBC. Imagine that the “full,” “delegated,” and “sbc” claims about a “confidence” claim have all been specified. The permitted and excluded constraints could be used to limit claims to one of these categories, e.g., permitted would be set to “full” for the claim “confidence” for numbers in the block used by Enterprise Y. Alissa, This presumes that claims are to be made about 'interesting' properties and issues, whereas the actual task the work is chartered for is far simpler, namely authentication of a call's identifier. More generally, you have described here a broad model for processing that is to be performed by the receiver, based on these (standardized?) claims by the caller (or, rather, the caller's operator.) Do you have examples of such a distributed, multi-administration policy and decision model being used successfully? What has been defined and what you describe is quite a complex system. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Nov 2 12:17:48 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB01129B51; Wed, 2 Nov 2016 12:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=eS4zZraU; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=IoXnNiWg 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 32SAt2cowrhu; Wed, 2 Nov 2016 12:17:45 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 221B41297CD; Wed, 2 Nov 2016 12:17:45 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8541720775; Wed, 2 Nov 2016 15:17:44 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute1.internal (MEProxy); Wed, 02 Nov 2016 15:17:44 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= x-me-sender:message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:date :references:subject; s=mesmtp; bh=DIhgbWuyxkTrR6S58ZDzu1sCdv8=; b= eS4zZraUMKwICM7DxGr78h7kdvQTPvavQHjPM2t/x4ooHUDlAuYXOmIFuDGG2QyJ gj44Wc2+wcMbXQiOvwcfgHGyRFPxVaMwUg92IKW84f5xeqwG6FuLdM5Ho73H4fUN lmLHBNG/CvXfvhygrP0YJC+eg9lon5u9ow7/Pn3M6j4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-me-sender:message-id:from:to:cc :mime-version:content-transfer-encoding:content-type:in-reply-to :date:references:subject; s=smtpout; bh=DIhgbWuyxkTrR6S58ZDzu1sC dv8=; b=IoXnNiWgzbBkKNEr6ZAciDnqDeWwF0QCnKjEzQ8jdwLpDn4vylTfVCMg BUi5+hEgZtBP/3snYDdGilWjxYUrveyVjOGT7yTAYgWfvQU5OG6ozsihRNw83tXm MGj4NfIIrUJUNH+34LgOcduBoPzxY7P70DfM+HXXnOe+qTCdW7Q= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 5414B5A678; Wed, 2 Nov 2016 15:17:44 -0400 (EDT) Message-Id: <1478114264.260284.775416225.782F8598@webmail.messagingengine.com> From: Alexey Melnikov To: Alissa Cooper MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-037c6db9 In-Reply-To: <26856EBB-3272-4D70-A60E-2714E8B1FB15@cooperw.in> Date: Wed, 02 Nov 2016 19:17:44 +0000 References: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> <1478101725.216255.775166569.1BD2E379@webmail.messagingengine.com> <58F5F6BD-02E0-4DC9-8A69-D918AB5A4B65@vigilsec.com> <26856EBB-3272-4D70-A60E-2714E8B1FB15@cooperw.in> Archived-At: Cc: Russ Housley , IETF STIR Mail List , IESG , draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, Robert Sparks Subject: Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 19:17:47 -0000 Hi Alissa, On Wed, Nov 2, 2016, at 06:41 PM, Alissa Cooper wrote: > Alexey, >=20 > My understanding of the JWT Claim Constraints is that a CA can use them > to constrain which claims it expects to receive when asked to validate a > cert. Let=E2=80=99s imagine a context in which the base set of claims def= ined in > this spec has been extended to include a =E2=80=9Cconfidence=E2=80=9D cla= im that allows a > carrier to differentiate between cases where a number block is fully > operated by a customer (e.g., Carrier X assigns a block to Enterprise Y), > delegated to a wholesaler, or operating via an SBC. Imagine that the > =E2=80=9Cfull,=E2=80=9D =E2=80=9Cdelegated,=E2=80=9D and =E2=80=9Csbc=E2= =80=9D claims about a =E2=80=9Cconfidence=E2=80=9D claim have all > been specified. The permitted and excluded constraints could be used to > limit claims to one of these categories, e.g., permitted would be set to > =E2=80=9Cfull=E2=80=9D for the claim =E2=80=9Cconfidence=E2=80=9D for num= bers in the block used by > Enterprise Y. Ok, this makes some sense. A followup question: what is the syntax of claim name? (I understand that IA5String provides a restriction, but I am wondering if many people outside of Security area actually know what these restrictions are). Are claim tokens likely to be allocated by IANA? > The syntax for expressing permitted and excluded is analogous to the > syntax used for name constraints and policy constraints in RFC 5280 > (sections 4.2.1.10 and 4.2.1.11). >=20 > I realize this is a little hard to grasp because it is defining a > constraint mechanism largely for use cases involving claims that have yet > to be specified. Does it make sense conceptually, though? If so, > hopefully the authors can figure out some text to add that would clarify > it, if necessary. Yes, that is why I've asked about an example. Adding something along the lines of your hypothetical example is fine. > Thanks, > Alissa >=20 > > On Nov 2, 2016, at 11:54 AM, Russ Housley wrote: > >=20 > >=20 > > On Nov 2, 2016, at 11:48 AM, Alexey Melnikov w= rote: > >=20 > >> Hi Sean, > >>=20 > >> On Tue, Nov 1, 2016, at 03:15 PM, Sean Turner wrote: > >>>=20 > >>>> On Nov 01, 2016, at 09:35, Alexey Melnikov = wrote: > >>=20 > >> (snip) > >>=20 > >>>> --------------------------------------------------------------------= -- > >>>> DISCUSS: > >>>> --------------------------------------------------------------------= -- > >>>>=20 > >>>> I have one small issue that I would like to discuss before recommend= ing > >>>> approval of this document: > >>>>=20 > >>>> Reading Section 8 I was unable to figure out what are "claim", > >>>> "permitted" and "excluded" and what exact syntaxes they use. I think= this > >>>> is underspecified. > >>>> You are probably missing some references, examples or both. > >>>=20 > >>> From s5.1: > >>>=20 > >>> The public key in the certificate is used to validate the signature > >>> on a JSON Web Token (JWT) [RFC7519] that conforms to the conventions > >>> specified in PASSporT [I-D.ietf-stir-passport]. This specification > >>> supports constraints on the JWT claims, which allows the CA to > >>> differentiate those enrolled from proof-of-possession versus > >>> delegation. > >>>=20 > >>> the JWT claims for STIR are found in s5 of [I-D.ietf-stir-passport]. = We > >>> define our own but also use some existing ones so we could add a > >>> reference as follows to clear this up: > >>>=20 > >>> =E2=80=A6, This specification > >>> supports constraints on the JWT claims [I-D.ietf-stir-passport], > >>> which allows the CA to differentiate those enrolled from > >>> proof-of-possession versus delegation. > >>=20 > >> Adding this somewhere in section 8 would help. > >>=20 > >>> Permitted and excluded are in s8 (they=E2=80=99re just IA5Strings): > >>>=20 > >>> JWTClaimConstraint ::=3D SEQUENCE { > >>> claim IA5String, > >>> -> permitted [1] SEQUENCE OF IA5String OPTIONAL, > >>> -> excluded [2] SEQUENCE OF IA5String OPTIONAL } > >>> ( WITH COMPONENTS { ..., permitted PRESENT } | > >>> WITH COMPONENTS { ..., excluded PRESENT } ) > >>>=20 > >>> These are analogous to the permitted and excluded name and policy > >>> constraints in X.509/RFC 5280. > >>=20 > >> I am sorry if I am being thick, but I still don't get what is this all > >> about. Doing a quick scan of RFC 5280 I only found permittedSubtrees. > >> Can you give me an example or two on how this is going to be used? > >=20 > > Alexey: > >=20 > > For a named claim, the extension limits the possible values that can ap= pear. > >=20 > > If the permitted SEQUENCE is populated, then the listed claim MUST cont= ain one of the listed values. > >=20 > > If the excluded SEQUENCE is populated, then the listed claim MUST NOT c= ontain one of the listed values. > >=20 > > Russ > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir >=20 From nobody Wed Nov 2 16:38:30 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53201126FDC; Wed, 2 Nov 2016 16:38:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147812990930.24070.2354048411520933419.idtracker@ietfa.amsl.com> Date: Wed, 02 Nov 2016 16:38:29 -0700 Archived-At: Cc: stir@ietf.org, draft-ietf-stir-rfc4474bis@ietf.org, stir-chairs@ietf.org, rjsparks@nostrum.com Subject: [stir] Ben Campbell's Yes on draft-ietf-stir-rfc4474bis-15: (with COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 23:38:29 -0000 Ben Campbell has entered the following ballot position for draft-ietf-stir-rfc4474bis-15: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this work. I'm balloting yes, but have a few minor comments and questions: Substantive: - 6.2, step 4: This says that if the full form of passport is included, and the Date header and iat do not match, use iat if it is fresh. I'm curious why not just use iat in the first place? What should one do if Date is fresh, but iat is not? -6.2.2: This section recommends specific result code reason phrases for a couple of circumstances. I assume the idea is that one should use a "helpful" reason phrase, and these are examples of phrases helpful for the circumstances. But it reads as if you mean to standardize those specific reason phrases. If the intent is really to offer examples, please clarify. I'd hate to see us back in the days of commonly seeing SIP code break due to unexpected reason phrases. - 7.2: The first sentence says verifiers must have a way to acquire and _retain_ certificates. Why must they have a way to retain them? The last paragraph in the section says they might wish to have a way to retain certs, but doesn't seem to require it. -- Is there any concern that the requirement to be able to dereference effectively arbitrary URLs in "info" parameters could become a DOS attack vector? E.g. info parameters that point to HTTP URIs that never respond, respond very slowly, or return huge and/or corrupt certs? -13.1 and 13.2: Is there a reason not to retarget the references in the IANA entries for the Identity header field and for the error codes from 4474 to [RFCThis]? Editorial: - 4.1.1, example: I assume the backslashes indicate line folding for documentation purposes only. It might be worth mentioning that. - 6.1, step 4, last paragraph: Is the reference to section 9 mean that section of _this_ document, or that section of stir-passport? - 7.1, 2nd paragraph: It seems odd to use 2119 MUSTs in examples of policies that authenticator services might have. -8.1, third paragraph: s/exampple/example From nobody Wed Nov 2 18:02:07 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723781297BE for ; Wed, 2 Nov 2016 18:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuw4uOAQCrTJ for ; Wed, 2 Nov 2016 18:02:01 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242F31297FE for ; Wed, 2 Nov 2016 18:01:56 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id t79so70430131wmt.0 for ; Wed, 02 Nov 2016 18:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+aEfiWalQ39k8FNkrx410Gg2il/8u3cK2x7z5JVUoV8=; b=FU7b5LQoEs9zHQeADq5/leuXugUaOO5x+OhqXx2xrvrp/UyXB0UjSoWWk6We9Bmfae 0kgMfz9Q/L7IZmvSfOFiFbR/EHWuMt7l4rtn6XGT94eTROXR0fiBgLmih+/FFN+ekogD /IqmVHCsJFPqb5H+jDpGmoMEWrKBqZW39FzD0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+aEfiWalQ39k8FNkrx410Gg2il/8u3cK2x7z5JVUoV8=; b=CukhMNdVK4Co34AcZUCPGx3oGxJsM9iRYxadJuPg1W7Maic2/rFGHBk9Fk70lLTHbi WlINf5MKYhAiywq28Fg7BH8Or7Df5NxL4NRgbUoAkIr+ndNqKMJUUSleLsLkbpMYG9zv pGKSYuMXtn8VFE+KMRgKmZZNtcf/eqzpzamt7NZzYCMJQYrd4hAxTQqjdagtGRYPHVWw +HsDEuAscTl3uncQ60wIOuwby3jX4wq9q7FXTwWSl5pZLXc/4dGi3JCC9M0IxjkVpoeH cPz8Vl2O5bntfwUYYWCi41zZRODZl4VqQY38QvBowngTHu6NVK3RNoAPei4g+xMOJRdE KpFA== X-Gm-Message-State: ABUngvcUh2MuCZXuJTlejqEaExv9d+L9Lw6aw6ZFlTxSV9F8aH6OS9FPZCagkH8eqeUomQ== X-Received: by 10.28.229.132 with SMTP id c126mr5719661wmh.110.1478134914629; Wed, 02 Nov 2016 18:01:54 -0700 (PDT) Received: from [5.5.33.83] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id xq9sm5597761wjb.35.2016.11.02.18.01.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Nov 2016 18:01:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <147811238449.24049.15096118662101871394.idtracker@ietfa.amsl.com> Date: Wed, 2 Nov 2016 21:01:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3F2372C5-235A-4D49-B232-E60BABC6500E@sn3rd.com> References: <147811238449.24049.15096118662101871394.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, The IESG , stir@ietf.org, Robert Sparks Subject: Re: [stir] Kathleen Moriarty's No Objection on draft-ietf-stir-certificates-11: (with COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 01:02:02 -0000 On Nov 02, 2016, at 14:46, Kathleen Moriarty = wrote: >=20 > Kathleen Moriarty has entered the following ballot position for > draft-ietf-stir-certificates-11: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Introduction: nit, > Robocallers use impersonation as a means > of obscuring identity; while robocallers can, in the ordinary PSTN, > block (that is, withhold) their caller identity, callees are less > likely to pick up calls from blocked identities, and therefore > appearing to calling from some number, any number, is preferable. >=20 > s/appearing to calling/appearing to call/ >=20 > Section 10.2.1: > I'm wondering why SHA-1 is described as follows instaed of > discouraged/not allowed ... > o There is no requirement to support SHA-1, RSA with SHA-1, or DSA > with SHA-1. This is really kind of a heads up/observation for implementers. We = didn=E2=80=99t think it necessary to fight the SHA-1 die-die-die fight = to get this draft published. In other words, this bullet could safely = be dropped if it turns into a thing. > I don't see any references to RFCs that update RFC5280, like RFC6818. = It > would be good to include these when 5280 is used for revocation = methods > mentioned. 6818 is for CRLs. There=E2=80=99s only one RFC that updates 5280 - 6818 ;) I guess this = gets down to your philosophy on the updates header. YMMV, but if an RFC = updates a previous one then referring to the updated RFC really ought to = pull in the all the updates because it=E2=80=99s expected that all = implementations of the original RFC also implemented the updates. = Adding the additional references would be the cautious thing to do but = I=E2=80=99m thinking it shouldn=E2=80=99t be required that we do that. = Also note we 2119-recommend OCSP :) spt= From nobody Wed Nov 2 18:38:54 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8856812943F; Wed, 2 Nov 2016 18:38:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147813712551.24057.7121151522644219549.idtracker@ietfa.amsl.com> Date: Wed, 02 Nov 2016 18:38:45 -0700 Archived-At: Cc: stir@ietf.org, rjsparks@nostrum.com, stir-chairs@ietf.org, draft-ietf-stir-passport@ietf.org Subject: [stir] Kathleen Moriarty's Yes on draft-ietf-stir-passport-10: (with COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 01:38:45 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-stir-passport-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a very well written example of how to use some of the JOSE work. In section 9.1 there's another nit that was not identified (that I can see) by other reviewers. This section demonstrate the deterministic JSON s/demonstrate/demonstrates/ From nobody Wed Nov 2 18:45:22 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACEE129795; Wed, 2 Nov 2016 18:45:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147813752132.24106.5602048445726889072.idtracker@ietfa.amsl.com> Date: Wed, 02 Nov 2016 18:45:21 -0700 Archived-At: Cc: stir@ietf.org, draft-ietf-stir-rfc4474bis@ietf.org, stir-chairs@ietf.org, rjsparks@nostrum.com Subject: [stir] Stephen Farrell's Discuss on draft-ietf-stir-rfc4474bis-15: (with DISCUSS) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 01:45:21 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-stir-rfc4474bis-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This should be an easy one to fix (or else I'm missing stuff, which is quite possible) but if a fix is needed then it'd impact on interop... In 8.3, I think the ABNF conflicts with the E164Number definition in the certs draft which disallows "#" and "*" (if I understand the "FROM" clause in the ASN.1 module correctly). From nobody Wed Nov 2 18:55:04 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BAB1293FB; Wed, 2 Nov 2016 18:55:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147813810124.24082.5202071350275031584.idtracker@ietfa.amsl.com> Date: Wed, 02 Nov 2016 18:55:01 -0700 Archived-At: Cc: draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, stir@ietf.org, rjsparks@nostrum.com Subject: [stir] Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 01:55:01 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-stir-certificates-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Sorry but I have a load of discuss points on this one. I don't think any of 'em are that hard though, except maybe one. (I'll let us all guess which one:-) (1) TN auth list services - IIUC, these are not free today. Is that correct? It's not clear to me that alternatives such as listing all good numbers inside a cert are practical. Did the WG have an explicit consensus that building in a requirement to have verifiers pay to be an effective RP is ok? If so, can you send a pointer to the list archive or minutes where that was agreed. If not, don't the WG need to explicitly ok that? (2) setion 8: you need to say more clearly exactly what the IA5String values in the extension map to in the JWT. I assume it's the field names but you don't say. You need to say if this extension can or needs to be critical. (3) section 9: you need to say whether this extension needs to be or can be critical and where in the cert path it's allowed to be and how to interpret things if >1 cert in the path has this extension (if that's allowed, and if it is, then complexity awaits us;-). (4) section 10: you need to pick one MTI method I think. Why is that wrong? You nearly, but not quite, do. Why not just do it? (5) section 10: don't you need to somehow define "short-lived"? That could be defined as an RP-configurable value, but even if so, I think you need to say that. Even if you do that, I'm not sure that an RP-configured value is right as short-lived certs, vs. not, puts a different burden on the signer and if the signer and RP have different ideas of what short-lived means, then interop failures seem likely. Bottom line for this point: what's a short lived cert? (6) section 10: as with short-lived, don't you need to define HVE? (7) section 10.2.1: Can OCSP be made use HTTPs here? If not, then you have the RP sending out the caller's TN in clear. That seems bad (cf. BCP188). Did the WG consider that? If this spec needs OCSP/HTTPs then I think you need to have a new MUST for that (it's uncommon or maybe never done?) and address the potential bootstrap issues. (But I didn't think those through - did the WG?) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- General - So a passport structure or SIP message can have a URI for the cert. And the cert can have URLs for OCSP and AIA and for a TN download service. That's potentially an awful lot of comms out of the RP to do STIR. Has someone put all that together into a usable assembly? If so, where's that documented? (To be open about it, I was more of a fan of the DKIM starting point for this work, but that's really just opinion, so this is definitely a non-blocking comment. I'd still be intersted in an answer though.) - section 5: "Assignees of E.164 numbering resources participating in this enrollment model should take appropriate steps to establish trust anchors." That's ambiguous. Do you mean they should establish a list of other folk's public keys they trust or that they should generate their key pair and get their public key on other folk's list of trust anchors? - section 7: What's the REQUIRED for EST about? That just seems wrong. - section 10: SCVP? Really? Does anyone do that? I'd say get rid of that text, it'll only cause grief. - section 10: "CRLs are an obviously attractive solution" hmm - s/obviously/initially/ would seem more accurate. - 10.2: last two paras are speculative - do they belong in a spec like this? If so, maybe re-word 'em so that they're not going to confuse an implementer? From nobody Wed Nov 2 19:08:19 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A52161293FB; Wed, 2 Nov 2016 19:08:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147813889365.24118.12619854983152878871.idtracker@ietfa.amsl.com> Date: Wed, 02 Nov 2016 19:08:13 -0700 Archived-At: Cc: stir@ietf.org, rjsparks@nostrum.com, stir-chairs@ietf.org, draft-ietf-stir-passport@ietf.org Subject: [stir] Stephen Farrell's Discuss on draft-ietf-stir-passport-10: (with DISCUSS) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 02:08:13 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-stir-passport-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Deterministic ECDSA (RFC6979) gets rid of a significant weakness with ECDSA. IIRC when JOSE was done there was a feeling that adding a MUST or SHOULD for that was tricky due to lack of support in libraries. When we recently re-checked for COSE, the answer was that today, it's ok to have that as a MUST or SHOULD. (If some kind of FIPS-140 stuff precludes a MUST, then a "SHOULD unless you're sad enough to be stuck having to pay lip lipservice to FIPS-140" clause might be right. So the DISCUSS point here is: given the real-world demonstrated weakness inherent in the need for an RNG in ECDSA why didn't the WG choose to at least RECOMMEND deterministic ECDSA? (Or better, make it a MUST.) If the answer is: "we thought about it [ref] and decided to not require deterministic" then I'll clear. But even if the WG did consider it a couple of years ago, the situation may have changed so a quick re-think might be worthwhile. From nobody Wed Nov 2 19:47:22 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6981296E9; Wed, 2 Nov 2016 19:47:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147814124119.24029.4537545670737647774.idtracker@ietfa.amsl.com> Date: Wed, 02 Nov 2016 19:47:21 -0700 Archived-At: Cc: stir@ietf.org, draft-ietf-stir-rfc4474bis@ietf.org, stir-chairs@ietf.org, rjsparks@nostrum.com Subject: [stir] Kathleen Moriarty's No Objection on draft-ietf-stir-rfc4474bis-15: (with COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 02:47:21 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-stir-rfc4474bis-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a well written document. Just one comment, I would have liked to have seen section 10 much sooner in the document, maybe in the introduction as changes are usually up front. From nobody Thu Nov 3 01:37:32 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEF0129478; Thu, 3 Nov 2016 01:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=qnKOgQZL; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=m30FC6ke 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 h-IS3vaAaVE8; Thu, 3 Nov 2016 01:37:22 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20F01204D9; Thu, 3 Nov 2016 01:37:21 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 605DB20717; Thu, 3 Nov 2016 04:37:21 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 03 Nov 2016 04:37:21 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=UU3XQaTLvMiY1ze a3YKY5ZW5rh4=; b=qnKOgQZLzoRrB/g9RI/vL5I+PLr2PoTkcBf40vHe4qaUcAV 3C0XN/YdRZnN+5axhfzAM3jhQTmJb1i5ZovVi8d8E0c34hS/z3oFZrU5LpNScTr4 TKSzKJ2xNokfdtytytwq8y7XxTGqz+MO3ecejGpfOOoyULpHJyJGrOvTjzZA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=UU3XQaTLvMiY1zea3YKY5ZW5rh4=; b=m30FC6keRx3NUceslT3n GhmSJ9nPWrvn0o74E2po8MC7qAekgALI/XOI87o2vcCAnm98c9996Jnu2NdgoEEj Cjxq3R1UrkRSVvBnXcvEo/6cQC8/1JqEU+zRiHyZCodbxJQxj+1T5KUsyTLXkWO9 slRHV+wnLgycI+XQ2+Ve3aQ= X-ME-Sender: X-Sasl-enc: ZuVYctqYg0+UPyynTSYglEcMZRNiYllaE/lCOw1QhIPQ 1478162240 Received: from [10.236.252.27] (unknown [85.255.235.79]) by mail.messagingengine.com (Postfix) with ESMTPA id EC737F29CC; Thu, 3 Nov 2016 04:37:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: <147812990930.24070.2354048411520933419.idtracker@ietfa.amsl.com> Date: Thu, 3 Nov 2016 08:42:29 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <147812990930.24070.2354048411520933419.idtracker@ietfa.amsl.com> To: Ben Campbell Archived-At: Cc: stir@ietf.org, draft-ietf-stir-rfc4474bis@ietf.org, rjsparks@nostrum.com, The IESG , stir-chairs@ietf.org Subject: Re: [stir] Ben Campbell's Yes on draft-ietf-stir-rfc4474bis-15: (with COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 08:37:24 -0000 Hi Ben, A couple of comments on your comments. > On 2 Nov 2016, at 23:38, Ben Campbell wrote: > > - 6.2, step 4: This says that if the full form of passport is included, > and the Date header and iat do not match, use iat if it is fresh. I'm > curious why not just use iat in the first place? Good point. > What should one do if > Date is fresh, but iat is not? Then it might be a cut & paste attack. > -6.2.2: This section recommends specific result code reason phrases for a > couple of circumstances. I assume the idea is that one should use a > "helpful" reason phrase, and these are examples of phrases helpful for > the circumstances. But it reads as if you mean to standardize those > specific reason phrases. If the intent is really to offer examples, > please clarify. I'd hate to see us back in the days of commonly seeing > SIP code break due to unexpected reason phrases. This essentially a better version of my comment. From nobody Thu Nov 3 02:00:14 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9091012948C; Thu, 3 Nov 2016 02:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=ko2tygoP; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=N0l+fmh/ 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 n4u6I4Sm9jfx; Thu, 3 Nov 2016 02:00:06 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18483129455; Thu, 3 Nov 2016 02:00:06 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 586DF20C07; Thu, 3 Nov 2016 05:00:05 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 03 Nov 2016 05:00:05 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=3MxT5IZ9FaXu841 HKGqoyk7TDP4=; b=ko2tygoPfuwueWEJ0Vd6EyxP01bdst4UIsH+WV4kwKqv5W9 XA/YqJK0W8TGArYLBCviTU85qAWqSZXkvuGpbcDhfJxHHLHG5Mc50NnM6j2sZd+Z T6QGVvhQJ9up4XduRnHWaxoDQpYMmmw2b1ae68lstvpYbYN/ny+2QxTbKBhc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=3MxT5IZ9FaXu841HKGqoyk7TDP4=; b=N0l+fmh/iFSXIrXz6V5r QO/LLk6jmBBRR6ygIGgK8LlaJC66jBbc3rZzmamSRxcYB7k12BgxF1n6Yl56TIHD WyzVf1Q5uMsHVPH4Q7mXokJvhmKfyv9L/SwXlDlkScUufCtoj0BeoUFN7m0Ik2UO TLocUl1y7ByOzrBr/uDgy9w= X-ME-Sender: X-Sasl-enc: az6UvWGjac5zLuwd8ATlC4HYpaacECsbHHAmgICwCO6F 1478163604 Received: from [10.236.252.27] (unknown [85.255.235.79]) by mail.messagingengine.com (Postfix) with ESMTPA id EC990F2D2C; Thu, 3 Nov 2016 05:00:04 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: <147813810124.24082.5202071350275031584.idtracker@ietfa.amsl.com> Date: Thu, 3 Nov 2016 09:05:13 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <40069DDF-0A7E-4008-8C7D-CB64D4F85297@fastmail.fm> References: <147813810124.24082.5202071350275031584.idtracker@ietfa.amsl.com> To: draft-ietf-stir-certificates@ietf.org, Stephen Farrell Archived-At: Cc: stir@ietf.org, rjsparks@nostrum.com, The IESG , stir-chairs@ietf.org Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 09:00:07 -0000 Hi, > On 3 Nov 2016, at 01:55, Stephen Farrell wrote= : >=20 > (2) setion 8: you need to say more clearly exactly what the > IA5String values in the extension map to in the JWT. I assume it's > the field names but you don't say. This is basically covering my main DISCUSS point. I was also wondering if any of these value can possible contain non ASCII Un= icode characters, and if they do, how can they be encoded as IA5String. From nobody Thu Nov 3 05:52:16 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1205129578; Thu, 3 Nov 2016 05:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pa2rP4Sn2mBp; Thu, 3 Nov 2016 05:52:11 -0700 (PDT) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573B712958E; Thu, 3 Nov 2016 05:52:11 -0700 (PDT) Received: by mail-qt0-x244.google.com with SMTP id l20so1670108qta.1; Thu, 03 Nov 2016 05:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=O98k7Gsb6hYukNkOSvfKUlrLXheAnfLQtgcSD/sjZh0=; b=lA4E4mYQtNUGEIYkL+P9sGznViMgmcfhshfoJgSS9jaeaE2tGq4GofziqEEBE47JUR B0MHBb6v3NcO4DN9L840aP2yYBt5+uPEvFd9p/UKZ8yD83n1yFZibUolMawkOGlXQKOm sd3ujl/+ufTfz3zyHgQAK3rDKnhOrEv2S24YK8Zxwr0zqZK+LACDGZzMyZydxe9AsB2m t0O5UfF2zZshfiEJFJP7HhECMFTRW9IBI8T0AolYVzHm00fwA+mZ8YKybaVkcAgA3tFL GecswAsFkxtmFzcz/RRv7ix7SKmbapGS+lW8MQeJVyh0pCj4BTpZDGE4qoU/7PB/3YY5 efPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=O98k7Gsb6hYukNkOSvfKUlrLXheAnfLQtgcSD/sjZh0=; b=NG3N5MZx1dK5X619PUeFoH/trGQU5C/HDr/mRDM17eV8wqK/op8wG0/Gt7HGRpI2ux eUzjIhtx7CJquovD1AD5dp1nisjqAhmW8E1qv2rCCDp2WSg1IPyI0j4C9rBf5I6ecc2a I0bXfuzklgAv+eawvGXPu47D+W4wd9nLtmPS8mCbvVm774/Ut7zE7lFg6sQ9Y5Rn8Nib iKick39bKKZv8y6zPzrMkd37YvFkT11s/aUT3ZxPmhBQ9hae1ElHks2cPkTCnTDFDJ+H PJMF+v+nmEP6XJjpDyuvK6m1aqJ04u+D460iJQMMi22xKiwWwbebZ9HNHf5Twd9UPnu1 5p4w== X-Gm-Message-State: ABUngvdOzIdtJNjAY9UD92kDm7Fu24HyBMO5OvYV0h11fXlZUJOhex3CpmBUrOEnaE0dqg== X-Received: by 10.237.49.4 with SMTP id 4mr7951470qtg.56.1478177530470; Thu, 03 Nov 2016 05:52:10 -0700 (PDT) Received: from [192.168.1.4] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id 8sm4309989qty.2.2016.11.03.05.52.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Nov 2016 05:52:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: kathleen.moriarty.ietf@gmail.com Mime-Version: 1.0 (1.0) Date: Thu, 3 Nov 2016 08:52:06 -0400 Message-Id: References: <147811238449.24049.15096118662101871394.idtracker@ietfa.amsl.com> <3F2372C5-235A-4D49-B232-E60BABC6500E@sn3rd.com> In-Reply-To: <3F2372C5-235A-4D49-B232-E60BABC6500E@sn3rd.com> To: Sean Turner X-Mailer: iPhone Mail (13G36) Archived-At: Cc: draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, The IESG , stir@ietf.org, Robert Sparks Subject: Re: [stir] Kathleen Moriarty's No Objection on draft-ietf-stir-certificates-11: (with COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 12:52:14 -0000 Hi Sean, Please excuse typos, sent from handheld device=20 > On Nov 2, 2016, at 9:01 PM, Sean Turner wrote: >=20 >> On Nov 02, 2016, at 14:46, Kathleen Moriarty wrote: >>=20 >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-stir-certificates-11: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html= >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> Introduction: nit, >> Robocallers use impersonation as a means >> of obscuring identity; while robocallers can, in the ordinary PSTN, >> block (that is, withhold) their caller identity, callees are less >> likely to pick up calls from blocked identities, and therefore >> appearing to calling from some number, any number, is preferable. >>=20 >> s/appearing to calling/appearing to call/ >>=20 >> Section 10.2.1: >> I'm wondering why SHA-1 is described as follows instaed of >> discouraged/not allowed ... >> o There is no requirement to support SHA-1, RSA with SHA-1, or DSA >> with SHA-1. >=20 > This is really kind of a heads up/observation for implementers. We didn=E2= =80=99t think it necessary to fight the SHA-1 die-die-die fight to get this d= raft published. In other words, this bullet could safely be dropped if it t= urns into a thing. No problem, that's why I just had this as a comment. >=20 >> I don't see any references to RFCs that update RFC5280, like RFC6818. It= >> would be good to include these when 5280 is used for revocation methods >> mentioned. 6818 is for CRLs. >=20 > There=E2=80=99s only one RFC that updates 5280 - 6818 ;) I guess this get= s down to your philosophy on the updates header. YMMV, but if an RFC update= s a previous one then referring to the updated RFC really ought to pull in t= he all the updates because it=E2=80=99s expected that all implementations of= the original RFC also implemented the updates. Adding the additional refer= ences would be the cautious thing to do but I=E2=80=99m thinking it shouldn=E2= =80=99t be required that we do that. Also note we 2119-recommend OCSP :) Ok, sounds good. When I look at 5280, I didn't see a forward reference to t= he updates, hence this comment for developers not as familiar with RFCs. It= 's just a comment, so I'm fine either way. Thanks, Kathleen=20 >=20 > spt From nobody Thu Nov 3 06:13:00 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F73B12944D; Thu, 3 Nov 2016 06:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 QWkB73SRW2AV; Thu, 3 Nov 2016 06:12:40 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCAAD129552; Thu, 3 Nov 2016 06:12:40 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uA3D5FK3023725; Thu, 3 Nov 2016 09:12:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=neustar-biz; bh=RuHsWV8LH+y2QTX890dxRhrKKwDIjbdAt9UU4hLpRaQ=; b=dib4oDQrOYgWq4spVz9CrsNVQXo7tN1o0RcQGmVFPGD3ikH+KnG+3E+bx/d6uRVipiyb zkUe6gQI2OJIjmewMxs+K5Sxqd1GVpQKowJYyIm63d/Ua224pjbNnyYwVVi3PtxjJ4vw JNwb8QqJQmDwc0kg35bu1wiIXVEhhUCaVA/4Qejil7GbAZ03ZK77WX1g8xK80xrtoPsJ pJtF1QQ0Y3dZaIVjOEQBRz3VsI163nP4xZ+MFiM96cs6ueMK07VT4AKkbNiD7Q9IhErR yS1ADkpr7qCke+XWWLRigH/9Iq1ogNhZMqaCkStCbUNO2oV93Q6a17rNtZ8oGPe+FJ6l 3g== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 26crse0cgs-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 03 Nov 2016 09:12:38 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 3 Nov 2016 09:12:36 -0400 From: "Peterson, Jon" To: Alexey Melnikov , Alissa Cooper Thread-Topic: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) Thread-Index: AQHSNETBIbFPfH2f1UG8GHOmj7Q5JKDEf/KAgAGbwoCAAAGQgIAALsAAgAAKEwCAAOk/gA== Date: Thu, 3 Nov 2016 13:12:36 +0000 Message-ID: References: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> <1478101725.216255.775166569.1BD2E379@webmail.messagingengine.com> <58F5F6BD-02E0-4DC9-8A69-D918AB5A4B65@vigilsec.com> <26856EBB-3272-4D70-A60E-2714E8B1FB15@cooperw.in> <1478114264.260284.775416225.782F8598@webmail.messagingengine.com> In-Reply-To: <1478114264.260284.775416225.782F8598@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.147] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-03_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611030247 Archived-At: Cc: Russ Housley , IETF STIR Mail List , IESG , "draft-ietf-stir-certificates@ietf.org" , "stir-chairs@ietf.org" , Robert Sparks Subject: Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:12:52 -0000 >A followup question: what is the syntax of claim name? (I understand >that IA5String provides a restriction, but I am wondering if many people >outside of Security area actually know what these restrictions are). PASSporT claim names are simply JWT claim names (per stir-passport Section 5), and... >Are claim tokens likely to be allocated by IANA? ... PASSporT simply reuses the IANA allocation method of JWT, so yes, the claims are allocated by IANA. This is the registry. http://www.iana.org/assignments/jwt/jwt.xhtml To your more recent question, "I was also wondering if any of these value can possible contain non ASCII Unicode characters, and if they do, how can they be encoded as IA5String." If the question is "can possibly" then I'm not sure JWS/JWT specifically bars it (someone likely knows better than me, this may just devolve back to how JSON member strings are defined). However, I don't think any of the existing or planned registered values fall outside of ASCII ranges. I don't think I'd lose much sleep over it, given what the review processes are like and what the likely constraints are CAs would want to apply. Jon Peterson Neustar, Inc. From nobody Thu Nov 3 06:20:12 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F221295C3; Thu, 3 Nov 2016 06:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 8Iag1OrKgNq9; Thu, 3 Nov 2016 06:20:08 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0BC31295B6; Thu, 3 Nov 2016 06:20:08 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.17/8.16.0.17) with SMTP id uA3DFVNn002204; Thu, 3 Nov 2016 09:20:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=neustar-biz; bh=VLWWvn7ZCYLNt91BJIveW5fYDgnxz/yTuddTC5Jr19Y=; b=KWnaPT5ja0MLeOi89vJZ2To6S//EN52SpXDW4HjVARMq7mhvXt3j8fwf73SjrOoM2KAP xiDmxD6nCqwetwPxDnX31Esf6ayzSKDX5QQnO8ExSNoKIqgR2XdABxdJPr0DTg2id5CN aso6OihzvZfpzR1KsrS0Sq7EUJCVIYxuONjtpJGjR0I4LQN1HQxwh8u3aMKXOmoVp5pr zMHlWLG/xmmpvWn0iWhJEXdSNgKZnNdDtInQCEV4+tuV/lFbrO6+jeh9jjKGlYkprtHq BSxSe/Vq61EBGkElgpFgPJIW8Zwj3BOci7mX2vE8tzBFXL7gk1a8wcEwvikHUj58WvSH yw== Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 26crj18pkd-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 03 Nov 2016 09:20:03 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.125]) with mapi id 14.03.0279.002; Thu, 3 Nov 2016 09:20:03 -0400 From: "Peterson, Jon" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-stir-rfc4474bis-15: (with DISCUSS) Thread-Index: AQHSNXPyCK3ORY1edUG/RddTHzG1IKDHPwyA Date: Thu, 3 Nov 2016 13:20:02 +0000 Message-ID: References: <147813752132.24106.5602048445726889072.idtracker@ietfa.amsl.com> In-Reply-To: <147813752132.24106.5602048445726889072.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.147] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-03_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611030249 Archived-At: Cc: "stir@ietf.org" , "draft-ietf-stir-rfc4474bis@ietf.org" , "stir-chairs@ietf.org" , Robert Sparks Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-rfc4474bis-15: (with DISCUSS) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:20:10 -0000 > > > >This should be an easy one to fix (or else I'm missing stuff, >which is quite possible) but if a fix is needed then it'd impact >on interop... > >In 8.3, I think the ABNF conflicts with the E164Number definition >in the certs draft which disallows "#" and "*" (if I understand >the "FROM" clause in the ASN.1 module correctly). The presence of the special keys "#" and "*" in the canonicalizations allowed in rfc4474bis is a consequence of the fact that the canonicalization mechanism needs to work over both the origination and destination numbers. "*" and "#" are used in certain unusual dial strings for the destination number which resist canonicalization mostly because they are nationally-specific. The certs in stir-certificates are there to sign for originating numbers. Hence the usages shouldn't overlap. Now that much said, out of an abundance of caution for future use cases we can't anticipate, we could tweak the cert syntax to permit those characters, but that would end up being a stir-certs fix rather than a rfc4474bis fix. Jon Peterson Neustar, Inc. From nobody Thu Nov 3 06:24:31 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246451295ED; Thu, 3 Nov 2016 06:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 LrUtKNe5oz9A; Thu, 3 Nov 2016 06:24:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2AA61295DB; Thu, 3 Nov 2016 06:24:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5CF7CBE5F; Thu, 3 Nov 2016 13:23:59 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDG5XMiVmC6p; Thu, 3 Nov 2016 13:23:59 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 98F1BBE2E; Thu, 3 Nov 2016 13:23:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1478179439; bh=svSuTVnVJKG9ER9gTCjON7U3C4POIax/uc6gqyjJzmc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=pvel0Tw81/bG/UT8xqyx96ymB6nBYkod0LO5BwtAx0uaTW31yO35FEPG7OMH4tMxa BcWzukHNV8Nju+krs/F2uCspeFFRE4ORAf4RTFmVtQ7pTG5r0OZIbmV0gVGZKecQKu ZI4sSUsPxUZe1vgJAtem/ItVSswbIiSyZeogfkBU= To: "Peterson, Jon" , The IESG References: <147813752132.24106.5602048445726889072.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <158e812d-af49-842e-680d-b6b8cf181be5@cs.tcd.ie> Date: Thu, 3 Nov 2016 13:23:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010302050204040608070103" Archived-At: Cc: "stir@ietf.org" , "draft-ietf-stir-rfc4474bis@ietf.org" , "stir-chairs@ietf.org" , Robert Sparks Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-rfc4474bis-15: (with DISCUSS) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:24:24 -0000 This is a cryptographically signed message in MIME format. --------------ms010302050204040608070103 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/11/16 13:20, Peterson, Jon wrote: > Now that much said, out of an abundance of caution for future use cases= we > can't anticipate, we could tweak the cert syntax to permit those > characters, but that would end up being a stir-certs fix rather than a > rfc4474bis fix. Fair enough, and that'd be fine by me. Or, you could say somewhere that when matching the values one drops the stuff including and after any * or # maybe? S. --------------ms010302050204040608070103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDMx MzIzNThaMC8GCSqGSIb3DQEJBDEiBCCZsthj086Vu4yk2L09bGVzXJISliD8eqgDXDBVmkse djBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQApNOt7+BDWRKjw+H/3K+7/YW0HvMQoV9uwTBi5KjiALUf/+XYZ5qFd PIbVWcmpHT9X1J7tGIZNGB1DCliYaNu3XH0S2z/nbL5ebNBxz9yKB4TyLw9Yy2sOFZzqr1xl wJqj7BTfYzS8xMjzDDQTaZonJZ7jeLSxiGBPLtNddno6TPxbhSoOcaZQAc7DJlaJ4aTpZpk4 3EPFeDU+5nvRTzVuLniE260aCHITWczBE+N+D+0s6XLnk+7+e8ycK9q2CfMTR/MP039/tEII IM4gC+3rIRUHFgPV8ogzC+0fqKjYz03ds5ceekYcpsEIkOtpeq4TLD5ng+lwATpPCQTuUgtd AAAAAAAA --------------ms010302050204040608070103-- From nobody Thu Nov 3 06:33:28 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6141294DC; Thu, 3 Nov 2016 06:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 GDAkuyLdLbOF; Thu, 3 Nov 2016 06:33:26 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9798129471; Thu, 3 Nov 2016 06:33:25 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.17/8.16.0.17) with SMTP id uA3DX74V015558; Thu, 3 Nov 2016 09:33:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=neustar-biz; bh=2+XR/02Q/JVU6iMk8eLZCYzYsQ5gB5DyBocDbbJ17kE=; b=PlvqH+7Ob0GCj91hpMD82FDPMGfgzYdLOABBVV+xp0bdhKwfjoaRIiDUlR5FHGPU878L q9Kj93JhSyNTs4oVsnnNfP31vMjHyEwXu70RptTLq5Oo+ryP/0hHQDEcYW7Y86BMkAvU 0VXUP7zPraYO/XFvl2HPKumgkpKv2LVisdD6wH5riIQQ0AxaSudL6OCV9FgllBbGzGZI dE+FAV9+Qb1Rw+1VuutRKf9YzL8eC7LunPSk+3Fu0o8SWHwyxW067ubzqRQFdmjhW31k 8ujrSts828zX63ZcOmS6ACA7+H3bPsnqscOxx4N0AylGriCZixAntH/F7TdrRfWPuzwv vQ== Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 26crj18snr-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 03 Nov 2016 09:33:22 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 3 Nov 2016 09:33:21 -0400 From: "Peterson, Jon" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-stir-passport-10: (with DISCUSS) Thread-Index: AQHSNXclsTjBgKo0zEKDTbEMnaFzqKDHQr+A Date: Thu, 3 Nov 2016 13:33:21 +0000 Message-ID: References: <147813889365.24118.12619854983152878871.idtracker@ietfa.amsl.com> In-Reply-To: <147813889365.24118.12619854983152878871.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.147] Content-Type: text/plain; charset="us-ascii" Content-ID: <13F5EBC2156D5E429572E6D415CD7FF8@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-03_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611030255 Archived-At: Cc: "stir@ietf.org" , Robert Sparks , "stir-chairs@ietf.org" , "draft-ietf-stir-passport@ietf.org" Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-passport-10: (with DISCUSS) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:33:27 -0000 >Deterministic ECDSA (RFC6979) gets rid of a significant weakness >with ECDSA. IIRC when JOSE was done there was a feeling that adding a >MUST or SHOULD for that was tricky due to lack of support in >libraries. When we recently re-checked for COSE, the answer was >that today, it's ok to have that as a MUST or SHOULD. (If some >kind of FIPS-140 stuff precludes a MUST, then a "SHOULD unless >you're sad enough to be stuck having to pay lip lipservice to >FIPS-140" clause might be right. So the DISCUSS point here is: >given the real-world demonstrated weakness inherent in the need >for an RNG in ECDSA why didn't the WG choose to at least RECOMMEND >deterministic ECDSA? (Or better, make it a MUST.) I don't recall that we gave this any prior consideration. Would be fine with me, but I'll defer to some of our more security-focused folks. Jon Peterson Neustar, Inc. >If the answer is: "we thought about it [ref] and decided to not require >deterministic" then I'll clear. But even if the WG did consider it >a couple of years ago, the situation may have changed so a quick >re-think might be worthwhile. From nobody Thu Nov 3 06:37:38 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AE51299E4; Thu, 3 Nov 2016 06:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=H2YDiWTe; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=ZIMl4nFs 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 PKEcMWvqM5ke; Thu, 3 Nov 2016 06:37:29 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0643129890; Thu, 3 Nov 2016 06:37:15 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9795020860; Thu, 3 Nov 2016 09:37:13 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute1.internal (MEProxy); Thu, 03 Nov 2016 09:37:13 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=6VV8VN2ugYdyLHCiIwwyexg6bu w=; b=H2YDiWTeV/jOQhKW1FRcz3o5jzrgD4+7HLTlEtFGB57wzDICfi5iXntc3G rPmnc1KdvDWnJTvPKs48i7uqUiwZ1pNpOxfj8w8tn+f5U0/JW5N3AK4fMy42f+1G ubuFPqZsSg9sETiXoAHkV8uRf1eh8t/AHaDwwlIxNcWDLCh0c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=6V V8VN2ugYdyLHCiIwwyexg6buw=; b=ZIMl4nFsTroSmHjd8+3sWi/t1nXGZkRENF 9ZgHfuh6j4rPzR6CosPNytjRcVdrX4dc0X4XJjKSXjsnWuPxLh3/pKhPu5x0n53w UGbyE16LXY3x1QqbaOBQ3ce6rs4zg8wWxQojApQHU1xbxC3/EpKdL5LFkRhoKmma nfilq09SU= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 61BA45A678; Thu, 3 Nov 2016 09:37:13 -0400 (EDT) Message-Id: <1478180233.490936.776249657.710E2360@webmail.messagingengine.com> From: Alexey Melnikov To: "Peterson, Jon" , Alissa Cooper MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-8f4ad78c Date: Thu, 03 Nov 2016 13:37:13 +0000 In-Reply-To: References: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> <1478101725.216255.775166569.1BD2E379@webmail.messagingengine.com> <58F5F6BD-02E0-4DC9-8A69-D918AB5A4B65@vigilsec.com> <26856EBB-3272-4D70-A60E-2714E8B1FB15@cooperw.in> <1478114264.260284.775416225.782F8598@webmail.messagingengine.com> Archived-At: Cc: Russ Housley , IETF STIR Mail List , IESG , draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, Robert Sparks Subject: Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:37:31 -0000 On Thu, Nov 3, 2016, at 01:12 PM, Peterson, Jon wrote: > > >A followup question: what is the syntax of claim name? (I understand > >that IA5String provides a restriction, but I am wondering if many people > >outside of Security area actually know what these restrictions are). > > PASSporT claim names are simply JWT claim names (per stir-passport > Section > 5), and... > > >Are claim tokens likely to be allocated by IANA? > > ... PASSporT simply reuses the IANA allocation method of JWT, so yes, the > claims are allocated by IANA. This is the registry. I think this document should say so. > http://www.iana.org/assignments/jwt/jwt.xhtml > > > To your more recent question, "I was also wondering if any of these value > can possible contain non ASCII Unicode characters, and if they do, how > can > they be encoded as IA5String." If the question is "can possibly" then I'm > not sure JWS/JWT specifically bars it (someone likely knows better than > me, this may just devolve back to how JSON member strings are defined). > However, I don't think any of the existing or planned registered values > fall outside of ASCII ranges. I don't think I'd lose much sleep over it, > given what the review processes are like and what the likely constraints > are CAs would want to apply. I would just add a warning about possibility to alert future readers and Expert Reviewers. From nobody Thu Nov 3 06:46:55 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAF2129A0E; Thu, 3 Nov 2016 06:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 E6v7htz4aq5J; Thu, 3 Nov 2016 06:46:52 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7451299FD; Thu, 3 Nov 2016 06:46:40 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.17/8.16.0.17) with SMTP id uA3DgQa6022358; Thu, 3 Nov 2016 09:46:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=neustar-biz; bh=dSh7YQoj53r518RTFSbFZIzEhKQJOhpAVl9YBHZihGw=; b=DkUo/bAvHWfBxUpRS5rz3C6E1tNrHY2nF9vw83qjn6zF/VR5D7d7yaQ5rV21kMuQsQWD 7DNjV7XscoWhdS1TdLJ99SJ4o0QxgJ8qe704Ig6x9ToMyWVOUxMSzPgJqP9uW4lNeAfs 6/Hn5fdjyn0szR0fwVBcsaK4CJDPdvon//GNiFddMxFBoh1XdvVtanZb2xb221cKsefN wvXCKcJS0laahpDppMW0GzjUEiymw46EQYV0PZnQJ9XJxHHktwIXT62BpviQuvhevBb9 y/el95UYA4PeipNiDbzDM/dMM4fu5cqPS2m9hL1md56uNJmjE6+8lltq/0dpG37s9obc 6A== Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 26crj18vx4-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 03 Nov 2016 09:46:37 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 3 Nov 2016 09:46:36 -0400 From: "Peterson, Jon" To: Alexey Melnikov , Alissa Cooper Thread-Topic: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) Thread-Index: AQHSNETBIbFPfH2f1UG8GHOmj7Q5JKDEf/KAgAGbwoCAAAGQgIAALsAAgAAKEwCAAOk/gIAASfOA//+/jYA= Date: Thu, 3 Nov 2016 13:46:36 +0000 Message-ID: References: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> <1478101725.216255.775166569.1BD2E379@webmail.messagingengine.com> <58F5F6BD-02E0-4DC9-8A69-D918AB5A4B65@vigilsec.com> <26856EBB-3272-4D70-A60E-2714E8B1FB15@cooperw.in> <1478114264.260284.775416225.782F8598@webmail.messagingengine.com> <1478180233.490936.776249657.710E2360@webmail.messagingengine.com> In-Reply-To: <1478180233.490936.776249657.710E2360@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.147] Content-Type: text/plain; charset="us-ascii" Content-ID: <3C5FBEB0554C034AA2CDD67E54CC07CD@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-03_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611030258 Archived-At: Cc: Russ Housley , IETF STIR Mail List , IESG , "draft-ietf-stir-certificates@ietf.org" , "stir-chairs@ietf.org" , Robert Sparks Subject: Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:46:54 -0000 >>=20 >> >Are claim tokens likely to be allocated by IANA? >>=20 >> ... PASSporT simply reuses the IANA allocation method of JWT, so yes, >>the >> claims are allocated by IANA. This is the registry. > >I think this document should say so. I mean, the thing in stir-certs is called "JWT Claim Constraints". I think it would be clear that to figure out how you register claims, you look at JWT. The section also refers you to PASSporT, which pretty quickly drops you back to JWT, like stir-passport Section 8.3: "Specifying new claims follows the baseline JWT procedures ([RFC7519] Section 10.1)." Do you just want us to put another copy of that sentence in stir-certs? > >> http://www.iana.org/assignments/jwt/jwt.xhtml >>=20 >>=20 >> To your more recent question, "I was also wondering if any of these >>value >> can possible contain non ASCII Unicode characters, and if they do, how >> can >> they be encoded as IA5String." If the question is "can possibly" then >>I'm >> not sure JWS/JWT specifically bars it (someone likely knows better than >> me, this may just devolve back to how JSON member strings are defined). >> However, I don't think any of the existing or planned registered values >> fall outside of ASCII ranges. I don't think I'd lose much sleep over it, >> given what the review processes are like and what the likely constraints >> are CAs would want to apply. > >I would just add a warning about possibility to alert future readers and >Expert Reviewers. Makes sense, we can do that - though again I might ask the reviewers (Jim Schaad etc) whether their reading of the existing procedures wouldn't make that warning redundant. Jon Peterson Neustar, Inc. From nobody Thu Nov 3 07:00:30 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAAB129A1A; Thu, 3 Nov 2016 07:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 jiCSZsBHFGPG; Thu, 3 Nov 2016 07:00:22 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E27129612; Thu, 3 Nov 2016 07:00:22 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uA3DqduM024423; Thu, 3 Nov 2016 10:00:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=neustar-biz; bh=lMpJ2EVrq8jaFjjwpqAd8n6bRATlCcLcyVQzrBkg5Mk=; b=tgaB6ME0nrKM2tstm9LH2FFDNlfUTNaLTwHtHIG6KteBBsVGu5V3e8jxOXvoIjyKv6NJ dgpjs4Cv+yHLHrCl2N6U/8KulMgXbFXqliyEeeaHG/fgVOp7Hz6KRdtHNfOfDPTWEpbi siMDvbHiwzt9a1ejJcSIs+MUtQ+LGiHc8j/ihZ0lsNh1SJ0TyukzS0Yjpf+CVXb+XcDN 3ldWCm/6hs9IqQmTEb0upuNZebfZ+WIc+uhRzlnq3QKHBnYOscZoYSbOnCHZiJDs2sE8 s4sfjjm/uXmTBFtWRj5+CQuT6yGicdlCgBkFiHVAT1pAKfN5zgXV0bQd6FgQzkpO/YLE pg== Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 26cqs394he-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 03 Nov 2016 10:00:17 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 3 Nov 2016 10:00:17 -0400 From: "Peterson, Jon" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) Thread-Index: AQHSNXVN/COaOKgwAU6LL6dXcoQfqKDHSkgA Date: Thu, 3 Nov 2016 14:00:16 +0000 Message-ID: References: <147813810124.24082.5202071350275031584.idtracker@ietfa.amsl.com> In-Reply-To: <147813810124.24082.5202071350275031584.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.147] Content-Type: text/plain; charset="us-ascii" Content-ID: <327DEE02F89B2C49A12147475EDB0B05@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-03_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611030262 Archived-At: Cc: "draft-ietf-stir-certificates@ietf.org" , "stir-chairs@ietf.org" , "stir@ietf.org" , Robert Sparks Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:00:29 -0000 > >(1) TN auth list services - IIUC, these are not free today. Is >that correct? It's not clear to me that alternatives such as >listing all good numbers inside a cert are practical. Did the WG >have an explicit consensus that building in a requirement to have >verifiers pay to be an effective RP is ok? If so, can you send a >pointer to the list archive or minutes where that was agreed. If >not, don't the WG need to explicitly ok that? Um, I think the most immediate plans for stir-certs deployment include just using SPIDs, in which case the TNs hardly factor into it. Agreed that listing all good numbers inside a cert is likely not practical, except for cases where a cert contains just a single number or a manageable block - and that's probably the second-most-immediate plan for deployment. I don't think there is any real analog to the services required for fancier things here in the marketplace today. This'll be new. If it's done with OCSP, as the draft recommends, it'll cost about as much as OCSP does - which is a cost built into the certs, not a cost to relying parties. So in short, I'm not sure anyone is viewing this as a potential profit center. You'll note that some ACME-related drafts are starting to appear (draft-peterson-acme-telephone, say) which point in the likely direction this is all going. But to be clear, I completely agree that you should not have to pay to be a verifier - I just don't think that's what the mechanism does. >(2) setion 8: you need to say more clearly exactly what the >IA5String values in the extension map to in the JWT. I assume it's >the field names but you don't say. You need to say if this >extension can or needs to be critical. Already talking about this one separately... > >(3) section 9: you need to say whether this extension needs to be >or can be critical and where in the cert path it's allowed to be >and how to interpret things if >1 cert in the path has this >extension (if that's allowed, and if it is, then complexity awaits >us;-). This one I'll defer to Sean. > >(4) section 10: you need to pick one MTI method I think. Why is >that wrong? You nearly, but not quite, do. Why not just do it? We aren't confident enough to do it yet. We want to throw some ideas out there and try them in the marketplace. A lot of people are telling me they like short-lived certs for this; others like OCSP. OCSP will look more attractive if we figure out how to get stapling to work with SIP. I'd say we've got enough here that it's worth a PS and some implementation, but I'm interested to see how it goes. > >(5) section 10: don't you need to somehow define "short-lived"? >That could be defined as an RP-configurable value, but even if so, >I think you need to say that. Even if you do that, I'm not sure >that an RP-configured value is right as short-lived certs, vs. >not, puts a different burden on the signer and if the signer and >RP have different ideas of what short-lived means, then interop >failures seem likely. Bottom line for this point: what's a short >lived cert? Well, in this section a short-lived cert is largely a strawman discussed for rhetorical effect, not a fully-baked proposal. At the end of the section we say that the rest of the doc is going to explore the alternatives. Now again, I do think there are some good ideas about using short-lived certs for STIR, and I wouldn't be surprised if those were documented elsewhere. But for this baseline doc, we wanted to show an approach to doing status information. The jury's still out on which will turn out to be better. > >(6) section 10: as with short-lived, don't you need to define HVE? I would have thought the ref to RFC6960 was sufficient for at least defining it? That much said we're kind of just stealing ideas from HVE to build up our own profile. > >(7) section 10.2.1: Can OCSP be made use HTTPs here? If not, then >you have the RP sending out the caller's TN in clear. That seems >bad (cf. BCP188). Did the WG consider that? If this spec needs >OCSP/HTTPs then I think you need to have a new MUST for that (it's >uncommon or maybe never done?) and address the potential bootstrap >issues. (But I didn't think those through - did the WG?) I don't think we gave confidentiality for OCSP any serious consideration. At the very least that issue should be documented in the draft. If there's a reasonable fix, I'd be happy to use it - if it's breaking new ground, obviously that would take some doing. I'll respond to the comments below separately. Jon Peterson Neustar, Inc. [ (1) was the hard one, right? ] > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > >General - So a passport structure or SIP message can have a URI >for the cert. And the cert can have URLs for OCSP and AIA and for >a TN download service. That's potentially an awful lot of comms >out of the RP to do STIR. Has someone put all that together into a >usable assembly? If so, where's that documented? (To be open about >it, I was more of a fan of the DKIM starting point for this work, >but that's really just opinion, so this is definitely a >non-blocking comment. I'd still be intersted in an answer >though.) > >- section 5: "Assignees of E.164 numbering resources participating >in this enrollment model should take appropriate steps to >establish trust anchors." That's ambiguous. Do you mean they >should establish a list of other folk's public keys they trust or >that they should generate their key pair and get their public key >on other folk's list of trust anchors? > >- section 7: What's the REQUIRED for EST about? That just seems >wrong. > >- section 10: SCVP? Really? Does anyone do that? I'd say get rid >of that text, it'll only cause grief. > >- section 10: "CRLs are an obviously attractive solution" hmm - >s/obviously/initially/ would seem more accurate. > >- 10.2: last two paras are speculative - do they belong in a spec >like this? If so, maybe re-word 'em so that they're not going to >confuse an implementer? > > From nobody Thu Nov 3 07:06:36 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7483129A52; Thu, 3 Nov 2016 07:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=aaq6pahj; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=kZRhwzZY 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 dSzxEV7kkpO2; Thu, 3 Nov 2016 07:06:26 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7D5129A20; Thu, 3 Nov 2016 07:06:17 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0B3D220707; Thu, 3 Nov 2016 10:06:17 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute1.internal (MEProxy); Thu, 03 Nov 2016 10:06:17 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=JeFiO0fz5817jvBJqT3NAQArMV 8=; b=aaq6pahjoRnnu0OS0qBZfk4vrwmP+osDNklpw/KFWyk2q4K4BfJ/pLqG7C J/R08QQZJu/yP+FNkpfZDBlfxjCoCX1wFaUhQD11zgbprd8+/xe40xzghzELTokS BeaEx8DzpyngCgB2UFEirQETOdHNt3jx/WPjl1bXaCb+arFco= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=Je FiO0fz5817jvBJqT3NAQArMV8=; b=kZRhwzZY9M98rBGNzYODmaCgJDC8FELRX9 MyDXQZHb2Nv0h4U0/RvFLmTsNgEIJ+lDKMnRdUEQQC20KKAaewOcHvOxcI5H/dW0 kmyN9jKF9KJg6d60iAdhilipFwL8qGvKGpgWxv0uXil2/nBChZE4Y5uECjFfgnxX CDzNZrlq4= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id CF2835A679; Thu, 3 Nov 2016 10:06:16 -0400 (EDT) Message-Id: <1478181976.498603.776283929.7563270E@webmail.messagingengine.com> From: Alexey Melnikov To: "Peterson, Jon" , Alissa Cooper MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-8f4ad78c In-Reply-To: Date: Thu, 03 Nov 2016 14:06:16 +0000 References: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> <1478101725.216255.775166569.1BD2E379@webmail.messagingengine.com> <58F5F6BD-02E0-4DC9-8A69-D918AB5A4B65@vigilsec.com> <26856EBB-3272-4D70-A60E-2714E8B1FB15@cooperw.in> <1478114264.260284.775416225.782F8598@webmail.messagingengine.com> <1478180233.490936.776249657.710E2360@webmail.messagingengine.com> Archived-At: Cc: Russ Housley , IETF STIR Mail List , IESG , draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, Robert Sparks Subject: Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:06:34 -0000 On Thu, Nov 3, 2016, at 01:46 PM, Peterson, Jon wrote: > > >> > >> >Are claim tokens likely to be allocated by IANA? > >> > >> ... PASSporT simply reuses the IANA allocation method of JWT, so yes, > >>the > >> claims are allocated by IANA. This is the registry. > > > >I think this document should say so. > > I mean, the thing in stir-certs is called "JWT Claim Constraints". I > think > it would be clear that to figure out how you register claims, you look at > JWT. The section also refers you to PASSporT, which pretty quickly drops > you back to JWT, like stir-passport Section 8.3: > > "Specifying new claims follows the baseline JWT procedures ([RFC7519] > Section 10.1)." Please stick the relevant reference in Section 8 of this draft, this was not clear to me, especially as I read this document first. > > Do you just want us to put another copy of that sentence in stir-certs? > > > > >> http://www.iana.org/assignments/jwt/jwt.xhtml > >> > >> > >> To your more recent question, "I was also wondering if any of these > >>value > >> can possible contain non ASCII Unicode characters, and if they do, how > >> can > >> they be encoded as IA5String." If the question is "can possibly" then > >>I'm > >> not sure JWS/JWT specifically bars it (someone likely knows better than > >> me, this may just devolve back to how JSON member strings are defined). > >> However, I don't think any of the existing or planned registered values > >> fall outside of ASCII ranges. I don't think I'd lose much sleep over it, > >> given what the review processes are like and what the likely constraints > >> are CAs would want to apply. > > > >I would just add a warning about possibility to alert future readers and > >Expert Reviewers. > > Makes sense, we can do that - though again I might ask the reviewers (Jim > Schaad etc) whether their reading of the existing procedures wouldn't > make > that warning redundant. > > Jon Peterson > Neustar, Inc. > From nobody Thu Nov 3 07:08:29 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B10C129406; Thu, 3 Nov 2016 07:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 2HHcBK4Ddhdw; Thu, 3 Nov 2016 07:08:26 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCFAD129642; Thu, 3 Nov 2016 07:08:22 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uA3E3m1p029637; Thu, 3 Nov 2016 10:08:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=neustar-biz; bh=Iq9PxKBMn48QWFeXZRPOwat4IyCTbVGiybCfMxhyfJg=; b=b22YpdkIyRWCflnBoy1mPgtBM/Jpaq4xE3iXh8/CGykgZQJmdZFUssBs6G1DRe23Qjm+ 0N6PNma/131Zl3QWGJn4mp1VoWqOR8UMKmVaLGWWcRLbmj30Cn5OUEOVP2lya69wQUaK gpAs9hSjVy+LvIJjr2V5fjS7twvGkcywU5MzY38b52OVOu/WU37xPKGaqxK4cL5RiHn5 Ti5mbIcyPQg93SXusODOifTFxyUsIZ/KNbXrl7iPRDFNGkrS9b8/UV1lWElT8M+Uu3/E fFwzk+/Xb9b6iHcWdfgmy7llTDYTaEX+TOdxR/TSQljFmUs+8saarf5ijP7mTF0Sk6FL 1w== Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 26crse0see-13 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 03 Nov 2016 10:08:20 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.125]) with mapi id 14.03.0279.002; Thu, 3 Nov 2016 10:08:15 -0400 From: "Peterson, Jon" To: Alexey Melnikov , Alissa Cooper Thread-Topic: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) Thread-Index: AQHSNETBIbFPfH2f1UG8GHOmj7Q5JKDEf/KAgAGbwoCAAAGQgIAALsAAgAAKEwCAAOk/gIAASfOA//+/jYCAAEiQAP//vX0A Date: Thu, 3 Nov 2016 14:08:14 +0000 Message-ID: References: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> <1478101725.216255.775166569.1BD2E379@webmail.messagingengine.com> <58F5F6BD-02E0-4DC9-8A69-D918AB5A4B65@vigilsec.com> <26856EBB-3272-4D70-A60E-2714E8B1FB15@cooperw.in> <1478114264.260284.775416225.782F8598@webmail.messagingengine.com> <1478180233.490936.776249657.710E2360@webmail.messagingengine.com> <1478181976.498603.776283929.7563270E@webmail.messagingengine.com> In-Reply-To: <1478181976.498603.776283929.7563270E@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.147] Content-Type: text/plain; charset="us-ascii" Content-ID: <4AF2DEE3DD381643ACE7AF2204C6871A@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-03_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611030265 Archived-At: Cc: Russ Housley , IETF STIR Mail List , IESG , "draft-ietf-stir-certificates@ietf.org" , "stir-chairs@ietf.org" , Robert Sparks Subject: Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:08:27 -0000 Not a problem. Jon Peterson Neustar, Inc. On 11/3/16, 10:06 AM, "Alexey Melnikov" wrote: >On Thu, Nov 3, 2016, at 01:46 PM, Peterson, Jon wrote: >>=20 >> >>=20 >> >> >Are claim tokens likely to be allocated by IANA? >> >>=20 >> >> ... PASSporT simply reuses the IANA allocation method of JWT, so yes, >> >>the >> >> claims are allocated by IANA. This is the registry. >> > >> >I think this document should say so. >>=20 >> I mean, the thing in stir-certs is called "JWT Claim Constraints". I >> think >> it would be clear that to figure out how you register claims, you look >>at >> JWT. The section also refers you to PASSporT, which pretty quickly drops >> you back to JWT, like stir-passport Section 8.3: >>=20 >> "Specifying new claims follows the baseline JWT procedures ([RFC7519] >> Section 10.1)." > >Please stick the relevant reference in Section 8 of this draft, this was >not clear to me, especially as I read this document first. >>=20 >> Do you just want us to put another copy of that sentence in stir-certs? >>=20 >> > >> >> http://www.iana.org/assignments/jwt/jwt.xhtml >> >>=20 >> >>=20 >> >> To your more recent question, "I was also wondering if any of these >> >>value >> >> can possible contain non ASCII Unicode characters, and if they do, >>how >> >> can >> >> they be encoded as IA5String." If the question is "can possibly" then >> >>I'm >> >> not sure JWS/JWT specifically bars it (someone likely knows better >>than >> >> me, this may just devolve back to how JSON member strings are >>defined). >> >> However, I don't think any of the existing or planned registered >>values >> >> fall outside of ASCII ranges. I don't think I'd lose much sleep over >>it, >> >> given what the review processes are like and what the likely >>constraints >> >> are CAs would want to apply. >> > >> >I would just add a warning about possibility to alert future readers >>and >> >Expert Reviewers. >>=20 >> Makes sense, we can do that - though again I might ask the reviewers >>(Jim >> Schaad etc) whether their reading of the existing procedures wouldn't >> make >> that warning redundant. >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 From nobody Thu Nov 3 07:14:58 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B211299E6; Thu, 3 Nov 2016 07:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 DSFmW2XjOdfW; Thu, 3 Nov 2016 07:14:55 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535D31299D1; Thu, 3 Nov 2016 07:14:50 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uA3ED1Dt012814; Thu, 3 Nov 2016 10:14:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=neustar-biz; bh=WMyz5Bq180SB1o0rOyoqlbUyPtf8B2FRRSloTh36hzA=; b=SCuiN9UeSc5hvV7ACUFvP37DIlnT9D6MMhsLlbq4bLSZaxrIijbtwqwJhT8FGm8ige+r 6jGoV0Q9XF3uPT4buBUlZlU7PTRusx3wq1sICM7KkxCxxb9EmhdJZKovCu7fnOn2QNeJ /L9OCya91wa4cqLor+uE97afYz9N+oe0D5kQT6r/F+9VIW+WIAjpRO/JHp3VZcZjgh+/ dPIg2SN+FYrznl4BAFHJ780oObJzWWPhfLvBRiLC76nIZK6vC51ULeh9MST9ukQ5G7v2 17CaPByCqyTsslPJB+AWZVy6Dteo8o3F6BmNfmZ446Q1nRMOWmZs0YsoZq5RDyUHZ/1I oQ== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 26cqvqgsep-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 03 Nov 2016 10:14:47 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 3 Nov 2016 10:14:46 -0400 From: "Peterson, Jon" To: Alexey Melnikov , The IESG Thread-Topic: Alexey Melnikov's No Objection on draft-ietf-stir-rfc4474bis-15: (with COMMENT) Thread-Index: AQHSNS5L/6JWt6VrK0++oUN6lBLBZKDHTuKA Date: Thu, 3 Nov 2016 14:14:45 +0000 Message-ID: References: <147810760400.24029.4754110451794105928.idtracker@ietfa.amsl.com> In-Reply-To: <147810760400.24029.4754110451794105928.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.147] Content-Type: text/plain; charset="us-ascii" Content-ID: <0F42F1C28879184DBD219DCDE9CA8ACA@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-03_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611030267 Archived-At: Cc: "stir@ietf.org" , "draft-ietf-stir-rfc4474bis@ietf.org" , "stir-chairs@ietf.org" , Robert Sparks Subject: Re: [stir] Alexey Melnikov's No Objection on draft-ietf-stir-rfc4474bis-15: (with COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:14:57 -0000 > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >This is a well written document (despite giving too many deployment >choices in some areas). I have a short list of small issues/nits: > >In Section 4: ABNF for the signed-identity-digest allows empty string? Is >this intentional? If not, maybe use "1*" in front? Um, right. Yeah we'll fix that. >In Section 5.1: are you missing an empty line between the header and the >SDP payload? We can insert one. >In Section 6.2.2: is it customary in SIP to use the human readable >portion of error responses? We're discussing that in the Ben thread, but >In Section 7.4: HTTP URIs need a reference. Well... we meant here to use the URLs in RFC2585 (specifically in section 3, the "HTTP Conventions"), that RFC is ref'd at the end of the sentence. Is that adequate? >In Section 8.4: URI-ID from RFC 6125 can be used for the subdomain case >as well? Hadn't considered it. I'm not aware how much uptake that has with SIP services, but we could look into it a bit. Jon Peterson Neustar, Inc. From nobody Thu Nov 3 07:17:01 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7919129A57; Thu, 3 Nov 2016 07:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 b_X6_-Ku37m2; Thu, 3 Nov 2016 07:16:52 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A993D1296D4; Thu, 3 Nov 2016 07:16:42 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uA3ECudG003393; Thu, 3 Nov 2016 10:16:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=neustar-biz; bh=uNnr5x8/P20xIad5wf51lY3FrROcjuA6JwoNoOrb0YY=; b=ZVCdvB46ZNf4YLaQuJ/q663DfH+++ZVDGm7OJwaHmFvPoyePh3IKHy9akFOQroHI+eP+ +pWpGbYbXkl0MmrORnN/v4FGKPNqwA5LYt5tdKzhHn6mfnGeQ68LX3qYCh4KJSOt8S3h sE+MWNnHGyeH6gc+fNK3ZKw9mDoILnS85vxlpKmc4aeXIaPRGGxUlgN5FqeUg4jovlko /r4ipP1lG7a1SSCYjTZ60/SqEezn60lmEl9+1ODVK/NWG/RPsNiLQs5VOeClk8L3ZNDx smWPTP+Darg9KAvPrYt9CTB2oRuepIEd5OTLZyryNnusCUZKPXX1AZC2eWMHjae5nBeM 9A== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 26crse0uk6-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 03 Nov 2016 10:16:40 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 3 Nov 2016 10:16:39 -0400 From: "Peterson, Jon" To: Alexey Melnikov , Ben Campbell Thread-Topic: Ben Campbell's Yes on draft-ietf-stir-rfc4474bis-15: (with COMMENT) Thread-Index: AQHSNWI4YGNf5NNls0S7E8TuEcJTg6DHNLWAgAAaSoA= Date: Thu, 3 Nov 2016 14:16:38 +0000 Message-ID: References: <147812990930.24070.2354048411520933419.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.147] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-03_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611030267 Archived-At: Cc: "stir@ietf.org" , "draft-ietf-stir-rfc4474bis@ietf.org" , "rjsparks@nostrum.com" , The IESG , "stir-chairs@ietf.org" Subject: Re: [stir] Ben Campbell's Yes on draft-ietf-stir-rfc4474bis-15: (with COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:16:54 -0000 > >> On 2 Nov 2016, at 23:38, Ben Campbell wrote: >>=20 >> - 6.2, step 4: This says that if the full form of passport is included, >> and the Date header and iat do not match, use iat if it is fresh. I'm >> curious why not just use iat in the first place? > >Good point. > >> What should one do if >> Date is fresh, but iat is not? > >Then it might be a cut & paste attack. That is the most material threat. But to the question of "why not use what's in the JWT claims in the first place?" this is largely a philosophical question about whether we want to use JWT as a check that the SIP header field values are properly attested, or whether we want to use SIP as a delivery vehicle for JWT and have its values be authoritative instead of SIP's values. I guess I thought about this largely in terms of how I want SIP user agents to behave: like, when it came to the originating identity, did I want the SIP From header field value to kind of cede its place to the value in the "orig" claim of JWT? I guess what I want is for SIP user agents to render to users the value of the From header field, and to use "orig" as a > >> -6.2.2: This section recommends specific result code reason phrases for >>a >> couple of circumstances. I assume the idea is that one should use a >> "helpful" reason phrase, and these are examples of phrases helpful for >> the circumstances. But it reads as if you mean to standardize those >> specific reason phrases. If the intent is really to offer examples, >> please clarify. I'd hate to see us back in the days of commonly seeing >> SIP code break due to unexpected reason phrases. > >This essentially a better version of my comment. Well, agreed on that last point. We can soften the language here. What we wanted to do is to differentiate conditions that are signaled by the same reason code, and to use new reason codes sparingly. The rough guideline I use is that programmatic behavior has to trigger off the codes only, but human behavior can rely on the reason phrases. We're not asking an automaton to react to "Stale Date" or "Use Supported PASSporT Format," say. Jon Peterson Neustar, Inc. From nobody Thu Nov 3 07:30:20 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71A6129A69; Thu, 3 Nov 2016 07:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHVu1csW3aM5; Thu, 3 Nov 2016 07:30:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590FE1299E6; Thu, 3 Nov 2016 07:29:42 -0700 (PDT) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uA3ETcRM031133 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 3 Nov 2016 09:29:38 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Peterson, Jon" Date: Thu, 03 Nov 2016 09:29:37 -0500 Message-ID: <4830C88D-F5C4-4071-B475-E39F531DAB9D@nostrum.com> In-Reply-To: References: <147812990930.24070.2354048411520933419.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: "draft-ietf-stir-rfc4474bis@ietf.org" , Alexey Melnikov , "stir@ietf.org" , The IESG , "stir-chairs@ietf.org" , "rjsparks@nostrum.com" Subject: Re: [stir] Ben Campbell's Yes on draft-ietf-stir-rfc4474bis-15: (with COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:30:19 -0000 On 3 Nov 2016, at 9:16, Peterson, Jon wrote: > >> >>> On 2 Nov 2016, at 23:38, Ben Campbell wrote: >>> >>> - 6.2, step 4: This says that if the full form of passport is >>> included, >>> and the Date header and iat do not match, use iat if it is fresh. >>> I'm >>> curious why not just use iat in the first place? >> >> Good point. >> >>> What should one do if >>> Date is fresh, but iat is not? >> >> Then it might be a cut & paste attack. > > That is the most material threat. > But to the question of "why not use > what's in the JWT claims in the first place?" this is largely a > philosophical question about whether we want to use JWT as a check > that > the SIP header field values are properly attested, or whether we want > to > use SIP as a delivery vehicle for JWT and have its values be > authoritative > instead of SIP's values. I guess I thought about this largely in terms > of > how I want SIP user agents to behave: like, when it came to the > originating identity, did I want the SIP From header field value to > kind > of cede its place to the value in the "orig" claim of JWT? I guess > what I > want is for SIP user agents to render to users the value of the From > header field, and to use "orig" as a I'm okay with a general preference for Date, but does the issue of a stale iat but fresh date change that? > >> >>> -6.2.2: This section recommends specific result code reason phrases >>> for >>> a >>> couple of circumstances. I assume the idea is that one should use a >>> "helpful" reason phrase, and these are examples of phrases helpful >>> for >>> the circumstances. But it reads as if you mean to standardize those >>> specific reason phrases. If the intent is really to offer examples, >>> please clarify. I'd hate to see us back in the days of commonly >>> seeing >>> SIP code break due to unexpected reason phrases. >> >> This essentially a better version of my comment. > > Well, agreed on that last point. We can soften the language here. What > we > wanted to do is to differentiate conditions that are signaled by the > same > reason code, and to use new reason codes sparingly. The rough > guideline I > use is that programmatic behavior has to trigger off the codes only, > but > human behavior can rely on the reason phrases. We're not asking an > automaton to react to "Stale Date" or "Use Supported PASSporT Format," > say. Softening the language would make me happier. I note that elsewhere in this draft (and also in 4474), there are similar statements that use "For example,..." > > Jon Peterson > Neustar, Inc. > From nobody Thu Nov 3 07:33:53 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98AC12966A; Thu, 3 Nov 2016 07:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=QFWebhKs; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=T9dwGidm 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 LxY9Q82gUqht; Thu, 3 Nov 2016 07:33:44 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8C612950B; Thu, 3 Nov 2016 07:33:44 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 47FF620BEF; Thu, 3 Nov 2016 10:33:44 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute1.internal (MEProxy); Thu, 03 Nov 2016 10:33:44 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=iiVYw0YHTdLiSSJDgBDalTbUiv w=; b=QFWebhKsmPPRrI4zmIitelSCV4qGt4z0jqiXokjfidI36XBI32JhtZ2jNW cmL4jdB1y7hyB7qhTdo7wDDtv405zsnTQ31r9iTVuNQiAqs/1pMmRIQzdmw8DZbW GQLFm5NCBD/GKjrM7jroX4FrQs7LRXucAUPq+fRzs0gEUjdFs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=ii VYw0YHTdLiSSJDgBDalTbUivw=; b=T9dwGidmGSlsMwJbEZ9mDbXiupdRvgYa/x /PiVi+iRjfg3GXSLtHNdpfh+5L13voHSuMUyhF2teJ+1Y2DrEVvThwbHhdffLvIW HY+8gC8jfEuY6ILFF3a6/+nlmaCzVq72ee2G83s5XdpFiNI3MxoKc5gasVjZcqjh LWD4Bialo= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1A7A65A679; Thu, 3 Nov 2016 10:33:44 -0400 (EDT) Message-Id: <1478183624.503613.776313985.5112168C@webmail.messagingengine.com> From: Alexey Melnikov To: "Peterson, Jon" , The IESG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-8f4ad78c References: <147810760400.24029.4754110451794105928.idtracker@ietfa.amsl.com> In-Reply-To: Date: Thu, 03 Nov 2016 14:33:44 +0000 Archived-At: Cc: stir@ietf.org, draft-ietf-stir-rfc4474bis@ietf.org, stir-chairs@ietf.org, Robert Sparks Subject: Re: [stir] Alexey Melnikov's No Objection on draft-ietf-stir-rfc4474bis-15: (with COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:33:47 -0000 Hi Jon, On Thu, Nov 3, 2016, at 02:14 PM, Peterson, Jon wrote: > > > > > > > >---------------------------------------------------------------------- > >COMMENT: > >---------------------------------------------------------------------- > > > >This is a well written document (despite giving too many deployment > >choices in some areas). I have a short list of small issues/nits: > > > >In Section 4: ABNF for the signed-identity-digest allows empty string? Is > >this intentional? If not, maybe use "1*" in front? > > Um, right. Yeah we'll fix that. Good. > >In Section 5.1: are you missing an empty line between the header and the > >SDP payload? > > We can insert one. Great, thanks. > >In Section 6.2.2: is it customary in SIP to use the human readable > >portion of error responses? > > We're discussing that in the Ben thread, but You haven't finished the sentence... > >In Section 7.4: HTTP URIs need a reference. > > Well... we meant here to use the URLs in RFC2585 (specifically in section > 3, the "HTTP Conventions"), that RFC is ref'd at the end of the sentence. > Is that adequate? I suggest including both, as RFC 2585 is not even referencing RFC 2616. > >In Section 8.4: URI-ID from RFC 6125 can be used for the subdomain case > >as well? > > > Hadn't considered it. I'm not aware how much uptake that has with SIP > services, but we could look into it a bit. This is similar to adding telephone numbers to certificates: CAs will have to be updated to handle them. But yes, I am not going to push for this to be adopted, even though I personally think it is a good idea. From nobody Thu Nov 3 07:37:33 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0D7129A2B; Thu, 3 Nov 2016 07:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=d7aFGgxG; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=m8ll4PJz 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 lPGLQiMjeiHe; Thu, 3 Nov 2016 07:37:24 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7F4129A56; Thu, 3 Nov 2016 07:37:23 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E056F20925; Thu, 3 Nov 2016 10:37:22 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute1.internal (MEProxy); Thu, 03 Nov 2016 10:37:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=NiLr45i713p32DFi2a6gUoZTTZ 4=; b=d7aFGgxGxvKbNYXXVU7s7x3MF9g1aPqxOqlOTppEa9FMEVu2B5b5YHAvFl Jt86p/2t/rL0Sf6AD5Op1imNWfXPpW1YQItPkGdVvjxmd8LliSyFa49YpBBIJogO /AO7MNCBuzbF/qzjuhnmQ404FO7C3cXUIXn7WuaXDCV3ZdjOQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=Ni Lr45i713p32DFi2a6gUoZTTZ4=; b=m8ll4PJzZsKg8bADT09X/8QzWJ2Z1tl1uy ygIqO4gQ2ae7BKKTCMvmrs40twUd30+sYJNhQe3zOU0Sfq7M3kSCCTg9/N1ZWoYC f+JSOEaGJaWGy5rX4evXdgALyZHhEZOtB6antBdOJqkYkMD2d7dsKldvJcbx7pRg nQk7ay6Pc= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8CB5A5A679; Thu, 3 Nov 2016 10:37:22 -0400 (EDT) Message-Id: <1478183842.504419.776318793.0CCD7752@webmail.messagingengine.com> From: Alexey Melnikov To: Ben Campbell , "Peterson, Jon" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-8f4ad78c In-Reply-To: <4830C88D-F5C4-4071-B475-E39F531DAB9D@nostrum.com> Date: Thu, 03 Nov 2016 14:37:22 +0000 References: <147812990930.24070.2354048411520933419.idtracker@ietfa.amsl.com> <4830C88D-F5C4-4071-B475-E39F531DAB9D@nostrum.com> Archived-At: Cc: stir@ietf.org, stir-chairs@ietf.org, draft-ietf-stir-rfc4474bis@ietf.org, The IESG , rjsparks@nostrum.com Subject: Re: [stir] Ben Campbell's Yes on draft-ietf-stir-rfc4474bis-15: (with COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:37:26 -0000 On Thu, Nov 3, 2016, at 02:29 PM, Ben Campbell wrote: > On 3 Nov 2016, at 9:16, Peterson, Jon wrote: > > > > >> > >>> On 2 Nov 2016, at 23:38, Ben Campbell wrote: > >>> > >>> -6.2.2: This section recommends specific result code reason phrases > >>> for > >>> a > >>> couple of circumstances. I assume the idea is that one should use a > >>> "helpful" reason phrase, and these are examples of phrases helpful > >>> for > >>> the circumstances. But it reads as if you mean to standardize those > >>> specific reason phrases. If the intent is really to offer examples, > >>> please clarify. I'd hate to see us back in the days of commonly > >>> seeing > >>> SIP code break due to unexpected reason phrases. > >> > >> This essentially a better version of my comment. > > > > Well, agreed on that last point. We can soften the language here. What > > we > > wanted to do is to differentiate conditions that are signaled by the > > same > > reason code, and to use new reason codes sparingly. The rough > > guideline I > > use is that programmatic behavior has to trigger off the codes only, > > but > > human behavior can rely on the reason phrases. We're not asking an > > automaton to react to "Stale Date" or "Use Supported PASSporT Format," > > say. > > Softening the language would make me happier. I note that elsewhere in > this draft (and also in 4474), there are similar statements that use > "For example,..." I would like this as well. From nobody Thu Nov 3 07:40:34 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06ED3129A56; Thu, 3 Nov 2016 07:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 P73ZXcf2tGKc; Thu, 3 Nov 2016 07:40:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3675129A85; Thu, 3 Nov 2016 07:40:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E38CDBE5B; Thu, 3 Nov 2016 14:40:20 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2v_IcCie3DE; Thu, 3 Nov 2016 14:40:20 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 38540BE2C; Thu, 3 Nov 2016 14:40:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1478184020; bh=WANyAJcs8JApWdLzlD+y2beduxPvyXiAMDFn1oX/E0I=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=A6PIg6EZQ39riKO7IC7JTWpie9HfKXXuMifHAna56wgyIGn52yqfCjWhtiIvqGU0H 058NGxnWZeAQbekLn9BL49xK9ZdvJepn+11wMGputO/pdLPm4vucf6ZG9Q3EN5ZNhc mhYAROfxYKvpcYPq5NBhL0pO0wX0Z+9QGNuyEIEg= To: "Peterson, Jon" , The IESG References: <147813810124.24082.5202071350275031584.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <3fd07e43-625c-c20a-e526-71ce2583ecf2@cs.tcd.ie> Date: Thu, 3 Nov 2016 14:40:20 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040005070209050205000500" Archived-At: Cc: "draft-ietf-stir-certificates@ietf.org" , Robert Sparks , "stir-chairs@ietf.org" , "stir@ietf.org" Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:40:28 -0000 This is a cryptographically signed message in MIME format. --------------ms040005070209050205000500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 03/11/16 14:00, Peterson, Jon wrote: >=20 >> >> (1) TN auth list services - IIUC, these are not free today. Is >> that correct? It's not clear to me that alternatives such as >> listing all good numbers inside a cert are practical. Did the WG >> have an explicit consensus that building in a requirement to have >> verifiers pay to be an effective RP is ok? If so, can you send a >> pointer to the list archive or minutes where that was agreed. If >> not, don't the WG need to explicitly ok that? >=20 > Um, I think the most immediate plans for stir-certs deployment include > just using SPIDs, in which case the TNs hardly factor into it. Agreed t= hat > listing all good numbers inside a cert is likely not practical, except = for > cases where a cert contains just a single number or a manageable block = - > and that's probably the second-most-immediate plan for deployment. >=20 > I don't think there is any real analog to the services required for > fancier things here in the marketplace today. This'll be new. If it's d= one > with OCSP, as the draft recommends, it'll cost about as much as OCSP do= es > - which is a cost built into the certs, not a cost to relying parties. = So > in short, I'm not sure anyone is viewing this as a potential profit > center. You'll note that some ACME-related drafts are starting to appea= r > (draft-peterson-acme-telephone, say) which point in the likely directio= n > this is all going. >=20 > But to be clear, I completely agree that you should not have to pay to = be > a verifier - I just don't think that's what the mechanism does. Fair enough, probably just me not knowing what folks are planning. Assuming nobody yells, I'll clear this point. >=20 >> (2) setion 8: you need to say more clearly exactly what the >> IA5String values in the extension map to in the JWT. I assume it's >> the field names but you don't say. You need to say if this >> extension can or needs to be critical. >=20 > Already talking about this one separately... >=20 >> >> (3) section 9: you need to say whether this extension needs to be >> or can be critical and where in the cert path it's allowed to be >> and how to interpret things if >1 cert in the path has this >> extension (if that's allowed, and if it is, then complexity awaits >> us;-). >=20 > This one I'll defer to Sean. >=20 >> >> (4) section 10: you need to pick one MTI method I think. Why is >> that wrong? You nearly, but not quite, do. Why not just do it? >=20 > We aren't confident enough to do it yet. We want to throw some ideas ou= t > there and try them in the marketplace. A lot of people are telling me t= hey > like short-lived certs for this; others like OCSP. OCSP will look more > attractive if we figure out how to get stapling to work with SIP. >=20 > I'd say we've got enough here that it's worth a PS and some > implementation, but I'm interested to see how it goes. If how to use short-lived certs and OCSP are sufficiently well-defined (cf. other discuss points) then I think it'd be nearly a no-brainer to say short-lived certs are MTI with OCSP an option, or to just make both MTI. So maybe this point will resolve as we discuss the others. >=20 >> >> (5) section 10: don't you need to somehow define "short-lived"? >> That could be defined as an RP-configurable value, but even if so, >> I think you need to say that. Even if you do that, I'm not sure >> that an RP-configured value is right as short-lived certs, vs. >> not, puts a different burden on the signer and if the signer and >> RP have different ideas of what short-lived means, then interop >> failures seem likely. Bottom line for this point: what's a short >> lived cert? >=20 > Well, in this section a short-lived cert is largely a strawman discusse= d > for rhetorical effect, not a fully-baked proposal. At the end of the > section we say that the rest of the doc is going to explore the > alternatives. Now again, I do think there are some good ideas about usi= ng > short-lived certs for STIR, and I wouldn't be surprised if those were > documented elsewhere. But for this baseline doc, we wanted to show an > approach to doing status information. The jury's still out on which wil= l > turn out to be better. So my concern isn't whether short-lived is good or bad vs. OCSP, but just whether or not the signer and RP having different ideas about what is or is not short-lived can lead to interop problems. E.g. if the signer thinks it's using a short-lived cert but the RP figures that OCSP is needed, then passports will fail to be accepted. Don't we need to avoid that kind of falure? >=20 >> >> (6) section 10: as with short-lived, don't you need to define HVE? >=20 > I would have thought the ref to RFC6960 was sufficient for at least > defining it? That much said we're kind of just stealing ideas from HVE = to > build up our own profile. 6960 is OCSP, so maybe you mean 5019? (Which I'd forgotten:-) To clarify though my concern here is as with the previous one, I just want to check that we don't hit problems if the signer and RP have different ideas about what's a HVE or not. >=20 >> >> (7) section 10.2.1: Can OCSP be made use HTTPs here? If not, then >> you have the RP sending out the caller's TN in clear. That seems >> bad (cf. BCP188). Did the WG consider that? If this spec needs >> OCSP/HTTPs then I think you need to have a new MUST for that (it's >> uncommon or maybe never done?) and address the potential bootstrap >> issues. (But I didn't think those through - did the WG?) >=20 > I don't think we gave confidentiality for OCSP any serious consideratio= n. > At the very least that issue should be documented in the draft. If ther= e's > a reasonable fix, I'd be happy to use it - if it's breaking new ground,= > obviously that would take some doing. AFAIK, this would be breaking new ground yes so probably does need some thought. S. >=20 > I'll respond to the comments below separately. >=20 > Jon Peterson > Neustar, Inc. >=20 >=20 > [ (1) was the hard one, right? ] >=20 >> >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> >> General - So a passport structure or SIP message can have a URI >> for the cert. And the cert can have URLs for OCSP and AIA and for >> a TN download service. That's potentially an awful lot of comms >> out of the RP to do STIR. Has someone put all that together into a >> usable assembly? If so, where's that documented? (To be open about >> it, I was more of a fan of the DKIM starting point for this work, >> but that's really just opinion, so this is definitely a >> non-blocking comment. I'd still be intersted in an answer >> though.) >> >> - section 5: "Assignees of E.164 numbering resources participating >> in this enrollment model should take appropriate steps to >> establish trust anchors." That's ambiguous. Do you mean they >> should establish a list of other folk's public keys they trust or >> that they should generate their key pair and get their public key >> on other folk's list of trust anchors? >> >> - section 7: What's the REQUIRED for EST about? That just seems >> wrong. >> >> - section 10: SCVP? Really? Does anyone do that? I'd say get rid >> of that text, it'll only cause grief. >> >> - section 10: "CRLs are an obviously attractive solution" hmm - >> s/obviously/initially/ would seem more accurate. >> >> - 10.2: last two paras are speculative - do they belong in a spec >> like this? If so, maybe re-word 'em so that they're not going to >> confuse an implementer? >> >> >=20 --------------ms040005070209050205000500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDMx NDQwMjBaMC8GCSqGSIb3DQEJBDEiBCClJKU01t6NAVhM4cibnPch24FKxJ9AuHQJkkeA0VJ/ /zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAlMay+ic3QBOBVAKIPdsmZ7Ghd2y8K23v7mknqSj30AUKGRSUsSUmc QIi9YvIwIGaOmTG2ie9NBgrqv0OpBdO9I3vDvxa3JPxL+VrAbVNf7ErlaU+Afw6nKCz38iLZ D7jbYyuWAXcy95mhzkJLI0+oTIkU66XqxKTtkMilVQaKBZwbXol240Rer2QMF5+1V7uFM+TJ yP9WY6ZXoRtbPb0P6Sxbk+RiMPbxZOetXTJp7PBy6wEJRyX7OHOU9m6HFoMG2P8MIlUIG711 +k3FiSo4+d8yTDcluGM1J7Se1VDwGIu2J3vPqL6AbcKl2MsqV8qqW7b3mEGGjdVAqY7QOIpn AAAAAAAA --------------ms040005070209050205000500-- From nobody Thu Nov 3 07:48:11 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0BC12963F; Thu, 3 Nov 2016 07:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 Q2DJ2olfNt-M; Thu, 3 Nov 2016 07:48:07 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1F312966A; Thu, 3 Nov 2016 07:48:07 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uA3EjhF9032533; Thu, 3 Nov 2016 10:48:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=neustar-biz; bh=pe1uV2F7N9DzyOxFTTPsOM/9zVkf45P2hy8ecjF43GE=; b=QSHmt1QKdhiE13Ok0O1udhGrSuVb62CibsDrILIgEZ2Pe3x2oogP3JTVh+nVeaXiP9zH CN8sLo084kgHFzeWkmO6+N580NzK+l8cenrPJV/OtsSimmU7wJKlUMLd8EMDAE3vnZIY 7UWajDmEguFlCWkEqQV3wlJgnlnvQCzuKYR4BnsHIwGvWx4sCkLsPQBde0wYFAL4fiGB aRVQy35+DdR8Sp5bNoZl9uxjlYbwb/f6nl8JwVkrRDCKvIWdcg1ucAchNJBO0RcElQ4h 3Hke/aP8X4/WTt6Z5ZJu+eU+2ZfBoxtYaD747c7MOYXPsZbTdZjYbzB06acCZ1Kzo48M Hw== Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 26cqs39fhn-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 03 Nov 2016 10:48:04 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 3 Nov 2016 10:48:04 -0400 From: "Peterson, Jon" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) Thread-Index: AQHSNXVN/COaOKgwAU6LL6dXcoQfqKDHV6AA Date: Thu, 3 Nov 2016 14:48:03 +0000 Message-ID: References: <147813810124.24082.5202071350275031584.idtracker@ietfa.amsl.com> In-Reply-To: <147813810124.24082.5202071350275031584.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.147] Content-Type: text/plain; charset="us-ascii" Content-ID: <88FF09EF36FC614B807DE45B0C93CAC6@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-03_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611030274 Archived-At: Cc: "draft-ietf-stir-certificates@ietf.org" , "stir-chairs@ietf.org" , "stir@ietf.org" , Robert Sparks Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 14:48:09 -0000 Just the comments here: >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > >General - So a passport structure or SIP message can have a URI >for the cert. And the cert can have URLs for OCSP and AIA and for >a TN download service. That's potentially an awful lot of comms >out of the RP to do STIR. Has someone put all that together into a >usable assembly? If so, where's that documented? (To be open about >it, I was more of a fan of the DKIM starting point for this work, >but that's really just opinion, so this is definitely a >non-blocking comment. I'd still be intersted in an answer >though.) We're looking at OCSP staples, we're looking at a variety of optimizations going forward. As I suggested in my other mail, this is a situation where I think we have enough agreement on a direction to publish but we still need some deployment experience. And incidentally, we haven't entirely closed the door on acquiring credentials with the DNS either - we left that as a point of architectural modularity in the design of rfc4474bis. It just wasn't a direction we happened to have enough energy to pursue. >- section 5: "Assignees of E.164 numbering resources participating >in this enrollment model should take appropriate steps to >establish trust anchors." That's ambiguous. Do you mean they >should establish a list of other folk's public keys they trust or >that they should generate their key pair and get their public key >on other folk's list of trust anchors? More the latter, but we're intentionally not being prescriptive here - national regulators and so forth will do as they see fit, we're just suggesting they take whatever they might think would be appropriate steps. >- section 7: What's the REQUIRED for EST about? That just seems >wrong. I'll defer this to Sean. > >- section 10: SCVP? Really? Does anyone do that? I'd say get rid >of that text, it'll only cause grief. Again, this section is just trying to enumerate the options and explain why we're exploring the paths we're exploring. We're not suggesting anyone do SCVP. But since like I said we're still in a situation of some uncertainty, it seemed valuable to document our thinking. >- section 10: "CRLs are an obviously attractive solution" hmm - >s/obviously/initially/ would seem more accurate. OK. >- 10.2: last two paras are speculative - do they belong in a spec >like this? If so, maybe re-word 'em so that they're not going to >confuse an implementer? They are indeed speculative. Perhaps we could cordon these off in their subsection labeled "future directions" or something to avoid implementer shock. Jon Peterson Neustar, Inc. From nobody Thu Nov 3 09:23:21 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF7D12949B for ; Thu, 3 Nov 2016 09:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyZiunPbzPvl for ; Thu, 3 Nov 2016 09:23:18 -0700 (PDT) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id 73928129505 for ; Thu, 3 Nov 2016 09:23:18 -0700 (PDT) X-AuditID: 1207440e-c7bff70000000b1c-2f-581b6475a540 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 4F.C4.02844.5746B185; Thu, 3 Nov 2016 12:23:17 -0400 (EDT) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id uA3GNGcG000766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 3 Nov 2016 12:23:17 -0400 To: stir@ietf.org References: <147811238449.24049.15096118662101871394.idtracker@ietfa.amsl.com> <3F2372C5-235A-4D49-B232-E60BABC6500E@sn3rd.com> From: Paul Kyzivat Message-ID: Date: Thu, 3 Nov 2016 12:23:16 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <3F2372C5-235A-4D49-B232-E60BABC6500E@sn3rd.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixO6iqFuaIh1hMPWYicXytduYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0fXiImtBJ1dF22WZBsYWji5GTg4JAROJk6fvMncxcnEICVxm lHje9I0VJCEk8IpJovexMYgtLJApcfvZfTYQW0RAUOLejNNMEDWNjBIrLlqA2GwCWhJzDv1n AbF5BewlLk1fzQhiswioSPQ2PAGLiwqkSWxft5sZokZQ4uRMiDingK3El7X3wPYyC5hJzNv8 kBnClpdo3jqbeQIj3ywkLbOQlM1CUraAkXkVo1xiTmmubm5iZk5xarJucXJiXl5qka6xXm5m iV5qSukmRkiI8e1gbF8vc4hRgINRiYd3hp90hBBrYllxZe4hRkkOJiVR3sUxQCG+pPyUyozE 4oz4otKc1OJDjBIczEoivJsSgXK8KYmVValF+TApaQ4WJXFetSXqfkIC6YklqdmpqQWpRTBZ GQ4OJQne1GSgRsGi1PTUirTMnBKENBMHJ8hwHqDhOiA1vMUFibnFmekQ+VOMilLivM+SgBIC IImM0jy4XlgKeMUoDvSKMK8NSDsPMH3Adb8CGswENNg8SQJkcEkiQkqqgZG5ZvkkR0Nv4Qv2 6f/fX/tlKs4XN7tuF7dqpGxqRfITv5hzXxfN2OrN2agXHci2Ucrh3aF1Cq6LO/eevbrBpd7x 5JLra1aWHrq3LErD7t+n8B/lsz8p/Dy7aXLR2Ysq4l42n14r63mxHdeNT7nx8fWej87nTE0D jj85FT3j90ebUIY3+Q7fT19WYinOSDTUYi4qTgQA6tgG4twCAAA= Archived-At: Subject: Re: [stir] Kathleen Moriarty's No Objection on draft-ietf-stir-certificates-11: (with COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 16:23:20 -0000 Sean, On 11/2/16 9:01 PM, Sean Turner wrote: >> I don't see any references to RFCs that update RFC5280, like RFC6818. It >> would be good to include these when 5280 is used for revocation methods >> mentioned. 6818 is for CRLs. > > There’s only one RFC that updates 5280 - 6818 ;) I guess this gets down to your philosophy on the updates header. YMMV, but if an RFC updates a previous one then referring to the updated RFC really ought to pull in the all the updates because it’s expected that all implementations of the original RFC also implemented the updates. Adding the additional references would be the cautious thing to do but I’m thinking it shouldn’t be required that we do that. Also note we 2119-recommend OCSP :) This *really* further opens up that can of worms! IIUC you are taking the position that once an update to RFCnnnn is published then *every* implementation of RFCnnnn must/will immediately implement and deploy the update. That seems unrealistic. The situation is slightly different when we are talking about a reference in a new document that will of necessity get a new implementation. Even so, it seems unwise to make such an assumption. It is cheap to add the reference to the updating document. Thanks, Paul From nobody Thu Nov 3 12:22:32 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F983128B44; Thu, 3 Nov 2016 12:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=3e917kSe; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=juNnEzGx 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 OiJ1djQpPQaV; Thu, 3 Nov 2016 12:22:30 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B84112965B; Thu, 3 Nov 2016 12:22:30 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 84E19207F0; Thu, 3 Nov 2016 15:22:29 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 03 Nov 2016 15:22:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=yEL8tWZDMae8OKG v/ZlM/M12K0M=; b=3e917kSesQgGoHywdu7LDZtwdzJ0RP2/m6cE+PRHOzfWymJ 8HoHY2rVI5cHHXig4k6jLErrKTw9sRV8V56yUlzcqVFeAKpN86bm94P5Q5WpKCH1 RDD7OpPIdKZMrYtBwDbRFvZzpvzFG5RUJBYrob768MhcxN3tTxCjQP7HGAik= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=yEL8tWZDMae8OKGv/ZlM/M12K0M=; b=juNnEzGx+9dpq8JJp+Qf Og73fAKo8gm6Lppvr0x1vq2n7Dxjo2q/YX7QIIDTGgLmgzzEhJgrj+nRuQ3aS9o+ 8WKvsyHsCueFa5AIVvo+I1Br7WhDmC4FbXi0NUBnYyrecuwrdtZkLTf3N4k7EKHj OCIaGsgxIksJYulV2LsDj6I= X-ME-Sender: X-Sasl-enc: ox7ju6D/Ed2QS9zGH4KvSgiPMbOxraN29tzUSf/AgeUI 1478200949 Received: from dhcp-10-150-9-153.cisco.com (unknown [173.38.117.89]) by mail.messagingengine.com (Postfix) with ESMTPA id 0428EF29CD; Thu, 3 Nov 2016 15:22:28 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <5bf2eeec-e634-f4f6-2f61-9494dcb20ce0@dcrocker.net> Date: Thu, 3 Nov 2016 15:22:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> <1478101725.216255.775166569.1BD2E379@webmail.messagingengine.com> <58F5F6BD-02E0-4DC9-8A69-D918AB5A4B65@vigilsec.com> <26856EBB-3272-4D70-A60E-2714E8B1FB15@cooperw.in> <5bf2eeec-e634-f4f6-2f61-9494dcb20ce0@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Alexey Melnikov , Russ Housley , IETF STIR Mail List , IESG , draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, Robert Sparks Subject: Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 19:22:31 -0000 Hi Dave, > On Nov 2, 2016, at 2:52 PM, Dave Crocker wrote: >=20 > On 11/2/2016 11:41 AM, Alissa Cooper wrote: >> My understanding of the JWT Claim Constraints is that a CA can use = them to constrain which claims it expects to receive when asked to = validate a cert. Let=92s imagine a context in which the base set of = claims defined in this spec has been extended to include a =93confidence=94= claim that allows a carrier to differentiate between cases where a = number block is fully operated by a customer (e.g., Carrier X assigns a = block to Enterprise Y), delegated to a wholesaler, or operating via an = SBC. Imagine that the =93full,=94 =93delegated,=94 and =93sbc=94 claims = about a =93confidence=94 claim have all been specified. The permitted = and excluded constraints could be used to limit claims to one of these = categories, e.g., permitted would be set to =93full=94 for the claim = =93confidence=94 for numbers in the block used by Enterprise Y. >=20 >=20 > Alissa, >=20 > This presumes that claims are to be made about 'interesting' = properties and issues, whereas the actual task the work is chartered for = is far simpler, namely authentication of a call's identifier. The above was a hypothetical example provided to help Alexey understand = how the JWT Claim Constraints may be used. Section 8.1 of = draft-ietf-stir-passport specifies the requirements for additional = claims, which need to relate to the required claims and behaviors. What = is presently documented is simply the extension point, not any = particular extensions. >=20 > More generally, you have described here a broad model for processing = that is to be performed by the receiver, based on these (standardized?) = claims by the caller (or, rather, the caller's operator.) >=20 > Do you have examples of such a distributed, multi-administration = policy and decision model being used successfully? >=20 > What has been defined and what you describe is quite a complex system. I think the existing system of relationships and network paths that = comprise the phone system is the root of the complexity here; the = challenge for STIR has been to provide building blocks with enough = flexibility to help address the requirements in RFC 7340 across a = variety of different deployment scenarios and use cases. Alissa >=20 > d/ > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From nobody Thu Nov 3 13:15:23 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFB61200DF for ; Thu, 3 Nov 2016 13:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMGHwgfjo2hH for ; Thu, 3 Nov 2016 13:15:14 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 9A60112973D for ; Thu, 3 Nov 2016 13:15:13 -0700 (PDT) Received: (qmail 16960 invoked by uid 0); 3 Nov 2016 20:15:08 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy4.mail.unifiedlayer.com with SMTP; 3 Nov 2016 20:15:08 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id 3Y8Z1u00K1MNPNq01Y8cBw; Thu, 03 Nov 2016 14:08:36 -0600 X-Authority-Analysis: v=2.1 cv=fZg+lSgF c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=1oJP67jkp3AA:10 a=L24OOQBejmoA:10 a=ZZnuYtJkoWoA:10 a=48vgC7mUAAAA:8 a=hGBaWAWWAAAA:8 a=doUQZJtgAAAA:8 a=NwrGN2YM4aAADE8-eYsA:9 a=9Mz32QgxqChfrjMJ:21 a=8DQOrFDq-nKm14Er:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Q-ofuW86YyylptHqTH-7:22 a=d0-0EwFVFT64L02gzcZV:22 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: CC:To:From:Subject:Date; bh=7CJBZaxNHtqQ99Ucm6dc2Z64AgRtZMqItCMW7bA0qQQ=; b=O IdY38lFjRfWt5R08mRl75lfb5nMvKTLdruN4Twu7G9y4PUP0XYpDULl+AOGKNPm+A7vJ1zLCRTfz3 uBwnSKlXKq4+utgANV9kmF688bqUDC6hjjdkoYmTXGjS4ywQ1/; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:52645 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1c2OJM-0007ef-ST; Thu, 03 Nov 2016 14:08:33 -0600 User-Agent: Microsoft-MacOutlook/f.1b.0.161010 Date: Thu, 03 Nov 2016 16:08:30 -0400 From: Richard Shockey To: "Peterson, Jon" , Stephen Farrell , The IESG Message-ID: <72140957-AF17-4E35-85E1-2617630F2109@shockey.us> Thread-Topic: [stir] Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1c2OJM-0007ef-ST X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:52645 X-Source-Auth: richard+shockey.us X-Email-Count: 2 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Cc: "draft-ietf-stir-certificates@ietf.org" , Robert Sparks , "stir-chairs@ietf.org" , "stir@ietf.org" Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 20:15:18 -0000 On 11/3/16, 10:00 AM, "stir on behalf of Peterson, Jon" wrote: =20 > >(1) TN auth list services - IIUC, these are not free today. Is >that correct? It's not clear to me that alternatives such as >listing all good numbers inside a cert are practical. Did the WG >have an explicit consensus that building in a requirement to have >verifiers pay to be an effective RP is ok? If so, can you send a >pointer to the list archive or minutes where that was agreed. If >not, don't the WG need to explicitly ok that? =20 Um, I think the most immediate plans for stir-certs deployment include just using SPIDs, in which case the TNs hardly factor into it. Agreed t= hat listing all good numbers inside a cert is likely not practical, except = for cases where a cert contains just a single number or a manageable block = - and that's probably the second-most-immediate plan for deployment. RS> Just to concur with Jon here the preliminary US Profile of STIR, which = is called SHAKEN developed out of ATIS and the SIP Forum NNI Task Force, the= claims are made by licensed service providers that have a NECA Operating Ca= rrier Number (OCN) which is sort of a SPID.=20 The basics of SHAKEN was reported to the FCC by the Industry robocall strik= eforce.=20 https://www.fcc.gov/news-events/events/2016/10/second-meeting-industry-led-= robocall-strike-force There are provisions in our profile for per TN assertions but at this preli= minary point, it is only for highly specific applications. Jon is correct t= hat it is way way too soon to speculate further until there are some prelimi= nary deployments. The good news this it will deploy though there may be nati= onal specific differences. =20 =20 I don't think there is any real analog to the services required for fancier things here in the marketplace today. This'll be new. If it's d= one with OCSP, as the draft recommends, it'll cost about as much as OCSP do= es - which is a cost built into the certs, not a cost to relying parties. = So in short, I'm not sure anyone is viewing this as a potential profit center. You'll note that some ACME-related drafts are starting to appea= r (draft-peterson-acme-telephone, say) which point in the likely directio= n this is all going. RS> Well we=E2=80=99ll see about that. =20 =20 But to be clear, I completely agree that you should not have to pay to = be a verifier - I just don't think that's what the mechanism does. RS> This is dependent on the particular national profile of how the standar= ds deploy. This is NOT IMHO a one size fits all.=20 =20 >(2) setion 8: you need to say more clearly exactly what the >IA5String values in the extension map to in the JWT. I assume it's >the field names but you don't say. You need to say if this >extension can or needs to be critical. =20 Already talking about this one separately... =20 > >(3) section 9: you need to say whether this extension needs to be >or can be critical and where in the cert path it's allowed to be >and how to interpret things if >1 cert in the path has this >extension (if that's allowed, and if it is, then complexity awaits >us;-). =20 This one I'll defer to Sean. =20 > >(4) section 10: you need to pick one MTI method I think. Why is >that wrong? You nearly, but not quite, do. Why not just do it? =20 We aren't confident enough to do it yet. We want to throw some ideas ou= t there and try them in the marketplace. A lot of people are telling me t= hey like short-lived certs for this; others like OCSP. OCSP will look more attractive if we figure out how to get stapling to work with SIP. =20 I'd say we've got enough here that it's worth a PS and some implementation, but I'm interested to see how it goes. =20 > >(5) section 10: don't you need to somehow define "short-lived"? >That could be defined as an RP-configurable value, but even if so, >I think you need to say that. Even if you do that, I'm not sure >that an RP-configured value is right as short-lived certs, vs. >not, puts a different burden on the signer and if the signer and >RP have different ideas of what short-lived means, then interop >failures seem likely. Bottom line for this point: what's a short >lived cert? =20 Well, in this section a short-lived cert is largely a strawman discusse= d for rhetorical effect, not a fully-baked proposal. At the end of the section we say that the rest of the doc is going to explore the alternatives. Now again, I do think there are some good ideas about usi= ng short-lived certs for STIR, and I wouldn't be surprised if those were documented elsewhere. But for this baseline doc, we wanted to show an approach to doing status information. The jury's still out on which wil= l turn out to be better. =20 > >(6) section 10: as with short-lived, don't you need to define HVE? =20 I would have thought the ref to RFC6960 was sufficient for at least defining it? That much said we're kind of just stealing ideas from HVE = to build up our own profile. =20 > >(7) section 10.2.1: Can OCSP be made use HTTPs here? If not, then >you have the RP sending out the caller's TN in clear. That seems >bad (cf. BCP188). Did the WG consider that? If this spec needs >OCSP/HTTPs then I think you need to have a new MUST for that (it's >uncommon or maybe never done?) and address the potential bootstrap >issues. (But I didn't think those through - did the WG?) =20 I don't think we gave confidentiality for OCSP any serious consideratio= n. At the very least that issue should be documented in the draft. If ther= e's a reasonable fix, I'd be happy to use it - if it's breaking new ground, obviously that would take some doing. =20 I'll respond to the comments below separately. =20 Jon Peterson Neustar, Inc. =20 =20 [ (1) was the hard one, right? ] =20 > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > >General - So a passport structure or SIP message can have a URI >for the cert. And the cert can have URLs for OCSP and AIA and for >a TN download service. That's potentially an awful lot of comms >out of the RP to do STIR. Has someone put all that together into a >usable assembly? If so, where's that documented? (To be open about >it, I was more of a fan of the DKIM starting point for this work, >but that's really just opinion, so this is definitely a >non-blocking comment. I'd still be intersted in an answer >though.) > >- section 5: "Assignees of E.164 numbering resources participating >in this enrollment model should take appropriate steps to >establish trust anchors." That's ambiguous. Do you mean they >should establish a list of other folk's public keys they trust or >that they should generate their key pair and get their public key >on other folk's list of trust anchors? > >- section 7: What's the REQUIRED for EST about? That just seems >wrong. > >- section 10: SCVP? Really? Does anyone do that? I'd say get rid >of that text, it'll only cause grief. > >- section 10: "CRLs are an obviously attractive solution" hmm - >s/obviously/initially/ would seem more accurate. > >- 10.2: last two paras are speculative - do they belong in a spec >like this? If so, maybe re-word 'em so that they're not going to >confuse an implementer? > > =20 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir =20 From nobody Thu Nov 3 13:34:55 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4BB1297D6; Thu, 3 Nov 2016 13:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j2GGTzeUtkS; Thu, 3 Nov 2016 13:34:46 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB06129801; Thu, 3 Nov 2016 13:34:46 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id d2so37370734pfd.0; Thu, 03 Nov 2016 13:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:organization:reply-to:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=51yK+Tq7VPMGingoXBR/JcA5Mtajtb9c1qCx0/MRcfs=; b=0UKr57QBTzYXc9+2gvOn5Z7VH9s0hPAQywVu0hA7FV91G++mfg3SU3uShbReZ2Dbv2 nBGkzGebToJpAj+rA1TnCHu3ZKgbc5Ljew0ZbAtm0Nu0VQO1ztwR5Gn/Iig/MyJVwFHI cGZwVpo85IAYG81W8co5ElIri1oOuJ63Pwc3q6s414djpaAJ/w0tJhYYhUUPWguZIRCA PAou2Wiu46+CO4vRc1TWD5gu+wJ0Hvbc9agU7O+koJzeO7uZQCqSteKhPAOEetLbncJl KA5yB9L7gJ7O0WABm5QBJT/NSe64zBsJGmXpiQfyFyF7sjQI21fKli9W0CfWxERlAcsK Hppw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:organization :reply-to:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=51yK+Tq7VPMGingoXBR/JcA5Mtajtb9c1qCx0/MRcfs=; b=k2Zx+1cvQ5vCTcM7S0TfI2jdlDlROVmnAiOwDnQB3gYam0eBbeCyKXMqTPbuF11dx/ FQ7BCHPq98oyUjKbuL5iDbhlWYC44sf6XHdMCRWkR/ddeuQ/yoFIf/ikfONaAjnXt+Gj SR7xnxj/QhCJMP9bKboIx95/rdLArp+BAjYIy6f+8vLh8gd8fCL6GHun4cVx5fhlE1x2 5/gXy+MOlnTp0yGjlVtH0HoQdWO+PoGaC1ytAUcPy1DDgTWZaHekSj/8IgkdC8o6m7TU poSzh7G3yyr/MvHp9NkGwp4pRVlbputOgQF4w5Af3awMvLXcNqNbr38zeqvylq2SzjQk WaWg== X-Gm-Message-State: ABUngvcSca5Lfn3Rong/yI5T5VVtLmALbMKt63Ryq5XfqIC3W72an7m9EiIB71hqg1PHZQ== X-Received: by 10.98.91.198 with SMTP id p189mr20274837pfb.22.1478205285584; Thu, 03 Nov 2016 13:34:45 -0700 (PDT) Received: from ?IPv6:2620:10d:c082:101d:b1df:c115:212d:6f0a? ([2620:10d:c090:200::d:5bda]) by smtp.gmail.com with ESMTPSA id 3sm14778568pam.21.2016.11.03.13.34.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 13:34:44 -0700 (PDT) From: Dave Crocker X-Google-Original-From: Dave Crocker To: Richard Shockey , The IESG References: <72140957-AF17-4E35-85E1-2617630F2109@shockey.us> Organization: Brandenburg InternetWorking Message-ID: <1a1b1d09-c70c-f678-1b76-40e99a84aec8@dcrocker.net> Date: Thu, 3 Nov 2016 13:34:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <72140957-AF17-4E35-85E1-2617630F2109@shockey.us> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-stir-certificates@ietf.org" , Robert Sparks , "stir-chairs@ietf.org" , "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 20:34:48 -0000 On 11/3/2016 1:08 PM, Richard Shockey wrote: > The basics of SHAKEN was reported to the FCC by the Industry robocall strikeforce. > > https://www.fcc.gov/news-events/events/2016/10/second-meeting-industry-led-robocall-strike-force Basics. Yes. However... Small point: The Shaken activities are by a relatively small, closed group, with results that are private, with no public access to the details and no ability to contribute. Were Shaken merely an effort to provide some straightforward operational parameters, that might be fine. But getting STIR to be an functional service requires rather more than just agreeing to some parameters. So the public IETF STIR work is inadequate for creating a useful service, without the private, details specification work of Shaken. d/ ps. From a session at M3AAWG in Paris last week, I was promised that the Shaken specs would be made public. I look forward to that. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Nov 3 14:11:41 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D96129AB0; Thu, 3 Nov 2016 14:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQmmZVyxKldc; Thu, 3 Nov 2016 14:11:37 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C55D129AAD; Thu, 3 Nov 2016 14:11:37 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id d2so37806055pfd.0; Thu, 03 Nov 2016 14:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:reply-to:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=IlI9Jr/EBZ8tBwYN5LzQWZ+9pY2b4JcExu4Ex1omStc=; b=HrLpd7dLsTb+j2aq3ELPu0zkbjBPnygWephBqX25XJ85PzQacA7V/OiwyboLY7Elnv PzjHUySafAmobsfZ5jL9z4jXKbsJ6+KxOMI1JfDWgCgI3AmpScrY1hOelpzsHpBs6woG ERDpHr+tdWjJFbsmr81rSry8Os2dMATgO7F4Fdjz4Fu0szOqPa7OnZTzIqhMGfDKZppd 5e2t2hx7nXwRkDhY1yGBvSJpbyTQ5AWTLjy4Pto1ruF5ODUAiP0HdFcvOhBlF1Y8nn4R AHqVe97+KwebbbUTEBm4RU30BS2KmtqDEprCdttgllfMNqX/dIE9niKrDtKpwP+GTzin XERg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:reply-to :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=IlI9Jr/EBZ8tBwYN5LzQWZ+9pY2b4JcExu4Ex1omStc=; b=UaWSR+tjz6g1zNeMyfe1VVI9vJ4llX2XjQni6bfPeO2SzjzBRTNqYNjpbibB5pAJIp KogRARYCiJoQArxDsBi/oee8g4Czn2RWst1nUmk0Mptn9kylhH0x9ZJPhQZcVzzOb344 uxs2fFpQv9xbDuXDo8u1PBiL/raQQPj9RRSrnD94iSvX1GuKeja+GNVIH25L1WFFGkwi 8Rlcn+qSlPS2Zwvyz6Q/BOH0hRH4z5nrKCx3We2hm2yBIYMIE1W9vYIJJTwEvim4UK4k +Kj3xuqW4bP06vlbnj3O5CXlXBGk8pieXkYMRab/IwGtECtt363zfMIN+9WoXmfFVqHe Ppbg== X-Gm-Message-State: ABUngvdhUyM+yQ3hLldhuis6U53mDXNahrFHuskhLhj1Meclnb4Y3EMDKj/FmSuq5H8Q9w== X-Received: by 10.98.105.68 with SMTP id e65mr20003472pfc.174.1478207496763; Thu, 03 Nov 2016 14:11:36 -0700 (PDT) Received: from ?IPv6:2620:10d:c082:101d:7c6a:3d30:6c90:c902? ([2620:10d:c090:200::7:1055]) by smtp.gmail.com with ESMTPSA id p20sm14796803pfi.78.2016.11.03.14.11.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 14:11:36 -0700 (PDT) From: Dave Crocker X-Google-Original-From: Dave Crocker To: Alissa Cooper References: <147800730286.23932.1515952198717955239.idtracker@ietfa.amsl.com> <1478101725.216255.775166569.1BD2E379@webmail.messagingengine.com> <58F5F6BD-02E0-4DC9-8A69-D918AB5A4B65@vigilsec.com> <26856EBB-3272-4D70-A60E-2714E8B1FB15@cooperw.in> <5bf2eeec-e634-f4f6-2f61-9494dcb20ce0@dcrocker.net> Organization: Brandenburg InternetWorking Message-ID: Date: Thu, 3 Nov 2016 14:11:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Alexey Melnikov , Russ Housley , IETF STIR Mail List , IESG , draft-ietf-stir-certificates@ietf.org, stir-chairs@ietf.org, Robert Sparks Subject: Re: [stir] Alexey Melnikov's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 21:11:39 -0000 On 11/3/2016 12:22 PM, Alissa Cooper wrote: >> What has been defined and what you describe is quite a complex >> system. > I think the existing system of relationships and network paths that > comprise the phone system is the root of the complexity here; the > challenge for STIR has been to provide building blocks with enough > flexibility to help address the requirements in RFC 7340 across a > variety of different deployment scenarios and use cases. Alissa, I've heard that being said, but in fact the phone system's design is almost completely irrelevant to the specifics of STIR. STIR's actual task is almost identical to the job that DKIM does. The only relevant detail from the world of telephony is the existence of call centers that must be able to generate calls that appear to be from a call center customer. This is identical to being able to have an email From: address contain a value that differs from the domain name associated with the email operator being used. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Nov 3 18:01:29 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C437129580 for ; Thu, 3 Nov 2016 18:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wa7SBN9K9rwD for ; Thu, 3 Nov 2016 18:01:26 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 78A1712949C for ; Thu, 3 Nov 2016 18:01:26 -0700 (PDT) Received: (qmail 15273 invoked by uid 0); 4 Nov 2016 01:01:25 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 4 Nov 2016 01:01:25 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id 3cwM1u00L1MNPNq01cwQ9s; Thu, 03 Nov 2016 18:56:25 -0600 X-Authority-Analysis: v=2.1 cv=WL/sABcR c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=1oJP67jkp3AA:10 a=L24OOQBejmoA:10 a=ZZnuYtJkoWoA:10 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=HeG67adPAAAA:8 a=ll-iCDY8AAAA:8 a=pGLkceISAAAA:8 a=doUQZJtgAAAA:8 a=k7Ga1wGzAAAA:8 a=Y8WS0Dqd-joiclyuZ0IA:9 a=_H_0JMSbxK27V9Sm:21 a=lGuHAMhCZulIIxtu:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=jlXKPczUY4Vio7-9iMRd:22 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=d0-0EwFVFT64L02gzcZV:22 a=ijMaxGghyylP-n2pFjDB:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:CC:To:From:Subject:Date; bh=1yR7/gik8lqGgR3IhzUQhAartmg+5BVzco287XE/Pmk=; b=L+63m2rieN5K/LNW8w8+gGsECC jBZTM0W7P0HsKpFS0MI1KHYfo8aqryp0aH3sOoJgS+jOZNSh44SJ9va7m1pnGFIQCKdfMz+YUKXXl 04Fi+7HcWzTEAuX2q89q9BX6p; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:53205 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1c2Snt-0001ww-6O; Thu, 03 Nov 2016 18:56:21 -0600 User-Agent: Microsoft-MacOutlook/f.1b.0.161010 Date: Thu, 03 Nov 2016 20:56:18 -0400 From: Richard Shockey To: , The IESG Message-ID: <090A042D-E92D-497B-A0C2-59EDC841E73F@shockey.us> Thread-Topic: [stir] Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) References: <72140957-AF17-4E35-85E1-2617630F2109@shockey.us> <1a1b1d09-c70c-f678-1b76-40e99a84aec8@dcrocker.net> In-Reply-To: <1a1b1d09-c70c-f678-1b76-40e99a84aec8@dcrocker.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1c2Snt-0001ww-6O X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:53205 X-Source-Auth: richard+shockey.us X-Email-Count: 3 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Cc: "draft-ietf-stir-certificates@ietf.org" , Robert Sparks , "stir-chairs@ietf.org" , "stir@ietf.org" , Stephen Farrell Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 01:01:28 -0000 Fair point .. We are working pretty hard to open up this process. These things take time = negotiation lawyers etc. =20 The SHAKEN Documents are here. On a forward basis it=E2=80=99s the joint SIP For= um=E2=80=99s and ATIS plan to open up the process to as wide an audience as possib= le. More importantly the US telecom associations US Telecom and CTIA are ope= ning up their process to all participants look at some of the other issues d= efined in the strike force report including the all-important track and trac= e issues. We have to identify the networks that are injecting the malicious= traffic into the network. Looking at the existing CDR=E2=80=99s is just useless.= =20 If the IETF and the IESG can deliver this first phase of the protocols, the= n 3GPP and now DISPATCH can to their thing. The good news is STIR, at this s= tage will have wide adoption. It=E2=80=99s a fine set of tools.=20 http://www.sipforum.org/content/view/439/312/ In case you hadn=E2=80=99t seen. https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-callinfo-spam/ https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-status-unwanted BTW IMHO these should be kept in DISPATCH and AD sponsored. I will not sup= port a new WG here. We have enough of those as it is.=20 As you probably heard in Paris there is substantial interest in STIR/SHAKEN= from multiple national jurisdictions and I will specifically be addressing = some of those issues in the UK next week. http://www.niccstandards.org.uk/meetings/forum-2016.cfm In our defense the ATIS SIP Forum NNI TF has been looking at this for some = time. The strike force was under a very very short time line. The strike = force to the FCC enforced a non-disclosure agreement on this first phase of = the work to outline what was possible and provide a roadmap to solutions. Y= ou can argue one way or another on whether that was a good idea but in retro= spect I could live with it and I was NOT a signatory to the NDA. Lets try a= nd keep a cooperative effort going. =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 On 11/3/16, 4:34 PM, "Dave Crocker" wrote: On 11/3/2016 1:08 PM, Richard Shockey wrote: > The basics of SHAKEN was reported to the FCC by the Industry robocall= strikeforce. > > https://www.fcc.gov/news-events/events/2016/10/second-meeting-industr= y-led-robocall-strike-force =20 =20 Basics. Yes. However... =20 Small point: =20 The Shaken activities are by a relatively small, closed group,=20 with results that are private, with no public access to the details and= =20 no ability to contribute. Were Shaken merely an effort to provide some= =20 straightforward operational parameters, that might be fine. =20 But getting STIR to be an functional service requires rather more= =20 than just agreeing to some parameters. =20 So the public IETF STIR work is inadequate for creating a useful=20 service, without the private, details specification work of Shaken. =20 d/ =20 ps. From a session at M3AAWG in Paris last week, I was promised that=20 the Shaken specs would be made public. I look forward to that. =20 --=20 =20 Dave Crocker Brandenburg InternetWorking bbiw.net =20 From nobody Fri Nov 4 08:29:33 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808BC129563 for ; Fri, 4 Nov 2016 08:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNzMHUdg6JOh for ; Fri, 4 Nov 2016 08:29:30 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2209912943C for ; Fri, 4 Nov 2016 08:29:30 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id n204so91197189qke.2 for ; Fri, 04 Nov 2016 08:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=POrbSgzjJxpqIIQ/W7CGMyO4ioDszZYVZCb8uyW9q68=; b=j70rGVxlF69Fugso8ISwP9Y8Fho+jlkR/pjCJN5nsgvaweaK929xLYB7rVTqDPsoga wQXz4oY2U/SZulBiNh5D5BqNAqbpQNfgnT+gfFgS+wo0992rqk5GWFisRsbiJanctKnM Aej4vs5GkUGjgVNVGApEibRyMnlAE4AAxzvelP/Xicthd2GKqGsSZtBl4bsTRn0BuphO WHsjge1XZQtYNyxaFedqSGpUj0f4AIZ/LWukcTq28GMdLNObv7TontETLTGj0zG6wOe+ +/4gwYVxWTo8hw/ElFa00J89sLP6WCFzBkmf1dx/zaeL3bBYFbwIExRqXxh2AAK5BDNf Y8Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=POrbSgzjJxpqIIQ/W7CGMyO4ioDszZYVZCb8uyW9q68=; b=C5uCqkLekWIKEV8PVPFMJBIYAsWGcoPxX4ytR0IBfzyji0kIEkpVAZPMhYlnDGGcvX 8ihJI/kPpwoyHHXVAOexgnkdqx+SFp/qvB9gjMIX2VExyiMK8S3UY2DgI7n0mtv+gAS6 cu6yJureQt8DSAuISYKeK41/n6tGU5dTZla907+iXCVHhzqvQegzzqE/mjQs80f1Mw7J 5zQXjPmDRNmSfGwGV3YXxC6Ttcd75dbEqLzTHT8pBAaeJYRNY8kWdZZ0zXeKE+KfviHn OS2xCCJteczP0Fb44fnslQNOknC1AVYnAjH0viIaDPWJrORVCqhJtEN5rj/wOTp7nORi yaHg== X-Gm-Message-State: ABUngvdp34t7jDOujj/q0rbvcI6M2PD7lH10AU16z+0R0U9L9tk26DGRkhB2xUr6VNOtrg== X-Received: by 10.55.7.132 with SMTP id 126mr12921278qkh.224.1478273369273; Fri, 04 Nov 2016 08:29:29 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:d057:f30a:2440:c90? ([2601:41:c101:9364:d057:f30a:2440:c90]) by smtp.gmail.com with ESMTPSA id q65sm7088109qki.20.2016.11.04.08.29.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 08:29:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Chris Wendt In-Reply-To: <147813889365.24118.12619854983152878871.idtracker@ietfa.amsl.com> Date: Fri, 4 Nov 2016 11:29:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147813889365.24118.12619854983152878871.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3251) Archived-At: Cc: stir@ietf.org, stir-chairs@ietf.org, Robert Sparks , The IESG , draft-ietf-stir-passport@ietf.org Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-passport-10: (with DISCUSS) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 15:29:32 -0000 Hi Stephen, As Jon mentioned, we can=E2=80=99t claim to have spent time on this, but = I did look at over the past two days and discussed it with some of the = relevant security folks and I think this would be our position: The main concern around not using deterministic ECDSA is that you = =E2=80=9Cmay=E2=80=9D have bad random number generators as an input K, = and therefore may have some way of looking at patterns and finding = exploits perhaps for a given signature. I did a brief survey of popular packages used as part of popular server = side languages, golang, java, python, and only found a single mention of = python package last updated in early 2015 implementing = RFC6979/deterministic ECDSA. =20 Given the availability of solid implementations of RFC6979, I would say = we have a big hurdle here to getting acceptance and usage of = STIR/passport by implementation providers, and i would have a personal = concern that we may force folks to use less tested and less accepted = implementations of ECDSA and therefore potentially reduce security from = a completely different angle. =20 For the initial deployment of STIR, most implementations are going to be = server side in any case where there is less concern about bad random = number generation. So i think we are covered until and unless = deterministic ECDSA becomes more widely adopted. For the point when = smart phones may start doing STIR signatures, perhaps because they are = becoming as powerful as PCs, their random generators if they don=E2=80=99t= already (i suspect) will provide acceptable security in the signatures = as well. =20 One thing i could do in the passport document is have an informative = note to talk about this concern and if you are implementing passport = signatures on devices without proper random number generation = capabilities you may want to consider implementing RFC6979. Signatures = that are produced by normal ECDSA and deterministic ECDSA are compatible = so there shouldn=E2=80=99t be any concern there. Would that be acceptable? Or after the above discussion do you think = that is necessary? Thanks. -Chris > On Nov 2, 2016, at 10:08 PM, Stephen Farrell = wrote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-stir-passport-10: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 > Deterministic ECDSA (RFC6979) gets rid of a significant weakness > with ECDSA. IIRC when JOSE was done there was a feeling that adding a > MUST or SHOULD for that was tricky due to lack of support in > libraries. When we recently re-checked for COSE, the answer was > that today, it's ok to have that as a MUST or SHOULD. (If some > kind of FIPS-140 stuff precludes a MUST, then a "SHOULD unless > you're sad enough to be stuck having to pay lip lipservice to > FIPS-140" clause might be right. So the DISCUSS point here is: > given the real-world demonstrated weakness inherent in the need > for an RNG in ECDSA why didn't the WG choose to at least RECOMMEND > deterministic ECDSA? (Or better, make it a MUST.) >=20 > If the answer is: "we thought about it [ref] and decided to not = require > deterministic" then I'll clear. But even if the WG did consider it > a couple of years ago, the situation may have changed so a quick > re-think might be worthwhile. >=20 >=20 >=20 >=20 From nobody Fri Nov 4 11:59:01 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB2D129569; Fri, 4 Nov 2016 11:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZuqVUYSuO23; Fri, 4 Nov 2016 11:58:51 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B42471293DC; Fri, 4 Nov 2016 11:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CZSg8Uds4/hjwwK6LoYzCI4sWs6mcggLYse9H8eSot8=; b=siyfXohJpjSeffghXVX0EkKgb cu3OTaHpPFl19LpOAqOTzkuFGM0RS6k5COOjGpaJQQZGBYWmra2Ylk8npBIqEpjUbkog3sGkMiBP+ 87Hhk6gnYTo8CFKiIrT1NGNkFIS+qR4jRuPLli0wxQU/3rcvmrBw4XaKbwhAwwcFf/yLc=; Received: from [141.161.133.199] (port=53625 helo=[10.129.224.170]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1c2jhP-0000IU-Au; Fri, 04 Nov 2016 11:58:51 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_4E232FF8-36F6-495F-B027-D2562D1D9B69"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Eric Burger In-Reply-To: Date: Fri, 4 Nov 2016 14:58:45 -0400 Message-Id: <1E70EB66-4F9A-45FD-BFFE-086435939AC6@standardstrack.com> References: <147813889365.24118.12619854983152878871.idtracker@ietfa.amsl.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz104.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: The IESG Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-passport-10: (with DISCUSS) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 18:58:53 -0000 --Apple-Mail=_4E232FF8-36F6-495F-B027-D2562D1D9B69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would offer saying that the limited, but existing, availability of = deterministic ECDSA is a barrier to widespread adoption barriers for = STIR is a non-issue. We are not talking about how to update 300 = different browser-OS-hardware combinations in the wild where 15% are = running Mosaic on WindowsXP. We are talking about code that has yet to = be written. As such, there is no reason to effectively say =E2=80=9Cstrong= security is not important if the alternative is no security=E2=80=9D or = =E2=80=9Cwe cannot get the major browser players to adopt our approach = because OpenSSL does not implement the feature.=E2=80=9D Rather, given all this code is being written *today*, there is = absolutely no reason to hobble STIR before it launches. > On Nov 4, 2016, at 11:29 AM, Chris Wendt = wrote: >=20 > Hi Stephen, >=20 > As Jon mentioned, we can=E2=80=99t claim to have spent time on this, = but I did look at over the past two days and discussed it with some of = the relevant security folks and I think this would be our position: >=20 > The main concern around not using deterministic ECDSA is that you = =E2=80=9Cmay=E2=80=9D have bad random number generators as an input K, = and therefore may have some way of looking at patterns and finding = exploits perhaps for a given signature. >=20 > I did a brief survey of popular packages used as part of popular = server side languages, golang, java, python, and only found a single = mention of python package last updated in early 2015 implementing = RFC6979/deterministic ECDSA. >=20 > Given the availability of solid implementations of RFC6979, I would = say we have a big hurdle here to getting acceptance and usage of = STIR/passport by implementation providers, and i would have a personal = concern that we may force folks to use less tested and less accepted = implementations of ECDSA and therefore potentially reduce security from = a completely different angle. >=20 > For the initial deployment of STIR, most implementations are going to = be server side in any case where there is less concern about bad random = number generation. So i think we are covered until and unless = deterministic ECDSA becomes more widely adopted. For the point when = smart phones may start doing STIR signatures, perhaps because they are = becoming as powerful as PCs, their random generators if they don=E2=80=99t= already (i suspect) will provide acceptable security in the signatures = as well. >=20 > One thing i could do in the passport document is have an informative = note to talk about this concern and if you are implementing passport = signatures on devices without proper random number generation = capabilities you may want to consider implementing RFC6979. Signatures = that are produced by normal ECDSA and deterministic ECDSA are compatible = so there shouldn=E2=80=99t be any concern there. >=20 > Would that be acceptable? Or after the above discussion do you think = that is necessary? >=20 > Thanks. >=20 > -Chris >=20 >=20 >> On Nov 2, 2016, at 10:08 PM, Stephen Farrell = wrote: >>=20 >> Stephen Farrell has entered the following ballot position for >> draft-ietf-stir-passport-10: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >>=20 >> Deterministic ECDSA (RFC6979) gets rid of a significant weakness >> with ECDSA. IIRC when JOSE was done there was a feeling that adding a >> MUST or SHOULD for that was tricky due to lack of support in >> libraries. When we recently re-checked for COSE, the answer was >> that today, it's ok to have that as a MUST or SHOULD. (If some >> kind of FIPS-140 stuff precludes a MUST, then a "SHOULD unless >> you're sad enough to be stuck having to pay lip lipservice to >> FIPS-140" clause might be right. So the DISCUSS point here is: >> given the real-world demonstrated weakness inherent in the need >> for an RNG in ECDSA why didn't the WG choose to at least RECOMMEND >> deterministic ECDSA? (Or better, make it a MUST.) >>=20 >> If the answer is: "we thought about it [ref] and decided to not = require >> deterministic" then I'll clear. But even if the WG did consider it >> a couple of years ago, the situation may have changed so a quick >> re-think might be worthwhile. >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_4E232FF8-36F6-495F-B027-D2562D1D9B69 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJYHNplAAoJEORoZaSQsc1IFlYP/3ykIp15f+Ov0Y5OxRBQGf29 alJO3utrtWFLxzX9bdqScvfqCWqiLSf9c+40VH2uYHeNb1k6j9jse2XX+cvYJ/ar CDQpKOV9hj6Dz51UdQjXoCvEv3Cb46znlspnUc82ADJsf1ZDFgDJu0JNMb/dMPmG +03V8jYFUvrwbfonYIJxeZnnQHTp37JY/a6PFKjY3R9bXHht1uGaxgk5470ULzKy SMjq/8pPpsu05U2iPC+kSZdP7fQXjYaV0SIPJV/zn9yOROcuABJTJNxqW6ZWb9Xq pteRML9MY5KZwXb2+ThCgsWIcr9+zQWmbWzIXkIFR2DoP5Zt2fZ1HH+b1y6wTQhl EOJMt/VA5j2vCn4LV8E3VtWN/4zrpTDd4VCTZ5F6puzH6+Ke3NkFccXQOCGQl14Z i05k3CQ/2Eh4Yxv6o4cYgRXyVfIo4lwTnjX6aZ4ee8eP2xRZ1GhWNOBZoC/BYBGb eCD1l2sa8V6QFyl5vNeENn4LdY71RsjxVVjsV0/8aMKXyWcFJwtdR27t8AbQ3sUz 3pTbRFX8iJozMbqo28IMf4IxhMKCwRU40kXIx9vRD/0q+8NYyslljtUSIFkY4Kc2 W9vJYZ9XOT8T5DL/1HzIcXS4EYlEQPl0T/4Fvd39bzS744QEld4hRkpt1CeAbFHr xT6DHkOMKyTWsww3Xx2A =GBbw -----END PGP SIGNATURE----- --Apple-Mail=_4E232FF8-36F6-495F-B027-D2562D1D9B69-- From nobody Fri Nov 4 12:19:20 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015CC129658 for ; Fri, 4 Nov 2016 12:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMy85G0zs6sZ for ; Fri, 4 Nov 2016 12:19:01 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285BC129656 for ; Fri, 4 Nov 2016 12:19:01 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id w33so54285219qtc.3 for ; Fri, 04 Nov 2016 12:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dIcpBYxnqhCht+jDGAvEyUO0jBscIL7xD4qiFdfAk/w=; b=oCjibiDF/7ZoWLqRjr+uikoOCVwRdZ+XXm7Cjgd5VA8HndP0+fe+zm/EjosIXF1nQR nAwAU5VH0fHJ+hw6lNfsdqUm+yHjQ5D96e2tShUxR/WZZyO4EC6SRt62akVHmdtwsvvi 6yITWthE1C6an60DibB8JFkB+2d9cBk/JbbnAzz4DRRrLHzofXnV0d0Q3EIWEtadLD6o mR9ERl0CSrO9brGRPdso8AEp9TSyUKiAJtohkZVeXxT2TZ9K6QBoFZxoinSY+U1ZNoCm cDHVe4hZ5YJcI96PSuvZFDFh10qzRQIScYPrOO4zpSTeubWRw4+dLwaM+QTnYALlYs/E kKyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dIcpBYxnqhCht+jDGAvEyUO0jBscIL7xD4qiFdfAk/w=; b=NSXbth9hZSTyZTDSV4doCLJ0l+WXJ7114k7m6hZ88EqJ7inqpsAhDQF4rH++bAsS+D A/mvvywphAHKefBaodvu7MT9xyeBmUsHA0LBZGnxN5Da2ogdKkPAjNojUvFn3I5k+Gcd hloTRh7UCKqvw0CVxm67RFl4dprJiX2ZoZigPGnynAgT9rg9O8Z3huhd5L412IZF2Hbg X5m578nhJicXEmnNLCekSzJR98U4nJE5CcRIBzRXEPEZGacoH0GO0Ees8Df6/ZNnjQMF R+blCu1qOhV6Rftz8EQwwoVT+Q5RJmNR2j6yj5DJBO3nVeuXasO7FwRU72u9e5xhi/Sr ev1Q== X-Gm-Message-State: ABUngvcrq00jsSU7Jicy8M+D8/i3egG/Mdus7k/itlpmUsja9Cit7YHZHWQlT4XOM67djQ== X-Received: by 10.237.48.37 with SMTP id 34mr15655886qte.111.1478287140166; Fri, 04 Nov 2016 12:19:00 -0700 (PDT) Received: from [172.31.99.102] (96-83-244-75-static.hfc.comcastbusiness.net. [96.83.244.75]) by smtp.gmail.com with ESMTPSA id a54sm8360044qta.49.2016.11.04.12.18.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 12:18:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Chris Wendt In-Reply-To: <1E70EB66-4F9A-45FD-BFFE-086435939AC6@standardstrack.com> Date: Fri, 4 Nov 2016 15:18:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <78D6C6D9-9782-47FA-8E82-6C6A38C131A2@chriswendt.net> References: <147813889365.24118.12619854983152878871.idtracker@ietfa.amsl.com> <1E70EB66-4F9A-45FD-BFFE-086435939AC6@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF STIR Mail List , The IESG Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-passport-10: (with DISCUSS) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 19:19:14 -0000 =E2=80=9Chobble=E2=80=9D is a hugely inappropriate term. I=E2=80=99m not seeing any huge push to move to deterministic ECDSA = although to be frank i won=E2=80=99t claim to be in the middle of this = issue either. Seems to me, if deterministic ECDSA becomes the preferred/default = implementation, then problem solved and we didn=E2=80=99t have to change = anything because both are compatible with each other from a signature = validation point of view. > On Nov 4, 2016, at 2:58 PM, Eric Burger = wrote: >=20 > I would offer saying that the limited, but existing, availability of = deterministic ECDSA is a barrier to widespread adoption barriers for = STIR is a non-issue. We are not talking about how to update 300 = different browser-OS-hardware combinations in the wild where 15% are = running Mosaic on WindowsXP. We are talking about code that has yet to = be written. As such, there is no reason to effectively say =E2=80=9Cstrong= security is not important if the alternative is no security=E2=80=9D or = =E2=80=9Cwe cannot get the major browser players to adopt our approach = because OpenSSL does not implement the feature.=E2=80=9D >=20 > Rather, given all this code is being written *today*, there is = absolutely no reason to hobble STIR before it launches. >=20 >> On Nov 4, 2016, at 11:29 AM, Chris Wendt = wrote: >>=20 >> Hi Stephen, >>=20 >> As Jon mentioned, we can=E2=80=99t claim to have spent time on this, = but I did look at over the past two days and discussed it with some of = the relevant security folks and I think this would be our position: >>=20 >> The main concern around not using deterministic ECDSA is that you = =E2=80=9Cmay=E2=80=9D have bad random number generators as an input K, = and therefore may have some way of looking at patterns and finding = exploits perhaps for a given signature. >>=20 >> I did a brief survey of popular packages used as part of popular = server side languages, golang, java, python, and only found a single = mention of python package last updated in early 2015 implementing = RFC6979/deterministic ECDSA. >>=20 >> Given the availability of solid implementations of RFC6979, I would = say we have a big hurdle here to getting acceptance and usage of = STIR/passport by implementation providers, and i would have a personal = concern that we may force folks to use less tested and less accepted = implementations of ECDSA and therefore potentially reduce security from = a completely different angle. >>=20 >> For the initial deployment of STIR, most implementations are going to = be server side in any case where there is less concern about bad random = number generation. So i think we are covered until and unless = deterministic ECDSA becomes more widely adopted. For the point when = smart phones may start doing STIR signatures, perhaps because they are = becoming as powerful as PCs, their random generators if they don=E2=80=99t= already (i suspect) will provide acceptable security in the signatures = as well. >>=20 >> One thing i could do in the passport document is have an informative = note to talk about this concern and if you are implementing passport = signatures on devices without proper random number generation = capabilities you may want to consider implementing RFC6979. Signatures = that are produced by normal ECDSA and deterministic ECDSA are compatible = so there shouldn=E2=80=99t be any concern there. >>=20 >> Would that be acceptable? Or after the above discussion do you think = that is necessary? >>=20 >> Thanks. >>=20 >> -Chris >>=20 >>=20 >>> On Nov 2, 2016, at 10:08 PM, Stephen Farrell = wrote: >>>=20 >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-stir-passport-10: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 >>> Deterministic ECDSA (RFC6979) gets rid of a significant weakness >>> with ECDSA. IIRC when JOSE was done there was a feeling that adding = a >>> MUST or SHOULD for that was tricky due to lack of support in >>> libraries. When we recently re-checked for COSE, the answer was >>> that today, it's ok to have that as a MUST or SHOULD. (If some >>> kind of FIPS-140 stuff precludes a MUST, then a "SHOULD unless >>> you're sad enough to be stuck having to pay lip lipservice to >>> FIPS-140" clause might be right. So the DISCUSS point here is: >>> given the real-world demonstrated weakness inherent in the need >>> for an RNG in ECDSA why didn't the WG choose to at least RECOMMEND >>> deterministic ECDSA? (Or better, make it a MUST.) >>>=20 >>> If the answer is: "we thought about it [ref] and decided to not = require >>> deterministic" then I'll clear. But even if the WG did consider it >>> a couple of years ago, the situation may have changed so a quick >>> re-think might be worthwhile. >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Fri Nov 4 15:46:01 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B431299C2; Fri, 4 Nov 2016 15:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 wVA7oULlDgi4; Fri, 4 Nov 2016 15:45:51 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04251299AA; Fri, 4 Nov 2016 15:45:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0167CBE5B; Fri, 4 Nov 2016 22:45:48 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXjzTFVORqop; Fri, 4 Nov 2016 22:45:46 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9C0E0BE56; Fri, 4 Nov 2016 22:45:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1478299546; bh=P7IDhHHI6bhvuo7PZ++2TrYYvvIpmBHDzWD6UaRZUCM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=c+2xjyzBQbQLWKL1PnCGgctpDFe5r+AOgaGRui3AOVFhIaOM00UUsbnjAitZFfZju 5KBBxu2qGmLiKOhSm18UDikoXQ1AliLimRfEAVd/4FAc2gbhtO1RLnQ0EYW5ewE8OL F0igiyOpmOwbbQuHVv/4x2jRb0Q3gjlLR7g1R0aE= To: Chris Wendt , Eric Burger References: <147813889365.24118.12619854983152878871.idtracker@ietfa.amsl.com> <1E70EB66-4F9A-45FD-BFFE-086435939AC6@standardstrack.com> <78D6C6D9-9782-47FA-8E82-6C6A38C131A2@chriswendt.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 4 Nov 2016 22:45:45 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <78D6C6D9-9782-47FA-8E82-6C6A38C131A2@chriswendt.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010600050207010401030806" Archived-At: Cc: IETF STIR Mail List , The IESG Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-passport-10: (with DISCUSS) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 22:45:54 -0000 This is a cryptographically signed message in MIME format. --------------ms010600050207010401030806 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 04/11/16 19:18, Chris Wendt wrote: > =E2=80=9Chobble=E2=80=9D is a hugely inappropriate term. Well, arguably so is "hugely inappropriate" :-) I'd agree though that hobble is a teeny bit overstated. I think Eric does have a point though that STIR involves a chunk of new code so the problems aren't as bad as in other situations. I'd also encourage the WG to maybe look some more - as I said in the case of COSE, recent findings were that deterministic ECDSA was available in most crypto libraries now. That might not yet have percolated up to higher level libraries I guess (though last I looked neither had ECDSA, but it's been a while). Nonetheless that doesn't stop you saying something like: "Signers SHOULD use deterministic ECDSA if/when supported in their development environment for the reasons stated in [RFC6979]." As you said, verifiers don't need to care and I think the above is also painless for those writing signing code, but does give better guidance. Sound reasonable? Cheers, S. >=20 > I=E2=80=99m not seeing any huge push to move to deterministic ECDSA alt= hough > to be frank i won=E2=80=99t claim to be in the middle of this issue eit= her. >=20 > Seems to me, if deterministic ECDSA becomes the preferred/default > implementation, then problem solved and we didn=E2=80=99t have to chang= e > anything because both are compatible with each other from a signature > validation point of view. >=20 >=20 >> On Nov 4, 2016, at 2:58 PM, Eric Burger >> wrote: >>=20 >> I would offer saying that the limited, but existing, availability >> of deterministic ECDSA is a barrier to widespread adoption barriers >> for STIR is a non-issue. We are not talking about how to update 300 >> different browser-OS-hardware combinations in the wild where 15% >> are running Mosaic on WindowsXP. We are talking about code that has >> yet to be written. As such, there is no reason to effectively say >> =E2=80=9Cstrong security is not important if the alternative is no >> security=E2=80=9D or =E2=80=9Cwe cannot get the major browser players = to adopt our >> approach because OpenSSL does not implement the feature.=E2=80=9D >>=20 >> Rather, given all this code is being written *today*, there is >> absolutely no reason to hobble STIR before it launches. >>=20 >>> On Nov 4, 2016, at 11:29 AM, Chris Wendt >>> wrote: >>>=20 >>> Hi Stephen, >>>=20 >>> As Jon mentioned, we can=E2=80=99t claim to have spent time on this, = but >>> I did look at over the past two days and discussed it with some >>> of the relevant security folks and I think this would be our >>> position: >>>=20 >>> The main concern around not using deterministic ECDSA is that you >>> =E2=80=9Cmay=E2=80=9D have bad random number generators as an input K= , and >>> therefore may have some way of looking at patterns and finding >>> exploits perhaps for a given signature. >>>=20 >>> I did a brief survey of popular packages used as part of popular >>> server side languages, golang, java, python, and only found a >>> single mention of python package last updated in early 2015 >>> implementing RFC6979/deterministic ECDSA. >>>=20 >>> Given the availability of solid implementations of RFC6979, I >>> would say we have a big hurdle here to getting acceptance and >>> usage of STIR/passport by implementation providers, and i would >>> have a personal concern that we may force folks to use less >>> tested and less accepted implementations of ECDSA and therefore >>> potentially reduce security from a completely different angle. >>>=20 >>> For the initial deployment of STIR, most implementations are >>> going to be server side in any case where there is less concern >>> about bad random number generation. So i think we are covered >>> until and unless deterministic ECDSA becomes more widely adopted. >>> For the point when smart phones may start doing STIR signatures, >>> perhaps because they are becoming as powerful as PCs, their >>> random generators if they don=E2=80=99t already (i suspect) will prov= ide >>> acceptable security in the signatures as well. >>>=20 >>> One thing i could do in the passport document is have an >>> informative note to talk about this concern and if you are >>> implementing passport signatures on devices without proper random >>> number generation capabilities you may want to consider >>> implementing RFC6979. Signatures that are produced by normal >>> ECDSA and deterministic ECDSA are compatible so there shouldn=E2=80=99= t >>> be any concern there. >>>=20 >>> Would that be acceptable? Or after the above discussion do you >>> think that is necessary? >>>=20 >>> Thanks. >>>=20 >>> -Chris >>>=20 >>>=20 >>>> On Nov 2, 2016, at 10:08 PM, Stephen Farrell >>>> wrote: >>>>=20 >>>> Stephen Farrell has entered the following ballot position for=20 >>>> draft-ietf-stir-passport-10: Discuss >>>>=20 >>>> When responding, please keep the subject line intact and reply >>>> to all email addresses included in the To and CC lines. (Feel >>>> free to cut this introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for >>>> more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found >>>> here:=20 >>>> https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ >>>>=20 >>>>=20 >>>>=20 >>>> --------------------------------------------------------------------= -- >>>> >>>>=20 DISCUSS: >>>> --------------------------------------------------------------------= -- >>>> >>>> >>>> >>>>=20 Deterministic ECDSA (RFC6979) gets rid of a significant weakness >>>> with ECDSA. IIRC when JOSE was done there was a feeling that >>>> adding a MUST or SHOULD for that was tricky due to lack of >>>> support in libraries. When we recently re-checked for COSE, the >>>> answer was that today, it's ok to have that as a MUST or >>>> SHOULD. (If some kind of FIPS-140 stuff precludes a MUST, then >>>> a "SHOULD unless you're sad enough to be stuck having to pay >>>> lip lipservice to FIPS-140" clause might be right. So the >>>> DISCUSS point here is: given the real-world demonstrated >>>> weakness inherent in the need for an RNG in ECDSA why didn't >>>> the WG choose to at least RECOMMEND deterministic ECDSA? (Or >>>> better, make it a MUST.) >>>>=20 >>>> If the answer is: "we thought about it [ref] and decided to not >>>> require deterministic" then I'll clear. But even if the WG did >>>> consider it a couple of years ago, the situation may have >>>> changed so a quick re-think might be worthwhile. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ stir mailing >>> list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ stir mailing list=20 >> stir@ietf.org https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ stir mailing list=20 > stir@ietf.org https://www.ietf.org/mailman/listinfo/stir >=20 --------------ms010600050207010401030806 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDQy MjQ1NDVaMC8GCSqGSIb3DQEJBDEiBCCmgCbIymWdtZoqmrAfZ/ZiBZdS2FU9d3fmRI9XOEC9 ZDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBhFMrzpKYWV2yD5PzvyZiJjntl+tHoZBebZgMnNNaZFNSd1yHtf41w RZxwTe3a22Kq52pDzCKyb77yKbM1rDoaA6aSL3ZGzTCtAVLpRftpXWVaR8uZ5AjlPVQGJ0iQ 91KnTE1UEHhjXyNVIsUiBZSgV+3QROFedlzycfON+Om5tUPbn3j/IZSwLMteQyQlpB16G4kd yQrfKM2D6pxkHLgrNdlGKUPxXJra4gnywlIDSaYYMD1jWvgUQ2FlL/99ReLunR2lq+MQNN0T Kl1G4kN0yCRRHQJR2NbhA9PCMclARi+SRLw8AQYMRXlnXeG494DaqmRhhS+e8hwzP+aMYTU7 AAAAAAAA --------------ms010600050207010401030806-- From nobody Mon Nov 7 06:34:54 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2AD129766 for ; Mon, 7 Nov 2016 06:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiqMoihMCo3V for ; Mon, 7 Nov 2016 06:34:50 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C56129706 for ; Mon, 7 Nov 2016 06:34:50 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id c47so88007065qtc.2 for ; Mon, 07 Nov 2016 06:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vCJ7xYZKQeKx86quprd7PpNcfmaC6tVVVibZ9faG4RU=; b=1D40VNNqgwQkS/wNVGDaJyZg4fPDSyfEKeYxcOPXfRVMrfGoLZNoZ36T8jrPv8xkJB aJ7H+4sCn5QQQ1v93xYSePbNAR5grW5GBAlP9WTvH5sHN0SwIgQGsiIWrOBNbVMiWWNH 5/wDdwaliv3nz5TmRuMRiAekOuUxNANh2ys93OkgfiuROnSN+vkBa3u8ifJB+wL8m5KD RPpYTQNl3hdJY9R2A29Wdeacl318wmnHu2qX2HjAMqOpqsdP3dtTkpnveNFIpRjhiLZP lALHeAWxkv1sz2eNhuW21ExjkfqX6uTIvZZ9TMxYn6QtRuvWfmyKXHfADufunpDW9VZe MYWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vCJ7xYZKQeKx86quprd7PpNcfmaC6tVVVibZ9faG4RU=; b=l4+xya6ovpWrkF/F+zpMLik95i6KcmNcIATq4rkj3NE6fAiRrHtPK3ICpg0LMmJaFD 0e+sBu+42Q06zfcqAMQBrOt0eTnFmZ4PzZ6BbR5xtcaa2uVfGElH2L4V89KRI6Bgvgi8 oxtBAeI8fHDpqQWi3myTeeKQJhcfgo22P3FgjYRUVFTyujOJn/JL1diFLJ6BzZShgJCX aW0WHvzThshASySK9fpoy4B7asDd7BWT5XjH3GYO1vl1ZnA7q5nQjU1ZZ9pTRykvvFgn E4RATj9bwXvNWpkfeUfBHEEkLYPTWx8WZgmhM3OUSAevkHOCHjzs7c59iyxzCZ0hQAau gFKg== X-Gm-Message-State: ABUngvf1lh0bfBWWcuNOLX5eu6WPKlShiM4z4gljrJnkH4gkB8YTV7eHx4snuEoVqeheUA== X-Received: by 10.200.41.9 with SMTP id y9mr6887792qty.26.1478529288665; Mon, 07 Nov 2016 06:34:48 -0800 (PST) Received: from ?IPv6:2601:a40:100:d3:10a6:6f2:1e76:d362? ([2601:a40:100:d3:10a6:6f2:1e76:d362]) by smtp.gmail.com with ESMTPSA id s41sm16514474qtc.39.2016.11.07.06.34.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Nov 2016 06:34:47 -0800 (PST) From: Chris Wendt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E90E07E6-B25C-41C6-BF2A-E6602045AB4B" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Mon, 7 Nov 2016 09:34:46 -0500 In-Reply-To: To: Stephen Farrell References: <147813889365.24118.12619854983152878871.idtracker@ietfa.amsl.com> <1E70EB66-4F9A-45FD-BFFE-086435939AC6@standardstrack.com> <78D6C6D9-9782-47FA-8E82-6C6A38C131A2@chriswendt.net> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF STIR Mail List , The IESG Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-passport-10: (with DISCUSS) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 14:34:53 -0000 --Apple-Mail=_E90E07E6-B25C-41C6-BF2A-E6602045AB4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m good with that. -Chris > On Nov 4, 2016, at 6:45 PM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > On 04/11/16 19:18, Chris Wendt wrote: >> =E2=80=9Chobble=E2=80=9D is a hugely inappropriate term. >=20 > Well, arguably so is "hugely inappropriate" :-) >=20 > I'd agree though that hobble is a teeny bit overstated. >=20 > I think Eric does have a point though that STIR involves a chunk of > new code so the problems aren't as bad as in other situations. I'd > also encourage the WG to maybe look some more - as I said in the > case of COSE, recent findings were that deterministic ECDSA was > available in most crypto libraries now. That might not yet have > percolated up to higher level libraries I guess (though last I > looked neither had ECDSA, but it's been a while). >=20 > Nonetheless that doesn't stop you saying something like: >=20 > "Signers SHOULD use deterministic ECDSA if/when supported in their > development environment for the reasons stated in [RFC6979]." >=20 > As you said, verifiers don't need to care and I think the above > is also painless for those writing signing code, but does give > better guidance. >=20 > Sound reasonable? >=20 > Cheers, > S. >=20 >>=20 >> I=E2=80=99m not seeing any huge push to move to deterministic ECDSA = although >> to be frank i won=E2=80=99t claim to be in the middle of this issue = either. >>=20 >> Seems to me, if deterministic ECDSA becomes the preferred/default >> implementation, then problem solved and we didn=E2=80=99t have to = change >> anything because both are compatible with each other from a signature >> validation point of view. >>=20 >>=20 >>> On Nov 4, 2016, at 2:58 PM, Eric Burger >>> wrote: >>>=20 >>> I would offer saying that the limited, but existing, availability >>> of deterministic ECDSA is a barrier to widespread adoption barriers >>> for STIR is a non-issue. We are not talking about how to update 300 >>> different browser-OS-hardware combinations in the wild where 15% >>> are running Mosaic on WindowsXP. We are talking about code that has >>> yet to be written. As such, there is no reason to effectively say >>> =E2=80=9Cstrong security is not important if the alternative is no >>> security=E2=80=9D or =E2=80=9Cwe cannot get the major browser = players to adopt our >>> approach because OpenSSL does not implement the feature.=E2=80=9D >>>=20 >>> Rather, given all this code is being written *today*, there is >>> absolutely no reason to hobble STIR before it launches. >>>=20 >>>> On Nov 4, 2016, at 11:29 AM, Chris Wendt >>>> wrote: >>>>=20 >>>> Hi Stephen, >>>>=20 >>>> As Jon mentioned, we can=E2=80=99t claim to have spent time on = this, but >>>> I did look at over the past two days and discussed it with some >>>> of the relevant security folks and I think this would be our >>>> position: >>>>=20 >>>> The main concern around not using deterministic ECDSA is that you >>>> =E2=80=9Cmay=E2=80=9D have bad random number generators as an input = K, and >>>> therefore may have some way of looking at patterns and finding >>>> exploits perhaps for a given signature. >>>>=20 >>>> I did a brief survey of popular packages used as part of popular >>>> server side languages, golang, java, python, and only found a >>>> single mention of python package last updated in early 2015 >>>> implementing RFC6979/deterministic ECDSA. >>>>=20 >>>> Given the availability of solid implementations of RFC6979, I >>>> would say we have a big hurdle here to getting acceptance and >>>> usage of STIR/passport by implementation providers, and i would >>>> have a personal concern that we may force folks to use less >>>> tested and less accepted implementations of ECDSA and therefore >>>> potentially reduce security from a completely different angle. >>>>=20 >>>> For the initial deployment of STIR, most implementations are >>>> going to be server side in any case where there is less concern >>>> about bad random number generation. So i think we are covered >>>> until and unless deterministic ECDSA becomes more widely adopted. >>>> For the point when smart phones may start doing STIR signatures, >>>> perhaps because they are becoming as powerful as PCs, their >>>> random generators if they don=E2=80=99t already (i suspect) will = provide >>>> acceptable security in the signatures as well. >>>>=20 >>>> One thing i could do in the passport document is have an >>>> informative note to talk about this concern and if you are >>>> implementing passport signatures on devices without proper random >>>> number generation capabilities you may want to consider >>>> implementing RFC6979. Signatures that are produced by normal >>>> ECDSA and deterministic ECDSA are compatible so there shouldn=E2=80=99= t >>>> be any concern there. >>>>=20 >>>> Would that be acceptable? Or after the above discussion do you >>>> think that is necessary? >>>>=20 >>>> Thanks. >>>>=20 >>>> -Chris >>>>=20 >>>>=20 >>>>> On Nov 2, 2016, at 10:08 PM, Stephen Farrell >>>>> wrote: >>>>>=20 >>>>> Stephen Farrell has entered the following ballot position for=20 >>>>> draft-ietf-stir-passport-10: Discuss >>>>>=20 >>>>> When responding, please keep the subject line intact and reply >>>>> to all email addresses included in the To and CC lines. (Feel >>>>> free to cut this introductory paragraph, however.) >>>>>=20 >>>>>=20 >>>>> Please refer to >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for >>>>> more information about IESG DISCUSS and COMMENT positions. >>>>>=20 >>>>>=20 >>>>> The document, along with other ballot positions, can be found >>>>> here:=20 >>>>> https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>>=20 > DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 > Deterministic ECDSA (RFC6979) gets rid of a significant weakness >>>>> with ECDSA. IIRC when JOSE was done there was a feeling that >>>>> adding a MUST or SHOULD for that was tricky due to lack of >>>>> support in libraries. When we recently re-checked for COSE, the >>>>> answer was that today, it's ok to have that as a MUST or >>>>> SHOULD. (If some kind of FIPS-140 stuff precludes a MUST, then >>>>> a "SHOULD unless you're sad enough to be stuck having to pay >>>>> lip lipservice to FIPS-140" clause might be right. So the >>>>> DISCUSS point here is: given the real-world demonstrated >>>>> weakness inherent in the need for an RNG in ECDSA why didn't >>>>> the WG choose to at least RECOMMEND deterministic ECDSA? (Or >>>>> better, make it a MUST.) >>>>>=20 >>>>> If the answer is: "we thought about it [ref] and decided to not >>>>> require deterministic" then I'll clear. But even if the WG did >>>>> consider it a couple of years ago, the situation may have >>>>> changed so a quick re-think might be worthwhile. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ stir mailing >>>> list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir >>>=20 >>> _______________________________________________ stir mailing list=20 >>> stir@ietf.org https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ stir mailing list=20 >> stir@ietf.org = https://www.ietf.org/mailman/listinfo/stir = --Apple-Mail=_E90E07E6-B25C-41C6-BF2A-E6602045AB4B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99m good with that.

-Chris

On = Nov 4, 2016, at 6:45 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hiya,

On 04/11/16 19:18, Chris Wendt = wrote:
=E2=80=9Chobble=E2=80=9D is = a hugely inappropriate term.

Well, arguably so = is "hugely inappropriate" :-)

I'd agree though that hobble is a teeny bit = overstated.

I think Eric does = have a point though that STIR involves a chunk of
new code so the = problems aren't as bad as in other situations. I'd
also encourage the = WG to maybe look some more - as I said in the
case of COSE, = recent findings were that deterministic ECDSA was
available in most = crypto libraries now. That might not yet have
percolated up to = higher level libraries I guess (though last I
looked neither had = ECDSA, but it's been a while).

Nonetheless that doesn't stop you saying = something like:

"Signers SHOULD use = deterministic ECDSA if/when supported in their
development = environment for the reasons stated in [RFC6979]."

As you said, verifiers don't need to care = and I think the above
is also painless for those writing = signing code, but does give
better guidance.

Sound reasonable?

Cheers,
S.


I=E2=80=99m = not seeing any huge push to move to deterministic ECDSA although
to be frank i won=E2=80=99t claim to be in the middle of this = issue either.

Seems to me, if deterministic = ECDSA becomes the preferred/default
implementation, then = problem solved and we didn=E2=80=99t have to change
anything= because both are compatible with each other from a signature
validation point of view.


On Nov 4, 2016, at 2:58 = PM, Eric Burger
<eburger@standardstrack.com> wrote:

I would offer saying that the limited, but existing, = availability
of deterministic ECDSA is a barrier to = widespread adoption barriers
for STIR is a non-issue. We = are not talking about how to update 300
different = browser-OS-hardware combinations in the wild where 15%
are = running Mosaic on WindowsXP. We are talking about code that has
yet to be written. As such, there is no reason to effectively = say
=E2=80=9Cstrong security is not important if the = alternative is no
security=E2=80=9D or =E2=80=9Cwe cannot = get the major browser players to adopt our
approach = because OpenSSL does not implement the feature.=E2=80=9D
Rather, given all this code is being written *today*, there = is
absolutely no reason to hobble STIR before it = launches.

On Nov 4, 2016, at 11:29 AM, Chris Wendt
<chris-ietf@chriswendt.net> wrote:

Hi Stephen,

As Jon mentioned, we = can=E2=80=99t claim to have spent time on this, but
I did = look at over the past two days and discussed it with some
of= the relevant security folks and I think this would be our
position:

The main concern = around not using deterministic ECDSA is that you
=E2=80=9Cma= y=E2=80=9D have bad random number generators as an input K, and
therefore may have some way of looking at patterns and = finding
exploits perhaps for a given signature.

I did a brief survey of popular packages used = as part of popular
server side languages, golang, java, = python, and only found a
single mention of python package = last updated in early 2015
implementing = RFC6979/deterministic ECDSA.

Given the = availability of solid implementations of RFC6979, I
would = say we have a big hurdle here to getting acceptance and
usage of STIR/passport by implementation providers, and i = would
have a personal concern that we may force folks to = use less
tested and less accepted implementations of ECDSA = and therefore
potentially reduce security from a = completely different angle.

For the initial = deployment of STIR, most implementations are
going to be = server side in any case where there is less concern
about = bad random number generation.  So i think we are covered
until and unless deterministic ECDSA becomes more widely = adopted.
For the point when smart phones may start doing = STIR signatures,
perhaps because they are becoming as = powerful as PCs, their
random generators if they don=E2=80=99= t already (i suspect) will provide
acceptable security in = the signatures as well.

One thing i could = do in the passport document is have an
informative note to = talk about this concern and if you are
implementing = passport signatures on devices without proper random
number = generation capabilities you may want to consider
implementing RFC6979.  Signatures that are produced by = normal
ECDSA and deterministic ECDSA are compatible so = there shouldn=E2=80=99t
be any concern there.

Would that be acceptable?  Or after the = above discussion do you
think that is necessary?

Thanks.

-Chris


On Nov 2, 2016, at 10:08 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:

Stephen Farrell has entered the following ballot position = for 
draft-ietf-stir-passport-10: Discuss

When responding, please keep the subject line intact and = reply
to all email addresses included in the To and CC = lines. (Feel
free to cut this introductory paragraph, = however.)


Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html = for
more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found
here: 
https://datatracker.ietf.org/doc/draft-ietf-stir-passport/<= br class=3D"">


---------------------------------------------------------------= -------


DISCUSS:
---------------------------------------------------------------= -------




Deterministic ECDSA (RFC6979) gets rid of a = significant weakness
with ECDSA. IIRC when JOSE was done there was a feeling = that
adding a MUST or SHOULD for that was tricky due to = lack of
support in libraries. When we recently re-checked = for COSE, the
answer was that today, it's ok to have that = as a MUST or
SHOULD. (If some kind of FIPS-140 stuff = precludes a MUST, then
a "SHOULD unless you're sad enough = to be stuck having to pay
lip lipservice to FIPS-140" = clause might be right. So the
DISCUSS point here is: given = the real-world demonstrated
weakness inherent in the need = for an RNG in ECDSA why didn't
the WG choose to at least = RECOMMEND deterministic ECDSA? (Or
better, make it a = MUST.)

If the answer is: "we thought about = it [ref] and decided to not
require deterministic" then = I'll clear. But even if the WG did
consider it a couple of = years ago, the situation may have
changed so a quick = re-think might be worthwhile.





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

_______________________________________________ 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

= --Apple-Mail=_E90E07E6-B25C-41C6-BF2A-E6602045AB4B-- From nobody Tue Nov 8 10:52:59 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFFD129A49 for ; Tue, 8 Nov 2016 10:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.379 X-Spam-Level: X-Spam-Status: No, score=0.379 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ftm1ooc6_NZ0 for ; Tue, 8 Nov 2016 10:52:57 -0800 (PST) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 6FEF512945E for ; Tue, 8 Nov 2016 10:52:55 -0800 (PST) Received: (qmail 24311 invoked by uid 0); 8 Nov 2016 18:52:53 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy5.mail.unifiedlayer.com with SMTP; 8 Nov 2016 18:52:53 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id 5Wno1u0101MNPNq01WnrTr; Tue, 08 Nov 2016 11:47:52 -0700 X-Authority-Analysis: v=2.1 cv=PIacp5aC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=1oJP67jkp3AA:10 a=L24OOQBejmoA:10 a=ZZnuYtJkoWoA:10 a=VHBzDTT8AAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=4tmuiUaA-RUAQbjLGWgA:9 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=u8b4NlUyJ5YA:10 a=67vlWCJs8YzOJ7z0LNO8:22 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 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: To:From:Subject:Date; bh=pnFU8AkNOrqkBKtslsri+w/Muz8ab4paoQC7GsATx6A=; b=k6Y4 KhB/s2PeExIIgZUrSBsOrw0P2Xi+1fMhc7MFkJhwNwm5sftnGff3Oo/yErVcCgTg6deunFJGEQNlf Zc57L9hkAndaNQi6Hk9bNt1IACkeRHYv8jJC8m51zyAc9Yv; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:53243 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1c4BQz-0002z1-Sz for stir@ietf.org; Tue, 08 Nov 2016 11:47:50 -0700 User-Agent: Microsoft-MacOutlook/f.1b.0.161010 Date: Tue, 08 Nov 2016 13:47:47 -0500 From: Richard Shockey To: "stir@ietf.org" Message-ID: <64F0081C-6FCC-4F2D-840F-D09AB3AE2B16@shockey.us> Thread-Topic: FYI ... news from Canada. Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1c4BQz-0002z1-Sz X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:53243 X-Source-Auth: richard+shockey.us X-Email-Count: 5 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [stir] FYI ... news from Canada. X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 18:52:58 -0000 CRTC orders telecoms to start blocking =E2=80=98blatantly illegitimate=E2=80=99 spam ca= lls forms its own strike force =20 http://business.financialpost.com/fp-tech-desk/canadian-telecoms-told-by-cr= tc-they-must-start-blocking-spam-calls-within-90-days?__lsa=3D553e-ac03 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 From nobody Fri Nov 11 22:46:45 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F1E1299A2 for ; Fri, 11 Nov 2016 22:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6fWndYJ62BP for ; Fri, 11 Nov 2016 22:46:42 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3951A129608 for ; Fri, 11 Nov 2016 22:46:42 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id i145so31098199ywg.2 for ; Fri, 11 Nov 2016 22:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=uJF8mMiJNzPgseHcLo10JyLrfhgSK73AfEw8XhHc+V0=; b=0WriwTcihdJ6p3AfzBv5yXmPhhhjZyBY5oF6YR1pJ0kjsco4Ozo2hvu6cyno/qf7TJ mvUkRZFndOOLS0ctiXhKdfAqp9CPwmPHhLJsdVz6cA8b6uUh/JdeqkGossz5YXMFjtRy pc6rdXjosAx7CLUESvLr+8pUM1NahWjAbJjej0Db1QoNq4e1H+qRoHWcqDx+TNe12iPT 6wfbOmrHEaGOPT9L7J0MWbJX40o2hSUrjLV+7v5C57+VJ/ADPCM5guR2JJ6qzK86xHi7 itEH9pQ7M5Av7AKqFwVOvSN3Ie6q5SppIT1PoYy6SeOomT3FCsQ9HHmh15PjOq+9xk5p PdFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uJF8mMiJNzPgseHcLo10JyLrfhgSK73AfEw8XhHc+V0=; b=BuSYDZffM0s0vJUs0HsBAasdwNYQJ0Do8Wr5BEDs8oYqktuK9OUGf9cOikr7eYn4Hp 7ArvNPFspskWqciMwkUSCaP+dEIIX3BulJna+BU3T29qDMt0aRXT3URLCyT2KeudRfdi cP9Qsv7fSQumVYRbKOmPH6Xp5OKm4gS1RT47mncLQGUo/8U2D8EpFnvgxvLla/BjDlyO 72ChTMvUqMxd3LYarRZbCvVBGYb4N3wmp2C6Cp/7nn+skCHYHwTzxubXaTaTh5mZ/gsd F7gf7LMJ0OgrdHfhXQLnz1skMT3mr5jJV05X46maHmtG6o9HefhhDgfuRUnplVU2H5Og MsgQ== X-Gm-Message-State: ABUngvcIKiS6wWtCK3JjNAQHwRdujZ87HSVYlvgheYEh9D+iWEHIRYxZDgFftE9YFi7iHTFYawwt0YSgoJw3nQ== X-Received: by 10.129.53.194 with SMTP id c185mr6265658ywa.205.1478933201400; Fri, 11 Nov 2016 22:46:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Fri, 11 Nov 2016 22:46:00 -0800 (PST) From: Eric Rescorla Date: Fri, 11 Nov 2016 22:46:00 -0800 Message-ID: To: "stir@ietf.org" Content-Type: multipart/alternative; boundary=001a114214781dea99054114f899 Archived-At: Subject: [stir] Comments on draft-peterson-acme-telephone-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 06:46:44 -0000 --001a114214781dea99054114f899 Content-Type: text/plain; charset=UTF-8 SUBSTANTIVE Should "tn" be "tel"? This URL is intended to be opened in a web browser so that the user can have an interaction with the CA; it is not sufficient for the client to simply send a GET request to the URL. I don't understand what this text means. How does it interact with automatic validation? This text about exactly what the semantics of the SMS validation are should take into account the points raised by Karthik Bhargavan at: https://www.ietf.org/mail-archive/web/acme/current/msg00996.html EDITORIAL Abstract: telephonoe -> telephone --001a114214781dea99054114f899 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
SUBSTANTIVE
Should "tn" be "= tel"?

=C2=A0 =C2=A0This URL is intended to
=C2=A0 =C2=A0be opened in a web browser so that the user can have a= n interaction
=C2=A0 =C2=A0with the CA; it is not sufficient for = the client to simply send a GET
=C2=A0 =C2=A0request to the URL.<= /div>

I don't understand what this text means. How d= oes it interact with
automatic validation?


This text about exactly what the semantics of the SMS val= idation are
should take into account the points raised by Karthik= Bhargavan at:


<= br>
EDITORIAL
Abstract:
=C2=A0 telephonoe -&g= t; telephone

--001a114214781dea99054114f899-- From nobody Sun Nov 13 03:03:34 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A861296F9; Sun, 13 Nov 2016 03:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeA9YkYthWMr; Sun, 13 Nov 2016 03:03:26 -0800 (PST) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D26E91296EA; Sun, 13 Nov 2016 03:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hHpz9aiUgCXitNkzHFCQ8/BafAPTumNscEBC2VeZ0hA=; b=ARLq2ow0Fx59rl3IWT0l/LWhphv5pxOv7mpEwFqdztHp7bH86b1aRlWKc62PIgG5IafexeFmt5RSWGaVHqnPKQjA4MHWM0VMyLkCYfa1YnLi8LPbPXoann/vITmmuMr3O7pcJuHnfiG2vYXp/MCNZLrAHiLcWHQseRlToG7Culk= From: Henning Schulzrinne To: Alex Bobotek , "stir@ietf.org" , "dispatch@ietf.org" Thread-Topic: FYI only: Two new VoIP spam drafts Thread-Index: AQHSG4AHdXDxA/hrj06MJ4pEMbL5u6CUpQ4ggEJcrr4= Date: Sun, 13 Nov 2016 11:03:21 +0000 Message-ID: References: , <4B1956260CD29F4A9622F00322FE053101290E491F5A@BOBO1A.bobotek.net> In-Reply-To: <4B1956260CD29F4A9622F00322FE053101290E491F5A@BOBO1A.bobotek.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 7:z77W+e6iNZeeL3JX2GfapjbVDDlM36veCFILWuQ6Qs7RImi0zaRRLXCx5XvU02iRmUg6bvmcqCQDN1PBwcCxCCWs1bb6dpXqrWQRbM3clz6whlHPySkvYDrY8gxvlyuEbPkXJJ42nvy/ZCAhrMdKY6hpeufNrCk0FwzjWtUyK2VlnFKGHlO7EsZvzCn6P7HP/AMB0PzSrVANjiSpqn5WSZsr7OHl6MOHRyazntdV1hWumi+EeZ9uMicpkC4m062AH43q6vTCAZ9TuLKqrjxJ/Q3phThT9Ow8ANWA4lNW768DAXfOQb579AxO7m8eG1jaFOM/i19r9PejTr1ziaUrEre2qZ4KhDoRZpJYj6vbBQg= x-ms-office365-filtering-correlation-id: eaefbbd3-7ceb-4110-fdd4-08d40bb4ae76 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0635; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(231250463719595); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 012570D5A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(336003)(377454003)(189002)(69234005)(199003)(92566002)(33656002)(8676002)(77096005)(229853002)(2501003)(19627405001)(66066001)(15187005004)(2201001)(50986999)(76176999)(2900100001)(8936002)(54356999)(7696004)(86362001)(2950100002)(76576001)(101416001)(81156014)(81166006)(10126002)(107886002)(6606003)(87936001)(586003)(105586002)(106356001)(99286002)(5001770100001)(106116001)(74316002)(189998001)(6116002)(2906002)(3846002)(68736007)(102836003)(7846002)(9686002)(5660300001)(122556002)(7906003)(3660700001)(7736002)(97736004)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634FC71E04DE7796429FB25EABD0CY1PR09MB0634namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2016 11:03:21.3163 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-OriginatorOrg: fcc.gov Archived-At: Subject: Re: [stir] FYI only: Two new VoIP spam drafts X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 11:03:29 -0000 --_000_CY1PR09MB0634FC71E04DE7796429FB25EABD0CY1PR09MB0634namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Catching up on comments. Please see inline. ________________________________ From: stir on behalf of Alex Bobotek Sent: Sunday, October 2, 2016 2:01:50 AM To: Henning Schulzrinne; stir@ietf.org Subject: Re: [stir] FYI only: Two new VoIP spam drafts It=92s good to see the docs. I=92m very pleased to see the facilitation of= end-user feedback, information crucial to abuse mitigation. Comments on draft-schulzrinne-dispatch-status-unwanted: 1. The status code could, conceivably, be returned by automata or by = human-triggered action (e.g., user click on the =91report spam=92 button). = Consider whether the status code could reflect action by someone or someth= ing other than the typically-human called party and at points before the te= rminating device. IMHO, it should permit such indications from automata as= well as human-initiated actions. >> Definitely both. 2. The recommendation that the response code not be used in creating = call filters unless the call has been authenticated via 4474bis is too stro= ng. There are many cases where I want such non-authenticated information t= o be used to filter my calls. Just about everybody using the more popular = call blocking solutions available today benefit from blacklisting based on = feedback of unauthenticated caller IDs, and this practice should not be ter= minated capriciously. Additionally, 4474bis is only one of many methods of= auth and may instead be more of a statement of service provider originati= on than of calling address authority or authentication. I suggest toning t= his down to a statement that the possibility of spoofing or unauthorized us= e should be taken into consideration in constructing call filters. >> Good point. 3. The draft should include normative text that specifies when a SIP = entity MAY/SHOULD/SHALL return the status code. It only specifies what a r= ecipient of the code MAY do. For example, add to section 4: =93A SIP entity MAY reply to a SIP request with the =91Unwanted=92 response= code if there is a user-initiated or other indication that the request is = unwanted. =93 >> I'm not sure how to write this. I don't see a SHOULD/MUST here since the= UAS would never have to return this at all, even if it is spam. 4. Consider allowing SIP entities handling the response to substitute= a different code in any forwarded responses. A called party may not wish = to convey rejection as unwanted all the way back to the calling party. I d= on=92t know the right answer, and I hope others=92 opinions will be express= ed. There are times when a message instructing a caller to =91place me on = your organization=92s DNC=92 is desired, and times when a more silent appro= ach is preferred. >> With SBCs, this is common, so I see no harm. 5. The introductory paragraph discusses the need to express that a ca= ll is unwanted. Section 3 discusses the need to indicate that a caller=92s= calls are unwanted. These are different assertions. The most basic asse= rtion is =91this call is unwanted=92. Perhaps an additional =91no calls fr= om that address are wanted=92 assertion should also be supported. >> I'm not sure how expressing displeasure only about the call itself is he= lpful. The typical call spam button also doesn't just drop the message into= the spam folder (unless it's a stand-alone client); it flags the message s= ender, typically, for enhanced scrutiny. Regards, Alex From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Friday, September 30, 2016 6:08 PM To: stir@ietf.org Subject: [stir] FYI only: Two new VoIP spam drafts [Please address comments to the DISPATCH list; this copy is FYI only since = I forgot to bcc the list.] In collaboration with members of the Robocall Strike Force (https://www.fcc= .gov/news-events/events/2016/08/first-meeting-industry-led-robocall-strike-= force), I have submitted two I-D's: https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-status-unwanted= / https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-callinfo-spam/ that fill in operational needs for dealing with SIP spam. The first defines= a new status code (666) that users can use to mark unwanted calls, either = as a response code to an INVITE or in a Reason header in a BYE response. (T= his will likely be supplemented in practice by API-based mechanisms for pos= t-call spam reports.) The second defines a set of Call-Info parameters that allow the carrier or = other UE-trusted SIP entity in the path to indicate the spam probability, t= ype of call and other related information that will allow the UE and user t= o make better call handling decisions. This complements the 'verstat' work being submitted to 3GPP (by others), fo= r indicating the level of trust in the From/PAI tel URI. Henning --_000_CY1PR09MB0634FC71E04DE7796429FB25EABD0CY1PR09MB0634namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Catching up on comments. Please see inline.

From: stir <stir-bounces= @ietf.org> on behalf of Alex Bobotek <alex@bobotek.net>
Sent: Sunday, October 2, 2016 2:01:50 AM
To: Henning Schulzrinne; stir@ietf.org
Subject: Re: [stir] FYI only: Two new VoIP spam drafts
 

It=92s good to see the docs.  I=92m very pleased to see= the facilitation of end-user feedback, information crucial to abuse mitiga= tion. 

 

Comments on draft-schulzrinne-dispatch-status-unwanted:

 

1.       The status code could, co= nceivably, be returned by automata or by human-triggered action (e.g., user= click on the =91report spam=92 button).  Consider whether the status code could reflect action by someone or something other= than the typically-human called party and at points before the terminating= device.  IMHO, it should permit such indications from automata as wel= l as human-initiated actions.


>> Definitely both.=


2.       The recommendation that t= he response code not be used in creating call filters unless the call has b= een authenticated via 4474bis is too strong.  There are many cases where I want such non-authenticated information to be= used to filter my calls.  Just about everybody using the more popular= call blocking solutions available today benefit from blacklisting based on= feedback of unauthenticated caller IDs, and this practice should not be terminated capriciously.  Additionall= y, 4474bis is only one of many methods of auth and may instead be more of&n= bsp; a statement of service provider origination than of calling address au= thority or authentication.  I suggest toning this down to a statement that the possibility of spoofing or unauthorized = use should be taken into consideration in constructing call filters. 


>> Good point.


3.       The draft should include = normative text that specifies when a SIP entity MAY/SHOULD/SHALL return the= status code.  It only specifies what a recipient of the code MAY do.  For example, add to section 4:=

=93A SIP entity MAY reply to a SIP request with the =91Unwan= ted=92 response code if there is a user-initiated or other indication that = the request is unwanted. =93


>> I'm not sure how to w= rite this. I don't see a SHOULD/MUST here since the UAS would never have to= return this at all, even if it is spam.


4.       Consider allowing SIP ent= ities handling the response to substitute a different code in any forwarded= responses.  A called party may not wish to convey rejection as unwanted all the way back to the calling party.  = I don=92t know the right answer, and I hope others=92 opinions will be expr= essed.  There are times when a message instructing a caller to =91plac= e me on your organization=92s DNC=92 is desired, and times when a more silent approach is preferred.


>> With SBCs, this is common, so I see no= harm.



5.       The introductory paragrap= h discusses the need to express that a call is unwanted.  Section 3 di= scusses the need to indicate that a caller=92s calls are unwanted.   These are different assertions.  The most b= asic assertion is =91this call is unwanted=92.  Perhaps an additional = =91no calls from that address are wanted=92 assertion should also be suppor= ted. 


>> I'm not sure how expr= essing displeasure only about the call itself is helpful. The typical = call spam button also doesn't just drop the message into the spam folder (u= nless it's a stand-alone client); it flags the message sender, typically, for enhanced scrutiny.

 

 

Regards,

 

Alex

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Friday, September 30, 2016 6:08 PM
To: stir@ietf.org
Subject: [stir] FYI only: Two new VoIP spam drafts=

 

[= Please address comments to the DISPATCH list; this copy is FYI only since I= forgot to bcc the list.]

<= o:p> 

I= n collaboration with members of the Robocall Strike Force (https://www.fcc.gov/n= ews-events/events/2016/08/first-meeting-industry-led-robocall-strike-force<= /a>), I have submitted two I-D's:

<= o:p> 

<= a href=3D"https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-statu= s-unwanted/" target=3D"_blank" id=3D"LPlnk889361" style=3D"color: blue; tex= t-decoration: underline;" previewremoved=3D"true">https://datatracker.ietf.= org/doc/draft-schulzrinne-dispatch-status-unwanted/

<= a href=3D"https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-calli= nfo-spam/" target=3D"_blank" id=3D"LPlnk520780" style=3D"color: blue; text-= decoration: underline;" previewremoved=3D"true">https://datatracker.ietf.or= g/doc/draft-schulzrinne-dispatch-callinfo-spam/

<= o:p> 

t= hat fill in operational needs for dealing with SIP spam. The first defines = a new status code (666) that users can use to mark unwanted calls, either a= s a response code to an INVITE or in a Reason header in a BYE response. (This will likely be supplemented in practice by= API-based mechanisms for post-call spam reports.)

<= o:p> 

T= he second defines a set of Call-Info parameters that allow the carrier or o= ther UE-trusted SIP entity in the path to indicate the spam probability, ty= pe of call and other related information that will allow the UE and user to make better call handling decisions.

<= o:p> 

T= his complements the 'verstat' work being submitted to 3GPP (by others), for= indicating the level of trust in the From/PAI tel URI.

<= o:p> 

H= enning

 

--_000_CY1PR09MB0634FC71E04DE7796429FB25EABD0CY1PR09MB0634namp_-- From nobody Wed Nov 16 11:31:55 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A278912946D for ; Wed, 16 Nov 2016 11:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mt0eXOX0INq for ; Wed, 16 Nov 2016 11:31:52 -0800 (PST) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 3CD06129424 for ; Wed, 16 Nov 2016 11:31:52 -0800 (PST) Received: (qmail 24658 invoked by uid 0); 16 Nov 2016 19:31:47 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy2.mail.unifiedlayer.com with SMTP; 16 Nov 2016 19:31:47 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id 8jSk1u00B1MNPNq01jSn6L; Wed, 16 Nov 2016 12:26:47 -0700 X-Authority-Analysis: v=2.1 cv=K/+xQUmI c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=1oJP67jkp3AA:10 a=L24OOQBejmoA:10 a=ZZnuYtJkoWoA:10 a=HeG67adPAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=TeSDtN6pJ1xeBbo3YtcA:9 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=j_WYdJOcG9UA:10 a=jlXKPczUY4Vio7-9iMRd:22 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 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: To:From:Subject:Date; bh=9XSwP1HN0AoB89vJToit1cny5ZLBBRwKHhbL0T9oSPg=; b=jSOy noumhtjrUol3+EW6QDlr3w2SiauuLshzcP6Crnaao2Ucv9y1Z2mWAYzy32wWbji1jJvLBKJ3szW/3 U4y3JyDdYZJQb9ejyQTjUpyEcIpMwwHjQaatNRQmVAn7eSn; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:59059 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1c75r1-0007aQ-Px for stir@ietf.org; Wed, 16 Nov 2016 12:26:44 -0700 User-Agent: Microsoft-MacOutlook/f.1c.0.161115 Date: Wed, 16 Nov 2016 14:26:41 -0500 From: Richard Shockey To: "stir@ietf.org" Message-ID: <1E2CE99D-33FA-4EF0-BA57-7A2CF856F07F@shockey.us> Thread-Topic: FYI .. NICC Conference Presentations Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1c75r1-0007aQ-Px X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:59059 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [stir] FYI .. NICC Conference Presentations X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 19:31:54 -0000 While some of you are still nursing jet lag. I did my shopping at the Scotc= h Store in Terminal 2 at Heathrow. Of note is Huw Saunders Dir Network OFCOM and my presentations. =20 http://www.niccstandards.org.uk/meetings/forum-2016.cfm =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 From nobody Wed Nov 16 17:15:05 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24750129604 for ; Wed, 16 Nov 2016 17:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2xKw8O4CfXu for ; Wed, 16 Nov 2016 17:15:00 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CAB81295FB for ; Wed, 16 Nov 2016 17:14:53 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id q130so199656608qke.1 for ; Wed, 16 Nov 2016 17:14:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=yb5bGdAWEGLDPptGL/pofXIrRQxifhXBH6gwtOvsXfc=; b=qBNPFWV172ZU5yYIwnqBXjsb91TSzSx5TzGKAOA2cRO7JZGGYt1uy9/iuQOFw1TGea C48nk9EdMTb4plhQROgZIo0tEhUZxiFn98nV7yjlnEq3tBgI6rV7fNYwtBFidgh2xQrB 9Wzdsr8zmxAXyh8OiiBssGDyBtzv/Lin3TipyAIBlFZv62Ugauexk/J8WvLg21cjriJp PVZ09Rgd05qrWf4GdyTTBh+Yx48sVDZGzlCR3sTH5ZpbrWqwNPpDbGLsIjxcvmg0D82N G+5plikxXJyJFJWBS7EJTRG751roYoJKLic4HXS40sJSK05MjjkAgqN6NDzwgw1YwDFg 1fBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=yb5bGdAWEGLDPptGL/pofXIrRQxifhXBH6gwtOvsXfc=; b=HNsQLG6gjFdAyJn6/8jWQMbTaPNRCbbB7vS4Pgo6a1no4e2H0vzVHbVFlpx9v3gjXR kdkhHkruNj/HnivNxPx11tv1WZcinelAkeQPXC588IzborjpV2teH17DtLBpbZG5HGBh z2HiiBZ3ZE12vzkA+aOwDFwNdx4L5pRYB52UXR5OFp+ZXo2k5N/PDe38kxpu8MwFSSfr wTi/mCUBh8kMeWlBoovTKzHhMM2EGVrUIT0hdxfMQf6ZPXABxEjtyGFDSjeJr2wEgYlP 1fbJ/TYP32vp5Yg7TumPAbhL0x07/+tJtI+4LmaY4/8IeL4rsJvtwhxeDSBtoJo5IXrZ 3k5A== X-Gm-Message-State: AKaTC03OtCJg1W3lbkkgcH94EIJa5hb8X/9xD/Hpx74D1yb0yPa1g7l4YG0kZ7e3d+iQWQ== X-Received: by 10.55.66.67 with SMTP id p64mr614768qka.11.1479345291851; Wed, 16 Nov 2016 17:14:51 -0800 (PST) Received: from [10.96.8.226] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id a141sm269601qkg.49.2016.11.16.17.14.50 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Nov 2016 17:14:50 -0800 (PST) From: Brian Rosen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 17 Nov 2016 10:14:46 +0900 To: IETF STIR Mail List Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [stir] SHAKEN but not STIRred means 666 can cause collateral damage X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 01:15:02 -0000 I=E2=80=99ve sent this to stir, even though it has not been decided = where the 666 draft will land, and SHAKEN is not even in the IETF. The original idea of stir is that the credential used to sign is granted = as a result of delegation of the telephone number. When used as = envisioned, a valid signature will (mostly) guarantee that the calling = party number has not been spoofed. If we then implement 666, which is a = mechanism to create a black list, then numbers reported as spam come = from the actual TN they were placed with, or the signature wouldn=E2=80=99= t be valid and we get what we want. SHAKEN doesn=E2=80=99t do that. It doesn=E2=80=99t check the TN, it = only states that the service provider who signed it is willing to say = something about the call. It has a very desirable capability to lead = authorities to the source of spoofed calls. It will very clearly help = us cut down on spoofed calls. However, when used with 666, SHAKEN has the problem that spoofing is = still allowed - it=E2=80=99s just that we can better trace it to its = source. But if a user reports SPAM with a SHAKEN signed claim, the = spoofed TN is marked as a spam source. That means the legitimate owner = of the TN may have trouble placing calls. 666 creates collateral = damage. Brian= From nobody Wed Nov 16 17:34:34 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D29B1295FB for ; Wed, 16 Nov 2016 17:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlIeJjuuC2QH for ; Wed, 16 Nov 2016 17:34:32 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C081296E3 for ; Wed, 16 Nov 2016 17:34:24 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id q130so200118659qke.1 for ; Wed, 16 Nov 2016 17:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=RlxjXhkLxU2LWXBhDHf4olmtkv9kqhzq6i+WTuReNEs=; b=h9sxkebhyDQ5QSa8ImPNbH/JKJ/HEkTcfKc+gGwLOepoLvcIJF4Hng0skdKYVuVB2S b8CfZfJ1BDXtJGIuwxVHEfyEoPDKjpw0t/+a80QW1XmpIPhru/11Y0W/Fg/oDCGrS7i+ XwqYBH/AOIa5tpx0QB2+REExqoEOGKGfkcDIFQdMkdJ8+DsFcU9R9Tu5Wzcht+5/n92l /eUo6PVhbEeQYxr5SU6FKjV7mIwH5Lzw80LtsO1EshAOlNK/oHR9dWM2/+A33B5SuerG osdqVV+hZNwCX68kwW6dDss1TG1YgwxfN8GWfA4Kp51JzMUAXndfODTq0PZuaPsxWH6j SLFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=RlxjXhkLxU2LWXBhDHf4olmtkv9kqhzq6i+WTuReNEs=; b=aJpFvwsufrk3BCCPnY7QxU8htPKAA8/z+xrJLZBPIjWWplkjrMnfe2k7WRoR3Dgg/T miqkKD3M73zvQTR3vJ4nbufEpoyUe7aJNAszdCjbkU/pUqqgUWcQO3NcyjG0l4T8YIdr CGQMuCysdp1rp7OlqfT4yCMaqoxjZh+toWtRjP6O4vRUfMLjMqr4mhp68R0kGNhlPuH6 KHg+546c2Yszs+EIcWdrlZ9okXGTnPvUvnPFYSKz2pJ2QqRtPij2qXfEs3dbV4L+20Lb bRPvhA8SDwOoVyL8kqv3TOFM0I6Rt8WETPsyv6eAz5uZ/nxgPZLv9qFbYiFFMiiu6tm4 WIEw== X-Gm-Message-State: AKaTC03ht3Cdpvoo7K6fQNQGnMJPmqQAskFCJ2Mgk9lMI8A2dLUBAW3DMbjz2cEf+b0SvA== X-Received: by 10.55.134.1 with SMTP id i1mr607089qkd.219.1479346463160; Wed, 16 Nov 2016 17:34:23 -0800 (PST) Received: from [10.96.8.226] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id z7sm341610qkz.7.2016.11.16.17.34.21 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Nov 2016 17:34:21 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Thu, 17 Nov 2016 10:34:17 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: IETF STIR Mail List X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [stir] SHAKEN but not STIRred means 666 can cause collateral damage X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 01:34:33 -0000 Ah, I have over-reached. SHAKEN has a number of possible claims. The = =E2=80=9Chighest=E2=80=9D of those is roughly equivalent to what = original stir proposed to do. The net effect should be that 666 on that = claim should not cause damage. On the =E2=80=9Clesser=E2=80=9D claims, = it could. Brian > On Nov 17, 2016, at 10:14 AM, Brian Rosen wrote: >=20 > I=E2=80=99ve sent this to stir, even though it has not been decided = where the 666 draft will land, and SHAKEN is not even in the IETF. >=20 > The original idea of stir is that the credential used to sign is = granted as a result of delegation of the telephone number. When used as = envisioned, a valid signature will (mostly) guarantee that the calling = party number has not been spoofed. If we then implement 666, which is a = mechanism to create a black list, then numbers reported as spam come = from the actual TN they were placed with, or the signature wouldn=E2=80=99= t be valid and we get what we want. >=20 > SHAKEN doesn=E2=80=99t do that. It doesn=E2=80=99t check the TN, it = only states that the service provider who signed it is willing to say = something about the call. It has a very desirable capability to lead = authorities to the source of spoofed calls. It will very clearly help = us cut down on spoofed calls. >=20 > However, when used with 666, SHAKEN has the problem that spoofing is = still allowed - it=E2=80=99s just that we can better trace it to its = source. But if a user reports SPAM with a SHAKEN signed claim, the = spoofed TN is marked as a spam source. That means the legitimate owner = of the TN may have trouble placing calls. 666 creates collateral = damage. >=20 > Brian From nobody Wed Nov 16 23:59:24 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E961295C2 for ; Wed, 16 Nov 2016 23:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zq6KfWITvSql for ; Wed, 16 Nov 2016 23:59:21 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD69D12948C for ; Wed, 16 Nov 2016 23:59:21 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id i88so47985297pfk.2 for ; Wed, 16 Nov 2016 23:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uoETb9Jlg9ooUDAWJO7AiSP6sANeAQuJplt9MzlV72c=; b=ie8j7qbMZdu2BZiqS0aqi6UlZaspa6xIuBENPup02FrJZU4YVdiWsw5egk75zthgHd MaHaDUkNm+Ez+LAn4/W3S2AaowuCctkF18JAf4cqXYaP50/0+oW0Q/L9xoCmV4Fq5Ric InGObrw/I7tszmioZyMn7qdLzCMqghUGbNu8yn0FcvyEPioSgK51X0b7N9BC8GkuBqwn m9OW+/hVElhZ1MBXsj3s2848peTo1d+eUUMGkwCON+evWM009Nl5LnDYmOLyRP0zhVc2 No4vd3SC13VwJIL6xTjJWvWxLOyeVFeh6iTRTDs7MaONCv/aMDGyoT5Vs9LK3Wt0tNTR B7Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uoETb9Jlg9ooUDAWJO7AiSP6sANeAQuJplt9MzlV72c=; b=EZK7kEutF466ObwmdR8MqesAlj3PzreSiQhTGOs3gf26hruaC/ByiruxnT+8jip2Sy uoM5nU+MqZExlVZGXyHgzFVzGHQfIdGpIODF5yX4f94CIQXeMoZq6iUcEcXbbM/+wSAk M41i739KBeXoBzDhO+2rtcNhumb6bP+GlIKXW4L1XOVxVwh/KtHjhMJIzqBXpFou0BZH Zvj+pa9ULIRAWvu4qTvaBuog/jC5MNdDi3B0+JfRTBxj8GRqBmNw6T9U8qnAtWIS+WC5 8OLxzPhIAZd/P8Fk7uID6Tspi+qGeCUbtaTjyow7kG/7PNtsT34gC0Hz09uaIRy6YCzK jlCg== X-Gm-Message-State: ABUngvfltT0Pza8bM05IaYLsaPyWTEqDufVKBzj5HIAnPstuwILFMkYGAJoK/uyGPT0tiA== X-Received: by 10.99.149.22 with SMTP id p22mr4816530pgd.21.1479369561283; Wed, 16 Nov 2016 23:59:21 -0800 (PST) Received: from [192.168.100.101] (dhcp-95f7.meeting.ietf.org. [31.133.149.247]) by smtp.gmail.com with ESMTPSA id g82sm4032340pfb.43.2016.11.16.23.59.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 23:59:20 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Chris Wendt In-Reply-To: Date: Thu, 17 Nov 2016 16:59:17 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <602FDF00-0C34-4D4E-A163-21E9BF4B011D@chriswendt.net> References: To: Brian Rosen X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] SHAKEN but not STIRred means 666 can cause collateral damage X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 07:59:23 -0000 Hi Brian, With 666, other than in the case of as an input into analytics systems, = I don=E2=80=99t believe SHAKEN=E2=80=99s attestations are related, i = don=E2=80=99t believe STIR signatures are related either, at least not = directly. My understanding, the intent is a user sends back a 666 to provider and = says she believes there is some illegitimate or there is just an = unwanted call going on, independent of whether the call was verified or = not by STIR or SHAKEN at any attestation level. The thing would be how the 666 is interpreted by the provider with or = without any signature, with the implication that without a signature or = with different levels of SHAKEN attestation, service providers must = understand that the number may have been spoofed and where the call came = from may not be easily traceable. Similarly, as discussed, providers = should take into account whether the call was answered or not to = determine how =E2=80=9Creal=E2=80=9D the 666 response was toward any = user-specific filtering or influencing any more global call analytics. = This is the fuzzy reality we are in for a while, until every call is = VoIP and is signed end-to-end and what SHAKEN is trying to address in a = =E2=80=9Cbest we can do=E2=80=9D way until that becomes the case given = the realities of a mixed VoIP/SS7 telephone system and an environment = where spoofing of any number is an allowed practice. In addition, the system in general should assume that humans are not = perfect and may either mistakenly, or just for vengeance on their = ex-boyfriend, or whatever reason send 666 back. The application level = handling of 666 needs to account for or potentially have a way to reset = this on a per customer basis. More globally, from an analytics or = aggregation of complaints point of view, if you were to shut-down a = number more globally based on a single 666, i don=E2=80=99t think you = are implementing things correctly. I don=E2=80=99t believe there is any intent to fully dictate the = application behavior here rather than provide a tool for end users to = inject a response code feedback about a call, anything beyond that, from = a real-world implementation point of view will have some art in getting = things right particularly in the next many years. -Chris > On Nov 17, 2016, at 10:34 AM, Brian Rosen wrote: >=20 > Ah, I have over-reached. SHAKEN has a number of possible claims. The = =E2=80=9Chighest=E2=80=9D of those is roughly equivalent to what = original stir proposed to do. The net effect should be that 666 on that = claim should not cause damage. On the =E2=80=9Clesser=E2=80=9D claims, = it could. >=20 > Brian >=20 >> On Nov 17, 2016, at 10:14 AM, Brian Rosen wrote: >>=20 >> I=E2=80=99ve sent this to stir, even though it has not been decided = where the 666 draft will land, and SHAKEN is not even in the IETF. >>=20 >> The original idea of stir is that the credential used to sign is = granted as a result of delegation of the telephone number. When used as = envisioned, a valid signature will (mostly) guarantee that the calling = party number has not been spoofed. If we then implement 666, which is a = mechanism to create a black list, then numbers reported as spam come = from the actual TN they were placed with, or the signature wouldn=E2=80=99= t be valid and we get what we want. >>=20 >> SHAKEN doesn=E2=80=99t do that. It doesn=E2=80=99t check the TN, it = only states that the service provider who signed it is willing to say = something about the call. It has a very desirable capability to lead = authorities to the source of spoofed calls. It will very clearly help = us cut down on spoofed calls. >>=20 >> However, when used with 666, SHAKEN has the problem that spoofing is = still allowed - it=E2=80=99s just that we can better trace it to its = source. But if a user reports SPAM with a SHAKEN signed claim, the = spoofed TN is marked as a spam source. That means the legitimate owner = of the TN may have trouble placing calls. 666 creates collateral = damage. >>=20 >> Brian >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Thu Nov 17 00:27:17 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D5C1296A2; Thu, 17 Nov 2016 00:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lM34JkTe-etA; Thu, 17 Nov 2016 00:27:06 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3D212941A; Thu, 17 Nov 2016 00:27:06 -0800 (PST) Received: from dhcp-978a.meeting.ietf.org (dhcp-978a.meeting.ietf.org [31.133.151.138]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAH8R2Z4048601 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 Nov 2016 02:27:04 -0600 (CST) (envelope-from adam@nostrum.com) To: Brian Rosen , IETF STIR Mail List References: From: Adam Roach Message-ID: Date: Thu, 17 Nov 2016 17:27:01 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "dispatch@ietf.org" , 'SIPCORE' Subject: [stir] Discussion venue for 666 (was SHAKEN but not STIRred means 666 can cause collateral damage) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: 'SIPCORE' List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 08:27:08 -0000 [as SIPCORE chair] On 11/17/16 10:14, Brian Rosen wrote: > I’ve sent this to stir, even though it has not been decided where the 666 draft will land My understanding coming out of DISPATCH is that 666 is appropriate for SIPCORE, assuming the new charter is approved by the IESG. I expect the proposed charter changes to be uncontroversial. Based on the foregoing, we (the SIPCORE chairs) think it would be appropriate to hold general discussion of both of the draft-schulzrinne-dispatch-callinfo-spam and draft-schulzrinne-dispatch-status-unwanted documents on the SIPCORE list. I've copied DISPATCH and SIPCORE on this message, and set followups to SIPCORE. /a From nobody Thu Nov 17 00:53:24 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337E81294F0; Thu, 17 Nov 2016 00:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DmcS5_GFdrG; Thu, 17 Nov 2016 00:53:21 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44FB1294C6; Thu, 17 Nov 2016 00:53:21 -0800 (PST) Received: from dhcp-9744.meeting.ietf.org (dhcp-9744.meeting.ietf.org [31.133.151.68]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAH8rJ59050982 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Thu, 17 Nov 2016 02:53:21 -0600 (CST) (envelope-from rjsparks@nostrum.com) References: To: stir@ietf.org, "sipcore@ietf.org" From: Robert Sparks X-Forwarded-Message-Id: Message-ID: <927fb975-f4e2-2021-f719-972d4f62cbde@nostrum.com> Date: Thu, 17 Nov 2016 17:53:19 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BE1EC0B521888C9EC1D72E8B" Archived-At: Subject: [stir] Fwd: Re: [dispatch] Discussion venue for 666 (was SHAKEN but not STIRred means 666 can cause collateral damage) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 08:53:23 -0000 This is a multi-part message in MIME format. --------------BE1EC0B521888C9EC1D72E8B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Reply-all betrayed me. Forwarding for completeness. Sorry for the extra noise. -------- Forwarded Message -------- Subject: Re: [dispatch] Discussion venue for 666 (was SHAKEN but not STIRred means 666 can cause collateral damage) Date: Thu, 17 Nov 2016 17:51:52 +0900 From: Robert Sparks To: dispatch@ietf.org [as a STIR co-chair] I agree with this. Later in the discussion, I expect we will recommend splitting the passport extension work out and running that through STIR, but that doesn't need to happen immediately. If we discover that there's frequent unnatural tension in needing to talk about stir things while figuring out the SIP mechanics in these drafts, we can revisit. RjS On 11/17/16 5:27 PM, Adam Roach wrote: > [as SIPCORE chair] > > On 11/17/16 10:14, Brian Rosen wrote: >> I’ve sent this to stir, even though it has not been decided where the >> 666 draft will land > > My understanding coming out of DISPATCH is that 666 is appropriate for > SIPCORE, assuming the new charter is approved by the IESG. I expect > the proposed charter changes to be uncontroversial. > > Based on the foregoing, we (the SIPCORE chairs) think it would be > appropriate to hold general discussion of both of the > draft-schulzrinne-dispatch-callinfo-spam and > draft-schulzrinne-dispatch-status-unwanted documents on the SIPCORE list. > > I've copied DISPATCH and SIPCORE on this message, and set followups to > SIPCORE. > > /a > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------BE1EC0B521888C9EC1D72E8B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Reply-all betrayed me. Forwarding for completeness.

Sorry for the extra noise.



-------- Forwarded Message --------
Subject: Re: [dispatch] Discussion venue for 666 (was SHAKEN but not STIRred means 666 can cause collateral damage)
Date: Thu, 17 Nov 2016 17:51:52 +0900
From: Robert Sparks <rjsparks@nostrum.com>
To: dispatch@ietf.org 


[as a STIR co-chair]

I agree with this.

Later in the discussion, I expect we will recommend splitting the 
passport extension work out and running that through STIR, but that 
doesn't need to happen immediately.

If we discover that there's frequent unnatural tension in needing to 
talk about stir things while figuring out the SIP mechanics in these 
drafts, we can revisit.

RjS


On 11/17/16 5:27 PM, Adam Roach wrote:
> [as SIPCORE chair]
>
> On 11/17/16 10:14, Brian Rosen wrote:
>> I’ve sent this to stir, even though it has not been decided where the 
>> 666 draft will land
>
> My understanding coming out of DISPATCH is that 666 is appropriate for 
> SIPCORE, assuming the new charter is approved by the IESG. I expect 
> the proposed charter changes to be uncontroversial.
>
> Based on the foregoing, we (the SIPCORE chairs) think it would be 
> appropriate to hold general discussion of both of the
> draft-schulzrinne-dispatch-callinfo-spam and 
> draft-schulzrinne-dispatch-status-unwanted documents on the SIPCORE list.
>
> I've copied DISPATCH and SIPCORE on this message, and set followups to 
> SIPCORE.
>
> /a
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
--------------BE1EC0B521888C9EC1D72E8B-- From nobody Thu Nov 17 08:20:07 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F7D1295E3 for ; Thu, 17 Nov 2016 08:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN8C5q5aurmQ for ; Thu, 17 Nov 2016 08:20:04 -0800 (PST) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C3212949D for ; Thu, 17 Nov 2016 08:20:03 -0800 (PST) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-12v.sys.comcast.net with SMTP id 7PPZcAoPolHMY7PPucpnRj; Thu, 17 Nov 2016 16:20:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1479399602; bh=UUeXQplpczRKLVwzDCx6FJeS70ndrg22A0Sqg6QmWaY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=OtWqISpNWg2FYimhlJyXSCU1m41F6QjRrDEQxYa8GEZ+bXJwMPQZVHdqKdPYgdULS G4WqTeGG9IVkhjbe3gcnVWVM4gIcqQdGMLTwXNXuhHCoExpsyymz4CDVg2nf4wjK8v ziELEls7CCtxlVsZzzD7+rfcS9nTpki10HqJAmiX/39Q+W9e0Ibp4wc2j+upTk49/i t30pcBSkLF1dYafSOiHTuK4cQp8u3tRVGNoA6Lsu7lJGIDpV3rYidi3Awb/2GU8Dut 146HUmOM9+FQmRLW2VEtjpfw2a+wVG2DB1ElpPJUR+TXP+JiQtuVTaGH55HzR8MTlc CrRYME6P1towQ== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-09v.sys.comcast.net with SMTP id 7PPtc8VYcmPUL7PPtc3SE6; Thu, 17 Nov 2016 16:20:02 +0000 To: stir@ietf.org References: From: Paul Kyzivat Message-ID: Date: Thu, 17 Nov 2016 11:20:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfDrIE8/DgVx3gHUzETIJvM17CIEU9A3RsQLaucDlSD5qY2m53QNU8+uHMLrtpYiMaNk0f7hA9JIOH6fNyw4lGcjg02kRHssDJteR7+df7S80+SReyaEQ edCZawVV4PqNWp+kLuRXrilZ9rJZvM4fAJlJh5EtYiuvvAyCIDNHjhOe Archived-At: Subject: Re: [stir] SHAKEN but not STIRred means 666 can cause collateral damage X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 16:20:06 -0000 On 11/16/16 8:14 PM, Brian Rosen wrote: > I’ve sent this to stir, even though it has not been decided where the 666 draft will land, and SHAKEN is not even in the IETF. > > The original idea of stir is that the credential used to sign is granted as a result of delegation of the telephone number. When used as envisioned, a valid signature will (mostly) guarantee that the calling party number has not been spoofed. If we then implement 666, which is a mechanism to create a black list, then numbers reported as spam come from the actual TN they were placed with, or the signature wouldn’t be valid and we get what we want. > > SHAKEN doesn’t do that. It doesn’t check the TN, it only states that the service provider who signed it is willing to say something about the call. It has a very desirable capability to lead authorities to the source of spoofed calls. It will very clearly help us cut down on spoofed calls. > > However, when used with 666, SHAKEN has the problem that spoofing is still allowed - it’s just that we can better trace it to its source. But if a user reports SPAM with a SHAKEN signed claim, the spoofed TN is marked as a spam source. That means the legitimate owner of the TN may have trouble placing calls. 666 creates collateral damage. This is an example of the point I have been trying to make, about the *meaning* of the code. The meaning of a code used by STIR is different from the meaning of a code used with a cert that is actually tied to the calling number. And this can mean that a button used to the user to signal spam may vary. All this needs to be carefully aligned. Thanks, Paul From nobody Thu Nov 17 14:39:23 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C330129588 for ; Thu, 17 Nov 2016 14:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smJbJf3Nj4-t for ; Thu, 17 Nov 2016 14:39:20 -0800 (PST) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 3BE241294C3 for ; Thu, 17 Nov 2016 14:39:20 -0800 (PST) Received: (qmail 7572 invoked by uid 0); 17 Nov 2016 22:39:15 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy2.mail.unifiedlayer.com with SMTP; 17 Nov 2016 22:39:15 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id 9AaB1u0141MNPNq01AaETj; Thu, 17 Nov 2016 15:34:14 -0700 X-Authority-Analysis: v=2.1 cv=K/+xQUmI c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=1oJP67jkp3AA:10 a=L24OOQBejmoA:10 a=ZZnuYtJkoWoA:10 a=doUQZJtgAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=Q_ndXMULhIsErhjOy8wA:9 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=JSd0jWWiH7gA:10 a=d0-0EwFVFT64L02gzcZV:22 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 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: To:From:Subject:Date; bh=nbG+t0KRCEXxsGi9HdUYwzujOl1Lirl4dqU4rcWujU8=; b=OZ1n vVq9YgA+OuCVqi5JtEkjSN1wHPFTtK7oeGoaPx9JYzidu8aQnOFpVgymthIziqhX5f2YU8jOrb2C6 XPsqM8xOOT2daxHQs2wixCFX0YING1QOKAH7B7Uy817y0cw; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:56110 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1c7VFz-0008F1-Jq for stir@ietf.org; Thu, 17 Nov 2016 15:34:11 -0700 User-Agent: Microsoft-MacOutlook/f.1c.0.161115 Date: Thu, 17 Nov 2016 17:34:11 -0500 From: Richard Shockey To: "stir@ietf.org" Message-ID: <50ED344A-E83B-4109-B71D-BFA3E739E178@shockey.us> Thread-Topic: Your regulatory report of the day... Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1c7VFz-0008F1-Jq X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:56110 X-Source-Auth: richard+shockey.us X-Email-Count: 7 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [stir] Your regulatory report of the day... X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 22:39:22 -0000 The FCC enforcement bureau announced it signed a memorandum of understandin= g with the Canadian Radio-Television and Telecommunications Commission on ca= ller ID spoofing and robocalls. https://apps.fcc.gov/edocs_public/attachmatch/DOC-342222A1.pdf =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 From nobody Wed Nov 23 12:52:16 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF63129B43 for ; Wed, 23 Nov 2016 12:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yv8xNJbjgg4Q for ; Wed, 23 Nov 2016 12:52:13 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CFB129781 for ; Wed, 23 Nov 2016 12:52:13 -0800 (PST) Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uANKqCGj011828 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Wed, 23 Nov 2016 14:52:13 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local To: stir@ietf.org From: Robert Sparks Message-ID: Date: Wed, 23 Nov 2016 14:52:12 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [stir] draft minutes for STIR at IETF97 are on the datatracker X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 20:52:14 -0000 See https://www.ietf.org/proceedings/97/minutes/minutes-97-stir-00 Please send any corrections to the list or directly to the chairs. RjS