2.6.7 Message Authentication Signature Standards (mass) Bof

Current Meeting Report

Minutes of the Message Authentication Signature Standards (MASS) BoF
60th IETF, held Thursday, 5 August 2004, 0900 - 1130 PDT


Chairs:
Nathaniel Borenstein <nsb@guppylake.com>
Jim Fenton <fenton@cisco.com>


Scribe:
Dan Wing


Jabber Log:
http://www.xmpp.org/ietf-logs/mass@ietf.xmpp.org/2004-08-05.html


1. Agenda Bashing and Introduction


Nathaniel Borenstein presented a list of goals and non-goals for the proposed Working Group, and the positioning of MASS with respect to the work being done in the MARID WG. Many of the goals are the same as those of MARID, but would be accomplished by means of a signature attached to each message rather than an IP address check; it is a different form of evidence and in many ways complementary to MARID. There are a number of areas where MARID and MASS may use common mechanisms, such as marking of messages to indicate the verification result.


Brief descriptions of seven such proposals were to be presented. Rohan Mahy suggested we first discuss the draft WG charter, which was shown for information, but there was not consensus to discuss it prior to the proposal overviews.


2. Representative Proposals


2.1 DomainKeys (Mark Delany)


DomainKeys is a signature-based technique designed to be as transparent as possible to existing infrastructure. Public keys used by the domain are stored in DNS TXT records (e.g., 200401._domainkey.example.net IN TXT "g=;k-rsa;p=MHww...IDAQAB").


The signature is stored in an RFC2822 header, DomainKey-Signature.


Several methods of canonicalization to minimize message breakage are being tried out. Some senders might want to be more liberal than others.


There are 4 independent implementations based on the -00 specification, including a sendmail milter available on Sourceforge and a qmail patch. A -01 revision to the draft is due out in a few days.


Q: Why not use S/MIME?


A: Yahoo, for example, can't suddenly start sending S/MIME without generating complaints from users that aren't expecting it. One large ISP had said that if 1% of users complains, the support costs would be in the millions of dollars. Another problem is that many mailing lists can't handle S/MIME encapsulated SUBSCRIBE and UNSUBSCRIBE messages.


Q: The draft says 'no derivative works allowed'; will you give IETF change control?


A: Yes.


[Floor closed to further questions until presentations are complete]


2.2 Identified Internet Mail (Jim Fenton)


Identified Internet Mail (IIM) is similar to DomainKeys; the primary difference is that the public key is sent in the message itself and DNS is used to find the authorization of the key.


It explicitly supports both user- and domain-level signatures. The originator can decide which headers to include in the signature, and copies of the signed headers are included with the signature.


Signing and verification normally happens in MTAs, although possible to do in an MUA as well. A header has been defined to convey the results of verification from an MTA to the MUA (or to a later MTA).


User level keys are important for "affinity domains" like ieee.org, and outsourced functions like benefits@example.com where someone outside the domain needs to send messages using a specific address. Many domains won't support user-level keying because they don't need them and/or want to force outgoing messages through their own MTAs for archiving, compliance checking, virus scanning. Many domains will have only domain-level keys, and some will have some user-level keys and a few will key entirely at the user level.


The -00 draft (draft-fenton-identified-mail-00) was published in June, and a few changes have been made since. One is the ability to sign a portion of the body, to allow some mailing lists to append to the message. Also, the Sender: or From: address will be used rather than envelope-from as in the original draft.


2.3 E-mail Postmarks (Jim Lyon)


The goal is to have a domain attach a signature to a message, attesting that the mess has passed through the official mail servers of the domain and perhaps attest to other things we well. This proposal uses S/MIME because many MTAs munge headers (reorder, remove, etc.) and whitespace changes, character mapping, MIME delimiter rewriting, format conversion, HTML sanitization, etc.


Many MTAs are trained not to modify messages with content-type=multipart/signed. Many MUAs (but not all) have been trained to use S/MIME. Messages which have been signed by the user and signed again by the domain can be handled correctly.


For more information, see http://www.lessspam.org/EmailPostmarks.pdf


Q: Does Microsoft claim any IPR on this?


A: Don't know. The original author is on LOA.


2.4 Entity to entity S/MIME (Phillip Hallam-Baker)


