Monday, September 13, 2010

.

IETF 78, Maastricht

IETF 78 meeting bannerThe 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:

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.
Labels:
Posted at 9:24 AM

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)