From nobody Wed Nov 4 16:46:30 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F031B2CB2 for ; Wed, 4 Nov 2015 16:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4rhB5UMda_CO for ; Wed, 4 Nov 2015 16:46:22 -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 E243C1B2CCE for ; Wed, 4 Nov 2015 16:46:22 -0800 (PST) Received: from dhcp-85-14.meeting.ietf94.jp (t20010c40000030806496a606255f717e.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3080:6496:a606:255f:717e]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tA50kLih077589 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 4 Nov 2015 18:46:22 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host t20010c40000030806496a606255f717e.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3080:6496:a606:255f:717e] claimed to be dhcp-85-14.meeting.ietf94.jp To: stir@ietf.org From: "A. Jean Mahoney" Message-ID: <563AA6DC.9090002@nostrum.com> Date: Thu, 5 Nov 2015 09:46:20 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [stir] stir 94 meeting notes - cleaned up X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 00:46:25 -0000 Hi all, My cleaned up notes are below. I'll send raw notes in a separate email. Thanks, Jean STIR: IETF 94: Monday 1300-1500 --------------------------------------------------------- 10m Administrivia Presenters: Chairs Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-0.pdf Jabber scribe: Daniel Burnett (1st hour), Cullen Jennings Jabber log: http://www.ietf.org/jabber/logs/stir/2015-11-02.html Note takers: Jean Mahoney, Steve Donovan Note well and agenda were presented. No changes to the agenda. --------------------------------------------------------- 20m Report from design team discussions Presenter: Sean Turner Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-1.pdf No comments or questions were raised. --------------------------------------------------------- 30m draft-ietf-stir-rfc4474bis Presenter: Jon Peterson Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-3.pdf On the question raised on Slide 4 - The Bare Minimum: Is there a need for a “switch” to signify using PAI? Jon pointed out that currently there is no such thing, but it has been working since PAI was first introduced. Chris Wendt agreed in general that it works as-is, and it would be simpler to keep the logic the same. Richard Barnes raised a concern about having to verify every PAI in every combo. Dave Crocker said that the validator wouldn't know which choice was made by the signer. Jon asked for more eyes on the draft. Cullen pointed out that the From and PAI carry the same information. He was also fine with leaving as-is. Jon raised a concern about the modification by SBCs of the Date header field and asked if there were any examples of such behavior. Cullen said that he had seen SBCs accidentally modifying the Date. Since Date is almost never modified, it makes a useful debugging tool. Sean Turner said that Date modification seems like a surface for an attack. Jim McEachern said that call forwarding may modify the Date. Jon said some behaviors are not compatible with an end-to-end security system, but if the Date had only been tweaked a little bit there were strategies for handling it without re-signing. slide 5: The Bare Minimum Adam asked for clarifications. Jon said that the JSON header and claims were optional since they would make the message larger and he wanted to discourage that. [ajm: missed most of the exchange between Jon and Adam regarding knowing verifier handling of optional contents beforehand.] Jon asked the room is anyone was uncomfortable with JWT. Robert Sparks, as an individual, had no problem with it. Sean agreed with it and wanted to move on. Chris reiterated that JWT could be used for other purposes. Jon said that, although SBCs are not defined and have broad powers, we want to get through them and need to decide what will work for deployment environments that we care about. Chris said that it would be easy to update SBCs. slide 6: Multiple Identity Signatures Russ Housley from floor supported multiple identity signatures, and pointed out that email went through a transition from one to multiple signatures caused by the transition from SHA-1 to SHA-256, and that there could be text that could be reused. Jon said that "spec" parameter would allow for signing different fields for use in authorization, but we would not specify how the authorization decision is made. Jon talked about a transitive approach to security, where you don't trust the endpoint but you trust the intermediary. slide 7: Handling Metadata Richard Barnes mentioned a specification that could be used instead of separate grammars. Jon wanted a pointer to that draft. slide 8: Extensibility Size of the message was discussed, and Adam wondered what was sensitive to it. Robert pointed out that the size was still an order of magnitude lower than an SDP negotiation. Jon said that there were implementations that could not handle really large headers. Robert said that the issue had not been seen at SIPit for many years. Chris said that since UDP is used, it's valid to keep the headers as small as possible, but he didn't know if it was a showstopper. Jon asked what the appropriate IANA policy would be for this. JWT extensibility's IANA policy is expert-review with specification. He didn't see how we could be less constrained than that. Dave Crocker pointed out that DKIM's signature lists the fields it has hashed. Jon said that is what the first option offers. Adam said that JWT supports private use, but it would be nice to have the information collected somewhere. Richard pointed out that if you require the verifier to understand the field, then you get stuck in lockstep upgrades. Jon clarified that the 1st option covered adding just one or two new fields. The second option solves a different problem that may not be specified in the IETF, but the people wanting to solve that problem want to use the baseline mechanism. Jon didn't think it was ideal, but he would not say no. Pete Resnick suggested making it a FCFS registry, with an optional specification, and the IETF will use the specification. Cullen wanted to know why they did not want FCFS. Jon said that the arguments against it are that the specs should not be public, and IETF interoperability constraints don't apply. Cullen said that if those were the arguments, then "spec" should be removed. Jon said that with "spec", you don't have to include canon and make the message huge. For JWT, you have to include canon, which is why both have their place. Alissa Cooper said don't pervert it for people who don't want to do follow process. They can just do it. ACTION: Discuss IANA policy on list. slide 9: We Have the Technology Jon asked the working group if it was OK with having a separate WG item on the token that would be Proposed Standard. Sanjay said that two docs provides more flexibility. Sean and Chris were fine with it. slide 10: Next Steps Jon will revise the draft. ACTION: Sean, Chris, Richard to review updated draft. ACTION: find reviewers on list. slide 11: The job of non-SIP transports Jon pointed out this was not in charter and it needed more discussion. Adam wanted to use this in RTCweb in the future. Jon would be happy to work on it and set up a design team. slide 12: Not So SIP specific Jon asked that, if anyone had a problem, to please talk to them. --------------------------------------------------------- 60m draft-ietf-stir-certificates Presenter: Sean Turner Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-2.pdf slide 6: Ultimate Requirement Questions Jon said that the first question was a policy question. Richard said that the slide was one question in four forms. Cullen wasn't sure what to make of the questions, and that if the members of club were decided by the FCC, the IETF could only provide technology in supporting that club. Sanjay said that, on the last point, you need to be able to trace the call back. Russ from floor said that we were specifying a trust store but not what was in it, that people will populate the store differently. Richard said that it was not a technical decision. Build a scalable infrastructure to deal with it. slide 7: Transitive Trust vs Intransitive Trust Jon said that it's unclear how great the value is since we already have ways to determine if the previous hop vouched for the call. The difference is that you can see past the previous hop. Chris said that the slide is implying that the call can only go between carriers, but the call will be going through multiple hops and untrusted networks. Jon wondered what you would get with using the PAI, but Chris said no one is saying that PAI should be trusted no matter what. Jon said that last-hop security was not much better than relying on PAI. Jon asked if we should detect abuse in realtime or just in audit. ACTION: Discuss transitive vs intransitive trust on the mailing list. slide 8: Public or Confidential Credentials? Jon said that 2 years ago, there were concerns that the subject would leak information, but the right way to manage certs is antithetical to those concerns. Chris pointed out there is some risk of leaking information no matter what you do with the credentials. Sean recommended that implementations be allowed to pick their pain threshold. slide 9: Certs for OCN Jon explained that OCNs may help alleviate leakage concerns. Richard said there were tradeoffs with cert size, and that there were issues with OCSP latency. Brian Rosen said that OCN doesn't fix the problem and asked how to get the assignments to those operators that don't have OCNs. Chris wanted flexibility. slide 10: Other Transitive Approaches Jon and Chris saw some promise here, and Chris said there should be some semantics here. slide 11: So what now? Sean and Jon want a design team call on certs. Chris wanted to start out simple with carrier certs and then go from there. ACTION: Sean Turner to set up a design meeting on certs. Russ said that the syntax and semantics of the signature should be nailed down so that we know what the requirements for the cert are. Jon said that the FCC has created a timeline for this, and he wants an LC as soon as possible. ACTION: Jon to bring up Date concerns on mailing list to ensure that it is not a blocker. Robert recapped major actions: - Revise 4474bis draft between now and the end of November. - Adopt the token draft as a stir doc. - Start the LC process on 4474bis at end of November. - Hold a design team discussion in mid December on certs. From nobody Wed Nov 4 16:47:46 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9310E1B3508 for ; Wed, 4 Nov 2015 16:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 H7hBhocfM7dv for ; Wed, 4 Nov 2015 16:47:41 -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 960491B2CB2 for ; Wed, 4 Nov 2015 16:47:41 -0800 (PST) Received: from dhcp-85-14.meeting.ietf94.jp (t20010c40000030806496a606255f717e.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3080:6496:a606:255f:717e]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tA50ldoB077690 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 4 Nov 2015 18:47:40 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host t20010c40000030806496a606255f717e.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3080:6496:a606:255f:717e] claimed to be dhcp-85-14.meeting.ietf94.jp To: stir@ietf.org From: "A. Jean Mahoney" Message-ID: <563AA72B.5060205@nostrum.com> Date: Thu, 5 Nov 2015 09:47:39 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [stir] stir 94 meeting notes - raw X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 00:47:44 -0000 And below are my raw notes. Ellipses (...) show where I missed stuff. Thanks, Jean STIR: IETF 94: Monday 1300-1500 --------------------------------------------------------- 10m Administrivia Presenters: Chairs Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-0.pdf Jabber scribe: Daniel Burnett (1st hour), Cullen Jennings Note takers: Jean Mahoney, Steve Donovan Note well and agenda were presented. No changes to the agenda. --------------------------------------------------------- 20m Report from design team discussions Presenter: Sean Turner Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-1.pdf No comments or questions were raised. --------------------------------------------------------- 30m draft-ietf-stir-rfc4474bis Presenter: Jon Peterson Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-3.pdf slide 1: Title slide 2: New Questions about Syntax slide 3: A Compromise Position slide 4: The Bare Minimum Jon - Is there anyone who thinks there needs to be a switch to indicate using PAI? Chris Wendt - I agree in general. From a normative perspective any concern with the generality. If they're a service provider network, they look at PAI. Richard Barnes - ... verify twice. ... Jon - there's multiple PAI headers. Richard - have to verify every PAI in every combo. Jon - you already know what you need to use. It's the way it works today, and for 15 years. Cullen - it's fine. It's often the same thing in both headers. Jon - it will canonicalize to the same value. Chris - ... simpler to keep logic the same as it is today. Dave Crocker, from Jabber room - "Probably"? So the validator of the signature won't know which choice was made by the signer? "Verify twice" is an approach to guessing. Guessing is not typically considered valid in interoperable protocol specifications. The specs need to be deterministic. Jon - supposed to ... deterministically. I appreciate eyes on the draft to make sure we don't botch it. Jon - the SBC could modify the Date header field. Date plays an enormous role. If there are transit networks that will modify the Date, I want to know. Cullen Jennings - We had SBCs accidentally modify the Date. Keeping Date unmodified is one of the best debugging tools. Jon - pics or it didn't happen. Sean Turner - it seems like a surface for an attack. Jon - yes, you can reply at the later time. Jim McEachern, from Jabber room - isn't call forwarding another case where the time could be modified by something other than the SBC? Jon - if acting as a b2bua, yes, the new message would have a new date. But there are some things that are not compatible with an e2e security system. Absent the cut n paste protection, voice mail protection goes out the window. There are strategies that we can use to handle the Date being tweaked a little bit. Chris - It would have to be re-signed. Jon - no. However if people are really mucking - but someone explain to me who would do this. Chris - the concern was about b2bua, and keeping signature valid through them. Jon - ... slide 5: The Bare Minimum Adam Roach - are we caring about the assertions? Jon - yes but optional. It will make the message larger and want to discourage that. Adam - need to know a priori that it will happen. Jon - correct you can't anticipate how a verifier will handle it. Adam - this will ... Jon - there's a good tradeoff on message size vs ... Jon - this isn't different than what we were doing in the draft. It's what we've all been signing. Just a change of syntax. Anyone uncomfortable with it? Robert Sparks - personally have no problem. Sean - if we're all in agreement, let's just move on Chris - the benefit is using JWT for other purposes. Robert - I didn't see any response on the Date question. Let's move ahead unless someone screams. Jon - SBCs are not defined and have broad powers, and we want to get through them. Need to decide what will work for deployment environments that we care about. Chris - the point Adam was making. If you want to participate in ecosystem, it is easy to update your SBC. Robert - if the SBC cannot be differentiated from the attacker ... slide 6: Multiple Identity Signatures Russ from floor - we went through this with email, and SMIME only supported 1 signature. Transitioning from SHA-1 to SHA-256 caused this. This is something we need. The algorithms were different but the semantics were the same. Are the semantics different for some cases? If not, we can borrow text. Jon - ... People have a spec that would allow you sign a very different set. Like a superuser of the network, authorizing the call. We don't specify how the authorization decision is made. Jon - don't trust the endpoint but trust the intermediary. It's a transitive approach to security. there a multiple use cases where spec can be useful. slide 7: Handling Metadata Do people understand this? Barnes - I should read the draft. Instead of separate grammars, use the specification... Jon - point me at the draft. slide 8: Extensibility Adam - we're focusing on size - what's sensitive to it? Jon - 700-800 bytes for encoding without spec. Robert - that's an order of magnitude lower than an SDP negotiation. Cullen - What you see with a video call at SIPit is not the same as carrier phones. If your message gets too large to handle, maybe you weren't handling it correctly. Jon - if you pull out the header and claims, it's 100 bytes. There are people who are adamant about using UDP. I've heard of implementations that will barf if headers are really large. Robert - haven't seen it for many years. Chris - people are clinging to UDP. It's valid to keep it as small as possible... Don't know if it's a showstopper. Jon - what's the change then? Chris - it's good to have the option of both. Andrew Allan - ... Jon - UDP limits are more forgiving than most think. Jon - What's an appropriate IANA policy for this? If you read the JWT extensibility, it is expert-review with spec. I don't see that we'll will get a less constrained policy than that. Dave - DKIM's signature lists the fields it has hashed. Jon - that's what the first option offers. ... Adam - JWT talks about some of these being private use. Would that approach address their use cases? People who are using this, would be nice to have it collected somewhere, Jon - ... Richard - if you require the verifier to understand the field, then you get stuck in lock step upgrades. Jon - 1st option... The point is, if you're adding by onesies-twosies, you use the first option. If you want to solve a different problem, we won't specify it in the IETF, but they want to use the baseline mechanism. It's not ideal for me, but I won't say no. Pete Resnick - why not make it a FCFS registry, with an optional specification, and the IETF will use the specification. Jon - I'd have to think about the trades offs. Richard - FCFS is not inconsistent Jon - there's 2 approaches here. 1st one - bare minimum and add a little thing to it, if don't understand it, that's ok. But the 2nd is for something different. Richard - ... Cullen - I haven't heard why they can't deal with FCFS. Jon - I'll channel the views of those who are not here - The specs should not be public. IETF interoperability constraints don't apply. If you don't ... Cullen - if that's it, then the spec should be removed. Jon - I can image uses of spec, it's in Sean's certs presentation. ... I want that to be interoperable. With spec, you don't have to include canon and make the message huge. For JWT, you have to include canon. Which is why both have their place. Alissa - don't pervert that for people who don't want to do follow process. They can just do it. No reason to pervert a legit use of this. Robert - we're in dead horse territory. Jon - If we took a hum, the room would show consensus ... but on the list - Robert - we can take this to list. I don't think we'll see a hard push against FCFS. ACTION: Discuss IANA FCFS on list. slide 9: We Have the Technology Jon - OK with the WG to have a separate WG item on the token? It would be Proposed Standard. Sanjay - 2 docs provides more flexibility. Sean - I'm fine with it. The 2 people involved in the compromise are working on it. Can't we just do it? Chris - I'm fine with it. slide 10: Next Steps Jon - I need to do one more rev, and then we need reviewers. Robert - ACTION: find reviewers on list. volunteers: Sean, Chris, Richard slide 11: The job of non-SIP transports Jon - Not in charter, need to discuss more. May want to have a call. Adam - long term, I would like to use this in RTCweb. Don't need to hold this up though. If you move to JWT, it becomes elegant. PSTN GW working with other protocol. The ability to carry this into the browser would be valuable. Jon - I'll be happy to work with you. Setup a design team on this. slide 12: Not So SIP specific Jon - if you have a problem, talk to us. --------------------------------------------------------- 60m draft-ietf-stir-certificates Presenter: Sean Turner Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-2.pdf slide 1: Title slide 2: No New Version slide 3: What is the STIR certs draft? slide 4: In-band STIR logical architecture slide 5: Is there another way? Jon - we think there are many approaches, they aren't exclusive. Sean - we're open to input. slide 6: Ultimate Requirement Questions Sean - is there anyone who doesn't think the calls should not be verifiable on the Internet? Chris - is that a policy question or tech question Jon - it's a policy question. Do you want to trust someone with whom you have no previous association? Chris - that's a different question. Richard - The 2nd question subsumes the first. Russ from floor - what you are asking is, how are we doing trust ... Jon - are we going to create systems that constrain... Richard - one question in 4 forms. How could the answer be no and it being ... (something about using keys) Cullen - I don't know what to make of these questions. If the membership of the club is allocated by FCC, we can only provide technology that could support that club. Chris - could boil the question down to, does X 509 work or not? Sanjay - on your last point, you need to be able to trace the call back. Russ from floor - to Cullen - there is a trust store, people will populate it differently. We can specify the trust store, not what's in it. Richard - it's not a tech decision. Build a scaleable infrastructure to deal with it. slide 7: Transitive Trust vs Intransitive Trust Jon - it's unclear how great the value is. It's only saying the previous hop vouched for this. We have ways to determine this. Not sure what the difference between PAI and when the environment is the small community of carriers that trust each other. The difference is that you can see past the previous hop. Chris - It's implying it can only go between carriers. It will be going through multiple hops and untrusted networks. Jon - assume that you are using PAI, what do you get with that? If I trust the sender... Chris - no one is saying that PAI should be trusted no matter what. Jon - it's your relationship with the carriers you know. It's effectively translated. If you discover call was abusive, you can take it to Comcast. Should we detect in realtime or just in audit. It's for accountability not for realtime. Chris - I don't think anyone is advocating that.. . unless I'm confused by the slide. Jon - using 4474bis, provides just last hop security not much better than PAI. Chris - that's a new conversation. Sean - can take to list. ACTION: slide 8: Public or Confidential Credentials? Jon - 2 years ago, there were concerns that the subject would leak information. The right way to manage certs (I'm AT&T) is antithetical to concerns expressed 2 years ago. Chris - if you are tying yourself to public keys you are exposing something. Sean - you can have lots of certs, you can leave it blank, lots of ways to do it. Chris - there's some risk of leaking no matter what you do. Sean - allow implementations to pick their pain threshold. slide 9: Certs for OCN Jon explains - OCNs are carrier ids, may help alleviate leakage concerns. Richard - trade off between cert size and ... OCSP latency is not up to snuff. We're shoving more stuff in the first message we get. Brian Rosen - OCN doesn't fix the problem. How do get the assignments to those guys that don't have those? Chris - As long as there's flexibility. slide 10: Other Transitive Approaches Jon - there's some promise here. ... Tools that verifiers will have... Chris - I agree with that - there should be some semantics. Sean - otherwise you don't know what it is. Chris - but don't go nuts with semantics. Jon - ... slide 11: So what now? Sean - I didn't know about the timeline. Have a design team call. Jon - need a design team call on certs. Chris - from our perspective, we want to start out simple with carrier certs. Go from there. Sean - ACTION - Setup a design meeting. Russ - nail down syntax and semantics of the sig are so we know what the requirements for the cert are. Jon - the FCC has created a timeline for this. I want a LC as soon as possible. Make sure that this Date thing is not a blocker. Chris - ... escape options? Robert - 5 minutes. Recap: Between now and end of Nov - rev of the 4474bis draft. The token doc as a stir doc. Start a LC process on 4474bis at end of Nov. Design team discussion in mid December on certs. From nobody Thu Nov 5 08:44:35 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89B61B3095 for ; Thu, 5 Nov 2015 08:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CmTakDKiZYU for ; Thu, 5 Nov 2015 08:44:30 -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 0FD291B308D for ; Thu, 5 Nov 2015 08:44:28 -0800 (PST) Received: (qmail 13856 invoked by uid 0); 5 Nov 2015 16:44:26 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy2.mail.unifiedlayer.com with SMTP; 5 Nov 2015 16:44:26 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id dsQH1r00X1MNPNq01sQLmW; Thu, 05 Nov 2015 09:24:25 -0700 X-Authority-Analysis: v=2.1 cv=Jv9i8qIC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=qtqOOiqGOCEA:10 a=ll-iCDY8AAAA:8 a=JtHPKIVgiei2MyRAiRcA:9 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=YeG65AgvWToA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:Message-ID:To:From:Subject:Date; bh=1INCeT5KFP5um289FzODvwA8cPThSzgI2C3qIIMowkE=; b=ZGGVLvJ/bZMep9MC+Kav5a79FRLcN3M6qAiYBSW+rRFonhPC3AvcEmmD2LlBx7nhOy1OiZB9ff95gOTX7iResKFBUu0Q9hyiIyyLkMur5P8fG5d0JA8ornAoFzppXPhb; Received: from [100.36.26.202] (port=53305 helo=[192.168.1.10]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZuNKk-0007ix-Su for stir@ietf.org; Thu, 05 Nov 2015 09:24:19 -0700 User-Agent: Microsoft-MacOutlook/0.0.0.151008 Date: Thu, 05 Nov 2015 11:24:11 -0500 From: Richard Shockey To: Message-ID: Thread-Topic: [stir] stir 94 meeting notes - raw One immediate comment on IANA issues. Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Subject: Re: [stir] stir 94 meeting notes - raw One immediate comment on IANA issues. X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 16:44:34 -0000 FCFS. Period.=20 Expert Review IMHO is a non starter.=20 I=E2=80=99ll have more when I can digest the notes. =E2=80=94=20 Richard Shockey Shockey Consulting LLC www.shockey.us www.sipforum.orgrichardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 > From nobody Tue Nov 10 11:40:24 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FE71B3DC5 for ; Tue, 10 Nov 2015 11:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yt1e2NU-hiUP for ; Tue, 10 Nov 2015 11:40:20 -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 4878E1B3DB5 for ; Tue, 10 Nov 2015 11:40:20 -0800 (PST) Received: from unnumerable.local (pool-71-164-199-31.dllstx.fios.verizon.net [71.164.199.31]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tAAJeJDo030196 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Tue, 10 Nov 2015 13:40:19 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-164-199-31.dllstx.fios.verizon.net [71.164.199.31] claimed to be unnumerable.local To: stir@ietf.org From: Robert Sparks Message-ID: <5642481E.5010109@nostrum.com> Date: Tue, 10 Nov 2015 13:40:14 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [stir] Draft minutes: STIR@IETF94 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 19:40:23 -0000 Many thanks to Jean and Steve for thorough notes. The minutes below are also available here: http://datatracker.ietf.org/doc/minutes-94-stir/ Please send any additions/corrections to the list or the chairs as soon as you can. ------------- Minutes: Secure Telephone Identity Revisited (STIR) - IETF94 Summary: The attendees approved of the design team's suggestion to shift the syntax for carrying the signature to use JWT as captured in draft-ietf-stir-rfc4474bis-06. Discussion converged on not explicitly signaling whether where the number was taken from (PAI or elsewhere) and on including Date in the signature. The attendees supported having multiple signatures, but expressed concern that each signature have enough information attached to be semantically distinct (spec). Extensibility, and policies around standardizing extensions will continue to be discussed on the list. The next steps will be to revise rfc4474bis, splitting the the token description out into a separate draft. We expect these drafts by the end of November, and we expect to be able to WGLC these drafts. The group discussed the requirements for the credentials, and began working towards some technical decisions. We expect a design team to form and report recommendations (likely mid-December) after the revised rfc4474bis and new token draft are available. The full notes are below: ============================================================================== STIR: IETF 94: Monday 1300-1500 --------------------------------------------------------- 10m Administrivia Presenters: Chairs Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-0.pdf Jabber scribe: Daniel Burnett (1st hour), Cullen Jennings Jabber log: http://www.ietf.org/jabber/logs/stir/2015-11-02.html Note takers: Jean Mahoney, Steve Donovan Note well and agenda were presented. No changes to the agenda. --------------------------------------------------------- 20m Report from design team discussions Presenter: Sean Turner Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-1.pdf No comments or questions were raised. --------------------------------------------------------- 30m draft-ietf-stir-rfc4474bis Presenter: Jon Peterson Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-3.pdf On the question raised on Slide 4 - The Bare Minimum: Is there a need for a “switch” to signify using PAI? Jon pointed out that currently there is no such thing, but it has been working since PAI was first introduced. Chris Wendt agreed in general that it works as-is, and it would be simpler to keep the logic the same. Richard Barnes raised a concern about having to verify every PAI in every combo. Dave Crocker said that the validator wouldn't know which choice was made by the signer. Jon asked for more eyes on the draft. Cullen pointed out that the From and PAI carry the same information. He was also fine with leaving as-is. Jon raised a concern about the modification by SBCs of the Date header field and asked if there were any examples of such behavior. Cullen said that he had seen SBCs accidentally modifying the Date. Since Date is almost never modified, it makes a useful debugging tool. Sean Turner said that Date modification seems like a surface for an attack. Jim McEachern said that call forwarding may modify the Date. Jon said some behaviors are not compatible with an end-to-end security system, but if the Date had only been tweaked a little bit there were strategies for handling it without re-signing. slide 5: The Bare Minimum Adam asked for clarifications. Jon said that the JSON header and claims were optional since they would make the message larger and he wanted to discourage that. Jon asked the room is anyone was uncomfortable with JWT. Robert Sparks, as an individual, had no problem with it. Sean agreed with it and wanted to move on. Chris reiterated that JWT could be used for other purposes. Jon said that, although SBCs are not defined and have broad powers, we want to get through them and need to decide what will work for deployment environments that we care about. Chris said that it would be easy to update SBCs. slide 6: Multiple Identity Signatures Russ Housley from floor supported multiple identity signatures, and pointed out that email went through a transition from one to multiple signatures caused by the transition from SHA-1 to SHA-256, and that there could be text that could be reused. Jon said that "spec" parameter would allow for signing different fields for use in authorization, but we would not specify how the authorization decision is made. Jon talked about a transitive approach to security, where you don't trust the endpoint but you trust the intermediary. slide 7: Handling Metadata Richard Barnes mentioned a specification that could be used instead of separate grammars. Jon wanted a pointer to that draft. slide 8: Extensibility Size of the message was discussed, and Adam wondered what was sensitive to it. Robert pointed out that the size was still an order of magnitude lower than an SDP negotiation. Jon said that there were implementations that could not handle really large headers. Robert said that the issue had not been seen at SIPit for many years. Chris said that since UDP is used, it's valid to keep the headers as small as possible, but he didn't know if it was a showstopper. Jon asked what the appropriate IANA policy would be for this. JWT extensibility's IANA policy is expert-review with specification. He didn't see how we could be less constrained than that. Dave Crocker pointed out that DKIM's signature lists the fields it has hashed. Jon said that is what the first option offers. Adam said that JWT supports private use, but it would be nice to have the information collected somewhere. Richard pointed out that if you require the verifier to understand the field, then you get stuck in lockstep upgrades. Jon clarified that the 1st option covered adding just one or two new fields. The second option solves a different problem that may not be specified in the IETF, but the people wanting to solve that problem want to use the baseline mechanism. Jon didn't think it was ideal, but he would not say no. Pete Resnick suggested making it a FCFS registry, with an optional specification, and the IETF will use the specification. Cullen wanted to know why they did not want FCFS. Jon said that the arguments against it are that the specs should not be public, and IETF interoperability constraints don't apply. Cullen said that if those were the arguments, then "spec" should be removed. Jon said that with "spec", you don't have to include canon and make the message huge. For JWT, you have to include canon, which is why both have their place. Alissa Cooper said don't pervert it for people who don't want to do follow process. They can just do it. ACTION: Discuss IANA policy on list. slide 9: We Have the Technology Jon asked the working group if it was OK with having a separate WG item on the token that would be Proposed Standard. Sanjay said that two docs provides more flexibility. Sean and Chris were fine with it. slide 10: Next Steps Jon will revise the draft. ACTION: Sean, Chris, Richard to review updated draft. ACTION: find reviewers on list. slide 11: The job of non-SIP transports Jon pointed out this was not in charter and it needed more discussion. Adam wanted to use this in RTCweb in the future. Jon would be happy to work on it and set up a design team. slide 12: Not So SIP specific Jon asked that, if anyone had a problem, to please talk to them. --------------------------------------------------------- 60m draft-ietf-stir-certificates Presenter: Sean Turner Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-2.pdf slide 6: Ultimate Requirement Questions Jon said that the first question was a policy question. Richard said that the slide was one question in four forms. Cullen wasn't sure what to make of the questions, and that if the members of club were decided by the FCC, the IETF could only provide technology in supporting that club. Sanjay said that, on the last point, you need to be able to trace the call back. Russ from floor said that we were specifying a trust store but not what was in it, that people will populate the store differently. Richard said that it was not a technical decision. Build a scalable infrastructure to deal with it. slide 7: Transitive Trust vs Intransitive Trust Jon said that it's unclear how great the value is since we already have ways to determine if the previous hop vouched for the call. The difference is that you can see past the previous hop. Chris said that the slide is implying that the call can only go between carriers, but the call will be going through multiple hops and untrusted networks. Jon wondered what you would get with using the PAI, but Chris said no one is saying that PAI should be trusted no matter what. Jon said that last-hop security was not much better than relying on PAI. Jon asked if we should detect abuse in realtime or just in audit. ACTION: Discuss transitive vs intransitive trust on the mailing list. slide 8: Public or Confidential Credentials? Jon said that 2 years ago, there were concerns that the subject would leak information, but the right way to manage certs is antithetical to those concerns. Chris pointed out there is some risk of leaking information no matter what you do with the credentials. Sean recommended that implementations be allowed to pick their pain threshold. slide 9: Certs for OCN Jon explained that OCNs may help alleviate leakage concerns. Richard said there were tradeoffs with cert size, and that there were issues with OCSP latency. Brian Rosen said that OCN doesn't fix the problem and asked how to get the assignments to those operators that don't have OCNs. Chris wanted flexibility. slide 10: Other Transitive Approaches Jon and Chris saw some promise here, and Chris said there should be some semantics here. slide 11: So what now? Sean and Jon want a design team call on certs. Chris wanted to start out simple with carrier certs and then go from there. ACTION: Sean Turner to set up a design meeting on certs. Russ said that the syntax and semantics of the signature should be nailed down so that we know what the requirements for the cert are. Jon said that the FCC has created a timeline for this, and he wants an LC as soon as possible. ACTION: Jon to bring up Date concerns on mailing list to ensure that it is not a blocker. Robert recapped major actions: - Revise 4474bis draft between now and the end of November. - Adopt the token draft as a stir doc. - Start the LC process on 4474bis at end of November. - Hold a design team discussion in mid December on certs. From nobody Tue Nov 10 12:01:56 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C151B3E1E for ; Tue, 10 Nov 2015 12:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efhuSsyEFGQk for ; Tue, 10 Nov 2015 12:01:53 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661EA1B3E11 for ; Tue, 10 Nov 2015 12:01:30 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-05v.sys.comcast.net with comcast id fw1P1r00A2GyhjZ01w1VJC; Tue, 10 Nov 2015 20:01:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with comcast id fw1V1r00A3KdFy101w1VQl; Tue, 10 Nov 2015 20:01:29 +0000 To: stir@ietf.org References: <5642481E.5010109@nostrum.com> From: Paul Kyzivat Message-ID: <56424D17.5020607@alum.mit.edu> Date: Tue, 10 Nov 2015 15:01:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5642481E.5010109@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1447185689; bh=SBISfNmVdVEs5JvzXBYJTsCkFXAdFjnRIa+nh7Y80/8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=bGBSksaWrkuvgiVhrSe5gGPlFQk5S9HtG22+LyZwhH5q1Del2UgQzfIkC2Z0FXO/E g8Zti64TfzQEcD/NjVxSIwySYSINymamn/gbAjJaAhgqvk8kzmT/U64M+U667K4F6g FpdFkIPMjQE9/WKCbsv75/OIfPplaMs1CIuNXVN/vqKkYV4ZlRq3tgLKOt9fxO72Xr M6UZBjiWr+l+XSod+YB7lPY+YY/f0N2MdDnKLHfUAGs2HZJqfnjJ36DMyPFIoZIlwo V/0pKWQRvBqlA0wMNE3goPn5hBfrRfTaGFaO9kD2MCyr/IcFtSaEj26dw5XTQYsV/d HfHVDuu0qsJBA== Archived-At: Subject: Re: [stir] Draft minutes: STIR@IETF94 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 20:01:55 -0000 On 11/10/15 2:40 PM, Robert Sparks wrote: > Summary: > > TThe attendees supported having > multiple signatures, but expressed concern that each signature have > enough information attached to be semantically distinct (spec). Isn't it sufficient that a recipient might trust one of the signers and not another? Thanks, Paul