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

From: Yaron Sheffer <[email-masked]>
Date: Sat, 24 Mar 2018 17:00:28 +0300

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://www.youtube.com/watch?v=r0hbpQqsN6s.

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.]

---

From: Phil Hunt <[email-masked]>
Date: Sat, 24 Mar 2018 08:12:30 -0700

Some corrections for minutes inline regarding http status. 

Phil

> On Mar 24, 2018, at 7:00 AM, Yaron Sheffer <[email-masked]> 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=.
> 
Redefining status codes in http may cause problems
> [Phil] It's needed for resending in case of error (?)
There was some other discussion i believe it was about status 400 which informs the client of jwt related error and that using status 403 would not let clients be able to differentiate between authz error and jwt error. 
> [Phil] Push is simple, but in terms of applicability it's not a long term use case
> [Yaron] Having two methods complicates the description which method is for which situation etc.
> [Ben as AD] If the WG doesn't select a single method the IESG would probably object
> [Yaron] Is going to make hums about selecting a single delivery method and whether we need to split the draft
> [Annabelle] The protocol are unidirectional, so MTI for transmitter/receiver is problematic
> [Leif] Confusion between MTI and to deploy, a good question - select MTI for transmitter
> [Tero] Minimal implementation requires one, bigger may have both, single MTI is better then two for limited devices
> [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
> [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.
> [Yaron] Wrap up: no MTI, split the document into two, transmitter implements either or both
> 
> [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
> [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
> [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] We have to allow it to be optional because of the need to distinguish from access tokens.
> [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
> [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
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bZnIUtQK2S3enqQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=bm9Kqkwb8W8ClkdHFvnnH60BmArjysl02dP_3TAjwew&e=

---

From: Phil Hunt <[email-masked]>
Date: Thu, 29 Mar 2018 23:14:39 -0600

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 <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 30 Mar 2018 10:53:23 +0000

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 <[email-masked]> On Behalf Of Phil Hunt
Sent: Thursday, March 29, 2018 10:15 PM
To: Yaron Sheffer <[email-masked]>
Cc: SecEvent <[email-masked]>
Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London)

Phil

> [Yaron] (WG status update, agenda bashing) [Annabelle] asks for 10 
> minutes for discussion
> 
> [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?
> [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?
> 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.
> 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 
> 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 
> 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?
> 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 ...
> [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 
> [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.]
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65
> eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bZnIUtQK2S3en
> qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=bm9Kqkwb8W8ClkdHFvnnH60BmArjysl02dP_3
> TAjwew&e=

_______________________________________________
Id-event mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/id-event

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 30 Mar 2018 15:01:50 +0300

I would rather have people who were NOT in the room chime in regarding 
the hums. Otherwise this is the sense of the group. I don't see value in 
reopening a decision just weeks after it was made.

Thanks,
	Yaron