IETF
dmarc
dmarc@jabber.ietf.org
Monday, March 19, 2018< ^ >
Room Configuration
Room Occupants

GMT+0
[09:34:13] Kurt Andersen joins the room
[11:13:34] Kurt Andersen leaves the room
[11:13:34] Kurt Andersen joins the room
[12:51:04] Kurt Andersen leaves the room
[13:00:30] Kurt Andersen joins the room
[14:46:04] Kurt Andersen leaves the room
[15:37:49] Kurt Andersen joins the room
[15:51:34] Kurt Andersen leaves the room
[15:51:39] Kurt Andersen joins the room
[16:04:20] <Kurt Andersen> We'll have a collaborative note taking document for the dmarc-wg - link is at https://bit.ly/ietf101dmarc
[17:09:04] Kurt Andersen leaves the room
[17:17:46] Kurt Andersen joins the room
[17:26:18] meetecho joins the room
[17:31:27] ssQ7WHPW joins the room
[17:31:44] Barry Leiba joins the room
[17:32:47] Yoshiro Yoneya joins the room
[17:34:26] <Kurt Andersen> Can anyone hear us on meetecho?
[17:34:28] <Barry Leiba> Can the remote people (Alessanro, Yoshiro) hear us?
[17:34:45] <Kurt Andersen> and can you see the title slide?
[17:34:58] <meetecho> Kurt, Barry: the access is not open yet, it will in a minute
[17:35:06] <Barry Leiba> Ahhhhh
[17:35:09] Andreas Schulze joins the room
[17:35:09] David Illsley joins the room
[17:35:13] Tim Draegen joins the room
[17:35:13] Dave Crocker joins the room
[17:35:14] <meetecho> we typically "open the doors" five minutes before the meeting
[17:35:18] <meetecho> aaaand they're in :)
[17:37:44] <Kurt Andersen> To all the remote people - can you hear us on the meetecho  stream?
[17:37:54] <Kurt Andersen> and see the slide?
[17:38:24] <Kurt Andersen> @tim - looking at you…
[17:40:23] <Tim Draegen> Sure can!
[17:40:37] <Tim Draegen> Sorry, biology
[17:40:49] Suzanne joins the room
[17:41:22] <Tim Draegen> (minor connectivity hiccup)
[17:41:40] <Yoshiro Yoneya> Sorry, I'm not using audio stream.
[17:42:40] Scott Rose joins the room
[17:42:41] fenton joins the room
[17:43:19] Seth Blank joins the room
[17:46:22] fenton leaves the room
[17:46:56] <Tim Draegen> DMARC WG tracker link (also used for ARC issue tracking): https://trac.ietf.org/trac/dmarc/report
[17:47:04] <Dave Crocker> Mic: While valid, the problem with Jim's point is that it requires making each aspect of a service separate.  DKIM publishing/singing vs. DKIM reception/validation.  DMARC has 3 components, so it needs 3 docs. I think the original focus on expected rate of change is more helpful.
[17:47:11] <Barry Leiba> After John
[17:48:06] fenton joins the room
[17:48:13] Seth Blank leaves the room
[17:48:18] <Dave Crocker> (what is the key of DKIM 'singing'?)
[17:48:39] <Kurt Andersen> B flat
[17:49:03] <fenton> minor
[17:49:25] Seth Blank joins the room
[17:49:27] <Tim Draegen> all-in-one when experimental +1
[17:49:36] <Dave Crocker> Mic: the benefit of keeping it in a single doc is likelihood readers will see it.
[17:49:39] Steve Jones joins the room
[17:49:52] <Dave Crocker> Mic: Each sub-function should get an official 'name".  
[17:50:27] Ned Freed joins the room
[17:50:36] <Seth Blank> I've been having issues with meetecho, and feel strongly on the other side (separate docs), but will save my commentary for the list
[17:50:50] Haizhou Xiang joins the room
[17:52:23] Haizhou Xiang leaves the room
[17:52:31] <Seth Blank> Only other question is if anything is missing from the Experimental Considerations section that should be reflected in the doc for last call
[17:53:05] <Seth Blank> Yes, invitation if anyone thinks there are missing items
[17:54:30] <Seth Blank> Agreed, ideally post-Experimental data
[17:54:38] Satoru Kanno joins the room
[17:54:43] <Tim Draegen> mic: maybe put a note in the Experimental doc that WG are actively seeking data
[17:56:42] <Steve Jones> Offline comment: IIRC the Usage doc for ARC was originally needed to explain why/how people would make use of ARC. If those questions are now answered in main spec, great. If not, maybe retitle an Experimental Recommendation Guide? Agreed that a Usage guide should be produced based on real world experience - existing guide was to help us get to that point.
[17:58:41] <Tim Draegen> :)
[17:59:12] William Zhang joins the room
[17:59:35] fenton leaves the room
[18:01:08] William Zhang leaves the room
[18:02:46] fenton joins the room
[18:02:49] <Dave Crocker> MIC:  Given the degree of IETF objection to DMARC's lack of comfortable processing through intermediaries, I doubt DMARC can go without it.
[18:03:07] <Dave Crocker> yes
[18:03:51] <Tim Draegen> List of DMARC interop issues here: https://trac.ietf.org/trac/dmarc/wiki/MilestoneOneWiki
[18:04:34] <Dave Crocker> MIC: I suggest documenting DMARC experience, issues, and projected changes that are believed sufficient to justify standardization.Get wg consensus on the doc. Then circulate it to the IETF and the IESG, soliciting comments.  This would serve as a non-binding community feedback exercise.
[18:07:02] <Seth Blank> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-12#section-12.2
[18:07:12] <Seth Blank> (To Bron's point, that's explicitly called out in the spec)
[18:08:09] <Dave Crocker> MIC: Barry's point is worth separate, careful discussion.  It's not the first time this scenario has come up for ARC.  It might not be possible to make it work adequately, but I think it actually might be useful.
[18:08:29] Andreas Schulze leaves the room
[18:08:39] <Tim Draegen> Of all of the identified interop issues, calendaring is one of the sharper unaddressed breakage points.
[18:09:14] <Dave Crocker> MIC: here's the teaser for why it might work:  'normal' use of ARC requires having a basis for trusting the first ARC signer.  So would the third-party origination.
[18:09:27] <Steve Jones> Both are origination of a message at a third party. ARC isn't designed for this.
[18:10:13] <Steve Jones> Both points
[18:10:25] <Tim Draegen> Forwarding of calendar invites
[18:10:53] <Dave Crocker> MIC: calednaring is quite a nice example.
[18:11:19] <Tim Draegen> Yes; there is a lot of breakage in different contexts; just pointing out it needs some discussion
[18:11:39] <Dave Crocker> MIC: As host of a meeting, I want calendaring mail about an event to be on my behalf, which means it's best if it is 'from' me.
[18:11:53] <Seth Blank> ARC helps where an intermediary breaks authentication information, allowing it to be encapsulated and transmitted. When the originator never authenticates properly to begin with, that's out of scope...
[18:12:22] Suzanne leaves the room
[18:12:58] <Seth Blank> What Dave called out earlier, we should get all open issues with DMARC into the issue tracker
[18:14:49] <Tim Draegen> Mic: "draft DMARC usage guide" (required to exit phase 2) is expired: https://trac.ietf.org/trac/dmarc/wiki/MilestoneOneWiki
[18:14:59] <Tim Draegen> sorry, wrong link: https://datatracker.ietf.org/doc/draft-tdraegen-dmarc-usage-guide/
[18:15:10] <Tim Draegen> no, expired doc
[18:16:23] <Tim Draegen> yay!
[18:19:15] <Seth Blank> Agreed that this is a real issue. Also being seen with US .gov, and other gtld's like .microsoft and .bank
[18:19:51] <Dave Crocker> MIC: this seems both useful and unrelated to DMARC.
[18:20:45] <Seth Blank> MIC: it's related to DMARC because of how an "organizational" domain is defined, and there are instances where the organization is the top level and they no longer have control of DMARC policy
[18:22:15] <Dave Crocker> MIC:the relationship to DMARC needs to be made /very/ careful.
[18:22:39] <Ned Freed> I agree; I'm not convinced this should be addressed with DMARC.
[18:23:29] <Steve Jones> First, perhaps we need to be clearer how much freedom the report generator has re: what details are included in a forensic report.
[18:25:44] <Steve Jones> Second, haven't looked recently, but perhaps one or two examples of an information rich forensic report, and a very heavily redacted forensic report.
[18:25:54] <Dave Crocker> MIC: Might be interesting to split the entire reporting mecvhanisms from the alignment-requirement mechanism.
[18:26:19] Andreas Schulze joins the room
[18:26:25] <Dave Crocker> ls
[18:27:24] <Dave Crocker> MIC: reporting is more general, separate from the from-field enforcement.
[18:27:32] <Steve Jones> In spec or separate doc is fine, but provide examples of the intermediate content flavor NCSC was suggesting.
[18:36:03] <Dave Crocker> MIC: Consider this as independent of DMARC.  Consider whether it is useful for a receiving filter engine to know that there is no From field alignment. It's an added evaluation point, not a policy assertion.
[18:37:48] Suzanne joins the room
[18:39:48] <Ned Freed> Boil it down: Exactly what is this additional header field telling us?
[18:40:23] fenton leaves the room
[18:40:25] <Steve Jones> The only place this would be seen is within the receiver, or if the message is forwarded.  The receiver is free to do whatever they want internally. What would be the impact of an additional dmarc= value if the message is forwarded? Answer/discussion on the list.
[18:40:29] <Seth Blank> Thank you!
[18:40:42] <Tim Draegen> (Y)
[18:40:52] <Steve Jones> Thank you all!
[18:40:53] <Ned Freed> Bye
[18:40:55] Barry Leiba leaves the room
[18:40:59] <Andreas Schulze> Bye
[18:41:04] <Dave Crocker> MIC: thanks for having the session later in the day.
[18:41:06] meetecho leaves the room
[18:41:12] <Steve Jones> +1
[18:41:18] Ned Freed leaves the room
[18:41:18] Steve Jones leaves the room
[18:41:18] David Illsley leaves the room
[18:41:18] Dave Crocker leaves the room
[18:41:18] Satoru Kanno leaves the room
[18:41:18] Scott Rose leaves the room
[18:41:18] Seth Blank leaves the room
[18:41:18] Tim Draegen leaves the room
[18:41:19] Andreas Schulze leaves the room
[18:41:25] Yoshiro Yoneya leaves the room
[18:42:01] Suzanne leaves the room
[18:43:35] Kurt Andersen leaves the room
[22:41:22] Kurt Andersen joins the room
[22:53:36] Kurt Andersen leaves the room
[23:02:01] Kurt Andersen joins the room
[23:14:05] Kurt Andersen leaves the room
[23:22:41] Kurt Andersen joins the room
[23:35:05] Kurt Andersen leaves the room
[23:43:20] Kurt Andersen joins the room
[23:55:35] Kurt Andersen leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!