ietf-mailsig
[Top] [All Lists]

Draft minutes for MASS BoF

2004-08-31 10:09:41

In the nick of time, here are the draft minutes from the MASS BoF in San Diego. 
 Please let me know if you have any corrections; I will send these in to the 
Secretariat in a couple of days.  We do have an opportunity to send corrections 
until 17 September so feel free to send me corrections even if it's not in the 
next couple of days.

-Jim


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

Chairs:
        Nathaniel Borenstein <nsb(_at_)guppylake(_dot_)com>
        Jim Fenton <fenton(_at_)cisco(_dot_)com>

Scribe:
        Dan Wing

Jabber Log:
       
http://www.xmpp.org/ietf-logs/mass(_at_)ietf(_dot_)xmpp(_dot_)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 Corporate Dev Consulting Eng 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(_at_)example(_dot_)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(_at_)example(_dot_)com would map into
batv-mailbox/scheme/parms(_at_)example(_dot_)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(_at_)imc(_dot_)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.


<Prev in Thread] Current Thread [Next in Thread>
  • Draft minutes for MASS BoF, Jim Fenton <=