Misconceptions about DKIM

I chair the DKIM working group in the IETF. The working group is finishing up its work, about ready to publish an update to the DKIM protocol, which moves DomainKeys Identified Mail up the standards track to Draft Standard.

DKIM is a protocol that uses digital signatures to attach a confirmed domain name to an email message (see part 7, in particular). DKIM started from a simple place, with a simple problem statement and a simple goal:

• Email messages have many addresses associated with them, but none are authenticated, so none can be relied on.
• Bad actors — spammers and phishers — take advantage of that to pretend they are sending mail from a place (a domain name) the recipient might trust, in an attempt to fool the recipient.
• If we can provide an authenticated domain name, something that’s confirmed and that a sender can’t fake, then that information can be used as part of the delivery system, as part of deciding how to handle incoming mail.

It’s important to note that mail signed with DKIM isn’t necessarily good mail, nor even mail from a good place. All we know is that mail signed with DKIM was digitally signed by a specified domain. We can then use other information we have about that domain as part of the decision to deliver the message to the user’s inbox, to put it in junk mail, to subject it to further analysis or to skip that analysis, and so on.

Domain example.com signed this message, is just one of many pieces of information that might help decide what to do.

But some people — even some who have worked on the development of the DKIM protocol — miss the point, and put DKIM in a higher position than it should be. Or, perhaps more accurately, they give it a different place in the email delivery system than it should have.

Consider this severely flawed blog post from Trend Micro, a computer security company that should know better, but doesn’t:

In a recently concluded discussion by the [DKIM Working Group], some of those involved have decided to disregard phishing-related threats common in today’s effective social engineering attacks. Rather than validating DKIM’s input and not relying upon specialized handling of DKIM results, some members deemed it a protocol layer violation to examine elements that may result in highly deceptive messages when accepted on the basis of DKIM signatures.

The blog post describes an attack that takes a legitimately signed message, alters it in a way that does not invalidate the DKIM signature (taking advantage of some intentional flexibility in DKIM), and re-sends the message as spam or phishing. The attacker can add a second from address, and appear to the user to be from a trusted domain, though the DKIM signature is not.

The attack sounds bad, but it really isn’t, and the Trend Micro blog’s conclusion that failure to absolutely block this makes DKIM an EVIL protocol (their words) is not just overstated, but laughable and ridiculous. It completely undermines Trend Micro’s credibility.

Here’s why the attack is overstated:

1. It relies on the sender’s ability to get a DKIM signature on a phishing message, and assumes the message will be treated as credible by the delivery system.
2. It ignores the facts that delivery systems use other factors in deciding how to handle incoming messages and that they will downgrade the reputation score of a domain that’s seen to sign these sorts of things.
3. It ignores the fact that high-value domains, with strong reputations, will not allow the attackers to use them for signing.
4. The attack creates a message with two from lines, and such messages are not valid. It ignores the fact that delivery systems will take that into account as they score the message and make their decisions.

Apart from that, the blog insists that the right way to handle this attack would be to have DKIM go far beyond what it’s designed to do. Rather than just attaching a confirmed domain name to the message, DKIM would, Trend Micro says, now have to check the validity of messages during signature validation. Yes, that is a layer violation. Validity checking is an important part of the analysis of incoming email, but it is a separate function that’s not a part of DKIM. All messages, whether DKIM is in use or not, should be checked for being well-formed, and deviations from correct form should increase the spam score of a message. That has nothing to do with DKIM.

In fact, the updated DKIM specification does address this attack, and suggests things that delivery systems might do in light of it. But however good that advice might be, it’s not mandated by the DKIM protocol, because it belongs in a separate part of the analysis of the message.

---

Others have also posted rebuttals of the Trend Micro blog post. You can find one here, at CircleID, and look in the comments there for pointers to others.

IP blocklists, email, and IPv6

Engineers in the Internet Engineering Task Force, in the Messaging Anti-Abuse Working Group, and elsewhere have been debating how to handle e-mail-server blocklists in an IPv6 network. Let’s take a look at the problem here.

We basically have three ways to address spam, in our goal of reducing the amount of spam in our inboxes:

1. Prevent its being sent in the first place.
2. Refuse to accept it when it’s presented for relay or delivery.
3. Discard it or put it into a junk mail folder at (or after) delivery.

The last is handled by what we usually think of as spam filters, which analyze the content and other aspects of the messages. Dealing with the first involves law enforcement, as well as adoption of best practices for legal email marketers. To implement the second, we try to do various analyses during the actual transmission of the email messages, in order to respond at the protocol level with some sort of refusal. It’s rather like standing between your postal carrier and the mailbox at your house, and telling the carrier that she may put this envelope into the box, but she should take those two catalogues and the credit-card offer right back to the post office with her.

And one can actually imagine doing that, by looking at the envelopes and applying rules such as, If it’s pre-sorted, it’s probably junk, and, The more urgent it claims to be, the more likely it is to be junk. But a better way, still, would be if we could get this to happen as soon as the junk mail entered the postal system, by having a way to say, See that guy who’s dropping that pile of mail at the post office? He only sends junk, and when you see him coming just make him go away. Don’t even let him bring his pile in the door.

We have that in our email systems, in what we call IP blocklists (or blacklists). These are lists of the numeric Internet addresses of email servers that we think send so much spam that we won’t even let them come to the door. When one of these servers makes an Internet connection to one of our mail servers, we don’t even start an email protocol exchange with them — we just refuse the connection. We make them go away.

Estimates vary as to what portion of attempted spam this blocks, but at least some estimates are on the order of 90%. Despite the problems with this mechanism (legitimate mail servers do find themselves on blocklists, for various reasons, and sometimes have a hard time getting the list-managers to remove them), it’s a critical one in the fight against spam, saving a great deal of time and computing resources by cutting the spam messages off much earlier in the process.

But note that it deals with IP addresses. Today, of course, that means IPv4 addresses, those things that look like 192.168.0.1, and that there are around 4 billion of. 4 billion is a large number, but, as we’ve seen, it’s notably finite and manageable. It’s reasonable to take every IP address we ever see trying to send mail, and keep it on a list, sorting the addresses into the good ones and the bad ones. It’s feasible to block Internet connections from the ones in our list that are marked bad.

Not so when we consider IPv6. Bumping the IP address from 32 bits to 128, bumping the 4 billion up to a billion billion billion or so — the number doesn’t matter, at that point — makes it infeasible to keep a list of bad addresses. There are enough addresses there to allow the bad guys to use a new one every time, so we’d never see repeats. There are, of course, ways we can group addresses into large blocks, and know that any address we see in one of those blocks will be bad, but even that isn’t enough to make it work.

We could switch to a pass list, a whitelist of known good addresses — that would still be small enough to be manageable — and refuse anything else. But that makes it very hard for an organization to deploy a new server, or for a new organization to join in.

John Levine has one approach: leave the email system on IPv4 for the foreseeable future. Even, John points out, when many other services, customer endpoints, mobile and household devices, and the like have been — have to have been — switched to IPv6, we can still run the Internet email infrastructure on IPv4 for a long time, leaving the IP blocklists with v4 addresses, and a system that we’re already managing fine with.

Of course, some day, we’ll want to completely get rid of IPv4 on the Internet, and by then we’ll need to have figured out a replacement for the IP blocklist mechanism. But John’s right that that won’t be happening for many years yet, and he makes a good case for saying that we don’t have to worry about it.

At least not until he and I have long been retired

Challenge/response still lives (barely)

Wow; I haven’t gotten one of these in a long time:

ATTENTION!

A message you recently sent to a 0Spam.com user with the subject "[redacted]" was not delivered because they are using the 0Spam.com anti-spam service. Please click the link below to confirm that this is not spam. When you confirm, this message and all future messages you send will automatically be accepted.

I wrote about challenge/response anti-spam systems about three years ago, but probably haven’t seen a challenge message in at least two years. I thought people had given up on them.

Alas, no. But if the last two years is something to judge by, they’ve at least fallen further into disfavour.

Anyway, it’s worth a re-post, then, of my three-year-old item about them. All the problems, all the reasons one shouldn’t use them, are still valid now. So, here’s the link again: head over and read (or re-read) it.

Analyzing some spam

I got an amusing little piece of email spam this morning. Amusing, that is, from the point of view of someone who likes to figure out what the spammers are doing and what they’ve compromised in order to do it. Here’s the message, as displayed to me in gmail (I’ve inserted spaces in the URL and email addresses, so your browser won’t make them clickable):

from McDonald’s Survey Department. <survey @ mcdonalds.com>
reply-to survey @ mcdonalds.com
to
date Mon, Sep 27, 2010 at 15:01
subject McDonald’s Survey

Dear customer,


Please give us only 5 minutes of your valuable time to ask you some questions about our products . Please be aware that we will not ask you about any personal information.

In return, we will credit $90.00 to your account - just for your time.

If you want to answer our simply 8 questions , please click the link below :

http: //dyn248.ele.uri.edu/.mcdonalds.com/survey/index.html

Thank you for helping us to become better .

Sincerely, McDonald’s Survey Department.


Please do not reply to this email. This mailbox is not monitored and you will not receive a response.

Of course, the message isn’t really from anyone at mcdonalds.com, but you knew that.

The first interesting thing is the URL. As is often the case with spam URLs, they’ve tried to make it look like a legitimate URL from the company by sticking their domain name in there somewhere — in this case, it’s after the slash, and one has to know how to read URLs to understand that putting it there just makes it information that’s passed to the web server, and has nothing to do with what web server gets used.

