Preliminary minutes from the meeting this morning2004-03-03 21:08:28If you have comments, let me and Ted know. pafMarid BoF Scribes include Spencer Dawkins <spencer(_at_)mcsr-labs(_dot_)org>... Patrik and Ted co-chairing, with a really tight leash... Topic is MTA authentication, period. Behave in the BoF if you want to move to a working group. BoF chartered out of ASRG in IRTF - we think this is what is ready for IETF now. Patrik - we're working on this wrong - solutions driving search for problems instead of the other way around. Need to agree on the problem we're solving, and need to do that up front. SMTP used in many ways, between many entities, with spam, worms and trojans injected in a proper mail flow These injections look like any other mail until they get to the end user Patrik displayed a lovely work of modern art showing mail flows between MUAs using a variety of paths Things start fairly simply, but get complicated pretty quickly with relays, mailing lists, etc. Open questions - will verification of SMTP peer help? what transition strategies are going to work? What will spammers do in response? Not everyone uses the same SMTP relay (some belonging to ISP, some belonging to domain) Is SMTP-AUTH/port 576 the right answer? Are increased restrictions on relay rewriting going to be deployed? What DNS RRs should be used? Patrik has a summary comparison of proposals, but we're not talking about "which one is best" Q: How many MTAs are there? at least one per e-mail domain? Raising concern about database size requirements... A: Problem is that attack vectors are constantly changing - who is a zombie this week? Q: Need to look at whether DNS record use is forward-tree, reverse-tree, or something else - this determines also DNS impact Q: We can't answer "will this stop spam" with our current problem statement? A: You're right. We're asking if it's worth putting engineering effort into this work. Q: Are the social engineering impacts of zombie creation in scope? A: Fraudulent domain aspect is in scope Q: Original problem statement was whether these proposals impact the DNS. But what spammers do should be in scope (the cure could be worse) Q: We're talking about implications, and a lot of people are motivated to look at spam. But we need to look at longer-term effects, including e-mail use and users. Q: What SMTP domain name useage forgery are we talking about? There are three. Q: Domain names change for "roaming MTAs" and we'll have problems verifying them. A: Probably need to be clear on which identity is being authorized at any given point in time and make sure mechanisms that do this work A: There are proposals on the table for using specific identities - need to focus proposals on which identity is being used and what problem is being solved MTAs are becoming MSAs, and that's different Q: Verification of SMTP peers will help, but will only help a little Q: Reduce the number of permissible channels so necessary audit process is more approachable Gordon - DMP shooting for lightest load on DNS queries both network address and domain at once queries DNS on every SMTP transaction (MAIL FROM) works better for roaming users does not require changes to DNS deals with ISPs that won't let us insert stuff in DNS demonstrating 20% decrease in SMTP volumes DMP requires more individual records in the DNS zone, and more work for DNS administrator (although some of this can be automated) No way to point to another domain as authoritative Overloads TXT RR, but could use another RR if that's better Does define another namespace Q: Problem statement should include performance impacts of various approaches Patrik, channeling Hadmut Danisch - RMX ++ DNS is not a good choice for a variety of reasons Q: if we're not using DNS, how are we looking up the server? Only to find a non-DNS service - may have DNS impact anyway A: records would have TTLs, so could be cached A: no policies stored in DNS Lots of reasons to use HTTP/HTTPS Policy flexiblity with Dynamic/Auth Fraud/spoofing not limited to e-mail Q: Not happy because BoF is on DNS and proposal is not - not good use of IETF time, no way to prepare Meng - SPF Came from RMX and DMP DMP lookups are simple, RMX can define everything in a single record you can cache macro that expands to DMP records includes "soft fail" capability in grammar to allow testing of policies looks at both return path and HELO (if no return path is available), or either taken separately but there is a tradeoff here Q: Which identities are you authenticating? A: Return path domain, unless it's null, and there are seven response codes providing flexible policy statement Q: How did the macro language come about? Macro language seems to extend SMTP, not replace it Authentication could be per-user, or lots of other things Q: Are we doing authentication, authorization, or policies? A: Simplest answer is "authenticated senders are authorized", but complexity rises from there Q: do you have way to tell policy writer what policy is evaluating to? how to debug this language? A: probably based on user complaints... Q: what about inserting notification as part of the macro? Of course, this is an invitation to DoS attacks... A: "dig altavista.com" - they send no e-mail, but want to see who is forging mail Q: concerned about arbitrarily complicated policy languages - wannabe senders don't know what to do when mail acceptance rule is arbitrarily complex A: senders write policy, not receivers Q: but rules are too complex to debug Q: don't exceptions that you can see in the DNS, like per-user exceptions, invite attacks? A: yes, they do, but some customers want the exceptions anyway... Q: why does SPF go into policies? A: because we don't all run PGP yet... Q: please think about trust paths for deployability Dave Crocker - Role of authentication need to add "who does what" to our list need to be clear about identify vs authentication vs authorization remember that Mail-From: is a Bounces address, not an identity some schemes validate authors, others validate provider network concerns about "author-based" MTA registration schemes - administration and scaling, kiosks/greeting card services not authentication schemes and not useful beyond spam redefining long-standing e-mail semantics removes store-and-forward on the internet policy implications Q: redefining core e-mail semantics include semantics that spammers exploit Q: Harald thinks Dave can't be wrong all the time - checking Mail-From could prevent bounces from ending up in the wrong place is a good thing Q: XMPP uses an SRV scheme to link IPs with domains - useful there, why not here? Pete Resnick (XMPP chair) - XMPP uses SRV to find destination, I think we're trying to use to find the source, but we can follow up offline General Discussion C: use of reverse tree is decreasing, not increasing - IPv6 is clouded, but IPv4 is clear and big C: we have a delegation issue in the root - 20-percent of reverse tree is broken C: DNS follows administrative lines, but the lines are different in forward and reverse trees - organization/forward vs topology/reverse not clear that reverse is all that helpful want to use existing records and overload them weirdly. this is not good. TXT is too overloaded now, it's all freeform, interactions are problems need to use specific resource records, not overload randomly there is an upgrade problem, but it's not upgrading the world - no stubs, etc. interative resolvers need to be upgraded, that's all we're putting spammer/attack targets in DNS, and DNS is fragile - need DNSSEC up front, and this requires upgrades anyway - new RR is minor problem C: RFC 2929 allows new RR type creation pretty easily C: even from operator perspective, it's easy to get confused would like to support ten-year-old implementations, with no more pain than a service pack upgrade is DNS really that fragile? can we lean on it a little longer? Rob Austein has DNS threats draft in front of the IESG now (draft-ietf-dnsrext-threats-06.txt) C: adding an RR has OS implications, too, and GUI implications can do your own socket call to get unknown DNS RRs without OS implications C: we're not just changing the basics of SMTP, we're changing the basics of DNS as well - need to watch this carefully never seen an application try to put configuration data in DNS before C: distinction between DNS operators and SMTP operators - dynamic DNS update had the same implications C: too easy to forge sub-domains of protected domains, behavior forced by RFC 1034 section 4.3.2 A: this is the way DNS wildcards work. Using them is a mistake. That's why they are optional. C: where is the increased query load going to land? RIRs? somewhere else? C: also a tree-walking issue, because eventually you have to specify tree-walking in the general case, and that's not easy C: bounces that don't go anywhere have impacts on systems trying to send bounces - if destination has no mailer, MTA will retry for days C: doesn't the DNS load call on the sender? A: depends on TTL values - can't answer in the general case. need to be aware of impacts of deployed mistakes in resolvers as we do this stuff Impacts on SMTP C: need a list of operators and administrators as part of proposal evaluation who updates what? when? all proposals have serious administrative overhead, some more than others inertia of 0.5B e-mail users is immense - easier to add behavior than to change behavior removing capability for store-and-forward - implications are huge third-party mail handling creates a lot of additional considerations altering the human uses of e-mail, and this gets ignored - too many ways people use e-mail in too many ways cannot send mail except from a computer you've previously registered C: tried to design around these considerations - sending bounces to somewhere else for e-greeting card sites, etc. maybe store and forward is too abusable to save C: but the current mail situation cannot continue - AOL blocked 4B pieces of e-mail in three days this month C: I heard you say this ... need to avoid hysteria in engineering analysis and tradeoffs C: DNSSEC, early on, focused more on putting security into DNS than looking at how DNS really worked. learn from this example or you'll spend time fixing stuff you've broken C: need to take a stand on what we're willing/not willing to lose store and forward could go away if we support disconnected clients with authenticated dropoff protocols C: fundamental design of e-mail is a many-to-many mesh. spammers take advantage of this fundamental fact everything we do to abate the problem changes the fundamental design of e-mail how far can we go in changing the fundamental design of e-mail? what can we change that spammers won't fight? C: we need to be constructive - saying "this breaks e-mail" isn't constructive saying this breaks a feature, but the cost of forgery is higher than the value of the feature is also constructive. C: maybe the many-to-many mesh is already gone. C: reminded me of a bit of hysteria over "raw sockets" previously C: many-to-many mesh is already breaking - people are afraid to open e-mail, entire domains being blacklisted C: spammer cost isn't the point - almost nothing we can do will kill e-mail completely <ruled out of scope> Is there IETF work in this arena - developing an MTA authorization DNS resource record for MTAs checking Mail-From/HELO to signal to peer MTAs that it is authorized to send mail? Actual text from Patrik C: Some proposals are anti-spam, others are just plain good ideas - need to keep this distinction in mind believe that the question as stated is a plain good idea and should be done whether there was spam or not C: some of the 4B mail messages are forged, some are not, some are bounces, some are not, not sure what the percentage we'll fix is people who need to solve the problem quickly are throwing out solutions maybe we can come up with a good idea that these people haven't thought of don't overload TXT records, for instance do good work, and see if it helps - existing proposals all need work C: resounding yes, including technical and political aspects, because people are going to implement something, and "something" could be worse C: haven't established that DNS record is the best approach C: do you intend that the authorization be binary? Ted: that's a tradeoff - "yes/no" might deploy faster than something policy-based C: Harald thinks this the right thing to do, Pete is long, the love fest is over we've built the entire Internet as a debugging exercise, take the chance and get somewhere C: really want to see this work come through the IETF just to scrub proposals for bad effects C: the work is useful, how long to deploy? how snappy will the spammer response be? C: something like this will get done whether we do it or not limit the scope to authorization, not policy - need a clear target and tractable problem not clear that DNS is the right answer/only answer, need more discussion before we know this C: concerned about doing this work in an open forum, especially if we bring in the current proposals not everyone with a proposal is interested in consensus lots of people will be participating Harald: there's more than one way to run a working group C: what about a next-generation protocol? shouldn't bog this down for short-term issues C: WG should concentrate on semantics, not the representation - we have plenty of DNS geeks who will figure this out if you know the semantics C: There are people in the IETF with agendas, this shouldn't bother us concerns may be warranted, but this session proves it can be done - with a lot of overhead, but it can be done this goal would be worth doing if there were no spam we don't have to ignore existing proposals, there are issues about bringing them in (IPR, etc), but we should move forward C: need good model of how mail works today Hummms Chartered working group in 4-6 weeks - would you participate 5 hours/week or more? Stand up ... there is a core of active participants If we deploy an experimental answer early, is transition to final answer in six months too painful? C: we're not going to get this right the first time, so this is acceptable Looks like this is also good enough to go forward
|
|
||||||||||||||||