v09 posted https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/
This version should have all discussed changes across all reviewers. Eric > Hiya, > > On 17/05/16 20:10, Eric Voit (evoit) wrote: > > + more > > Looks like we're sorted. Just shoot out a rev with those > changes and I'll clear, > > Thanks, > S. > > > > >> From: Stephen Farrell, May 17, 2016 2:24 PM > >> > >> > >> Hiya, > >> > >> On 17/05/16 18:45, Eric Voit (evoit) wrote: > >>> Hi Stephen, > >>> > >>>> Stephen Farrell, May 03, 2016 8:23 PM > >>>> > >>>> Stephen Farrell has entered the following ballot position for > >>>> draft-ietf-i2rs-pub-sub-requirements-06: 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-i2rs-pub-sub-requirements/ > >>>> > >>>> > >>>> > >>>> > >>>> > >> ---------------------------------------------------------------------- > >>>> DISCUSS: > >>>> ---------------------------------------------------------------------- > >>>> > >>>> > >>>> > >>>> > >> I have what I hope are two very easily sorted things that I'd like to > >> chat about: > >>>> > >>>> (1) 4.2.5, para2: > >> > >> It's para 3 now. Not sure if that changed in this rev or if > >> I goofed. If the latter, apologies;-) > > > > Yes. That is what caught me too. I was answering for Paragraph 2. > > > >>>> Hang on - this is 2016 isn't it? :-) Why would we > >>>> ever have a pub/sub service whose subscribers can pretend to be the > >>>> service? > >>> > >>> I am not sure I understand. The Subscription Service is located on > >>> the Publisher. Having the Publisher and Subscriber mutually > >>> authenticate each other makes sense. > >>> > >>> If you mean something else and you are wondering if whether a > >>> Subscriber can also be a Publisher for the information it receives, > >>> yes it can. Having a collector/controller as a middle-man is a very > >>> valid implementation. But there is nothing which binds such > >>> independent subscriptions together. > >> > >> The problem is that the text says "it SHOULD be possible to provide > >> cryptographic authentication in such a way that no Subscriber can > >> pose as the original Subscription Service" > >> > >> I see no reason for that SHOULD. The implication I take from it > >> is that someone wants to use purely symmetric keying which seems > >> pretty odd. I'd say better text would be to say that "Subscribers > >> MUST NOT be able to pose as the original Subscription Service" > >> maybe. > > > > Your text is better. Changed. > > > >>> > >>>> (2) Don't you need a statement somewhere that commensurate security > >>>> needs to be provided for pushed notifications as was used for the > >>>> original subscription? That might be a little hard to phrase > >>>> correctly but I hope we agree that the notifications ought not be > >>>> significantly less secure than the subscription. > >>> > >>> We had some interactions with Ben Campbell on this topic. In > >>> general we are doing our best to decouple the subscription > >>> establishment and maintenance from the underlying transport options. > >>> This is because there are implementations (for example wholly within > >>> an MSDC) which don't require payload encryption. Still most > >>> implementations should have transport encryption. So after several > >>> interactions with Ben, the text leading off Section 4.2.5 now reads: > >>> > >>> Some uses of this Subscription Service will push privacy-sensitive > >>> updates and metadata. Good deployment practices will bind this > >>> generated information within secure, encrypted transport layer > >>> mechanisms. For example if NETCONF is used as transport, then > >>> [RFC5539] would be a valid option to secure the transported > >>> information. The Subscription Service can also be used with > >>> emerging deployment contexts as well. As an example, deployments > >>> based on [i2rs-usecase] can apply these requirements in conjunction > >>> with those documented within [i2rs-protocol-security] to secure > >>> ephemeral state information being pushed from a Network Element. > >>> > >>> Does this hit your objective? > >> > >> Not quite, though it is related. > >> > >> If you added "Commensurate strength security mechanisms MUST > >> be defined (and SHOULD be used) for all of the stages of > >> the pub/sub process, for example using the same algorithms > >> and endpoints for keying for both subscription and publication > >> stages would seem advisable." > >> > >> The thing to avoid is e.g. using some really strong mechanism > >> for the subscription but something much weaker or with worse > >> endpoints for the publication (or vice versa). > >> > >> Sorry if that wording is a bit vague, I didn't re-read the > >> entire doc to get the context right. > > > > I see what you are getting at now. How about the requirement text: > > > > "For any encrypted information exchanges, commensurate strength security > mechanisms MUST be available and SHOULD be used. This includes all stages of > the Subscription and update push process." > > > > Thanks, > > Eric > > > > > > > >> Cheers, > >> S. > >> > >>> > >>> Eric > >>> > >>>> > >>>> ---------------------------------------------------------------------- > >>>> > >>>> > >> COMMENT: > >>>> ---------------------------------------------------------------------- > >>>> > >>>> > >>>> > >>>> > >> - I wondered if this was maybe of interest to more than just i2rs, and > >> if so, > >>>> whether any effort had been made to try figure out if these > >>>> requirements work for folks who don't care about i2rs? It'd seem a > >>>> shame to work on this but stop one step short of being > >>>> appropriately general. (But you probably already checked that I > >>>> guess.) > >>>> > >>>> - 4.2.2, last para: The MUST here seems like it may be quite > >>>> onerous, in general. Did someone think all of that through? For > >>>> example, what if the reason for declining is that the Subscriber > >>>> doesn't have sufficient privilege? Saying what privilege is needed > >>>> would be a breach of least-privilege. Transient errors may also > >>>> make this very hard to do well. I'd suggest s/MUST/MAY/ and to also > >>>> turn the information returned into a hint and not a promise. > >>>> > >>>> - 4.2.5, para 1: saying there "MUST be mutual authentication" is > >>>> odd - the usual terms would be "MUST implement" or "MUST use" which > >>>> of those does "MUST be" mean? > >>>> > >>>> - 4.2.8: when you say fetch... by whom? Is there an implicit > >>>> requirement in the title of the subsection? > >>>> > >>>> > >>>> _______________________________________________ i2rs mailing list > >>>> [email protected] https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