And the web server it’s pointing us to is at uri.edu, which is what piqued my interest. This isn’t some throwaway domain, nor anything else registered by the spammer, but something residing at the University of Rhode Island. In particular, this looks like a temporary name assigned to some computer connected to U of RI’s network.

My guess is that a student machine was compromised — malware got installed on it — and the malware set up a hidden web server that’s meant to handle these requests.

Let’s look at where the email message really came from, by checking out the Received lines in the headers. Here are the two operative ones:

Received: from www-7419bfef271.modrsoft.com ([218.24.93.98])

by hormel7.ieee.org (8.13.8/8.13.8/Debian-3)

with ESMTP id o8S55UDI020590; Tue, 28 Sep 2010 01:05:32 -0400

Received: from User ([99.97.107.229]) by www-7419bfef271.modrsoft.com

with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Sep 2010 02:41:35 +0800

Reading bottom up, the message was submitted by an IP address in SBC Internet Services, to an IP address at Modrsoft, a legitimate service provider in China. The spammers appear to have found an open relay in Modrsoft’s network, or else Modrsoft doesn’t block port 25, and they compromised a machine there, as well.

Here’s what it looks like:

1. A compromised computer on SBC’s network was ordered to submit the spam message.
2. It submitted it to a compromised computer on Modrsoft’s network.
3. That computer relayed the message to its recipients (including me).
4. The message directs users to a clandestine web server on a compromised machine at University of Rhode Island.

Unfortunately, the trail goes cold there: I tried to snag the web page, to see what it’s meant to do... but I can’t contact a web server at that address. The machine has been taken offline, has a new address, or has been cleaned up. In any case, it’s not serving the bad guys at the moment. That’s often true of these things: they may only work for a brief time, but they can certainly do their work in that time. They might do the dirty work directly, or redirect you to another web server that will.

Probably, visiting that web site with a susceptible browser (or user) would result in the installation of malware on the visiting computer, adding it to the zombie network. In addition, they’re offering $90 to your account for participating, so they’ll obviously be asking you to give them some sort of account information where they can deposit the money — an account they’re actually be sucking dry as soon as they have access to it.

Too bad I didn’t get to it soon enough, to see for sure what the web page is trying to do.

IETF 78, Maastricht

The 78th IETF meeting was held at the end of July in Maastricht, Netherlands. Maastricht is an old town in the far southeast of the Netherlands, right next to Belgium; it’s just about the midpoint of a line between Brussels, Belgium, and Köln, Germany.

The meeting venue itself, the Maastricht Exhibition and Conference Center (MECC), was pretty good for the meetings. The logistics were less good in dealing with food and lodging, with us using hotels strewn all about the city, and with very limited options for lunch. The host arranged for us to use the bus system for free during the meeting days, so people could more conveniently get between their hotels and the meeting, and could get to dinner more easily. I found it nice to walk.

The customary Tuesday night social event was held along the Maas river, set up on three docked boats and on the dock itself. They had bands playing music, and they served local food and drink, with the old town area right nearby.

 

As usual, I’m keeping the detailed meeting report off the front page (unless you’re reading the RSS/Atom feed). Click here to read the detailed report.

Detailed report...

I chaired four sessions at this meeting: three working groups (DKIM, MARF, and MORG) and a BoF (ftpext2). I chair a fourth working group, VWRAP, which did not meet this time. There’s a bunch of new work in the IETF Applications Area dealing with three things:

• HTTP, and HTTP-related issues (hybi, httpstate, core, hasmat, in addition to httpbis).
• Internationalization (iri, urnbis, precis, and the recharter of eai).
• Updating of some old standards and experimental protocols (iri and urnbis fall here, too, and also ftpext2 and yam).

Details of the working groups and BoFs I attended follow.

apparea — Applications Area general session

1. The Area Directors did a brief demo of the datatracker, to remind working group chairs and participants of the capabilities. They followed with a short discussion, and a reminder that new work on the datatracker and the state machine behind it is underway.
2. BoF introduction: hasmat (HTTP application security minus authentication)
   Jeff Hodges gave the introduction:
   • Modern web apps (web 2.0, rich internet apps) have grown, become very complex, with gnarly interactions.
   • Javascript, HTML 5, secure/unsecure HTTP, redirects, etc... all leave us open to vulnerabilities and attacks (cross site scripting, man-in-the-middle, cookie theft, etc.).
   • Researchers have been developing web security things haphazardly.
   • Goal: Work closely with web applications people & web security community, generate coherence in this area.
   • Initial work done: 3 Internet Drafts.
   • Propose working group to finish those specs, develop problem statement & reqirement doc for wider space.
   • Coordinate with W3C... new web-application security working group forming there.
3. BoF introduction: urnbis (Update to URN specifications)
   Alfred Hönes gave the introduction:
   • URNs are persistent identifiers; most important application so far: libraries use URNs to identify documents, and to do archiving.
   • Libraries need clear standards. URN specification is still informational/experimental.
   • Name spaces have evolved, increased in scope; there have been modifications.
   • URN docs need to be updated for persistent identifiers (libraries) — ISBN, in particular
4. BoF introduction: ftpext2 (FTP extensions)
   I gave the introduction, as BoF chair:
   • Active work exists on ftp extensions.
   • It’s best for the protocol to coordinate these, avoid haphazardness.
   • BoF will explore interest in doing this in a working group.
5. Breakfast BoF introduction: resource discovery
   Patrik Fältström gave the introduction:
   • New DNS RR record for resource discovery, returns a URI.
   • How many ways do applications have to find necessary resources/servers/etc?
   • Each protocol shouldn’t have its own way.
   • This has been discussed on the apps-discuss mailing list; a core group is interested.
6. ADs ask for resolution of unresolved errata for Applications Area RFCs. It’s a particular issue for RFCs that are not associated with an active working group. There was a discussion about handling errata for RFCs that have been obsoleted.
7. Presentation of idnkit-2.0, an implementation of IDNA2008
   • APIs for encoding, decoding, comparison, validity check (C only; java/perl/python & doc in the works).
   • Command-line tools for all functions as well (idnconv, idncomp, idncheck).
   • Looking for feedback, bug reports, suggestions, information about other implementations.
8. Presentation of HTTP mutual authentication proposal
   • Current http authentication weak in security, functionality:
     • Basic is plain text, relies on TLS for security.
     • Digest is open to offline attack, and is not widely implemented.
     • TLS client certificates are too complex.
     • No log-off function is present.
     • Implementations block the UI with modal dialogues.
     • There’s no provision for guest users.
   • New authentication scheme proposed: mutual.
   • Mutual authentication stops phishing.
   • Dased on RFC2617, PAKE; relies on TLS for encryption.
   • Want reviews & comments.
9. Presentation of privacy preferences for email messages (Ulrich Koenig)
   • Proposed by the Independent Centre for Privacy Protection (Germany)
   • Want to tell the receiver what to do with email (don’t forward, don’t print, etc).
   • Proposed solution: include polite, standardized statement at the beginning of the message.
   • Privicons: X/=0o>
   • There had been some discussion of this before the IETF meeting, among some Applications Area regulars. There was much discussion in the room.
   • These are just advisory. Will they help? Will they do any good at all? Will people understand them? Will clients use them to show useful/understandable cues for the user? Will clients try to enforce them? Etc.
10. Presentation of name-based sockets (Javier Ubillos, Swedish Institute of Computer Science)
    • Problem: applications use gethostbyname, then use the returned IP address.
    • Problems with mobility, multi-homing, renumbering, NAT, v4/v6 interop, etc.
    • Need a surrogate address (HIP, Shim6) or socket abstraction.
    • Existing abstract sockets reuse the resolved IP address forever.
    • Need to solve this with no new indirections, no new delays (first-packet delay, 4-way handshake, ...), strong address management, backward compatibility.
    • Propose new socket API: give name, get stream; uses standard socket semantics.
    • Currently supports TCP, Shim6; adding UDP, mobility/multi-homing.
11. Presentation on deprecating unicode language tag chars: 2482 is historic (John Klensin)
    • Unicode has deprecated the capability.
    • When it’s needed, proper markup, such as content-type is better.
    • No discussion....
12. Presentation on HTTP timeouts (Martin Thomson)
    • Came out of HyBi, but that group is not chartered for this.
    • Long polling is the de facto asynchronous communication standard for the web.
    • Problem: no information is available on how long to hold a request open.
    • Propose a new HTTP header. Timeout is already used, so request-timeout.
    • Intermediate hop may reduce the timeout value.
    • Idle connections are reusable in theory, but not in practice.
13. The ADs presented a proposal for an Applications Area working group
    • Would handle things that would otherwise be individual submissions.
    • Much discussion...
    • Concerns that it only adds another layer of management, unnecessary.
    • Could reduce load on ADs, but will it?
    • Does it help or hinder broad review and gathering of consensus?

codec — Internet Wideband Audio Codec working group (charter)

The goal of this working group is to produce an audio codec that is optimized for use in interactive Internet applications, that can be widely implemented and easily distributed among application developers, service operators, and end users, and that is published as an IETF standards-track document.

1. Working group status:
   • Guidelines document: behind schedule and inactive; needs work.
   • Requirements document: behind schedule and progressing.
   • Specification document: ahead of schedule for now; good collaborative development.
