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

[Dick Hardt <[e-mail]>]

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-3Dr0hbpQqsN6s&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=
> bZnIUtQK2S3enqQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=
> VbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP0&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.
> ietf.org_mail
>     >> man_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIr
> MUB65
>     >> eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPk
> AI1aLcLN4KZNA&m=bZnIUtQK2S3en
>     >> qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=bm9Kqkwb8W8ClkdHFvnnH60BmArjys
> l02dP_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
>