Re: [i2rs] Stephen Farrell's Abstain on draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT)

["Susan Hares" <[e-mail]>]

Stephen: 

Thank you for your note.   You do not have to respond then to the questions.   I will check with Alia this morning to see what she wants to do. 

Sue 

-----Original Message-----
From: Stephen Farrell [mailto:[e-mail]] 
Sent: Sunday, August 21, 2016 7:24 PM
To: Susan Hares; The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [i2rs] Stephen Farrell's Abstain on draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT)


Hiya,

On 21/08/16 22:57, Susan Hares wrote:
> Stephen: Thank you for the explanations.  Iterative edits do impact
> on the style. 

Well, yes, but it is not just a matter of style, when there are so
many non-sentences.

> While you denote the concern as pervasive monitoring,

Not just I - the IETF adopted that term in BCP188.

> in my mind it is better to consider the effort as ensuring pervasive
> privacy for individuals and groups utilizing the Internet.  (Having
> worked with survivors of domestic abuse and sexual abuse, I cheer
> IETF effort on pervasive monitoring.) My focus and the reason I asked
> about the security directorate reviews - is that it is important to
> fix problems early in the process.  

If you really want my opinion on process here - I think that the
process the WG are following to document requirements in RFCs is
where the problem lies. That causes us all to want to ensure that
the text documenting the agreed requirements is sufficient precise
for us all, whereas that level of precision (of the text) is not
really required for most requirements in order to pursue the work.

> When I come to an unexpected
> failing grade for a document, 

Again, I do not agree with the concept that there is any such
failing grade. We (the IETF) ought consider that it's a normal
part of the process that work has to go back a step or two now
and then in order to be done as well as we need it to be done. If
the end result of this IESG evaluation is that this document ends
up back with the WG, then I would hope that that leads to an overall
better outcome. If OTOH, the document still moves ahead, then I
am not insisting on being a blocking factor as I have balloted
abstain.

> I try to address both the document and
> the process in order to improve.  I expected the process of getting a
> security directorate reviews would detect problems sooner. 

I think it did detect some problems. Did it identify all problems? No.
And one ought not expect that from any volunteer-lead review process.
One ought also not expect that an early secdir review will focus on
the precise words used, as those will change before the work is done.
And many of my comments on this relate to (im)precision in the words
used.

>  So I am
> asking what happened in the security directorate reviews that caused
> them to miss your concerns?   Did miss something in their comments? 

See above. It's entirely normal that reviews do not involve a constant
level of effort, nor produce a predictable outcome.

> My next question is what do you expect from a protocol security
> document?  Do you have a checklist? 

I don't think it's reasonable to ask an AD what they consider a
perfect document, nor for a checklist. (And the document in question
is not a "protocol security" specification but a requirements
specification, which is a different beast entirely.)

> On the next steps, I responded up
> through your ~discuss-criteria.html comment 5.  If you have time to
> answer  just my qustions on the 5 discuss Qs - it will help my
> discussion with Alia. 

I will look tomorrow. But to be honest, it would really help me if
it were possible for your email to use normal email quoting. (Your
mail seems to not do that - "who said what" may be nicely visible in
your mail UA but in my very basic one it's very hard to pick out
what you and what I wrote.) But I can manage with what you sent if
it's hard to do it with normal quoting. (FWIW, I suspect the form
of quoting you used has lead other discussions on this draft to be more
prolonged that would otherwise have been the case - at least that's
a pattern I think I see over many discussions and in this one too.)

Cheers,
S.