2. Liaison status: ITU SG-16, 3GPP, ISO/IEC, all OK.
3. Prototype codec:
   • Koen Vos & Jean-Marc Valin are working on it.
   • Hybrid implementation.
   • Mixes aspects of kelt & silt.
   • Good initial results.

httpbis — HTTP update working group (charter)

1. Status review.
2. Review & resolution of some open issues.
3. Version 11 of the document set will be out soon.
4. Memento overview (http://mementoweb.org).

ftpext2 — FTP Extensions BoF (as chair)

The FTPEXT2 BoF met at 5:40 p.m. on Mon, 26 July 2010. There were approximately 22 attendees in the room, and four participating remotely on jabber.

1. Review of purpose and goals of BoF.
2. Review of two behave documents,^[1][2] with discussion.
   Consensus to separate alg and non-alg into two docs, released as a pair.
   Iljitsch has the action.
3. One-minute overview of hash document.^[3]
4. Note existence of other documents.
5. Call for participation...
   Authors, implementors, reviewers: 5 in the room, 4 on jabber.
   Interest in creating a working group.
   No face-to-face meetings.
   Will have relatively few participants.
   Participants do represent most of the current FTP work.
   Consensus can thus be considered valid.
6. AD uncertain about WG formation at this point.
   Participants will work on draft charter on mailing list.

---

^[1] http://tools.ietf.org/html/draft-ietf-behave-ftp64
^[2] http://tools.ietf.org/html/draft-liu-behave-ftp64
^[3] http://tools.ietf.org/html/draft-bryan-ftp-hash

fedauth — Federated Authentication Beyond the Web BoF

1. Descriptions of use cases and related work.
2. Discussion of use cases.
3. Discussion of approach: EAP over GSS, vs something else.
   Several participants don’t like GSS, don’t want to see a working group with a charter that locks GSS in.
   Pushback: If you have a concrete alternative, let us see it written down.
   Comment: Different groups can work on different things. This group wants to work with GSS. If you want something else, that’s OK, but that’s a different group.
4. Consensus that charter is basically OK.

hasmat — HTTP application security minus authentication BoF

1. Overview:
   • Vulnerabilities: cross-site request forgery, cross-site scripting, overlaying windows on browsers, clickjacking, malvertising, man-in-the-middle attacks against supposedly secure sites.
   • Uncoordinated solutions: HTTP headers, secure cookies, HTTP-only cookies, content-type.
   • Policy framework: need to set policy via configurable declaration.
   • Uncoordinated solutions require developers to get it right every time.
   • Existing drafts: strict-transport-sec, origin, media-type sniffing
   • Work in W3C: charter for web-applications security WG; cross-origin resource sharing; unified messaging policy.
   • Mozilla work -> W3C; content security policy
2. Web security
   • Honest browser isolates different sites.
   • User visits bad web sites.
   • Assume user is not infected.
   • Cookies based on (sub)domain.
   • Script and images can come from anywhere; forms can be sent to anywhere.
   • Same-origin: DOM access, XMLHttpRequest
3. Media-type sniffing
   • Only browsers that sniff appear to work, so sniffing persists.
   • But diff browsers sniff differently, with different results and security holes.
   • Solution: define standard sniffing algorithm, balancing security and compatibility.
4. Strict transport security
   • Addresses vulnerabilities with HTTP over TLS.
   • Sniff wireless (WEP/WPA).
   • Steal session cookies.
   • Compromise wireless access points.
   • Certificate error bypass...
   • ...click-through insecurity.
   • Web site bugs.

My comments: This was presented as a solution to haphazard, uncoordinated mechanisms. But then the proposed charter looks to standardize three haphazard uncoordinated mechanisms. That leaves me puzzled. The charter does talk about a broader problem statement and looking to the future, and I would like to see the charter go more in that direction.

marf — Message Abuse Reporting Framework working group (as chair) (charter)

The MARF working group met at 3:20 p.m. on Tue, 27 July 2010.

1. Review document status:
   marf-base in RFC editor queue.
   dkim-reporting under discussion; need reviews and comments.
2. Discussion of two new documents — JD Falk.
   Please comment on the docs, consider adopting (within charter).
3. Discussion of coordination with OMA SpamRep:
   Presentation of differences & pain points.
   Avoid duplication of effort, avoid divergent specs.
   XML vs email-header format is significant.
   Deployed base for ARF; end of doc schedule for OMA.
   Working group needs to consider shifting format to coordinate with OMA.

morg — Message ORGanization working group (as chair) (charter)

The MORG working group met at 5:10 p.m. on Tue, 27 July 2010.

1. Review doc status and issues:
   Problem: no reviews coming in; group needs to review docs.
   4 docs almost ready to go.^[1][2][3][4] Again, need reviews.
2. Consider message-recall,^[5] after update:
   Decision: morg may be wrong place for that; discuss on ietf-smtp list
3. Consider imap-move:^[6]
   Much interest in the idea, but there are serious implementation problems
   Decision: add experienced co-authors, include discussion of problems

---

^[1] http://tools.ietf.org/html/draft-ietf-morg-fuzzy-search
^[2] http://tools.ietf.org/html/draft-ietf-morg-list-specialuse
^[3] http://tools.ietf.org/html/draft-ietf-morg-multimailbox-search
^[4] http://tools.ietf.org/html/draft-ietf-morg-inthread
^[5] http://tools.ietf.org/html/draft-leiba-morg-message-recall
^[6] http://tools.ietf.org/html/draft-krecicki-imap-move

Service discovery discussion (breakfast BoF)

1. Harder to implement new RR in DNS.
2. What do application clients want for service discovery?
3. Part of application provisioning in general, including metadata about service.
4. Configure per user, per server, per domain... configure all services in one discovery.
5. Not end up with arbitrarily large number of these... complicates things.
6. Won’t get to one, but prefer not to strew many around.
7. DNS: right place to put pointer to these things, wrong place to put the things themselves.
8. Apple bonjour system; Stuart Cheshire gives overview, much discussion follows.
9. Discovery of context in order to proceed to discovery of services.
10. Will create mailing list to continue discussion.

core — COnstrained Restful Environments working group (charter)

1. WG status review: working group document for basis of CoAP.
2. One WG draft, but many related drafts. Lots of work.
3. Description of CoAP, some detail.
4. CoAP goes over UDP, msg/response; one-way messages.
5. Service discovery through DNS-SD.
6. Resource discovery through HTTP get /.well-known/r
7. Retrieving offered links, modeled on web discovery.
8. Long discussion on discovery.
9. Mapping/proxying between CoAP and HTTP.
10. Comment (Mark N): mappings usually incomplete, leaky abstractions. Worries.

[I left at this point, to go to vCardDAV.]

vcarddav — vCard and CardDAV working group (charter)

1. Document status:
   • mkcol, issued as RFC5689.
   • carddav, in RFC Editor queue.
   • vcardrev, in working group last call, some issues:
     • Escaping of semicolon, tab, unicode codepoint.
     • Must use PID with LANGUAGE.. maybe put the grouping into the language parameter.
   • vcardxml, in working group last call, no open issues.
   • SRV service types, CardDAV discovery... port registration/alias issue.
2. Charter discussion:
   • Current docs mostly done.
   • Leave working group open and expedite new docs.
   • draft-smarr-vcarddav-portable-contacts
   • draft-george-vcarddav-vcard-extension (needs my action)

dkim — Domain Keys Identified Mail working group (as chair) (charter)

The DKIM working group met at 1 p.m. on Wednesday, 28 July 2010. Theworking group has just rechartered, and we discussed the new charteritems and assigned tasks.

1. Advancement of DKIM spec to Draft Standard
   We clarified what’s needed for the interoperability report. Tony and Murray tested their implementations at a DKIM interoperability test in 2007. They will repeat their tests and dig up the 2007 data, and they’ll prepare a draft report. Target date: end of August.
2. Other DKIM data collection
   Murray is collecting data on deployment, verification failures, etc. JD will get data too, and Jim posted URLs with data. SM agreed to collate and organize.
3. ADSP data collection
   Jim posted some brief ADSP data; Murray can provide some counts. This item is lower priority for now, and we need more data sources.
4. mailing-lists draft
   New version just pushed out, incorporating recent comments. There are no particular issues still open. Murray will solicit more comments, and if the draft stays stable we’ll consider WGLC in September.
5. TPA label for ADSP (individual draft)
   Doug Otis presented the current state of this draft, which specifies a mechanism to deal with third-party authentication. It was revised recently, based on comments from DKIM participants. We had some discussion; the draft will continue as individual.
6. Other business
   We had a brief discussion of the appropriate home for a domain reputation protocol. The suggestion is to go to the app area, create a non-wg mailing list, and discuss there.

We’re anticipating not meeting at IETF 79 (Beijing), as most upcoming work appears not to need face-to-face time.

precis — Preparation and Comparison of Internationalized Strings working group (charter)

1. Problem statement: current version of stringprep is limited.
   • Bound to unicode 3.2.
   • Poor bidirectional script support.
   • In new version, backward compatibility is important.
   • Normalization in current profiles differs from IDNAbis.
   • Design new stringprep, similar approach to IDNAbis.
   • Discussion of problem statement (and difficulties).
   • Problem statement document adopted as working group doc.
2. Framework: replacement solution.
   • Survey existing stringprep use, analyze & propose replacement.
   • Proposal: define two classes of internationalized strings... restricted, and less restricted.
   • Satisfies 4 of 6 profiles, follows initial objectives.
   • Framework document not ready for working group yet.

sieve — Sieve Mail Filtering Language working group (charter)

1. Discussion of sieve-include, and potential implementation issues:
   • Considering multiscript as well.
   • Interaction with managesieve also needs to be documented.
   • Needs thorough review.
2. Discussion of imap-sieve:
   • Needs reviews, especially from Ned, also from others.
   • I will revise the draft to keep it from expiring, chairs will ask Ned again for review.
3. Discussion of external-lists:
   • One comment, about LDAP and comparators.
   • We don’t think the situation is a problem.
4. Discussion of sieve-regex:
   • No discussion in the room; needs comments on the mailing list.
5. Discussion of notify-presence, vacation-seconds, auto-reply:
   • No discussion in the room; all are ready for working group last call.
   • Looking for other use-case examples for auto-reply.
6. Discussion of sieve-convert:
   • Needs security considerations.
   • Issues of looping through parts.
   • Maybe change convert to a top-level action.
7. Review other charter issues:
   • Much discussion on moving Sieve base to Draft Standard.
   • I will write a test-plan Internet Draft.
   • Alexey will take it to the IESG for comment.
8. Discussion about Sieve error reporting (to end users):
   • Stephan Bosch will solicit and collect info for a possible BCP.
9. Discussion (blue sky) about using Sieve for instant messages.
10. Discussion (blue sky) about using Sieve with reputation tests.

yam — Yet Another Mail working group (charter)

The primary issue for YAM this time was what to do in light of the two-maturity-levels draft that may, if approved, abolish the distinction between Draft Standard and full Standard, since the purpose of YAM is to advance a number of Draft Standard documents to full Standard level.

1. Off-topic discussion of svg+xml media type registration.
2. Long discussion (most of meeting) about whether to continue in light of draft-housley-two-maturity-levels.
3. Call for consensus: going dormant or closing the working group?
4. Inconclusive; take the decision to the mailing list.

eai — Email Address Internationalization working group (charter)

1. Three docs (one in working group last call) need reviews and comments.
2. Few have reviewed, no substantive comments.
3. Chairs get out their figurative club, people promise to do reviews. Chair photographs raised hands.
4. Most of the remaining discussion was about one issue, brought up on the mailing list:
   • What do we say about improper addresses, of the form <ascii-string@non-ascii.string>?
   • Argument about flexibility/heuristics vs well defined behaviour.
   • Overwhelming consensus, after discussion, to say MUST reject.

Other meetings

DNS dinner discussion: In preparation for the ISOC lunchtime press event (see below), a small group invited by ISOC had a discussion of DNS and DNSSEC over dinner. We talked about our thoughts on the current state of DNS (secure and non-secure), about the challenges ahead, and about future directions with DNS and DNSSEC.

ISOC lunchtime press event: I was invited by the Internet Society to participate in a panel discussion of DNS and DNSSEC, and what it means for the trust and security of the Internet. The session was set up in light of the recent signing of the root DNS zone. The session was well attended, and there were questions from the floor, in addition to the moderated discussion.

WG chairs lunch: Adrian Farrel (Routing Area Director) gave a presentation to the working group chairs about advice for moving individual drafts into working groups. There was discussion, along with further advice from some of the working group chairs.

IESG scribing: I responded to a call by the IESG for scribes to take narrative minutes of IESG meetings, and I scribed three IESG meetings during the IETF week. I’m glad that I volunteered: it’s interesting to attend the meeting and to pay close attention to the conversation, so that I can make a best effort at taking down what everyone is saying. The narrative notes will be used by the IESG to help them keep track of the substance of the discussions, beyond what’s noted in the regular minutes. Narrative notes of the regular telechats will also be posted for public use.

Email, IP addresses, and privacy

This summary is not available. Please click here to view the post.

Should IMAP be replaced?

A friend recently sent me a link to this page, which outlines the author’s idea for a “reimagined Mail Access Protocol” that he would use to replace IMAP. The author starts with the premise that “IMAP is a complex and difficult protocol,” a claim I’ve heard often. My friend says, “I’m not convinced that IMAP is as badly in need of replacement as he says,” and asks what I think.

The short answer is that I’m not convinced either. I also have a much longer answer; read on, if you’re interested in technical details of email protocols.

The author, Gabor, wants his new design to be based on Representational State Transfer (REST) concepts (in the jargon, he’ll make it RESTful). REST architecture is certainly good for many things, and is a useful thing to consider. Unfortunately, as often happens in this business, REST seems to be all the rage these days, the new buzz-word. Everything now has to be RESTful, or it’s not cool enough. I’d want to see a compelling case for throwing away IMAP in favour of a new design, and that would include an analysis of why a new design based on REST would be better than what we have — and would be so much better as to be worth the work, the bugs, the risk, and the deployment problems.

We (the email folks at the IETF) have actually talked about doing a simplification of IMAP and a webmail overlay on it. But there’s that general “IMAP is too complex and difficult” attitude that I really don’t get. Having implemented IMAP on both clients and servers multiple times, I can say that it’s not bad. There’s a little that I would yank out, perhaps... but not a lot. Those who would reject it in favour of “something simpler” would soon find out that there are good reasons for what’s there, and that eliminating something means implementing it in another way. There is, as Heinlein wrote, no such thing as a free lunch.

What’s more, I think the operative bit for Gabor’s outline is here:

One of these days, I’ll write up a spec for the mail access protocol of my dreams. I’m planning to call it the “reimagined Mail Access Protocol” (short: reMAP) which is handy because reMail already owns the domain name

Well, exactly: he needs a business model for his startup. If he can convince enough people that it’s a better mousetrap, he wins.

But is it a better mousetrap? I looked at each of his specific points.

1. All communication over HTTP / HTTPS: TCP connections are great, but for transferring large amounts of email securely, HTTP is the way to go. Problems like security, parallel downloads, persistent connections, caching, compression, download continuation via ranges, and so on have already been solved. There is no reason to solve them again.

I don’t see how HTTP “solves” any of these things. Mostly, HTTP relies on TCP and TLS/SSL to solve them, all the while he’s saying that “TCP connections” don’t do it. Does he not know that HTTP uses TCP connections, and depends upon TCP features?

2. Stateless: There’s no reason to introduce state like IMAP does with its selected mailboxes. All you need is a HTTP session cookie used for authentication purposes. Session cookie also allow for things like OAuth. OAuth would let third parties get your permission to access your email without having to give them your username and password.

It’s certainly true that you can design a mail access protocol that uses state, or one that doesn’t, and one can argue either way on which is a better design. But if he really thinks that “Session cookie [sic] also allow for things like OAuth,” then he doesn’t understand OAuth. (Apart from that, I have concerns about OAuth — not from a protocol-design point of view, but from a human factors one; maybe that’s another blog post some time.)

3. JSON and UTF-8: All data that’s ever sent to or received from the server would be in JSON format. JSON is much more human-readable than XML. UTF-8 would be the only encoding allowed, since it is able to represent any character in the Unicode standard.

Who cares about whether what’s on the wire is more human-readable? Honestly.... It’s true that implementors sometimes initially make mistakes in producing or parsing the IMAP protocol. The same is the case for XML and JSON — any format has to be gotten right, but once the code is written and tested, you’re set.

And it’s great to turn everything into UTF-8, but how will he deal with all the difficulties we have today with email and character sets and languages, including stuff that’s mis-tagged or un-tagged? There are far more problems here than can be waved off with a statement that we’ll just use UTF-8 — that’s not a magic wand.

4. Conversations as first-order objects: Gmail, the iPhone SMS app, and Facebook’s messaging system have shown the value of viewing messages not individually but in the context of conversations. In reMAP, the server would be responsible for grouping together messages. While you could still access individual emails, the first-order unit of data would be a conversation.

See the IMAP Thread extension.

5. Labels, not folders: Labels are much for flexible than folders. Each conversation should have multiple labels, and the labels would be included when you request the message, rather than having to scan all folders for the message via IMAP.

An implementation detail. Labels can easily be implemented in IMAP with the Annotate extension. It’s a question of getting the email client software to switch from the folder model to the label model. Of course, you have to get them to do that if you want to replace the protocol, as well.

6. Stable and unique IDs: IMAP has a UID for each message, but it changes the moment you move the message into a different folder. An IMAP server can also declare all UIDs to be invalid at any moment throughout the session. No more! reMAP would have stable and unique IDs for all conversations, emails, and attachments.

Again, Annotate can handle this. Or one can do as many servers do, and use the Message-ID header field.

It might be useful to have an document that specifies some standard annotations that can be used in standard ways, and “labels” and “guid” (globally unique ID) would be good candidates.

7. The beginning of the end for MIME: Yes, you could still get the MIME representation of each message that is sent. But MIME is a messy and complex beast. Instead of requesting the MIME-encoded message parts, you could just ask the server to give you the message as represented in plain text or HTML. Attachments can be downloaded in separate HTTP calls.

Ah, and so he’s attacking MIME as well. It’s true that there are things that should have been done better, and the MIME document editors will be the first to say that, but it’s widely implemented and stable. It’s perfectly fine to turn a received message into HTML when you store it, but, as with item 3, you still have to deal with the MIME that everyone’s sending around, and if you want to replace that you have to figure out how to put those attachments into the message. Unless he’s proposing to replace SMTP as well.

Apart from that, one of the features of IMAP is that it lets the clients not have to deal with MIME, putting the burden on the server (just as he is). There’s really no difference in retrieving multiple message parts through IMAP or through HTTP, is there?

8. Push built in: The two prevailing methods for implementing push email are the IMAP IDLE command (not widely available in IMAP servers) and Microsoft’s ActiveSync, which requires developers to purchase a license from Microsoft. In reMap, clients could just call an HTTP endpoint on the server which returns as soon as new messages are arrive.

IDLE very much is widely available in IMAP servers. Every major one supports it. Even Gmail’s implementation supports it.

And HTTP does not have push either, of course, so he’s proposing using the long-polling hack. The newly chartered HyBi working group should help here.

9. Full-text index on the server: reMAP servers would need to maintain a full-text index of the contents of all messages. There’s no reason clients should be required to download and index everything in order to do an exhaustive full-text search of your email.

And, surprise, IMAP servers do the same thing. Is he unaware of the IMAP SEARCH command?

On the surface, I would say that the guy is either inadequately prepared for this, or is intentionally misrepresenting things in order to promote his idea. It’s certainly possible to design a slimmer, groovier email access protocol — no one, not even the original IMAP author, thinks IMAP is the Best of All Possible Worlds^tm — but this doesn’t seem to be much of a step toward that, and it’s not clear how much it’s needed anyway. The budding effort in the IETF died for lack of real interest.

IETF 76, Hiroshima

The 76th IETF meeting was held in mid-November in Hiroshima, Japan. It was a long trip from the northeastern U.S., but it worked well, with good weather, mostly good meeting space, and plenty of reasonable food in the area.

This meeting included about 1100 attendees from 44 countries. Not surprisingly, nearly half were from Asia, and only about 30% were from the U.S. As is often the case with IETF meetings in Asia, many key participants did not attend, and a number of working groups did not meet. In contrast, though, there were an unusually large number of BOF sessions exploring or proposing new work.

 

As usual, I’m keeping the detailed meeting report off the front page (unless you’re reading the RSS/Atom feed). Click here to read the detailed report.

Detailed report...

Neither of the working groups that I chair met this time, but neither of those decisions involved the Asian venue. DKIM is in a decision phase right now, having completed its chartered work and deciding whether to re-charter to take on new work. VWRAP is newly chartered, and was not yet ready for a face-to-face meeting this time. The document editors plan to have documents ready between now and IETF 77, and we should be meeting in Anaheim.

Of the other active working groups that I participate in, sieve, eai, idnabis, and httpbis did not meet. IDNAbis has joined calsify and lemonade in “soon to shut down” state. The others were missing key people (including chairs), and did not feel there would be value in meeting in Hiroshima. In addition, morg and vcarddav met, but probably should not have. Key participants “attended” remotely, using jabber and the audio feed, and no work was done that couldn’t have just been done on the mailing list.

Of particular value, though, was an informal session that a few of us set up to do some live document editing on an eai document, downgraded display. The document was sent to the IESG prematurely, and contains some very confusing steps for reconstructing original header fields from downgraded ones. Having had a chance to talk with the original author about the algorithm, I’m now prepared to re-write the problematic sections so that the document can proceed.

morg — Message ORGanization extensions working group

There were very few attendees at the morg meeting this time, with one participating remotely, via Jabber and the audio stream. We reviewed document status: “Status In List” is in IESG processing; “Sort Display” got two new issues during the brief discussion, both of which have since been posted to the mailing list. As working group secretary, I have to post a prod on the mailing list to try to get other documents, such as “Fuzzy Search”, moving. “Multi-Mailbox Search” and “Message Recall” are on my own queue for update and finalizing.

The other point of discussion was a suggestion that we take on some version of Google’s “XLIST” extension. We talked about how we might incorporate it into the regular LIST command, and we’re trying to contact someone who currently works on Gmail, to see if we can agree on an approach that will make everyone happy.

yam — Yet Another Mail working group

The big discussion in the yam working group this time was the IESG’s response to our submission of the first document template, and how the working group should respond to it. The IESG was initially confused by our submission, a problem that turned out to be due to the tools they use to manage their work, rather than anything else. But in the end, while we had decided to start with a very simple document to test the water, they couldn’t see how to do an approval of a simple document that depends on a much more complex one, and asked that we do the more complex one (RFC 5321) first.

After Alexey presented his summary of the IESG’s position, and after much discussion of it in the room, we took a straw vote on whether to close the working group, drop the two-step-process experiment, or go ahead and try the two-step process again with the bigger document. We also considered the idea of processing two documents, one in one step and the other in two, and then comparing the results. We decided to try the two-step process with RFC 5321, and that’s going ahead now.

vcarddav — vCard update and CardDAV protocol working group

vCardDAV was another lightly-attended, short meeting, also with one remote participant (but not using the audio stream). We briefly went over issues with the vCard update draft, and discussed a point about the KIND property and one about specifying the XML property. We followed with a brief discussion of the vcard-xml draft issues.

Finally, we looked at the IESG review of carddav, focusing on a DISCUSS point: the draft proposes to register a service without a port number, which is not currently allowed. There’s a document in the works in another area that will enable that, so we’ll have to wait for it. There was discussion of alternatives, but we decided it would be OK to wait a month or two, and then see where things are with the other document.

tls — Transport Layer Security working group

The big issue for the TLS working group at this meeting was understanding and dealing with the TLS renegotiation vulnerability that was made public in early November. A number of remote participants were on WebEx, including a couple of presenters, and the discussion was lively.

Possible mitigations discussed:

1. Disable renegotiation, dismissed as impractical.
2. Mitigate in the applications, also impractical and has to be done differently in every application.
3. Introduce a TLS change to carry information from before the renegotiation to allow the TLS stack to check continuity. This isn’t an ideal fix, but will help for now.

The working group will use option 3, and will process it on a fast track, overlapping process stages in order to get it out as quickly as possible.

6lowapp — Application Protocols for Low-power V6 Networks BOF

The 6lowapp BOF aimed to look at protocol issues for low-power V6 applications, to identify potential work in that area. The organizers have a number of application domains in mind; the two that were particularly presented in the BOF are home and building automation (having, for example, every lamp in the building as a separately addressable/controllable device, in addition to dealing with HVAC, fire control, building security, etc.) and power-system management (smart meters, remote-controllable thermostats, etc.).

Some versions of much of this stuff is working now, in limited environments. The goal here is to generalize the solutions and standardize protocols to be used. The key is the initial scope of the work. The BOF presented two protocol ideas, based on REST (representational state transfer) concepts: one for “Constrained Application Protocol” (CoAP), and one for “Constrained-to-General- Internet Intermediates” (CoGII). Service discovery, device discovery, and system security are key points (and there was discussion of the difference between channel security (where (D)TLS may be used) and object security (where CMS may be used)).

Significant issues/questions:

• Questions about how much of this fits into the IETF, and how much is already being done in industry consortia and other SDOs.
• Concern about timeline, need for speedy development, normal IETF timeframes. Will the industry be willing to wait for IETF process? Counter: significant momentum behind this, might be able to move through the IETF quickly.
• Concern that this be general, not just restricted to constrained environments/devices.
• Concern about the CoGII portion, related to location of CoGII intermediary, interaction with REST, and other issues.

Consensus is to work on the CoAP side, but to drop CoGII. The group will move ahead with charter plans.

homegate — Broadband Home Gateway BOF

The goal of the homegate BOF was to consider standards for home gateways, to deal with the problems of the inconsistent ways that home gateways operate (and, therefore, don’t interoperate). There are many errors in DNS implementations, lack of IPv6 support, problems with congestion management, and many security issues.

I personally found the security issues to be the most interesting. Of course, the obvious point, which many of us have been railing about for years, is that most gateways are shipped with trivial default administrator access (account name/password), and wireless gateways are shipped with no encryption enabled by default... and a great many customers do not change those defaults. But there are other problems, such as gateways that actually block the use of some security protocols (such as DNSSEC and IPSEC). Surprisingly, some gateways can actually become compromised, as “zombies”, in much the same way as a personal computer can. That can result in autonomous bad behaviour by the gateway, even when the PC is shut down. It can also result in having the gateway re-infect the PC after the latter is disinfected.

The targets of this work are manufacturers of home gateways, of course, but also service providers, who often write contracts with manufacturers. Clear documents about proper operation, and encouragement not to buy devices that don’t meet the requirements, would help a great deal.

The group does not aim to create any new protocols, but to produce BCPs to define how the existing protocols should be used by conforming gateways. The consensus is that the problem statement isn’t yet sufficiently clear and isn’t concisely scoped. There seems to be enough interest to continue scoping and defining, and to continue work on a charter, but a working group is not imminent.

hybi — BiDirectional or Server-Initiated HTTP BOF

The hybi BOF was set up to look at some solutions to the problem of HTTP use cases where the server needs to push something to the client. Currently, this is often done with some sort of polling — either “short polling”, which is the normal type of polling where the client keeps asking the server for any updates, or “long polling”, where the client asks the server something and the server doesn’t answer until it has an update to give, leaving the request open for a long time. Implementers would prefer a “bidirectional HTTP” mechanism, several approaches have been discussed, and hybi has narrowed the field to a few contenders. There is an Internet draft that looks at the design issues and some of the choices.

At the informal BOF in Stockholm, it was clear that the main impediment to getting started is the need to define the scope of the work, and this BOF tried to do that. We went over the design issues, requirements, and problems, and then had quite a bit of discussion of the WebSocket protocol. We followed that with a presentation of the problems that WebSocket doesn’t solve, and a look at alternatives. One possibility is Bidirectional Web Transfer Protocol (BWTP). Others include changes to HTTP and changes to WebSocket to resolve some of its problems/limitations.

There was a discussion of Blocks Extensible Exchange Protocol (BEEP), which the IETF spent time working on and which deals with some of these issues. One question is why we think we can do better here. BEEP is complicated, but it turns out that when you try to ignore many of those complications, you wind up coming back to them anyway — the features actually are needed.

We had a general discussion of the “port 80” issue, wherein everything wants to run on port 80 (or 443, for SSL/TLS), because that’s the port that everyone lets through their firewalls (that is, “because it works”). I think this is a bad idea, but it’s clear that fighting it is an uphill battle, at best, and may simply be an impossible one to win.

It’s clear that there will be both short-term and long-term solutions, and the charter allows for that. There was a strong sense that in the long term, we still may end up with more than one answer, and the charter needs to make it clear that that’s a valid outcome.

Consensus on scoping is for a working group to start with WebSockets, and then expand scope from there.

iri — Internationalized Resource Identifiers BOF

The iri BOF was meant to kick off work on fixing some probelms with the current Internationalized Resource Identifier (IRI) specification. This is a follow-on from an informal discussion in Stockholm, where we thought the work could be done as an individual submission. The decision between meetings, though, was to go ahead with a formal BOF and look toward a working group.

The primary problems here are interoperability of existing implementations because of inconsistencies in the interpretations of the current specs, the extensive effect of any changes to the IRI spec on existing implementations, and the interaction between the IRI specification and other standards (including those by other organizations). The group needs to decide which protocol schemes to work on (http and mailto; what others?).

Discussion included questions about using IRIs as protocol elements, rather than simply as names that get translated at a different operational layer. For example, web browsers can use IRIs internally, but handle all the encodings necessary to create URIs on the protocol end. The problem here is that that’s not the way it works today, and there are non-browser applications of IRIs that do not have a presentation layer. IRIs are already being used as protocol elements, so that horse has left the barn.

Consensus is to continue work on the draft charter, and nail down the issues that have been raised. We might have a working group chartered before IETF 77. The consensus is that the working group will sort out some details, such as which schemes to work on.

aplusp — Address Plus Port BOF

The aplusp BOF presented a proposed mechanism for using “address plus port” to deal with limitations on IPv4 addresses. The concept is that one V4 address is assigned to multiple computers (or interfaces), the different computers are assigned different port ranges, and the address plus the port is used to route data to the computers. The translation is isolated, so the routing protocols and the consumer’s NAT boxes and applications are not affected by this.

For the BOF, the scope is limited to the “dual stack lite” configuration. We saw a presentation that covered the key points of the idea, and which showed various scenarios that demonstrated out it would work. We saw a presentation about how this fits into mobile environments. We saw a presentation about the difficulties that AplusP introduces. In that last, Dave Thaler’s summary is this:

1. Port-restricted IPs are a drastic change to the IP model
   • Lots of complexity
   • Lots of problems known, and probably more
   • People will get it wrong
2. This architectural change is unnecessary
   • Multiple layers of NAT is already bad enough, this is arguably worse

There was a long microphone queue of questions and comments (mostly comments). In the end, when it was time to take a consensus hum, the decision was overwhelmingly not to do this. I don’t think I’ve ever seen such a decisive hum against a proposal in a BOF before.

grobj — Generic Referral Object BOF

The grobj BOF looked at the idea of a “generic referral object” as a means to do protocol-level referrals without the limitations that current referral mechanisms have — specifically, limitations to IPv4 addresses. In a sense, this is looking to design a generic tool like Interactive Connectivity Establishment (ICE).

Essentially, the point is for the “object” to have as many definitions as possible of how to get to the resource it’s referring to, keeping in mind that both IPv4 and IPv6 addresses may be needed, that connectivity isn’t always symmetric, that there may be difficulties going through firewalls and network address translation, and so on. The object will say, “Here is a [prioritized?] set of ways to find what I’m trying to refer you to.” I asked whether they had considered the possibility of including a token given by the service that would allow someone to access it in a way they might normally not be allowed to — such as punching through a firewall. They had not considered it, but the idea sounded interesting.

It was noted that this is a clear “layer violation”, to which the slightly joking response was, “That’s why we’re doing it in the Applications Area,” implying that lots of things have to leak up to the applications layer — too often true, but perhaps true more often than it needs to be.

There was a thought that just changing ICE would be best, and the response to that was that ICE is currently in the RFC Editor queue, and “Please don’t mess that up.” That seems a troubling approach: avoiding interference with another protocol’s progress is not the best reason to design a new protocol. I don’t know enough about ICE to tell whether this proposal would best be incorporated as a revision or extension to ICE.

The “generic referral object” isn’t intended to be incorporated into existing use cases, but to be adopted by new applications. It’s not clear yet what those applications will be, so it’s not clear who will use it.

In the end, there seems clear interest in working on this further, but the problem isn’t sufficiently well defined yet, and opinion was divided on whether it’s a solvable problem, in general. We need to have a defined problem statement document to take to a second BOF, and see where that leads.

decade — Decoupled Application Data Enroute BOF

The decade BOF aimed to start work to define a protocol used by peer-to-peer applications to access data stored “in the cloud”. The initial proposal was for a working group to produce four results:

1. A problem statement (informational).
2. A requirements document (informational).
3. A survey of existing technology (informational).
4. An online-data-access protocol (standards track).

There are starting points for the informational drafts already created, the problem statement, the requirements, and the survey.

The group is aiming the work at peer-to-peer applications, but specifically does not want to include service discovery in the work — it will leave that to the ALTO working group, which is already engaged in the issue of finding good/better peers.

The most significant point of discussion in the room was whether an existing protocol could/should be considered here, perhaps with extensions. WebDAV and NFS were the ones mentioned; the existing survey draft does talk about the latter, but not about the former. It strikes me that it’s very important, here, to reuse as much as possible from a well defined and well tested protocol. File access protocols can be difficult to get right, and if what’s already been done is close to what we need, it would be a bad idea to reinvent it.

One of the Area Directors feels uneasy about chartering a working group to do the preparatory work (problem statement, requirements, and survey), rather than having that done ahead, and chartering a working group to deal with the protocol issues. I don’t agree: I think if it’s done that way, it’s more likely that requirements will change with the scope of the working group, and will thus change the conclusions from the survey. Also, having a working group to focus the effort will make it less likely that the survey might miss something that’s important to consider.

The consensus in the room seemed to be that the problem statement was reasonably clear, but that without a completed survey and set of requirements, we can’t know what comes next: defining a new protocol, or using or adapting an existing one. The sense is that we should move toward chartering a working group, but only charter it for the first three items (the informational documents), and then re-charter when we know where we want to go from there.

Technical plenary presentation on internationalization

This meeting’s technical plenary presentation was about “Internationalization in Names and Other Identifiers”, presented by John Klensin and Stuart Cheshire. They gave an interesting presentation showing why the problem is as hard as it is, and looking at some of the ways we’re trying to solve them.

This presentation ties into the work of the idnabis and eai working groups, and the iri bof.

ISOC presentaion: Internet Bandwidth Growth

Following successful previous press events, on IPv6 and DNSSEC, the Internet Society held a press event over lunch on Tuesday, titled “Internet Bandwidth Growth: Dealing with Reality”. There were no surprises here, as this really was meant for publicity, rather than technical work. Apart from the ISOC introduction, four speakers talked about their experience and predictions about the growth of data transmission on the Internet. I think this was a less interesting session than the two previous ones were.

Charitable donations to send email

In 2004, Mark Wegman, Peter Capek, Scott Fahlman, and I, wrote a paper about using charitable donations to “stamp” email messages as a mechanism against unwanted mass mailings (see Charity Begins at… your Mail Program (PDF)). The paper was not accepted at that year’s Conference on Email and Anti-Spam (CEAS).

In this year’s CEAS, Yahoo! presented a similar paper, profiling a micro-donation system that they’re piloting (see CentMail: Rate Limiting via Certified Micro-Donations (PDF)). Running code is always more compelling, and five years brings a change in focus.

The basic idea is that if you take a company’s or an individual’s existing donations, you can break them into small chunks of, say, one cent each, and count each of those chunks toward a “stamp” for your mail. On the theory that a spammer sending 50 million messages would not be willing to spend half a million dollars to stamp them, you can give at least some preference through your spam filtering to stamped mail.

MacGregor Campbell just wrote an article for New Scientist about Yahoo’s CentMail pilot, and he refers back to the IBM work and quotes Scott Fahlman and me (though he didn’t get the part that I’m not with IBM any more).

Here’s what he got from me:

Barry Leiba, also at IBM, points out that one of CentMail’s core features could also be a weakness, though.

People may not wish to receive messages plugging a cause they don’t agree with. “I might feel that by accepting his messages, I’m implicitly supporting his charity choices — choices that I might be vehemently against.”

I don’t think this is an insurmountable problem, but I don’t know how to get around it. Here’s the scenario in full, as I gave it to Mr Campbell:

I have a colleague whom I like and respect professionally, and with whom I get on well personally... except that we’re politically opposite. If we should start using Charity Seals or CentMail, I might feel that by accepting his messages, I’m implicitly supporting his charity choices — choices that I might be vehemently against.

Note that this issue exists whether or not we disclose the specific charities. The fact that I know what kind of organisations he’s likely to donate to is sufficient to trigger it. So we can’t mitigate this just by saying (as Yahoo! appears to be doing) that the message is stamped, without saying to what charity the sender gave money.

The responses I get to this concern are usually either

1. “That won’t really be a problem,” which amounts to summary denial, or
2. “We’ll only choose non-controversial charities,” which I think is somewhat naïve, and perhaps unworkable.

It might indeed be that it won’t turn out to be a problem. We won’t know that until it’s out there, and we see how it works. I worry, though, that if it does become a problem, it’ll be harder to solve at that point.

That said, I think the charitable donations thing is a good idea, worth pursuing, piloting, experimenting with. I’m eager to see how Yahoo’s program goes.

IETF 75, Stockholm

The 75th IETF meeting was held last week in Stockholm, Sweden — a nice place for an IETF meeting. The weather was pleasant, the conference center was a very workable venue, there are lots of reasonable places to eat in the area, and there’s a good choice of hotels. The meeting itself was not in a hotel, and that’s sometimes a disadvantage, but the many hotels in the area and the good weather made that situation work fine this time.

The city of Stockholm was apparently very pleased to have us there, and they paid the significant cost for the opening reception, for which they had us come over to the Stockholm City Hall (Stadshuset). The mayor addressed us in the room where the Nobel prize banquet is held — the “Blue Room”, which is not blue — and we had a chance to see the “Gold Room” — which is gold, or, more correctly, heavily decorated with gold.

The Tuesday night social event — the only time during the week that many of us have to escape, though, well, even there we tend to talk about work — was at the fascinating Vasa Museum, a maritime museum that displays a 17-century ship that sank on its maiden voyage.

This meeting included about 1100 attendees from 50 countries, and nearly a quarter of those present were from Asia. And I got two new IETF jobs at this meeting: the IAB appointed me as liaison to the Messaging Anti-Abuse Working Group (MAAWG), and the Applications Area Directors appointed me as working group secretary for the Message ORGanization (morg) working group, asking me to help keep the work moving and shepherd some of the documents.

A few photos of the venue; click to enlarge:

The convention center — Scandinavian design.	Restaurants and shops around the corner.	City Hall on an overcast Sunday afternoon. There are better photos on Wikipedia and at the Stockholm site.	The Gold Room (Gyllene Salen) at City Hall.

 

As usual, I’m keeping the detailed meeting report off the front page (unless you’re reading the RSS/Atom feed). Click here to read the detailed report.

Detailed report...

The calsify and lemonade working groups did not meet this time. Both are winding down, and much of the current work of calsify has shifted to the CalConnect organization. The new oauth group did not officially meet, but held an informal breakfast BOF to discuss its status and issues (see below). The httpbis group did meet, but I wasn’t able to attend because of a schedule conflict — only one schedule conflict isn’t bad for a busy IETF meeting.

apparea — Applications Area general session

The apparea general session is meant to give an overview of Applications Area meetings for the week and to cover items of interest to people who follow the area in general. This time, in addition to the introductions to the BOFs, both formal (OGPX) and informal, we had brief looks at these items:

1. Issues with using FTP in a mixed IPv6 and IPv4 environment, especially considering using translators as a last resort for clients or servers that don’t support the EPSV and EPRT commands.
2. An introduction to SCTP, with the idea of promoting it as an alternative to TCP for some applications (such as HTTP).
3. A proposal to pull the vendor name registry from the ACAP protocol specification, so it can be used more generally. Brief discussion here as to whether we need to use readable names (and if so, what characters should be valid), or whether the enterprise numbers that are already extensively registered would be preferable.
4. Continuing the discussion on a timezone registry and protocol, which came up in the vcarddav session at IETF 74, and which I wrote an initial draft of at that time. This may turn into a working group, because of the potential complexity.
5. Suggestion to move the SPF and Sender ID specifications, currently “experimental”, to “historic” status. It seems clear, after the discussion, that the consensus is against any such idea.
6. A proposal to create an Abuse Reporting Format (ARF) working group, based on the Email Feedback Reports draft.
7. An introduction to my proposed Message Recall draft, which will be discussed in more detail in the morg working group session.
8. An introduction to Zhipeng Zhou’s DRM Proxy Architecture draft, which I presented in Zhipeng’s absence. No one expressed interest during the meeting, but someone approached me afterward, and I put him in touch with Zhipeng.

idnabis — Internationalized Domain Names in Applications, update

The idnabis group had scheduled two sessions at this meeting, but finished its work in the first one. This is a group with a potential to debate minor issues and edge conditions endlessly, and the chair necessarily called the discussion, declared consensus on what we have, and moved toward wrapping up the documents and closing the working group.

A main point, here, comes from the chair’s slides: “No amount of mapping, contexting or restricting will absolutely prevent phishing or confusion. Nor can those measures force absolute consistency among system or between applications on the same system.” In other words, we need to do the necessary fixes and updates, but can’t argue forever about character combinations that could confuse people if they’re abused — it’s an unfortunate side effect of the character-set flexibility that’s very much wanted in this space, and it’s up to the registries to handle some of the issues through policy.

The principal remaining issue that was discussed was that of normalization of text, to avoid comparison problems with different encodings of the same character. The desire, here is to avoid having a user type exactly what she sees, but not have it match because the encoding differs.

eai — Email Address Internationalization

The main point in eai is to finish the remaining documents — primarily the unicode IMAP and POP specifications — and to collect the implementation experience and prepare to move the documents from experimental to standards track.

The primary issue with the POP document is whether commands that return message sizes, in bytes, can return inexact sizes. The sense is that these sizes are mostly used to set thresholds, and not to download too-large messages without warning the user, or some such. Terminating the actual RETR command is done by looking for the ending delimiter, regardless of the expected message size. The reason to allow inexact sizes is to defer a possibly expensive conversion until the message is actually retrieved — it could be a serious performance hit to have to convert 1000 messages for a LIST command, when only one or two winds up being downloaded. Consensus is to allow the sizes to be inexact, with warnings in the spec about its effect on clients that might not be carefully and defensively written.

Some basic testing has been done with the SMTP extensions, but the working group has no real experience with downgrading unicode addresses. Still undecided is whether we should retain the downgrade capability and get some experience with it, or drop downgrade and move to standards track without it.

Also uncertain at this point is how the mailto URL and mailing lists will fall out. These issues remain open to ongoing discussion.

dkim — Domain Keys Identified Mail

The DKIM working group’s chartered work is nearly done (the last document is in working-group last call, and two others are now in the RFC Editor queue), so the goal of this meeting was to discuss implementation reports and draft-standard progression for the base protocol.

Dave Crocker has posted implementation surveys to the mailing list, but has so far gotten few replies. Working group participants were urged to complete them, and to pass them on to others. I will pass them to MAAWG and urge response, as IETF liaison to MAAWG. I would also like to collect data not only on feature use by signers and verifiers, but also on what use the verifiers make of the results.

There was much discussion about dropping unused or little-used features in the process of going to draft standard. We noted that RFC 2026 requires dropping features that are truly unused, but whether to drop others is a different question. Several opinions were given about keeping all features, because, while there’s plenty of experience with signing and verifying, knowledge of usage of the result of verifying is still limited. We don’t yet know what verifiers will decide is important, over time. Counter-argument: history shows that when we learn that, we’ll find that the features we kept purely speculatively will be the wrong ones anyway.

Informal vote showed approximately a 2-to-1 preference for keeping all features, versus removing some. The chairs don’t consider that to be sufficient for “rough consensus”, so it will be discussed on the mailing list. Pasi Eronen pointed out, and the chairs agree, that because we had consensus on these to start with, the default action, lacking clear consensus to remove a feature, is to keep it.

There was also discussion indicating that documenting DKIM use cases could be helpful. Perhaps more of these could be added to the “deployment” document (in working-group last call now), or perhaps they could be recorded in an easily updated wiki.

ogpx — Open Grid Protocol BOF

This BOF session was a follow-on to the MMOX BOF at IETF 74. That one explored topics and interest in standardizing virtual-world protocols, and its result was clear direction to narrow the focus to something manageable — which led to this. OGP is a specific protocol proposed by Linden Research that will bite off just a small piece of the cake by allowing defined communication between worlds that are similar to Second Life.

After an introduction to the concept of OGP — which was itself interrupted by a great deal of discussion — the main goal was to bash out the charter. Apart from some obvious edits that will be needed, like listing explicitly the drafts that will be used as starting points for the work, a firmer and clearer list of deliverables, and so on, a few significant issues arose:

1. Several participants thought that the terminology was unclear to those who have not already been working on it. The charter should try to fix that to a reasonable extent.
2. Several participants were confused by the reference to “grid”, expecting to see something related to what’s normally called “grid computing”. A new name will be chosen.
3. While “the protocol allows virtual words to interoperate” is a good, broad statement, several participants argued for more specificity. The charter should be clear about what, exactly, interoperates, and what doesn’t.

The result of this BOF session was a strong consensus to do this work on the IETF, and what seemed to be a sufficient number of people actually interested in working on it (writing and reviewing documents) to make a go of a working group. Joshua Bell quickly posted a “charter issues” list to the ogpx mailing list, and it is being discussed. Their goal is to have the charter updated, with consensus behind it, within the next couple of weeks.

vcarddav — vCard update and CardDAV protocol

In vcarddav, the CardDAV documents are nearing completion, some ready for shepherd write-up and others with just minor issues remaining. For vCard, the main issues involve the timezone and vendor registries. For vendor registry, consensus is to start with the enterprise number.

I presented the social networking extension draft, written by Robins George and me. At the moment, it’s very preliminary, and we have to get together with the FOAF folks to refine it. An issue here is that because the old vCard format lacks a hierarchy, it’s hard to tie properties to specific social networking systems. One suggestion was to have this apply only in the XML format. Another was to allow an XML blob. This fed into a discussion of how to encode XML within the old format, resulting in consensus to have a single base64-encoded XML chunk as an “extension element”.

oauth — Open Authentication Protocol informal BOF

This is a new working group, formed after two BOFs at earlier IETF meetings. The group wasn’t able to get things going (and would be missing some critical people) for an official session at this IETF meeting, but it set up an informal early-morning meeting that drew around 15 participants.

The group had a brief, informal discussion, to be continued on the mailing list, to get started on a few issues:

1. Handling callbacks.
2. Non-HTTP use cases, such as access to shared calendars and authorization over XMPP.
3. Authentication vs authorization, and using oauth for authentication — perhaps defining new SASL mechanisms.
4. Channel bindings in oauth.
5. Distinguishing cases involving the number of “legs” in the authorization request.
6. “DKIM for the web”, using oauth’s header-signing aspects separately.
7. Extensibility.
8. Conflict between habit of oauth community to discuss on Google groups, and the IETF oauth list.

sieve — Sieve email filtering language

For the sieve working group, we have the Notary and Include drafts ready for working-group last call, Notify SIP waiting for RAI review (chairs will push for this), and IMAP-Sieve waiting for input from Ned Freed as well as review on the mailing list. Because both chairs are authors on the Include draft, a separate document shepherd is needed; I volunteered.

I worked with Alexey in the last couple of weeks on some changes to the External Lists draft, cleaning up the security considerations and implementing some changes discussed on the mailing list. Even with those changes, though, there were concerns: the main issue is how to specify the list in a portable manner, given that the Sieve engine has to know how to interact with each specific list. Jeff Hutzelman suggested using a two-part identifier, one specifying the type of list, the other specifying the name. There seems to be consensus on this, which now needs to go back to the mailing list.

There was quite a bit of discussion about reviving the Regular Expressions document. The document author will choose which RegEx syntax to use, and we discussed how it will interact with the other features and extensions.

For Robins George’s Autoreply draft, we considered having it extend Vacation to allow a “force” option so auto-replies are not limited to one per day. There appears to be consensus for that.

We discussed the interaction of Sieve with EAI, and decided, again, that we’re still waiting for EAI to move ahead before doing anything about it in Sieve. The main issue that we see is how comparisons will work with the two-part downgradable addresses.

morg — Message ORGanization extensions

Status of morg documents:

• Status In List: Mostly done. I did an editorial pass and sent the result back to Timo. I had also raised the issue of limiting LIST responses, but we’ve decided that I should post that to the list as a separate item, because it’s really an issue with LIST in general, and not with this document.
• Sort Display: The only open issue is how to handle address groups. Consensus is that the author can just “flip a coin” between using the first address in the group, or using the group name. The draft has to add DISPLAYTO and DISPLAYCC, along with DISPLAYFROM... otherwise, it appears to be done. Dave Cridland will do a formal review.
• Fuzzy Search: Also essentially done. Minor issues have recently been resolved. Some minor discussion in the meeting, but nothing significant.
• Multi-Mailbox Search: Security considerations need more work; otherwise, it needs more review before we declare it done.

I then presented the Message Recall draft, and we had a good discussion on it. There was clear agreement that, while some people appreciated the reasoning behind the two-stage hold/recall option, it caused too much complexity and was unlikely to work anyway. I’ll drop that in the next revision. The other change we agreed on was to put it on top of message tracking (RFC 3885, RFC 3886, and RFC 3887); I’ll make that change in the next version also, with help from Chris Newman in getting the security details done. Jacob Palme suggested reviving his 10-year-old “Replaces” header, which certainly could apply here. Consensus is to go with the message tracking approach instead. Consensus is also to adopt this as a working-group document; will confirm on the mailing list.

hybi — Hypertext Bidirectional informal BOF

There are a number of uses of HTTP where the server needs to push something to the client. Currently, this is often done with some sort of polling — either “short polling”, which is the normal type of polling where the client keeps asking the server for any updates, or “long polling”, where the client asks the server something and the server doesn’t answer until it has an update to give, leaving the request open for a long time. Implementers would prefer a “bidirectional HTTP” mechanism, and several approaches have been discussed.

The purpose of this informal BOF was to discuss the requirements and possible solutions, and to see if there’s interest in trying to form a working group to work on this further. This also involves coordination with the World Wide Web Consortium (W3C) — broadly, W3C owns the data format (HTML, XHTML) and the IETF owns the protocol (HTTP), but it’s not always clear what fits where, particularly as we look at proposals such as Bidirectional Web Transfer Protocol (BWTP) and Web Sockets.

The first thing that’s clear is that the work needs to be scoped with a requirements discussion followed by nailing down some design issues. There are currently too many proposals with different characteristics and different “sweet spots”. There are also political issues involved, as I said above (W3C vs IETF).

Consensus at the informal meeting was to set up a formal BOF at IETF 76, clean up the current drafts before them and get everything submitted and ready, and see if there’s enough interest at IETF 76 to work on chartering a working group.

yam — Yet Another Mail working group

This was the first formal meeting of a new working group that’s chartered to take a set of email-related documents that have draft standard status and advance them to full standard. The major documents in the list are the current versions of SMTP, Internet Message Format, and Message Submission, and the five-part MIME specification. A handful of minor documents fill out the list.

The main points of discussion for the meeting were how to approach the particular set of documents, considering the dependencies and the technical aspects of the documents on the list, and the template that Chris Newman has proposed for presenting each document to the IESG.

The most difficult issue, one that took up a good bit of time, was how to handle the formal syntax in the MIME documents. Based on the original RFC 822 format specification, they use the old ABNF from that document, and they point to specific elements defined in that document. The newer RFC 5322 document, though, uses the newer ABNF defined in RFC 5234, and fixes the definitions of some of the elements that MIME uses. Doing a complete conversion to the RFC 5234 language will be error prone, and would arguably push us to another round at draft standard (or even proposed standard) while it was tested in the field. Staying at the RFC 822 language doesn’t work, because of the corrections made in RFC 2822 and now RFC 5322.

In the end, we decided to stay with the RFC 822 syntax for elements defined in MIME, but to refer to RFC 5322 for the updated elements. And we decided to include text warning about the two slightly different ABNF formats used. Meanwhile, we will go about converting to the RFC 5234 ABNF completely, as a parallel effort. Tony Hansen and I agreed to work on that task.

IRI issues informal BOF

The purpose of this meeting was to look at issues with the current Internationalized Resource Identifier (IRI) specification, which have prompted work on an update to that specification. There was also a concern about how to proceed with getting the original RFC updated.

Consensus is that the remaining issues could be cleared up and the document could be entered as an individual submission, rather than doing it through a working group. If a working group is needed, one would have to be created for this: there’s no clear home for it.

I’ve volunteered to help with shepherding and other process issues, and the goal will be to have it ready to go as an individual submission by IETF 76. If that doesn’t work out, we can do a formal BOF at IETF 76, and proceed from there.

Technical plenary presentation on network neutrality

When I was on the IAB, I started work on a plenary presentation about network neutrality. When I left the IAB, new IAB member Marcelo Bagnulo took over the arrangements. I stayed involved, though the session developed into a very different one to what I’d intended, which had been a four- or five-speaker panel, including representatives from content providers, service providers, legislators, electronic freedom advocates, and the IETF itself.

Though the changes narrowed the scope significantly, I think it was a very successful plenary presentation. The topic was relevant to everyone in attendance, and I know a number of people who listened to the live audio feed from home, as well. Barbara van Schewick, a professor at Stanford Law School, presented some of the issues, specifically focusing on “blocking” that service providers do, “driven by their interests.” She looked at the effects that has on users’ experiences, and at the role of regulators. And she considered the concept of paying extra for higher levels of service, and the question of whether (and to what extent) that’s discriminatory.

Mark Handley then spoke about the IETF’s role, specifically looking at blocking, rate limiting, and prioritizing traffic, but considered it primarily from the perspective of security and network congestion, because that’s where he sees the IETF as having something to contribute. Providing protocols to identify and control traffic can, he posits, replace the use of deep packet inspection and other such problematic techniques. We should consider such things as improved congestion-control mechanisms and protocol-level denial-of-service-attack protection.

The lines at the floor mics were long, though it was not so much a Q&A period as it was a chance for people to go on about their views of particular aspects of the net neutrality debate. That’s where I’d have preferred my original panel format, where we could have gotten comments about the issues from the different sides. Still, the participants were all eager, and it was clear from the comments at the mic that this topic interests many people and that discussion of it belonged here.

ISOC DNSSEC presentaion

Following its successful IPv6 press event at IETF 74, the Internet Society held a press event over lunch on Tuesday to present DNSSEC status and to encourage further deployment. There were no surprises here, as this really was meant for publicity, rather than technical work. Apart from the ISOC introduction, five speakers, from ICANN and several network registries, talked about what they’ve done to secure their respective portions of the DNS, and what their plans are for the future.