The banks are being impersonated in phishing attacks; and if they won't use S/MIME, who will? The goal here is to make it easy and free to sign email, and get past the S/MIME vs. PGP standards war. The Draft (draft-hallambaker-entity-00) describes the problems with S/MIME in detail.


Rather than put user-level information (such as keys) in DNS, it's a better idea to have a DNS entry point to a server which contains user keys. XKMS 2.0 is a W3C candidate recommendation which might be used as a repository to check signatures.


Some alternatives are WS-Trust (which only does part of XKMS), SCVP (delivers X.509 certificates), or something new (which will take a long time). We should keep the key management piece out of the charter.


2.5 MTA Signatures (William Leibzon)


William looked at S/MIME and PGP as mechanisms to attach a signature; S/MIME was chosen because it was more extensible. It would be desirable to use one of these mechanisms automatically, but it's important that these new signatures be confused with existing signatures.


Two ways this could be done with S/MIME are to invent a new MIME type or embed the signature as part of an unknown multipart MIME type. Decided to create a new MIME type, multipart/x-postal-data. Since only the body is signed, headers to be signed would need to be copied into the body to be signed there.


Since S/MIME depends on the use of certificates, a new method of signature verification is proposed. The X-Certificate-Verification-Service provides a number of ways (http, ftp, etc.) the signature can be verified. It's also possible to determine if mail from a given domain should always be signed.


2.6 Bounce Address Tag Validation (Dave Crocker)


BATV uses similar technology to previous presentations, but solves a different problem. The idea is to digitally sign the MAIL FROM address by putting a signature into the left side (local part) of the address. There is a hard limit of 64 bytes for the local part; we want everyone throughout the mail system to be able to find the local part so an address like mailbox@example.com would map into batv-mailbox/scheme/parms@example.com .


The goal is for the receiver of a bounce to be able to determine if it's a bad bounce. You should be able to look at the address and determine if MAIL FROM is forged; if so, it's likely that the rest of the message is forged as well.


There are very serious replay protection issues, but this isn't trying to be a perfect solution.


2.7 Trusted Email Open Standard (John Levine)


