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