2.1.1 Applications Open Area Meeting (apparea)

Current Meeting Report

- 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


The Atom Project
MTA Authorization Records in DNS
Message Authentication Signature Standards (MASS) BOF
Protected Entertainment Rights Management (PERM) BOF
Datagram Transport Layer Security (DTLS)