[There were no slides for this presentation; this describes a white paper at http://eprivacygroup.net]


TEOS is implemented as a commercial product known as Postiva. It takes a digest of the message, some information from the headers, and assertions from the sender, puts it in XML, signs the XML, and puts all of that into a header. The recipient sees the header, gets the key of the sending domain, and validates the XML. The MUA can display this to the user.


Q: Is there IPR around this?


A: There are patents pending, but the head of the company is committed to giving open-source compatible licenses.


3. Issues for WG to resolve


These include:
Signature encapsulation
key management
canonicalization
Behavior through mailing lists


Q: (Rohan Mahy) Need to decide the requirements on backward compatibility and what the scope is. The chair agreed.


Q: (Eric Rescorla) Why do you think this will work? The chair (Nathaniel) ruled this out of scope; different technologies presented here will work in different threat models. Agreed that we need to make the response to threats explicit.


A: (Jim Fenton) There is a threat discussion in the draft I co-authored.


Q: (Rand Wacker) Does "behavior through mailing lists" mean survival of messages through mailing lists, or what mailing lists should do?


A: Both


Q: (Mike Thomas) The charter should address the key transport issue. DNS was alluded to, but we need to be clearer in the charter.


4. WG Name


Two names were proposed: Message Authentication Signature Standards (MASS) and Signatures for Transport Recognition of Imposture in Viral Email and Repugnant Spam (STRIVERS). Ted Hardie suggested we just call it "HUM".


5. Deliverables


A list of deliverables was presented (extensions to SMTP, etc.) on slide 17. Comments on the list of deliverables:


- (Ted Hardie) Need to clarify is his is to work with MTAs or SUBMIT servers. Need to determine which M*A entities need to sign.


- (Dave Crocker) This is about message contents, why refer to SMTP at all?


- (Dave Crocker) Delivering the signature along with the message constrains the behavior of the working group.


- (Jim Lyon) MUA behavior needs to be discussed.


- (Chris Lonvick) Clarify whether non-email messaging is in scope.


- (Rand Wacker) Clarify who can/should check these signatures


- (Phillip Hallam-Baker) Define how this will work with legacy MTAs that are routinely broken and mangle bits.


- (Mike Thomas) Need to define encapsulation and canonicalization in messages, and a way of checking the authorization of the message. These are disjoint problems.


- (Randy Gellans) Dave Crocker's proposal is somewhat different from the others; need to determine if it is in scope. If so, the deliverables are too restrictive.


- (Randy Gellans) Need to clarify if signing is done at SUBMIT agents or MTAs, since SUBMIT agents are the only entities that determine authorization.


6. Threat Model


(Jim Fenton) Two main kinds of threats, phishing (fraud) characterized by large financial losses to the affected domains, and spam, characterized by small losses to virtually everyone. Human-engineered look-alike domains will remain a problem for phishing attacks. Accreditation and reputation services will be required (especially for spam) to indicate whether the address is well-behaved.


Q: (Eric Burger) S/MIME isn't working because of the need to update clients, send keys, etc,; how is this different?


A: Most of these proposals don't require MUA changes; the MTA would typically do the authorization check for you. And S/MIME solved a different problem.


Q: (Eric Rescorla et al) Why do you think this will work with phishing? Phishing works because of social engineering; a domain looks like paypal.com, but isn't paypal.com. The phisher could send with paypal1.com. We need an estimate for how much phishing would be reduced by any of these proposals.


A: Allows banks to say "look carefully at the domain" (which won't be 100% effective). While it's dangerous to cite current behavior, something like 95% of phishing emails are currently spoofed. They use spoofed addresses because they're more effective than other human-engineered addresses. But if the domain is socially engineered, this can't solve the problem by itself.


Q: (Ted Hardie) Should we really consider reputation to be out of scope for this WG?


A: We're trying to divide-and-conquer.


Q: (Rohan Mahy) Do you intend the product of this WG to be standards-track, BCP, informational, or experimental?


A: Standards-track


Q: (Rohan Mahy) Need to describe the problem you're solving, and how well.


A: How about "preventing spoofing of known domains, but not socially engineered ones".


Q: There is overlap between MARID and MASS. Describe why MARID doesn't solve the problem.


A: Potential commonalities include PRA, message marking, and accreditation. (Phillip Hallam-Baker): Accreditation is important, but we shouldn't be describing how to do accreditation, but rather how to link to it.


(Dave Crocker) Concerned that the BoF is ignoring important issues; need to make sure that we're not reacting just to today's spammer behavior. MTA-to-MTA use of S/MIME and PGP has been done and works fine, but there is difficulty in managing the keys. It is useful to sign messages independently of phishing and spam. But we need to understand how the current proposals do a better job than PGP and S/MIME.


(Cullen Jennings) The requirements need to be at the "reduce spam or phishing" level, not at the "prevent spoofing one header" level.


(Dave Crocker) Responding to Ted on accreditation services, any such system has to be based on an identity you believe. What we're building is the foundation for such a system.


(Nathaniel) Requirements discussion will need to be finished on the mailing list.


(Phillip Hallam-Baker) Phishing is getting more sophisticated, using trojans. We should concentrate on domain-level security, where we have been successful in the past (SSL, padlock icon, etc.)


(Mike Thomas) Once we have a way to detect forgery, the spammers and frauds will need to get throw-away domains. Domain-level reputation may have legal problems we're not aware of. Divide the problem and deal with authorization first, and later on accreditation.


(Jim Fenton) 1. Will a crypto approach without accreditation be beneficial? Yes. 2. Would accreditation fragment this group? Perhaps. 3. This BoF is under Security, not applications. Accreditation seems more like an applications-area problem.


(Marcus Leech) This won't work for traffic originating within someone's network via trojans.


(Phillip Hallam-Baker) The big issue is the message encapsulation formats; that's where these proposals differ in substance. S/MIME vs. headers, and need to find what types of canonicalization work and which don't.


7. Conclusion


Word-smithing the charter will be done on the mailing list, which is ietf-mailsig@imc.org (see http://www.imc.org/ietf-mailsig/)


Consensus via hum that effort in this area should go forward.


(Russell Housley/Steve Bellovin) We need a threat and requirements document, but one that makes hard decisions and isn't just the union of everyone's requirements.

Slides

Agenda
DomainKeys Overview
Identified Internet Mail
E-Mail Postmarks
Entity to Entity
MTA Signatures Proposal
Bounce Address Tag Validation