> SueSue
> 
> Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone --------
> Original message --------From: Stephen Farrell
> <[e-mail]> Date: 8/21/16  3:41 PM  (GMT-05:00) To:
> Susan Hares <[e-mail]>, The IESG <[e-mail]> Cc:
> [e-mail], [e-mail], [e-mail],
> [e-mail] Subject: Re:
> [i2rs] Stephen Farrell's Abstain on
> draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT)
> 
> Hiya,
> 
> On 21/08/16 20:10, Susan Hares wrote:
>> Stephen: Thank you for leaving your vacation early to do this
>> review. It is one of the most negative viewpoint I have read from
>> you, and since  have read many of your DISCUSS comments since you
>> became an AD
> 
> Well, I've done far more negative reviews, but this one has a lot of
> smaller negative comments. My guess is quite a lot of that is down to
> a) it's very very hard to write protocol requirements text crisply 
> and accurately, and b) that kind of text is very very easily messed
> up when doing iterative edits in response to reviews, and c) the
> writing is really not that good in this version - to the point where
> the accumulation of nits itself becomes a notable issue, and where
> it's likely past time that an editorial pass was done to get that out
> of the way.
> 
>> - I think this gives me unique perspective.  This is far from the 
>> early comments you sent 2 weeks ago.
> 
> No. I would not have asked for a defer if I thought the only concern 
> was the possibility of this resulting in a hard-to-deploy set of 
> security mechanisms - I would have just balloted that. It is the
> case that that's all I said before I had properly read the document
> though, yes. And it wasn't 2 weeks ago:-)
> 
>> In developing this document and I2RS technology the I2RS WG and I
>> as the I2RS chair have request reviews from the Security
>> directorate.  We delayed out first revisions to try to address
>> security issue by adding this document and the security environment
>> document.  We have had early and late reviews.  Since the initial
>> review on the I2RS architecture we have discussed the non-secure
>> interface and tried to get security directorate's review.
> 
> I have looked back at the secdir mails on this, yes.
> 
>> I raised the pervasive privacy issue and asked for input in your
>> review.
> 
> Yes. And I responded with two would-have-been-discuss points related 
> to pervasive monitoring. (I assume that what's you mean when you say 
> "pervasive privacy" but if you mean something else above, please do 
> clarify.)
> 
>> This meta-comment is that process of asking for aid ahead of this
>> point has failed according to your review,
> 
> I think that's an odd view of IETF processes, which are never
> expected to produce perfection at any stage. IMO we're iterating
> towards better outcomes, not failing/succeeding at each stage of the
> process.
> 
>> but I cannot find a point where the I2RS WG did not solicit the
>> security area's aid and take its advice.  Therefore,  I must ask
>> you to check the process of your security directorate's reviews to
>> find what happened to cause such a failure.
> 
> Don't think of it as failure, think of it as more eyeballs finding
> more things. (Or repeating things already considered, for those where
> that's the case.)
> 
>> Now as to the document, I have a WG waiting for these requirements.
>> 
> 
> I'd encourage you to question the above, as a first order goal. Are 
> the WG really waiting on these in a final, fixed-forever, form? Or do
> you need a general agreement as to direction and can then make 
> progress? (And perhaps reduce the final requirements to RFC status 
> later if there's value in that, which there can be.)
> 
> As I noted a couple of times in my review, it's not possible to be 
> that precise about some requirements without having done more of the 
> design. (One of the traditional waterfalll design problems I guess.) 
> The scope of replay detection is probably a good example.
> 
>> I would like to hear in a completely separate email thread what
>> kernel of information you would have expected regarding the
>> security first an i2rs protocol.
> 
> I don't understand your question sorry.
> 
>> I would then like to compare this against the security
>> directorate's suggestions on this document.  We have a second
>> document on the security environment so your insights will be
>> applied to that document. Since in the general text you indicate
>> the style is terrible and needs to be written, please provide an
>> example of a document as an example of the style.
> 
> Really? The accumulation of badly written sentences in -09 has got to
> be a clear enough problem that you don't need an example of what is
> not-that. So I'm puzzled at the request.
> 
>> My understanding is that style is a lower priority than technical
>> correctness and consensus.
> 
> Correct/good-enough writing is certainly secondary, up until the 
> issues get to a certain point that impinges on the reader's ability 
> to asses the meaning, and that happens a couple of times in this 
> document. (As I said in my review.) The other writing issues make 
> this a harder read than ought be the case. That doesn't reach the 
> level of making the document unreadable, nor nearly get that bad, but
> it is enough that I wonder if other readers may have been put off by
> that in reading some of the text.
> 
>> This email ends my comments on your summary message.  The next set
>> of comments will take your discuss comments one at a time. The
>> exact next steps that I and my co-author will take will be guided
>> by the AD responsible for the I2RS WG,
> 
> That's all good.
> 
> I would re-iterate though, that since my ballot is an abstain
> there's no onus on you or the WG to respond in any more detail than
> you feel is useful.
> 
> Cheers, S.
> 
>> Alia. Cheerily,  Sue Hares
>> 
>> Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone
>> -------- Original message --------From: Stephen Farrell 
>> <[e-mail]> Date: 8/21/16  8:37 AM  (GMT-05:00)
>> To: The IESG <[e-mail]> Cc: [e-mail], [e-mail], 
>> [e-mail], 
>> [e-mail] Subject: 
>> [i2rs] Stephen Farrell's Abstain on 
>> draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT) 
>> Stephen Farrell has entered the following ballot position for 
>> draft-ietf-i2rs-protocol-security-requirements-09: Abstain
>> 
>> 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-i2rs-protocol-security-requirements/
>>
>>
>>
>>
>>
>> 
----------------------------------------------------------------------
>> 
>> 
> COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>>
>>
>> 
First, apologies for not getting my review done for this when it was
>> scheduled due to my vacation and thanks for being willing to defer 
>> the document.
>> 
>> Second, having now properly reviewed this, I am balloting abstain
>> as I think it's unlikely that this document can be fixed in a way
>> that results in something useful happening. I think that the likely
>>  outcome is that this document will be used later when people are 
>> arguing and will not much help in resolving those arguments, or
>> else this will be ignored and arguments will be held afresh, as
>> needed. That latter outcome is what I'd guess is most likely and
>> therefore it seems that spending all of our cycles on DISCUSS
>> ballot processing for this would not be wise. That said, I am
>> willing to change to a DISCUSS ballot if the responsible AD prefers
>> that, but I suspect I'll end up with an abstain in any case, after
>> some discussion. The only plan I can think of that'd lead to me
>> ending up with a yes or no-objection ballot would be if this was
>> returned to the WG for fixing and possibly major surgery, which is
>> what I actually think would be the best plan. (I realise this has
>> had a somewhat tortured history, so folks may not be willing to
>> take it back to the WG, but honestly, I think the failings visible
>> in this document do indicate that this is not ready for approval
>> and ought be returned to the WG.)
>> 
>> Third, I think the overall set of requirements posed here might
>> (with some unknown probability) lead to later specifications that
>> are considered too hard to deploy, with the result that non-secure 
>> variants of I2RS become the norm. That seems like it would be a 
>> really bad outcome. I would suggest that might be partly mitigated
>> if a requirement were added to the effect that deployment issues
>> and specifically ease of deployment MUST be considered as a first
>> order requirement when developing I2RS protocol solutions.
>> 
>> Fourth, the (19!) comments below that are preceded by "(discuss" 
>> would have been DISCUSS ballot points had I not decided to abstain.
>> I am happy to chat about any of my comments below, but if the 
>> authors/WG do want to chat, it might be more efficient to
>> concentrate on those that would otherwise have been DISCUSS points.
>> (But that's your call, I don't mind.) I think the 19
>> would-have-been-discuss points is another clue that this ought
>> really be sent back to the WG.
>> 
>> And with that, and with apologies for this being such an overall 
>> negative review, here're my detailed comments:
>> 
>> - general: The writing here is generally poor, for example the
>> opener is "This presents..." whereas it ought be "This document
>> presents..." (or s/document/whatever you prefer/). Such issues are
>> repeatedly seen and all that makes this a much harder read than
>> ought be the case. I'd strongly recommend an editorial pass from
>> someone who hasn't been down in the weeds with this text for a
>> while (which could be one of the authors, if one of them has been
>> less active recently.) Note that this is not only (but is
>> primarily) an editorial issue - there are some cases (hopefully
>> called out below) where the writing does create real ambiguity that
>> might lead to re-opening old arguments later.
>> 
>> - abstract: "mutual authentication, transport protocols, data 
>> transfer and transactions" don't seem to me to be commensurate 
>> things, so the abstract, as written is very uninformative for me.
>> 
>> - intro 3rd para: I'm really not sure what you're telling me about 
>> [I-D.ietf-i2rs-ephemeral-state].  "The draft [RFC7922]" is odd,
>> that being no longer a draft. I'd have expected such nits would
>> have been fixed by now TBH. Same for the last sentence.  That para
>> makes the intro pretty unclear for me.
>> 
>> - 2.2: The definition of higher level protocol seems like an odd 
>> place to introduce the fact that i2rs == netconf + restconf.
>> That'd be more usefully said in the abstract/intro if that's
>> solidly agreed by the WG.
>> 
>> - 2.2: This is wrong: "While it is possible to have an I2RS
>> operation which is contained in multiple I2RS (E.g.  write in
>> multiple messages), this is not supported in order to simplify the
>> first version of I2RS." The reason this is wrong, is that it is
>> here that you are defining that it is not possible to have an
>> operation in multiple messages. s/it is/it could have been/ would
>> work maybe.
>> 
>> - 2.2: " *  The I2RS client issues a read request to a I2RS agent, 
>> and the I2RS Agent responding to the read request" Shouldn't that
>> use respond and not responding? Given that you seem to be trying
>> to define the scope of what is and is not a transaction, I think
>> being precise with the language is something well worth doing.  The
>> 2nd bullet could also do with a re-write.
>> 
>> (discuss1) 2.2: you sort-of define messages, operations,
>> transactions and actions. None of the definitions are that precise,
>> e.g. are those the only operations or examples? And transaction and
>> action aren't really defined at all. I'm not sure if that's likely
>> to be a problem or not. I suspect it will later, e.g. when you get
>> to figuring out the scope within which replay needs to be
>> detectable.
>> 
>> - 2.2: s/transation/transaction/
>> 
>> (discuss2) - 2.2: "defines a secondary identity as the entity of
>> some non-I2RS entity " That could be abused for tracking of various
>> kinds I would guess, e.g. if an IMEI were used. I think you need to
>> note that and should impose some requirements that such secondary 
>> identifiers are not used thusly for tracking.  Also, should the
>> first occurrence of entity there be identity?
>> 
>> - 3, 1st para: s/The security for the/The/ - there isn't a thing 
>> called the security for the i2rs protocol.
>> 
>> (discuss3) - section 3 says "the I2RS protocol requires mutually 
>> authenticated I2RS clients and I2RS agents communicating over a 
>> secure transport." To me that implies that something like TLS or
>> SSH is MTU which seems to contradict recent emails.
>> 
>> - section 3 says: "The I2RS protocol MUST be able to provide 
>> atomicity of an I2RS transaction, but it is not required to have 
>> multi-message atomicity and roll-back mechanism transactions. 
>> Multiple messages transactions may be impacted by the
>> interdependency of data."  I don't believe that that's easily
>> enough understood to be useful. Also, wouldn't s/Multiple messages
>>  transactions/Multiple-message transactions/ be much clearer if
>> that's what's meant? And finally, I think the MUST embedded in the
>> above is not that great an idea - it's clearer IMO to separate the
>> 2119 language from introductory text in documents like this.
>> 
>> - 3: "There are dependencies in some of the requirements below"
>> would be better as "There are inter-dependencies between some of
>> the requirements below" unless you mean dependencies on some
>> external things, which is not clear from the text as-is.
>> 
>> (discuss4) " For confidentiality (section 3.3) and integrity
>> (section 3.4) to be achieved, the client-agent must have mutual
>> authentication (section 3.1) and secure transport (section 3.2).  "
>> This is incorrect. One can have confidentiality without
>> authentication (see RFC7435) so the text is not accurate.
>> 
>> - capitalisation needs fixing in various places, e.g. around the
>> end of p5, we get "secure Transport" and then "I2RS client" and
>> "I2RS Agent" in the title of 3.1 Is any of that capitalisation
>> supposed to be significant? Either way, fixing it now would be good
>> as you'll need to get the RFC editor to do it later if you don't
>> (which takes longer).
>> 
>> (discuss5) SEC-REQ-01: what is the scope of uniqueness required
>> here? I see no reason why two different data centres cannot re-use
>> a client or agent identifier, if they so wish. I'd be fine if you
>> say that's for later decision, but being silent on the matter could
>> lead to trouble later if different folks decide differently.
>> 
>> (discuss6) SEC-REQ-02: the "MUST utilize" there means MTU, which 
>> wasn't what you wanted I think
>> 
>> (discuss7) - SEC-REQ-03: how is "upon receiving... MUST confirm" a 
>> good choice? As stated that'd be hugely onerous, implying e.g.
>> OCSP checks for each packet received. Same point applies to
>> SEC-REQ-04.
>> 
>> (discuss8) - SEC-REQ-05: this either means nothing at all (being a 
>> tautology) or else something I don't get. I think it's the former, 
>> but am not sure.
>> 
>> - 3.1: s/One mechanism such mechanism/One such mechanism/ I guess. 
>> And it's not at all clear to me "AAA protocols" is the right idea 
>> there, and nor is it clear what's meant, with the text as-is.
>> 
>> - SEC-REQ-06: where is a "priority" defined?
>> 
>> - SEC-REQ-07: here you say read/write is a transaction, but
>> earlier you said it was an operation, which is it?
>> 
>> (discuss9) 3.2: As with others, I don't think the idea of
>> annotating parts of yang modules with "can be insecure" is a good
>> one. There's a separate thread discussing that though, so maybe
>> better to not fork that.
>> 
>> (discuss10) - SEC-REQ-O9: I hate to do this to ya, but BCP107 is
>> IMO a fairly clear failure when it comes to routing. And yet again
>> the exceptions clauses here are so broad as to be meaningless
>> (e.g. considered low value by whom?). What is the real goal here?
>> (other than an attempt to keep the sec ADs from being annoying and
>> trying to insist on BCP107? ;-)
>> 
>> (discuss11) - SEC-REQ-09: Separately, to my other would-be-discuss 
>> point on this requirement, "can guarantee" is well beyond the
>> state of the art in key management. I'd just drop that sentence
>> maybe, but can't make a concrete suggestion until I understand
>> where you want to be wrt BCP107.
>> 
>> - SEC-REQ-10: the last sentence here is also involved in the "may
>> do stuff insecurely" thing, and so will likely need fixing when
>> that is fully resolved.
>> 
>> - How is SEC-REQ-11 useful? What protocol artefacts do you have in 
>> mind here? Perhaps a requirement that DDoS attacks be specifically 
>> considered in I2RS would be more useful.
>> 
>> - SEC-REQ-12: This seems to me to have too many words, e.g. the 
>> current text could be read to imply that outside of critical 
>> infrastructure there is less or no need for confidentiality, so
>> those added words (presumably there to motivate) might be 
>> counter-productive.
>> 
>> (discuss12) SEC-REQ-12: I don't get the meaning of the SHOULD here
>> - combined with "certain data" that SHOULD seems to end up meaning
>> MAY, as in, it seems to mean the same as "Read/write operations MAY
>> have to be protected using a confidentiality service."
>> 
>> - 3.4, bullet (2) here means that we're not talking about data 
>> integrity but data origin authentication as well.
>> 
>> (discuss13) 3.4, (3): Within what scope must replay be detected?
>> The text implies for ever, which can be very onerous. SEC-REQ-14
>> doesn't quite go so far, but is ambiguous on this aspect. I'd say
>> best is to note that the scope within which replay needs to be
>> detectable is for future study.
>> 
>> (discuss14) SEC-REQ-15: Sorry, I don't understand what's required 
>> here (having read this >1 time). Can you explain?  I'm not sure if 
>> any substantive change is needed, but there are certainly
>> editorial changes needed for sure as there are multiple wording
>> problems with the text as-is.
>> 
>> - 3.5, 1st para: the text here is not as good as the actual 
>> definition of "role" in RFC7921, and in fact I found the text here 
>> confusing. Better to just delete that and say that 7921 defines 
>> roles.
>> 
>> (discuss15) SEC-REQ-16: I don't see any content in this text as it 
>> seems to just say "some role based access control and some level
>> of transport protection need to be provided" which is always true,
>> as you are allowing "no transport security" and (I assume) "fully 
>> public access" so any protocol/system will always meet this 
>> requirement.
>> 
>> - SEC-REQ-16: "privacy requirements" here is wrong, you mean 
>> confidentiality I think.
>> 
>> (discuss16) SEC-REQ-17: "MUST work" is far too vague. That could
>> for example hide a major debate about push v. pull of role
>> information. If the WG haven't considered that, I think you could
>> ack that again by saying that more work is needed to define how
>> RBAC is consistent across multiple transport layer connections.
>> 
>> (discuss17) SEC-REQ-18: again this seems to have no content, other 
>> than perhaps imposing an odd requirement on implementations - I
>> don't see a protocol requirement here at all. It is reasonable to
>> note that libraries for clients ought not assume a single client
>> identity but even that's very specific to library implementations
>> and since it's just a MAY that's entirely obvious, I'd leave it
>> out.
>> 
>> (discuss18) SEC-REQ-19: I fully agree with the motivation here but
>> I think the stated requirement is broken.  For example, I don't
>> know how a piece of s/w will determine whether or not it is
>> correlated with a person. I also don't think a SHOULD works here,
>> as again something would need to be stated about the situations
>> when the feature is not needed, and I can't figure out a sensible
>> statement for that. The last sentence also seems likely not useful.
>> All in all, I think this is likely to be ignored or even worse
>> treated like a piece of fig-leaf specification text to pretend that
>> we're caring about privacy.
>> 
>> (discuss19) - 3.6: I have no idea whether this other draft is 
>> supposed to be considered as setting requirements or not. I assume 
>> that the answer is "not" as you've made it an informative
>> reference, but in that case you really should say that.  The
>> alternative would be that 3.6 is essentially specifying an
>> applicability statement for the environments in which it is, and is
>> not, ok to run i2rs. If the latter were intended, then you'd need
>> to say it and make the draft a normative reference.
>> 
>> 
>> _______________________________________________ i2rs mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/i2rs
>> 
>