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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
