Secure Telephone Identity Problem Statement and Requirements
draft-ietf-stir-problem-statement-05
Yes
(Richard Barnes)
No Objection
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Stewart Bryant)
Abstain
Note: This ballot was opened for revision 03 and is now closed.
Richard Barnes Former IESG member
Yes
Yes
(for -03)
Unknown
Sean Turner Former IESG member
Yes
Yes
(2014-02-20 for -03)
Unknown
Verbose but it got through the gauntlet I think it ought to go.
Spencer Dawkins Former IESG member
(was No Objection)
Yes
Yes
(2014-02-18 for -03)
Unknown
This first comment is about halfway to a Discuss. If the IESG wasn't already chatting about application of the Discuss criteria to a ballot for another document and frightening the incoming ADs, and if this wasn't pretty obviously a problem and trivial to fix, I'd have balloted Discuss, so please fix it :D This document contains a problem statement *and* requirements resulting from that problem statement, but the presence of a section on requirements isn't apparent from the document title, and isn't mentioned in the Abstract. There's one mention of requirements (and maybe even "start of an attempt to develop requirements") several paragraphs into the Introduction: With this document we would like to start an attempt to develop a common understanding of the problem statement as well as requirements to develop a vision on how to ^^^^^^^^^^^^^^^^^^^^^^^ advance the state of the art and to initiate technical work to enable secure call origin identification. and nothing else until you hit 7. Requirements This section describes the high level requirements of the effort: If you could make the requirements a bit more visible, that would be great. As it is, if someone asked me where the requirements for STIR are after this doc is published, I couldn't find them from the RFC index or from the abstract. The rest of these comments are mostly places where the document wasn't clear to me, or was more US-centric than I was comfortable with. Please consider them along with any other comments you receive. In this text: 1. Introduction With this document we would like to start an attempt to develop a common understanding of the problem ^^^^^^^^^^^^^^^^ statement as well as requirements to develop a vision on how to advance the state of the art and to initiate technical work to enable secure call origin identification. I'm not understanding what "start an attempt" means - is the intention that a follow-on problem statement doc would be published later? I would have guessed "yes" from this, but then I guessed "no" because the document also contains requirements, and now I'm back to being lost. In this text: 2. Problem Statement This model worked as long as the number of entities was relatively small, easily identified (e.g., through the concept of certificated ^^^^^^^^^^^^ carriers) and subject to effective legal sanctions in case of misbehavior. does "certificated" have a different meaning than "certified"? It's a word (I checked), but it's not a familiar word to me. In the same section: Other boiler-room ^^^^^^^^^^^ is this word clear to non-native English speakers? organizations use number spoofing to place illegal "robocalls" (automated telemarketing, see, for example, the FCC webpage [16] on ^^^ please expand, and qualify as "US"? this topic). Robocalls are a problem that has been recognized already by various regulators; for example, the Federal Trade Commission (FTC) recently organized a robocall competition to solicit ^^^ please qualify as "US"? ideas for creating solutions that will block illegal robocalls [17]. In this text, but not only in this text: 4.4. VoIP-to-PSTN Call Consider Figure 4 where Alice calls Carl. Carl uses a PSTN phone and Alice an IP-based phone. When Alice initiates the call the E.164 number needs to get translated to a SIP URI and subsequently to an IP ^^^^^^^^^^^^ is? address. The call of Alice traverses her VoIP provider where the call origin identification information is added. It then hits the reaches? ^^^ PSTN/VoIP gateway. the wording is more casual than I'm accustomed to (and I'm a pretty casual guy). If someone could make a gentle pass looking for wording like this, that would be helpful for ESL readers. In this text: 5. Limitations of Current Solutions SIP Identity is meant both to prevent originating calls with spoofed From headers and intermediaries, such as SIP proxies, from launching man-in-the-middle attacks to alter calls passing through. the wording was difficult for me to grok. Does that mean something like this? SIP Identity is meant to prevent SIP UAs from originating calls with spoofed From headers and to prevent intermediaries, such as SIP proxies, from launching man-in-the-middle attacks by inserting spoofed headers as calls pass through. In this text: 7. Requirements Usability: Any validation mechanism must work without human intervention, e.g., CAPTCHA-like mechanisms. ^^^^ I know what you mean, but the text says (in Latin) "for example, CAPTCHA", and I'm pretty sure you mean "anything but CAPTCHA". In this text: 10. Security Considerations This document is about improving the security of call origin identification. Right. There will be security considerations associated with that improvement. I think it's fair to say they'll be addressed in the documents that define those improvements, but this is kind of a punt.
Benoît Claise Former IESG member
No Objection
No Objection
(2014-02-20 for -03)
Unknown
What is not clear to me: is this document supposed to contain requirements, or is this supposed in https://datatracker.ietf.org/doc/draft-ietf-stir-threats/ ? Or maybe the two? The charter is not too clear about this. I'm mean: certainly, we would have some (others) requirements from the threat model, right? However, I don't even see the "requirement" word in draft-ietf-stir-threats? Can you please clarify Unlike some of my esteemed IESG colleagues, I actually like this document, which gives some history, explain the problem statement, and explain the limitations of the current solutions. Granted, it's a little bit verbose, but if one document type could be verbose, this would be problem statement. On regular basis, I claim that the IETF makes it too difficult for for newcomers to jump on the IETF train (how many SIP RFCs do we have?). This type of document provides the needed entry point. I agree with Spencer's and Stephen's comments.
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -03)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -03)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -03)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -03)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-02-19 for -03)
Unknown
- I like the document overall, thanks! - It'd be an easier read if references were given more readable names, e.g. things like "Some have therefore proposed weakening the security constraints of [1]..." make it hard to know what's meant sometimes. I get that this'd be a lot of editing work to fix though, but I think it would make the eventual RFC more useful for longer if someone has the time and energy. - 5.3 uses the term "nonce" wrong I think, I guess you mean cookie really. - 6.2, a reference for the "some national authorities" statement would be nice to have. - 6.3, "architecting new certificate authorities" isn't quite right, you're talking about building new PKIs which is a deployment and not necessarily a s/w thing. Bit of a nit though. - 6.X, I could suggest adding a new 6.7 since another important thing that has changed is snowdonia. I can buy that that's not done here though since STIR has been underway whilst we're still figuring out snowdonia. It could still be worth noting though, since there is a real tension there the WG will have to deal with. That tension being the inherent one between securing origin information (good) and assisting pervasive monitoring (bad). I realise that not all those involved in STIR do consider PM as a bad thing, as least insofar as it might be assisted by STIR, but nonetheless the tension is real. - 7: I think you should say that these requirements will be elucidated further in the WG. The reason is that they're quite informally stated (e.g. "golden root") which is ok as long as they're not used later as gospel since that would likely lead to repeating arguments and delay. If you do mean these requirements as gospel, then I think I'd likely turn this into a discuss. - 7: The privacy requirement is limited to the out-of-band case. I'm sure there will be things to say about the in-band case too that will be different for different potential solutions. I'm not sure if there's a useful requirement you can state here though for that without getting into solution detail. Was that considered?
Stewart Bryant Former IESG member
No Objection
No Objection
(for -03)
Unknown
Barry Leiba Former IESG member
Abstain
Abstain
(2014-02-19 for -03)
Unknown
Indeed, what Brian said. I think it's important for us to take a step back and pare down some of the language we put into documents that amounts more to marketing hype than to technical material. My sense is that most people reading this would glaze over before they got to the important bits.
Brian Haberman Former IESG member
Abstain
Abstain
(2014-02-19 for -03)
Unknown
I don't have an issue with the general premise of this document. However, I think its verbosity leads to significant information loss, resulting in a far less useful document. For example: 1. It is completely unclear that there will be a list of requirements at the end of the story (hence part of Spencer's Comment). 2. The actual problem statement section contains far more historical context than actual statement of a problem. 3. Sections 4.x could easily be condensed into a concise (and readable) bulleted list. 4. Sections 5.x do not need long-winded descriptions of the current solutions. A reference will do. I think the document would be much more useful in a condensed format. However, since the WG has consensus on this formulation, I am not going to stand in the way.