[09:50:47] --- RandyG has become available
[10:17:31] --- hildjj has become available
[10:18:31] --- SAH has become available
[10:18:48] --- SAH has left
[10:20:59] --- hildjj has left: Logged out
[10:33:19] --- mrose has become available
[10:37:09] --- psa has become available
[10:43:22] --- galvinjamesm has become available
[10:52:16] <galvinjamesm> No scribe here??
[10:52:42] <mrose> we're starting a few minutes late
[10:52:50] <galvinjamesm> thanks
[10:52:56] <mrose> scott and ted have arrived. meeting is starting
[10:53:03] <mrose> now asking for a scribe...
[10:53:20] --- tonyhanse has become available
[10:53:41] --- leifj has become available
[10:54:00] --- hardie has become available
[10:54:08] <mrose> first scribe: marshall rose
[10:54:14] <mrose> tim bray is in the room!
[10:54:54] <hardie> kudos for Tim's AV skills...
[10:54:59] <galvinjamesm> Thanks to the scribe!
[10:55:06] --- rlbob has become available
[10:55:09] --- CSVjohn has become available
[10:55:36] --- paulehoffman has become available
[10:56:08] <mrose> agenda: new wgs and bofs (atom publishing format and protocol, marid, message authentication signatures, protecting entertainment rights management)
[10:56:30] <mrose> agenda: cross-area technical topics (datagram transport layer security)
[10:56:36] <mrose> agenda: mic
[10:56:44] <mrose> scott: reviewing agenda
[10:57:02] --- leg has become available
[10:57:09] <mrose> agenda: volunteer solicitation (apparea mailing lis moderators, mime type reviewers)
[10:57:33] <mrose> tim bray/paul hoffman: atom publishing format and protocol
[10:57:42] --- hildjj has become available
[10:57:50] --- javier has become available
[10:58:34] <mrose> tim: attempt to standardize practice in the area of syndication
[10:59:21] <mrose> tim: why people would care (about 30% of the room reads syndicated feeds)
[11:00:13] <mrose> tim: taking a look at his netnewswire to give people an example of what syndication is.
[11:01:21] --- SAH has become available
[11:02:04] --- sakai has become available
[11:02:05] --- Tom Phelan has become available
[11:02:34] * SAH has set the topic to: atompub
[11:03:17] <mrose> tim: on june 23rd: about 2.8m feeds, 14k blogs created on that day, 270k updates on that day
[11:03:47] <mrose> tim: how it works now: make an xml document available at a well-known URI describing recent updates, clients poll it.
[11:03:58] --- rcg has become available
[11:04:56] --- SAH has left: Replaced by new connection
[11:04:56] --- SAH has become available
[11:05:32] <mrose> tim: what's in a feed: channel info (title, uri, logo, etc.), each channel has item info (author, title, URI, description, etc)
[11:05:38] --- paf has become available
[11:05:57] <mrose> tim: at least 5 different "standards" in the marketplace
[11:06:42] <mrose> tim: the usual problems: too many formats, poorly specifications, technical issues, etc.
[11:08:52] --- Tom Phelan has left: Disconnected.
[11:09:01] <mrose> tim: no "real" APIs for updating newsfeeeds in real-time
[11:09:34] --- SAH has left: Replaced by new connection
[11:09:35] --- SAH has become available
[11:10:28] <mrose> tim: pre-ietf atom: started summer 2003, buy-in from most factions, but not all, atom wiki at http://www.intertwingly.net/wiki/pie
[11:11:53] <mrose> paul: the atompub charter: floated in april, 2004, w3c asked iesg to delay
[11:12:27] <mrose> paul: w3c asks atom folks to go to them for standardization
[11:13:59] <mrose> paul: atom folks decided to go to the ietf
[11:14:21] <mrose> paul: atompub drafts: atom format, atom publishing protocol, perhaps add an implementor's guide
[11:15:50] --- javier has left: Disconnected
[11:16:16] <mrose> paul: mailing list does 200 msgs/wk, 20 active posters, primarily implementors, few ietf folks
[11:18:04] <mrose> paul: tend to avoid f2f meetings (only 10 would have showed in san diego) and no ietf regulars
[11:19:06] <mrose> lisa: it is difficult for chairs to bridge that kind of gap
[11:19:56] --- CSVjohn has left: Disconnected
[11:20:12] <mrose> tim: major technical issues - publication dates semantics? subset http? extensibility?
[11:20:52] --- leifj has left: Lost connection
[11:21:14] --- leifj has become available
[11:21:40] <mrose> paul: more issues: autodiscovery, identifier, context packaging, xml religion?
[11:22:30] --- hartmans has become available
[11:22:45] <mrose> paul: we don't need input, but we can use help
[11:23:02] --- javier has become available
[11:24:27] <mrose> dave crocker: do the milestones include an outside review? paul: no, send an email.
[11:24:43] --- hildjj has left: Replaced by new connection
[11:24:57] <mrose> paul: done.
[11:25:18] --- hildjj has become available
[11:25:19] <mrose> now going to talk, tim can you scribe?
[11:25:51] <psa> hildjj can scribe :P
[11:26:00] <paulehoffman> Tim's working on it.
[11:26:11] <hildjj> mrose: marid
[11:26:24] * psa is scribing in xcon....
[11:26:31] --- timbray has become available
[11:26:34] <paulehoffman> Marshall tells some jokes
[11:26:38] <timbray> Scribing.........
[11:26:59] <hildjj> timbray: thx
[11:27:04] <timbray> Core problem: identify someone talking to an SMTP server
[11:27:09] --- resnick has become available
[11:27:19] <hildjj> we had some wireless hiccups here.
[11:27:19] <timbray> sender-id by Aug, CSV by Nov
[11:27:54] <timbray> (comments are those from MRose)
[11:28:03] <timbray> "a small deliverable in a short time-frame"
[11:28:43] <timbray> Sender-ID: "best hits" compilation of SPF & calller ID
[11:29:52] <timbray> Pulling resources out of the DNS: Sender-ID looks at HELO etc, Caller-ID uses headers
[11:30:52] <timbray> policies published in the DNS by the sending party i.e. what's on the right side of the address
[11:31:07] <timbray> separate SMTP notions of where-to-send-bounce and who-sent
[11:31:45] <timbray> lots of attention to avoiding collateral damage
[11:32:02] <timbray> "separate" is a verb two lines above
[11:32:45] <timbray> draft-ietf-marid-core:
[11:33:09] <timbray> An SMTP server should:
[11:33:20] <timbray> 1. determine a client's Purported Rresponsible Address (PRA)
[11:33:22] --- Tom Phelan has become available
[11:33:30] --- dcrocker has become available
[11:33:47] <timbray> 2. Look it up in the DNS to find rules, results are: pass, fail, softfail, temperror, etc
[11:34:28] --- SAH has left: Lost connection
[11:35:01] <timbray> draft-ietf-marid-submitter:
[11:35:07] <timbray> SMTP extension: SUBMITTER
[11:35:37] <timbray> just an optimization, can be re-derived from 2822 headers
[11:36:50] <timbray> draft-ietf-marid-protocol:
[11:36:53] --- leifj has left
[11:37:13] <timbray> defines a new textual RR with syntax/semantics for authorized MTA's
[11:37:26] <timbray> can bootstrap with existing TXT records
[11:37:45] <timbray> trade-offs for: lots of domain admins, few MTA coders
[11:40:23] <timbray> ... side-trip into how to compute PRA by looking through the 2822 headers
[11:41:16] <galvinjamesm> is mrose using slides that are available anywhere?
[11:41:33] <timbray> CSV stands for Client SMTP Validation
[11:42:11] <timbray> when an smtp client at a given IP is trying to send:
[11:42:23] <timbray> 1. determine whether domain's mgmt authorizes that client to send
[11:42:35] <timbray> 2. determine whether domain's management is accredited to behave responsibly
[11:44:13] <timbray> not as far advanced as Sender-ID
[11:45:04] <tonyhanse> #1 on slide is HELO domain
[11:45:27] <timbray> Q: is sender-ID a subset of CSV?
[11:45:45] <tonyhanse> summary: bad mail comes from bad MTAs
[11:46:24] <timbray> Q: how to authenticate if MTA is behind a NAT?
[11:46:27] <timbray> A: good question
[11:47:09] <timbray> drafts are all on the schedule for Wed
[11:47:25] <timbray> potential IPR issues
[11:49:22] <timbray> Note: ASRG meeting moved to Tue 9AM in Grande C, it was formerly in the noon slot between AM & PM Marid discussions
[11:49:55] --- hildjj has left: Replaced by new connection
[11:49:59] --- leg has left: Replaced by new connection
[11:49:59] --- leg has become available
[11:49:59] --- leg has left
[11:50:01] <galvinjamesm> will ASRG meeting have a jabber room. There is not one setup right now.
[11:50:07] <timbray> test
[11:50:07] --- leg has become available
[11:50:13] --- dcrocker has left: Replaced by new connection
[11:50:13] --- hildjj has become available
[11:50:14] --- dcrocker has become available
[11:50:16] --- dcrocker has left
[11:50:31] <timbray> Q: has there been outside expert review?
[11:50:34] <timbray> A: no.
[11:50:44] --- Tom Phelan has left: Disconnected.
[11:50:45] <timbray> Q: particularly because of security/operational concerns
[11:50:47] --- resnick has left: Replaced by new connection
[11:50:47] --- resnick has become available
[11:51:49] <timbray> Q: further emphasis on getting review from security people
[11:52:30] <timbray> Eric Rescorla: related: there has been push-back on SPF
[11:52:55] <timbray> Q: security review important because this is a new security model
[11:53:08] <timbray> Q: eg. this can lead to unbounded DNS query sequences
[11:53:58] <timbray> back to Marshall: this was on a short leash because work will expand to fill what the milestones allow
[11:54:36] <timbray> idea is that the 90% effectiveness achievable in the short term is getting a lot of interest
[11:54:42] <timbray> Q: is Sender ID reliable?
[11:54:46] <hardie> Just to be clear, there are two folks from the DNS side who have been acting as Technical Advisors; it is the security and deployment sides that I'm hearing Dave say would benefit from additional as-soon-as-possible review.
[11:55:10] <timbray> A: not good consensus yet on the right answer
[11:55:42] <hardie> (More DNS would be valuable too, no doubt, but not as lacking)
[11:56:02] <timbray> Back to Marshall?
[11:56:18] <timbray> Fenton/Borenstein introducing MASS BOF
[11:56:22] --- jis has become available
[11:56:40] <mrose> tim - do you want to keep scribing? if not, i can take over; if so, no worries...
[11:56:47] <timbray> similar motivations to Marid, but they have a specific charter which excludes signature-based approaches
[11:57:09] * resnick has set the topic to: MASS BOF
[11:57:11] <timbray> either way, I can hang in for a while. You will be able to identifer the questioners unlike me
[11:57:22] <jis> I'll be readling the documents with a security eye...
[11:57:43] --- resnick has left
[11:57:50] --- resnick has become available
[11:58:06] <timbray> EricR: MUA or MTA client?
[11:58:08] <timbray> A: Both
[11:58:16] <timbray> ER: haven't we solved MUA 15 times?
[11:58:20] <timbray> A: Haven't solved it once
[11:58:41] <timbray> Fenton: getting things rolled into MUA space is hard
[11:58:50] <timbray> contrasting Marid & MASS
[11:58:59] <timbray> MASS: msg authent based on crypto signature
[11:59:11] <timbray> autho of key & often key may be stored in DNS or separate server
[11:59:16] <mrose> jis - thanks!
[12:00:17] <timbray> EricR: what threats?
[12:00:28] <timbray> NB: phishing. Banks care.
[12:01:16] <timbray> some things, eg .forward, are not well dealt with by Marid; if the message survives forwarding intact, MASS can still work for someone receiving it indirectly
[12:01:40] <timbray> Fenton: there are tough cases for both this and Marid: voting might be useful
[12:02:33] <timbray> Q: redundant mechanisms to solve the same problem are not inherently flawed given our failure thus far to curb spam
[12:02:57] <timbray> Q: so far, drafts in this space don't characterize the threat adequately
[12:02:57] --- rlbob has left: Disconnected
[12:03:11] <timbray> Fenton: we're just trying things out to see if they work
[12:03:33] <timbray> Q: we should start from the threat characterization & work forward from that
[12:03:46] <timbray> Fenton: don't have a comprehensive anti-spam architecture
[12:03:50] --- jjavip has become available
[12:04:05] <timbray> Q: not trying for that.... in one space you have a good characterization: phishing
[12:04:46] <timbray> Q: what's phishing?
[12:05:38] <timbray> For MASS, not yet decided whether to use both 821 & 822
[12:06:08] <timbray> Klensin: we run the risk of having so many partial solutions that as a sender I might have to implement all of them, and that could be the end of email
[12:06:22] <timbray> Klensin: so "phishing and other stuff" isn't good enough
[12:06:50] <timbray> Klensin: we should work on an area business to avoid a situation where we have a bunch of 5% solutions where if you deploy all of them you solve 30% of the problem and kill email
[12:07:10] <timbray> Klensin: at ITU meeting, they aid "the anti-spam community has a lot to learn from X.400"
[12:07:13] <timbray> <general agreement>
[12:07:41] <timbray> Klensin: design an environment where almost nobody can send email and it's even harder to reply will kill spam
[12:07:46] <timbray> <it's a joke>
[12:08:06] <timbray> Fenton: it would be good to characterize the weak spots of each of these clearly enough that we understand the overlap
[12:08:24] <timbray> Common ground between MASS & MARID:
[12:08:26] --- jjavip has left: Replaced by new connection
[12:08:26] --- jjavip has become available
[12:08:30] <timbray> Def'n of PRA
[12:08:39] <timbray> Message marking to indicate pass/fail validation
[12:08:49] <timbray> Evenntual use of accreditation infrastructure
[12:09:43] --- jjavip has left: Replaced by new connection
[12:09:44] --- jjavip has become available
[12:09:49] <timbray> Hardie: Is building the accreditation infrastructure an IETF task?
[12:10:03] <timbray> JF: the business part isn't but the protocol is, but it's probably a different protocol
[12:10:14] <timbray> Laundry list of representative proposals
[12:11:08] <timbray> Potential issues:
[12:11:20] <timbray> signature encapsulation: signatures in headers, S/MIME
[12:11:40] <timbray> key management
[12:12:00] <timbray> canonicalization, to avoid signature breakage, how to treat headers
[12:12:59] <timbray> Behavior through mailing lists (don't understand this bullet)
[12:13:05] <timbray> Q: too big a problem
[12:13:17] <timbray> NB: we are constraining the solution space
[12:13:54] --- jjavip has left: Replaced by new connection
[12:13:55] --- jjavip has become available
[12:14:07] <timbray> if you don't care about a strong guarantee of immutability, you can use hacks such as ignoring white space in signatures
[12:14:35] <timbray> Hoffman: I'll back last questioner (Hilary); we've looked at this a lot of times in S/MIME, if you can get further that's great but don't assume it
[12:15:04] <timbray> JF: key mgmt is not as absolute, because the consequence of failure isn't a financial transaction, it's an incorrectly delivered email message
[12:15:46] <timbray> BOF Thu 9-11:30, Marina 2
[12:15:53] <timbray> ietf-mailsig@imc.org
[12:16:23] <timbray> Marshall, when we get to open discussion, you take over, I don't know the names
[12:16:57] <timbray> Mark Baugher on PERM
[12:17:12] <timbray> Developed by the Digital Entertainment Network consortium, brought to IETF
[12:17:32] <timbray> goal is to be a stds-based protocol that can fit into a DRM & security context
[12:18:05] <timbray> Overview:
[12:18:15] <timbray> PERM is a key-establishment protocol with a rights/policy payload
[12:18:24] <timbray> security passes payloads for e.g. movies
[12:18:31] <timbray> establishes keys to users, devices, or zones
[12:18:48] --- jjavip has left: Replaced by new connection
[12:18:48] --- jjavip has become available
[12:18:49] <timbray> maybe zone == household?
[12:19:04] <timbray> PERM treats a zone as a secure group
[12:19:29] <timbray> independent of licensing, both of content works & devices that access them
[12:19:40] --- nsb has become available
[12:19:53] <timbray> there are all these vertical licensing stacks, PERM tries to cut across these & provide a horizontal standard
[12:20:11] <timbray> ... picture of a "reference configuration"...
[12:20:21] <timbray> [Disclosure] scribe things DRM is mostly evil
[12:20:27] <timbray> s/things/thinks/
[12:20:55] <timbray> tamper-resistance out of scope
[12:21:30] <timbray> so both for tamper-proof devices and for use between consenting individuals
[12:21:52] <timbray> BOF discussion guidelines:
[12:21:58] <timbray> not address policy enforcement
[12:22:11] <timbray> independent of licensing, fair use and copyright laws or agreements
[12:22:40] --- paf has left: Disconnected
[12:22:43] <timbray> PERM is a security protocol, not a DRM system, no need for anti-DRM speeches
[12:22:59] <timbray> Q: IETF newbie asks if it's OK to rule out discussion of social implications
[12:23:00] <timbray> A: yes
[12:23:50] <timbray> Hilary: the payload, is it annything at all?
[12:23:57] --- mstjohns has become available
[12:24:22] <timbray> A: it's oriented toward DRM apps, but the rights payload is what makes PERM unique
[12:24:37] <timbray> Q/A: yes, the rights payload is specified
[12:24:42] <timbray> Q: relation to XRML?
[12:25:09] <timbray> A: that's just a rights expression language, it's doesn't do security, authentication, etc. Also it's apparently IPR-encumbred
[12:25:25] <timbray> Q: is what you're doing the same thing?
[12:25:32] <timbray> A: different space
[12:26:07] --- hta has become available
[12:26:15] <timbray> klensin: exclusion of social impact is not entirely out of bounds; cf recent discussion of email system breakage
[12:26:31] --- paf has become available
[12:26:33] <timbray> klensin: e.g. if someone says "and a side-effect is, it breaks the internet" then that's fair game
[12:27:01] <timbray> Eric Rescorla: Datagram Transport Layer Security (DTLS)
[12:27:29] <timbray> one-liner: secure communication layer for unreliable datagram transport
[12:27:46] <timbray> TLS only works over reliable transport, e.g. TCP
[12:28:00] <timbray> DTLS works over datagram (eg UDP)
[12:28:25] <timbray> note: there are lots of datagram protocols out there: SIP, video, gaming, snmp
[12:28:31] <timbray> which today can't use TLS
[12:28:33] <timbray> or IPSec
[12:28:50] <timbray> lots of ad-hoc security key/xchange protocols (SIP/S-MIME....
[12:28:55] <timbray> why not IPsec?
[12:29:43] <timbray> because it won't work:
[12:30:06] <timbray> - better suited for host/host not appsecurity, runs in the kernel, non-uniform APIs, interop problems, key xchange complicated
[12:30:18] <timbray> since neither TLS nor IPsec works, need something new
[12:30:34] <timbray> why base on TLS:
[12:30:38] <timbray> popular & works
[12:30:52] --- amarine has become available
[12:30:53] <timbray> familiar model, simple API, in-band key xchange, easy to implement, good OSS code out there
[12:31:11] <timbray> plus, no kernel changes: user-land, can package with apps & patch easily
[12:31:24] <timbray> Basic principle: bang for the buck
[12:31:45] <timbray> Start with TLS, make the minimal required changes (loss & reordering), no "improvements", similar to TLS as possible
[12:31:53] <timbray> protocol overview:
[12:32:13] <timbray> same flow as TLS: initial handshake, DTLS records
[12:32:27] <timbray> reliability for handshake with std timeout/rexmit
[12:32:30] --- hartmans has left: Lost connection
[12:32:43] <timbray> stateless processing of app data records. TLS 1.1 already supports this for block ciphers
[12:32:47] <timbray> no support for stream ciphers
[12:32:51] <timbray> Status:
[12:33:18] <timbray> individual submission, ref implementation in progress based on Open SSL (API like sockets), plan to make publicly available
[12:34:06] <timbray> Guenther: so TLS compression will work?
[12:34:13] <timbray> A; yes, if it's stateless
[12:34:16] <timbray> Q: Hilary
[12:34:40] <timbray> Q: this is just fine except for you misrepresented IPsec and didn't need to bash it
[12:34:57] --- jjavip has left: Replaced by new connection
[12:35:00] <timbray> Q: since SNMP is already baked, what are the targets?
[12:35:08] <timbray> A: SIP
[12:35:13] <leg> yeah, way too kind to IPsec
[12:35:25] <timbray> A: some interest from SNMP direction
[12:35:46] --- jjavip has become available
[12:36:30] --- sakai has left
[12:36:43] --- mstjohns has left
[12:36:45] --- hildjj has left: Disconnected
[12:36:46] <timbray> looking for volunteers to go in once/day on the apps area mailing list
[12:36:54] <timbray> (that was Scott)
[12:37:01] <timbray> Paul: once/week is good enough
[12:37:33] <timbray> Ted; trouble is, they get so long you have to use lynx to access it or your browser blows up (on all three OSes)
[12:37:36] --- hildjj has become available
[12:37:44] <timbray> Ted: really there is a lot of spam
[12:37:51] <amarine> sorry, not in room. go into mailng list and do what?
[12:38:19] <timbray> Marshall: recent versions of mailman only show a couple of lines, but still, a big job with a thousand msgs
[12:38:40] <timbray> Ted: you could mark them all deferred-discard and then go through to only do positive approvals
[12:39:24] <timbray> some people would do it but only if they can do it on their server with their tools
[12:39:53] <timbray> Paul: with better tools, you might get more volunteers
[12:40:15] <timbray> scott: reads out the lists
[12:40:26] <timbray> scott: interested in discuss@ and feature-feature-tags@
[12:40:27] --- rcg has left: Logged out
[12:40:55] <timbray> Martin Dürst will help with w3c-policy
[12:41:06] <timbray> scott: volunteers please email Ted & me
[12:41:43] <timbray> Ted: need MIME type reviewers... Ned has been doing ti
[12:43:47] <timbray> discussion of term length... registrations often involve a lot of interaction & follow-up, one stretched out for two years
[12:43:54] <timbray> klensin: this job sucks
[12:44:18] <timbray> Marshall: over to you
[12:44:32] <timbray> SASL is in last call;please review
[12:44:50] <timbray> that's all folks
[12:45:04] --- resnick has left: Disconnected
[12:45:04] --- resnick has become available
[12:45:04] --- resnick has left: Lost connection
[12:45:15] --- hildjj has left
[12:45:20] --- jis has left: Disconnected
[12:45:29] --- timbray has left
[12:46:06] --- javier has left
[12:46:25] --- hardie has left: Disconnected
[12:46:53] --- galvinjamesm has left
[12:47:09] --- amarine has left
[12:48:43] --- paulehoffman has left: Disconnected
[12:52:35] --- jjavip has left: Replaced by new connection
[12:52:35] --- jjavip has become available
[12:53:23] --- psa has left: Disconnected
[12:54:08] --- nsb has left: Disconnected.
[12:58:25] --- hta has left: Disconnected
[13:00:17] --- mrose has left
[13:01:06] --- leg has left: Disconnected
[13:06:30] --- paf has left: Disconnected
[13:11:49] --- mrose has become available
[13:13:06] --- jjavip has left: Disconnected
[13:14:34] --- mrose has left
[13:37:00] --- tonyhanse has left: Disconnected
[14:05:03] --- jaltman has become available
[14:07:33] --- jaltman has left
[14:24:06] --- SAH has become available
[14:24:29] --- SAH has left
[14:40:19] --- hta has become available
[14:43:47] --- paf has become available
[14:50:52] --- hta has left: Replaced by new connection
[14:50:52] --- hta has become available
[14:50:53] --- hta has left
[14:54:41] --- leg has become available
[14:54:59] --- leg has left
[14:59:22] --- paf has left
[14:59:22] --- RandyG has left: Lost connection
[15:22:43] --- rcg has become available
[16:24:20] --- paulehoffman has become available
[16:24:48] --- paulehoffman has left
[17:21:58] --- rcg has left: Replaced by new connection
[17:22:43] --- RandyG has become available
[17:30:21] --- tonyhansen has become available
[17:30:35] --- tonyhansen has left
[17:31:43] --- tonyhansen has become available
[17:32:02] --- tonyhansen has left
[19:19:04] --- RandyG has left: Disconnected
[19:31:30] --- RandyG has become available
[21:19:42] --- RandyG has left: Replaced by new connection
[21:20:30] --- RandyG has become available