Re: [Id-event] SecEvent draft minutes - IETF-101 (London)

[Marius Scurtescu <[e-mail]>]

Agreed, having two different protocols in one document makes it more
complicated for implementers (or anyone trying to wrap their head around
what they need).

And again, with one document we are unnecessarily slowing one and rushing
the other delivery method.

Marius

On Mon, Apr 9, 2018 at 3:15 PM, Dick Hardt <[e-mail]> wrote:

> So someone needs to read about two methods instead of just the one that
> the profile says they need to read? Seems simpler for someone to read a
> Push spec if all they need is to do Push, instead of having to read a spec
> that describes both, and then trying to decipher which aspects are relevant
> for them.
>
> On Mon, Apr 9, 2018 at 3:13 PM, Morteza Ansari (moransar) <
> [e-mail]> wrote:
>
>> I definitely agree that we shouldn't specify an MTI at the protocol spec.
>> I think each profile should be specifying that as part of the profile
>> definition and semantics.
>>
>> And if we don’t have an MTI at the protocol document, I think we are much
>> better off with a single protocol document covering different protocols in
>> the same document. It will be all in one place for developer to choose,
>> much easier to maintain the common language common and not let them
>> diverge, and we could even describe scenarios one would be preferred over
>> the other as hints and suggestion to the developers.
>>
>>
>> Cheers,
>> Morteza
>>
>> On 4/9/18, 2:31 PM, "Id-event on behalf of John Bradley" <
>> [e-mail] on behalf of [e-mail]> wrote:
>>
>>     I think splitting the drafts was an attempt to get around declaring
>> one or the other method MTI.
>>
>>     Clearly due to deployment constraints many people will only be able
>> to do one or the other.
>>
>>     Having them both in the same draft would be best if we don’t wind up
>> having to declare one or both MTI.
>>
>>     John B.
>>     > On Mar 30, 2018, at 7:53 AM, Mike Jones <
>> [e-mail]> wrote:
>>     >
>>     > I agree with Phil that having separate push and pull delivery
>> drafts would be a mistake.  Many participants will end up implementing both
>> modalities.  Having them both in one draft will help keep them as common as
>> possible - preventing unnecessary and possibly unintended drift between
>> them.
>>     >
>>     > Also, as I said at the microphone in London, I think we'll have a
>> much easier time with the IESG taking one draft forward with two closely
>> related delivery modalities defined, rather that two different delivery
>> drafts.  I fear that if we try to get approval for two drafts, we might
>> receive DISCUSS feedback saying "pick one".
>>     >
>>     > For what it's worth (and to inform people who weren't in the room),
>> my personal sense was that the hums weren't conclusive.  Most of them had
>> significant portions of people humming for both positions.  In short, my
>> (personal) sense was there wasn't clear consensus demonstrated to split the
>> delivery draft.  I think the topic needs more discussion on the list.
>>     >
>>     >                           Best wishes,
>>     >                           -- Mike
>>     >
>>     > -----Original Message-----
>>     > From: Id-event <[e-mail]> On Behalf Of Phil Hunt
>>     > Sent: Thursday, March 29, 2018 10:15 PM
>>     > To: Yaron Sheffer <[e-mail]>
>>     > Cc: SecEvent <[e-mail]>
>>     > Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London)
>>     >
>>     > Regarding the hums, I think they may be premature. In part, because
>> there is a unifying draft proposal available now.
>>     >
>>     > When we formed the group the sole purpose was a common format and a
>> single delivery draft for all cases.
>>     >
>>     > Several ietf people complained in Argentina about yet another pub
>> sub system the ietf does not need.
>>     >
>>     > Another comment was made not to follow the route stix/taxii made in
>> developing multiple incompatible methods of delivery.
>>     >
>>     > If we split the draft we will have 3 methods not two(including
>> Backchannel).
>>     >
>>     > I worry this will lead to delay from rejection down the road. This
>> should be clarified first.
>>     >
>>     > I worry with multiple methods, profilers will develop their own
>> undermining the point of this work.
>>     >
>>     > Maybe I stand alone here, but I think splitting is a mistake.
>>     >
>>     > Phil
>>     >
>>     >> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer <[e-mail]>
>> wrote:
>>     >>
>>     >> Thank you Valery for taking the minutes. All, please let us know
>> if anything is incorrect or missing.
>>     >>
>>     >> In addition, we had a series of hums on the SET Delivery draft.
>> Per IETF process, we need to validate them on the list. So if you weren't
>> in the room and you have a major objection to the results of these hums,
>> please speak up. I do suggest that before doing so, you review the actual
>> recorded meeting: https://urldefense.proofpoint.
>> com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN
>> 6s&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
>> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bZnIUtQK2S3enq
>> Q3E8wJZHxLExg0UyssjEM1UAJ18jw&s=VbJxhADDKAULj3hrOYI1cbC5A8hE
>> mFIesTvuGzkkOP0&e=.
>>     >>
>>     >> IETF 101 London Friday 23 March 2018 9:30 - 11:30
>>     >>
>>     >> [Yaron] (WG status update, agenda bashing) [Annabelle] asks for 10
>>     >> minutes for discussion
>>     >>
>>     >> [Mike] (presents Security Event Token draft update)
>>     >>
>>     >> [Annabelle] (presents SET Token delivery using HTTP draft) [Mike]
>>     >> Microsoft needs for both POLL and PUSH [Phil] Redefining smth in
>> HTTP
>>     >> may cause problems [William] Return codes are only for browsers to
>>     >> display messages for users [Phil] It's needed for resending in
>> case of
>>     >> error (?) [Annabelle] What is MTI - push or poll?
>>     >> [Phil] With PUSH  happened immediately...
>>     >> [Leif] What is MTI for server or for client?
>>     >> [William] Each option has an explicit use case [Yaron (as chair)]
>> We
>>     >> need to have only one preferred option [Phil] There are very
>> different
>>     >> cases [Phil] Push is simple, but in terms of applicability it's
>> not a
>>     >> long term use case [Annabelle] There use cases for both [Phil] Take
>>     >> two and then abandon one [William] Why does the chair require a
>> single
>>     >> MTI [Leif] It's from chair's experience, WG consensus needed
>> [William]
>>     >> We have use cases for both [Mike] Procedurally it's better to keep
>>     >> both methods in one draft [Yaron] Having two methods complicates
>> the
>>     >> description which method is for which situation etc.
>>     >> [William] Still have interoperability issue for receiver [Yaron]
>> Need
>>     >> to resolve this [Leif] WG should decide [Ben as AD] If the WG
>> doesn't
>>     >> select a single method the IESG would probably object [Annabelle]
>> SET
>>     >> will probably be profiled for different use cases [Yaron] Is going
>> to
>>     >> make hums about selecting a single delivery method and whether we
>> need
>>     >> to split the draft [John] What is hum about - mandatory to
>> implement or to deploy?
>>     >> [Leif] We should analyze scenarios
>>     >> [Annabelle] The protocol are unidirectional, so MTI for
>>     >> transmitter/receiver is problematic [Justin] No negotiation,
>> either it
>>     >> is or not, MTI for the receiver is dictated by what the receiver
>>     >> supports [Phil] They both must be able HTTP, the roles can be
>> changed
>>     >> [Leif] Confusion between MTI and to deploy, a good question -
>> select
>>     >> MTI for transmitter [Annabelle] Every transmitter should have both
>>     >> [Tero] Minimal implementation requires one, bigger may have both,
>>     >> single MTI is better then two for limited devices [Annabelle] IoT
>>     >> implementers have special requirement [William] They are
>> application
>>     >> specific, we expected profile this [Yaron] Hum if we need a single
>> MTI
>>     >> for transmitter - silence Later edit: Clearly no support for a
>> single MTI.
>>     >> [Justin] Hum must be for multiple discrete options [Yaron] Hum on
>> use
>>     >> cases for two methods - some hums [Yaron] Hum if both should be
>> MTI -
>>     >> some hums [Yaron] Hum if should not specify MTI - some hums Later
>>     >> edit: room was split between two MTIs and no MTIs.
>>     >> [Annabelle] We should split the spec
>>     >> [Justin] Agree to split the spec
>>     >> [Justin] I hummed for both MTI for transmitter, because they are
>> not
>>     >> usually constrained [Annabelle] SET is possibly to be used w/o
>> HTTP,
>>     >> this is only MTI for those using HTTP; both MTI is problematic
>> because
>>     >> implementers will do unnecessary stuff [William] If both are MTI,
>> we
>>     >> need 2 specs [John] Splitting the spec is the best way [Mike] If
>>     >> split, then the information for developers will be duplicated [Ben]
>>     >> Why single document better (?) [Mike] My experience with JOSE
>>     >> [Annabelle] Significant overlap between documents is SET, otherwise
>>     >> little commonality Later edit: existing editors volunteered to
>> take Push-specific doc, Annabelle and Mike volunteered to work on Poll.
>>     >> [from jabber] Little commonality between two methods [Mike] We'll
>> do
>>     >> both, we have use cases for both [Yaron] Hum if split documents -
>> some
>>     >> long hums [Yaron] Hum if one document - some hums [Yaron] Room is
>> in
>>     >> favor of splitting the documents [Yaron] Wrap up: no MTI, split the
>>     >> document into two, transmitter implements either or both
>>     >>
>>     >> [Annabelle] (presenting Subject Identifier Types) [Mike] 3rd party
>>     >> specifications cannot establish IANA registry [Leif] IANA Expert?
>>     >> [Ben] FCFS, doesn't need Expert, or specification required [Leif] I
>>     >> support this idea [William] I also support [Yaron] Any objections
>> to
>>     >> adopt this document? No objections, publish as WG document
>>     >>
>>     >> [Annabelle] Expiration ("exp") claim is not recommended; however it
>>     >> has some value [Mike] It's a layering violation; problems with
>> caching
>>     >> [Annabelle] We're not talking about caching, you don't want to grow
>>     >> anti-replay database forever, having expiration helps [Phil] The
>> past
>>     >> doesn't expire, it's up to receiver how to use it, caching doesn't
>> make sense [Yaron] What about replay protection?
>>     >> [Mike] JTI helps to detect replay (?) [from jabber] Transport
>> should
>>     >> deal with replay [John] Expiry is expected to mean that token
>> should
>>     >> not be processed after that, it's not an indication that
>> information
>>     >> is no longer valid [Mike] It must not be mandatory [Annabelle]
>>     >> Currently the draft says it's not recommended [Mike] We have to
>> allow it to be optional because of the need to distinguish from access
>> tokens.
>>     >> [Ben] Some use case when processing expired token (?) [John] Have
>> an
>>     >> explicit expire for JTI, there are other solutions [Phil] I prefer
>> to
>>     >> add a new attribute to SET, not changing ...
>>     >> [Yaron] The document in LC, smaller changes are OK without
>> blocking the doc's progress.
>>     >> [Phil] Replay and caching are different for PUSH and POLL, prefer
>> to
>>     >> see in HTTP header [Brian] Expiration is not necessary, receiver
>> has
>>     >> policy to follow [Annabelle] No-one is advocating using exp for
>>     >> caching [from jabber] JTI expiration belongs to JTI not to
>> transport
>>     >> [Yaron] We're not ready to have hum, room thinks there is an
>> issue, please work through it on the list.
>>     >>
>>     >> [Phil] Presents his SSTP Delivery draft - symmetric transport
>>     >> protocol, parameters used in requests and response are same [Phil]
>> We
>>     >> would change optionality from two methods to a single one, may be
>> a compromise [Yaron] The protocol was only published yesterday, so we are
>> not ready to discuss now.
>>     >>
>>     >> [Meeting adjourned.]
>>     >>
>>     >> _______________________________________________
>>     >> Id-event mailing list
>>     >> [e-mail]
>>     >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mail
>>     >> man_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8B
>> v7qIrMUB65
>>     >> eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=
>> bZnIUtQK2S3en
>>     >> qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=bm9Kqkwb8W8ClkdHFvnnH60BmAr
>> jysl02dP_3
>>     >> TAjwew&e=
>>     >
>>     > _______________________________________________
>>     > Id-event mailing list
>>     > [e-mail]
>>     > https://www.ietf.org/mailman/listinfo/id-event
>>     >
>>     > _______________________________________________
>>     > Id-event mailing list
>>     > [e-mail]
>>     > https://www.ietf.org/mailman/listinfo/id-event
>>
>>     _______________________________________________
>>     Id-event mailing list
>>     [e-mail]
>>     https://www.ietf.org/mailman/listinfo/id-event
>>
>>
>> _______________________________________________
>> Id-event mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/id-event
>>
>
>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>
>