[08:30:09] --- galvinjamesm has become available
[10:31:25] --- danwing has become available
[10:32:49] --- warlord has become available
[10:33:12] --- fenton has become available
[10:35:02] <danwing> MSS BoF. Chairs: Jim Fenton and Nathaniel Borenstein.
[10:38:54] --- kivinen has become available
[10:48:49] <danwing> room is full
[10:49:08] <danwing> Nathaniel starting BoF, reviewing agenda
[10:49:54] <danwing> Nathaniel: stating clearly: We don't want to do the same thing the 16th time and fail. We believe the problem we're solving has different constaints than the problems that have been solved 15 times unsucessfully.
[10:50:46] <danwing> Nathaniel: we will review 6 proposals.
[10:50:48] --- johnt has become available
[10:50:57] <danwing> one, domain keys, has seen a good amount of deployment.
[10:51:05] --- waynet has become available
[10:51:12] --- SAH has become available
[10:51:16] --- rand@sendmail.com has become available
[10:51:59] <danwing> Ted Hardie: agenda bashing: describe characteristic that makes these 6 proposals a common class of proposals.
[10:52:18] --- mass has become available
[10:52:18] <danwing> Nathaniel: yes, that's in the slide deck.
[10:52:26] <danwing> (slide 2)
[10:52:51] <danwing> Nathaniel describing WG Goals.
[10:53:15] --- fluffy has become available
[10:54:46] <danwing> rand wacker: anonymity concern. We need to clarify what we're identifying -- an email address, not necessarily a person.
[10:55:00] <danwing> Nathaniel: agrees, and says we're going into some detail shortly.
[10:55:09] --- rand@sendmail.com has left: Disconnected.
[10:55:13] <danwing> we're changing rooms....
[10:58:00] --- sakai has become available
[10:59:18] <danwing> .
[10:59:23] --- rand@sendmail.com has become available
[11:00:40] --- paf has become available
[11:02:00] <danwing> we're restarting in the new, improved room.
[11:02:26] --- pigdog has become available
[11:02:35] <danwing> Nathaniel discussing slide on WG non-goals.
[11:03:25] --- NFreed has become available
[11:03:42] <danwing> Nathaniel discussing difference between MASS and MARID
[11:04:08] <danwing> complementary technoligies which provide different forms of evidence about the sender. The combination of MASS and MARID will be more useful than either by itself.
[11:04:25] <danwing> next slide: potential commonalities between MASS and MARID
[11:05:21] <danwing> 7 representative proposals.
[11:05:24] <danwing> - domainkeys
[11:05:29] <danwing> - identified internet mail
[11:05:31] <danwing> - email postmarks
[11:05:35] <danwing> - entity-to-entity s/mime
[11:05:39] <danwing> - mta signatures
[11:05:44] <danwing> - bounce address tag validation
[11:06:17] --- hartmans has become available
[11:06:28] --- jis has become available
[11:06:48] <danwing> Rohan Mahy asked for the charter to be discussed before the 7 representative proposals.
[11:06:49] --- mass has left: Logged out
[11:07:01] --- mass has become available
[11:07:06] --- resnick has become available
[11:07:30] --- mengwong has become available
[11:07:51] <danwing> Charter being displayed for a few minutes; no consensus to discuss charter before the 7 representative proposals
[11:08:26] <danwing> - domainkeys
[11:08:30] <danwing> Mark Delaney, Yahoo.
[11:08:39] --- tonyhansen has become available
[11:09:37] <danwing> Yahoo has concluded they need a signature-based technique.
[11:09:58] <danwing> must be transparent to existing infrastructure; Yahoo can't start sending S/MIME everywhere on a day
[11:09:59] <danwing> KISS
[11:10:01] <resnick> Is that giant "Y!" part of the ABNF
[11:10:03] <resnick> ?
[11:10:11] <resnick> ;)
[11:10:18] --- randy has become available
[11:10:22] <danwing> No fees.
[11:10:37] --- hardie has become available
[11:10:42] <danwing> framework: public keys for a domain go into DNS.
[11:11:26] <danwing> 200401._domainkey.example.net in txt "g=;k=rsa;p=jkejfkejkf..jkjjk"
[11:11:45] <danwing> signature is stored in an RFC2822 header
[11:12:03] <danwing> new "DomainKey-Signature:" header
[11:12:44] <danwing> canonicalization needs to be worked out.
[11:13:09] <danwing> a more liberal canonicalization form can be used as well, to just sign a subset of signatures.
[11:13:19] <danwing> 4 independent implementations based on -00 specification
[11:13:23] <danwing> -01 due out ina few days
[11:13:56] <danwing> question from floor: why not use S/MIME.
[11:14:28] <danwing> Mark, Nathaniel: we can't send S/MIME without messing up receivers.
[11:14:49] --- jhutz has become available
[11:14:54] <danwing> Nathaniel: there is a particular constraint: we want to deploy this and not generate any complaints from users that aren't on S/MIME-compliant mailers.
[11:14:58] <jhutz> who are the chairs of this BOF?
[11:15:12] --- pigdog has left
[11:15:22] <danwing> Nathaniel: one large ISP said that if 1% of users complained support costs would be millions of dollars.
[11:15:29] --- Eliot Lear has become available
[11:15:32] <danwing> (Chairs are listed at beginning of this Jabber session)
[11:15:43] <danwing> (or see <http://www.ietf.org/ietf/04aug/mass.txt>)
[11:15:51] <hartmans> How much of the message is signed? Will signatures be screwed up by quoted-unprintable transformations?
[11:16:18] <danwing> Dave Crocker: defer enumerating differences between 7 proposals unitl the end.
[11:17:09] <danwing> Mark: one thing that messes up S/MIME is mailing lists that can't handle S/MIME-signed SUBSCRIBE/UNSUBSCRIBE.
[11:17:16] <danwing> Nathaniel agreed.
[11:17:34] <danwing> Richard Shockey: use of TXT for holding keys should be Considered Harmful
[11:18:00] <danwing> Nathaniel: yes, the use of DNS is unresolved, and many of these proposals put the keys into DNS.
[11:18:18] <danwing> question from floor: Domainkeys says 'no derivative works allowed; will you give IETF change control?'
[11:18:28] <danwing> Mark: we will give IETF change control.
[11:19:08] --- ekr has become available
[11:19:20] <danwing> Fred Baker: close the microphones until chairs are ready for Q&A to keep meeting on topic.
[11:19:29] <danwing> Jim Fenton: identified email is similar to domainkeys.
[11:19:53] <danwing> difference from domainkeys is public key itself is in the message, and DNS is used indirectly to find authorization of that key.
[11:20:05] <danwing> explicitly supports user- and domain-level signatures
[11:20:36] <danwing> originator can sign specific header, and those headers are included in the signature. This allows recipient's system to decide which headers to display to user.
[11:20:49] <danwing> signing and verifying in MTAs
[11:21:04] <danwing> although it's also possible to sign in an MUA, and to verify in an MUA.
[11:21:33] <danwing> a header has been defined to communicate MTA's verification, but as mentioned earlier this should be common between groups.
[11:21:48] <danwing> There is an ability to query originating domain's policy.
[11:22:00] <danwing> Jim now describing why user-level keying is important.
[11:22:22] <danwing> Affinity addresses (@ieee.org)
[11:23:00] <danwing> MTA restrictions - can only use your company's outgoing email servers
[11:23:36] <danwing> some functions are outsourced, such as benefits@example.com, and you want to authorize that outsourced provider to send mail directly without sending it through your domain.
[11:23:46] <danwing> A user-level key allows these functions.
[11:23:59] <danwing> We expect many domains will have only domain-level keys,
[11:24:04] <danwing> some will have a few user-level keys
[11:24:10] <danwing> and some domains will key entirely at the user level.
[11:24:17] <danwing> -00 was published in June.
[11:24:24] <danwing> a few changes have been made in the implementation since -00.
[11:24:48] <danwing> one change is "body counts", where you can specify a subset of the body to sign. This allows mailing lists to append stuff without breaking signatures.
[11:25:05] <danwing> original proposal was to base signature on envelope-from, but have changed it to sender: or From:
[11:25:22] <danwing> keys can now be stored in DNS or KRS. KRS is an HTTP-based key verification
[11:25:48] <danwing> next up: e-mail postmarks. Jim Lyon, Microsoft.
[11:26:04] <danwing> Nathaniel asked for clarifying questions on Jim Fenton's proposal - there were none.
[11:26:09] <danwing> Jim Lyon:
[11:26:50] <danwing> Will spend 4 minutes describing why a different proposal.
[11:26:58] <danwing> Goal: have domain attach a signature to a message.
[11:27:13] <danwing> attest this mail has passed through the offical mail servers of this domain
[11:27:36] <danwing> and to attest to various other things (the mail adheres to the antispam rules of that domain)
[11:27:57] <danwing> This proposals utilizes S/MIME because many MTAs don't send messages unchanged.
[11:28:05] <danwing> in the wild, some MTAs munge headers:
[11:28:07] <danwing> reordered
[11:28:07] <danwing> removed
[11:28:08] <danwing> changed
[11:28:18] <hartmans> OK, finally someone admits the implementations problems of previous proposals.
[11:28:47] <danwing> changed: whitespace and comments are lost, unfolding / refolding, ambiguous folding, character decoding and re-encoding
[11:29:00] <danwing> body munging:
[11:29:08] <danwing> end of line whitespace gets added / removed
[11:29:14] <danwing> transfer decoding and re-encoding
[11:29:18] <danwing> loss of mime prolog / epilog
[11:29:25] <danwing> rewriting MIME multipart delimiters
[11:29:27] --- hp has become available
[11:29:28] <danwing> MIME body part elision
[11:29:31] <danwing> content format conversion
[11:29:36] <danwing> html sanitization
[11:29:46] <danwing> add tag lines to content
[11:29:50] <danwing> .
[11:30:26] <danwing> The mistake of the world, is that with S/MIME, we have trained MTAs to not modify messages with content-type=multipart/signed
[11:31:00] <danwing> most of the MUAs have been trained to use S/MIME, although there are still some that aren't using S/MIME
[11:31:23] <danwing> issues: what does it mean if a message is already signed (by the user) and the domain signs it again
[11:31:55] <danwing> We concluded it's innocuous if the signerInfos is zero, and use a new certificate type.
[11:32:18] <danwing> existing code ignores certs it doesn't understand.
[11:32:33] <danwing> more information: http://www.lessspam.org/EmailPostmarks.pdf
[11:32:43] <danwing> question: does Microsoft claim any IPR
[11:32:48] <danwing> Jim: I dont know
[11:33:06] <danwing> Jim: I'm not the person who originally did this, that person is on LOA. I will find out if Microsoft has IPR on this.
[11:33:14] <danwing> next up: PHB from Verisign.
[11:33:29] <danwing> main issue is phishing: banks are being impersonated.
[11:33:37] <danwing> PHB=Phillip Hallam-Baker
[11:33:53] <danwing> The banks won't use S/MIME; if they won't use S/MIME, who will?
[11:34:00] <danwing> - mitigate phishing
[11:34:03] <danwing> - create signed email market
[11:34:17] <danwing> make it easy and free to sign email. Get past the S/MIME versus PGP standards war
[11:34:28] <danwing> problems with S/MIME are described in detail in the Draft.
[11:34:47] <danwing> unacceptable end user experiences; signatures are optional; end-to-end or nothing attitude.
[11:34:59] <danwing> The unacceptable end user experience is why banks won't send email using S/MIME
[11:35:53] <danwing> XKMS 2.0 slide
[11:36:15] <danwing> you get to the point where you have DomainKeys in the DNS.
[11:36:22] <danwing> DNS is a bad place to put information on users
[11:36:38] <danwing> it's a good idea to have a DNS entry to point to a server which contains user keys.
[11:36:56] <danwing> in large organizations the DNS people aren't involved with users.
[11:37:19] <danwing> XKMS is W3C candidate recommendation.
[11:37:28] <danwing> has been reviewed by PKI folks
[11:37:55] <danwing> manages whole key lifecycle. Original draft was 10 pages, current draft is 30 pages with lots of example.
[11:38:22] <danwing> To reuse XKMS for MASS, we need only define a URI as a MASS key and use XKMS as the repository to check signatures or to provision keys to the server.
[11:38:35] <danwing> there are alternatives to XKMS:
[11:38:46] <danwing> WS-Trust, PKIX SCVP, something new.
[11:38:53] <danwing> WS-Trust only addresses part of what XKMS does
[11:39:26] <danwing> SCVP delivers X.509 certificates
[11:39:56] <danwing> something new will take a long time if designed in MASS.
[11:40:10] <danwing> keep the key management piece out of the charter
[11:40:24] <danwing> Nathaniel: it is the chair's intent to not devolve into key management
[11:40:34] <danwing> Rohan Mahy: what would you do with keys retrieved with XKMS?
[11:41:26] <danwing> PHB: use a message encapsulation format, and use XKMS to retrieve the key. PHB says that using domainkeys or S/MIME for per-user keying isn't relevant to PHB's presentation.
[11:41:36] <danwing> next up: Bill Leibzon
[11:41:42] <danwing> MTA Signature Proposal
[11:42:12] <danwing> Goals: don't break email system, transparent to end users, any MTA in email path can check signature for any other MTA. Possible to implement using existing libraries.
[11:42:33] <danwing> slide: 'from S/MIME to MTA Signatures'
[11:43:02] <danwing> Looked at S/MIME and PGP as a mechanism to attach signature. Wanted to use one of those approaches automatically.
[11:43:07] --- nsb has become available
[11:43:12] <danwing> didn't want the new signatures to be confused with existing signatures
[11:43:53] <danwing> two ways with S/MIME: new MIME type, or embedded as part of unknown multipart MIME type.
[11:44:28] <danwing> MTA signature details slide:
[11:44:43] <danwing> create new MIME type, multipart/x-postal-data
[11:45:09] <danwing> headers are not signed, only the body is signed.
[11:45:21] <danwing> the headers are moved into the body to be signed there.
[11:45:32] <danwing> this is done because headers are modified by intermediate MTAS.
[11:46:11] <danwing> some mail servers remove certain MIME types from the body, such as .EXE attachments.
[11:46:32] <danwing> for verification, S/MIME depends on certificate of the vendor.
[11:46:41] --- NFreed has left: Disconnected
[11:46:48] <danwing> so a new type of signature verification method is defined.
[11:47:15] <danwing> X-Certificate-Verification-Service: "domain:key:email_key1._certs; http:download:der _certs completewhois-com-test1.cer"
[11:47:40] <danwing> only part of the DNS name is put in -- the prefix. The full DNS name is composed by taking the domainname out of the signature.
[11:48:16] <danwing> Email Verification slide:
[11:48:26] <danwing> proposal describes how to verify a signature
[11:48:42] <danwing> and a method exists to indicate if mail is always or sometimes signed.
[11:48:47] <danwing> .
[11:49:12] <danwing> next up: Dave Crocker
[11:49:52] <danwing> this proposal uses similar technology as previous presentations, but solves a different problem.
[11:50:10] <danwing> BATV: Bounce Address Tag Validation
[11:50:48] <danwing> A specification is almost complete. What exists today isn't a specification.
[11:50:56] <danwing> digitally sign mailfrom
[11:51:14] <danwing> identity is right-hand-side of mail domain.
[11:51:26] <danwing> puts its signature into left-hand side.
[11:51:49] <danwing> hard limit of 64 bytes for total of local-part.
[11:52:47] <danwing> throughout the mail system everyone can find the localpart without understanding signatures.
[11:53:05] --- paf has left: Disconnected
[11:53:12] <danwing> mailbox@example.com -> batv=mailbox/scheme/parms@example.com
[11:53:50] <danwing> The receiver of a bounce can determine if it's a bad bounce.
[11:54:24] <danwing> if you can fix the bounce generation problem, you can look at the address anywhere and detect a forged MAIL FROM.
[11:54:34] <danwing> if it's a forged MAIL FROM, the rest of it is probably forged.
[11:55:03] <danwing> benefit: it's only visible to the domain that generated it, so is opaque to everyone else.
[11:55:16] <danwing> very serious replay protection issues: solution is don't try to be perfect.
[11:56:06] <danwing> floor: one of the goals is to detect if a bounce that comes back is a message from you, or someone that tried to spoof you.
[11:56:37] <danwing> floor: when a message is coming inbound, how do you know if it's a BATV legitimate message or a spoofed BATV message.
[11:56:55] <danwing> Crocker: you have heuristics to detect if it's spoofed
[11:58:20] <danwing> next up: Jon
[11:58:39] <danwing> no slides, describing a whitepaper at http://eprivacygroup.net
[11:58:53] <danwing> implemented as commercial product called postiva (?spelling)
[11:59:28] <danwing> takes digest of the message, some information from the headers, and assertions from the sender, puts it into XML, signs the XML, and puts all of that into the header.
[11:59:38] --- kei has become available
[12:00:00] <danwing> receiver sees the header, pulls the domains key, and validates the XML. The MUA can then display this to the user.
[12:01:20] <danwing> PHB asks: is there IPR around this?
[12:01:37] <danwing> Jon: yes, there are patents pending. However, head of the company is committed to giving open-source compatible license to the patents.
[12:02:20] <danwing> open request made to disclose any other patents. No response from presenters.
[12:02:32] <danwing> Nathanial moving to next agenda item:
[12:02:37] <danwing> "Issues for WG to resolve"
[12:02:46] <danwing> - signature encapsulation
[12:02:49] <danwing> - key management
[12:02:54] <danwing> - canonicalization
[12:02:59] --- jhutz is now known as jhutz2
[12:02:59] <danwing> - behavior through mailing lists
[12:03:16] --- jhutz2 is now known as jhutz
[12:03:18] --- farias555 has become available
[12:03:33] <danwing> Rohan: before you can answer these questions, you need to decide the requirements on backward compatibility and what is scope.
[12:03:36] <danwing> Nathaniel agrees.
[12:03:52] <danwing> floor: why do you think this will work?
[12:04:22] <danwing> Nathaniel: rule that concern out of scope. There are complimentary technologies here which will work in different threat models.
[12:04:31] <danwing> I agree we should make that explicit, but if this is useful or not isn't in scope.
[12:04:46] <danwing> Nathaniel says there is a threat model in the slide deck.
[12:05:06] <jhutz> Uhh. This is a BOF. It's purpose is to determine whether to form a working group.
[12:05:11] <Eliot Lear> ***PLEASE*** don't get hung up on Threat Model docs.
[12:05:19] <jhutz> How can "is the work useful" possibly _not_ be in scope?
[12:05:26] <danwing> Jim Fenton, speaking as author of one of the drafts: there is a threat section.
[12:06:06] <danwing> rand wacker: issues. Behavior through mailing lists, does this mean survival through mailing lists, or does it mean what should a mailing list do?
[12:06:12] <danwing> Answer from audience: yes, both.
[12:06:57] <danwing> Mike Thomas: define as part of charter is the transport issue. DNS was alluded to, but we need to be clearer in the charter. This WG needs to look more in-depth on the appropriate transport.
[12:07:07] <danwing> Nathaniel: you mean key transport? Mike: yes.
[12:07:12] <ekr> I've read the threat section: it's clearly after the fact. What I want to see is: why is this supposed to work?
[12:07:56] <danwing> Nathanial discussing WG name. Ted says 'call the WG name 'HUM''.
[12:08:11] <danwing> Deliverables slide:
[12:08:20] <Eliot Lear> any solution the WG considers should clearly demonstrate that it can fix the problem, but that's not a WG item, right
[12:08:22] <Eliot Lear> ?
[12:08:34] <ekr> Well, first you need to describe what the problem is!
[12:08:48] <danwing> enable any SMTP-sending entity to:
[12:08:52] <randy> For name, how about "MESS": MEssage Signature Specification (or some such)
[12:08:59] <danwing> - convey that a crypto sig. is associated with message being delivered
[12:09:07] <danwing> - convery the identity and public key of the signing entity
[12:09:24] <danwing> - identify the precise message contents being signed (notably which headers)
[12:09:30] <danwing> - deliver the signature along with the message
[12:10:05] <danwing> And a mechanism allowing recipient to verify the public key of SMTP sender.
[12:10:06] --- tonyhansen has left: Disconnected
[12:10:12] <danwing> Ted: need to clarify if this is intended to work with MTAs or SUBMIT servers.
[12:10:40] <danwing> it's a critical question to determine which of these M*A entities need to do the signing.
[12:11:09] <danwing> Nathaniel: absolutely. We worded it as 'any SMTP-sending entity' to be inclusive.
[12:11:31] <danwing> But specifying just SMTP SUBMIT could be overly restrictive where there isn't a SUBMIT server.
[12:11:44] <danwing> Dave Crocker: this is about the message contents. Why refer to SMTP at all?
[12:12:42] <danwing> Nathaniel: you're probably right. If we can do this only changing RFC822, that would probably be better.
[12:13:56] <danwing> Crocker: second point: the deliverable "deliver the signature along with the message" constrains the behavior of the working group.
[12:14:01] <danwing> Nathaniel: point taken.
[12:14:51] <danwing> Jim Lyon: MUA behavior needs to be discussed.
[12:14:56] <danwing> Nathaniel: agreed.
[12:15:06] <danwing> Chris Lonvick: non-email messaging in scope?
[12:15:13] <danwing> Nathaniel: gray area.
[12:15:40] <danwing> Nathaniel: has been encourgaing folks in instant messaging to look for commonalities.
[12:15:50] <danwing> Rand: disassociate MTA / MUA
[12:16:29] <danwing> Eric Burger: what this WG does is going to make a difference. Before talking about Charter and Milestones, talk about the problem, how we're approaching it, and how this will fix it.
[12:16:50] <danwing> Nathaniel: we should get into the explicit threat model shortly, and we will in a few minutes.
[12:16:51] <rand@sendmail.com> not disassociate, clarify who can/should check these signatures
[12:16:56] <danwing> (thanks)
[12:16:59] --- tonyhansen has become available
[12:17:30] <danwing> PHB: problem is working with legacy MTAs, particularly forwarding. SMTP MTAs are routinely broken and they mangle bits.
[12:18:31] <danwing> Mike Thomas: re: deliverables. Two problems going on: 1. a domain has authorized a piece of mail to be sent (canonicalization, where signatures go), 2. you need a service to ask 'do you authorize this'?
[12:18:35] <danwing> These problems are disjoint.
[12:19:09] <danwing> Have a profile for email for this, and a profile for other services (instant messaging?).
[12:19:15] <danwing> Nathaniel: point taken.
[12:20:00] <danwing> Randy Gellans: one of Dave Crocker's proposals would be a simpler subset of the other one, and can be implemented without changing anyone else's infrastructure.
[12:20:06] <danwing> would that be handled in this group, or another group?
[12:20:11] <danwing> Nathaniel: I'm agnostic.
[12:20:37] <danwing> Nathaniel: if we decide Dave Crocker's proposal is in scope, the Deliverables is too restrictive.
[12:21:55] <danwing> Bill Leibzon: two points, 1. we might be changing crypto behavior of S/MIME syntax.
[12:21:59] <danwing> (sorry, missed his second point)
[12:22:04] --- hp has left: Disconnected
[12:22:39] <danwing> Dave Crocker: what's value of signing content?
[12:22:49] <danwing> Nathaniel: threat model answers this, so let's talk about it then.
[12:23:26] <danwing> Michael Thomas: asking Ted Hardie: a receiving entity are not concerned with who (or where) something was injected. Is rather more concerned if sending domain approved of the message.
[12:23:37] --- kivinen has left
[12:24:24] <danwing> Randy: useful to describe if we are changing SUBMIT agents, or MTAs? Because the SUBMIT agent is also the only entity that does the authorization for that message to be submitted.
[12:24:59] <danwing> Mike Thomas: receiving side can't tell if the SUBMIT agent or a different MTA actually did the signing.
[12:25:13] <danwing> Nathaniel: it's important to know if a message is supposed to be signed, but isn't.
[12:26:06] <danwing> Jim Fenton: a domain might choose a policy that says 'all our messages are signed', and they might do that at their egress, or where the messages are archived (such as a stockbroker). Other cases, the SUBMIT server makes the most sense.
[12:26:53] <danwing> .
[12:26:56] <danwing> Threat model:
[12:27:06] --- leg has become available
[12:27:13] <danwing> Nathaniel: phishing.
[12:28:30] <danwing> Jim Fenton: phishing - characterized by attacks on a small # of domains that are being phished. Financial losses to those domains is high.
[12:28:51] <danwing> other threat is a broad, but low-cost per domain threat -- spam and bounces as a result of your domain being spoofed.
[12:29:15] <danwing> phishing can be addressed directly by these proposals, aside from human-engineered look-alike domains.
[12:29:42] <danwing> the second threat (spam and bounces) will require accrediation and reputation services to indicate if the address is well-behaved.
[12:29:54] <danwing> floor: why do you think this will work with phishing?
[12:29:59] <danwing> Nathaniel: we'll get back to that.
[12:30:17] <danwing> Randy: instead of phishing, say 'spoofing'. phishing is a social engineering attack.
[12:30:31] <danwing> Nathaniel: we can train users to recognize citibank.com
[12:31:09] <danwing> Bill Leibzon: the authentication permitted by these proposals allows determing if phishing is occuring.
[12:31:29] <danwing> Michael Thomas: currently, with email, there is no authentication of senders. We need a way to go after people that send email.
[12:32:13] <rand@sendmail.com> "Its about the brand"
[12:32:39] <danwing> PHB: direct losses to banks aren't what worry banks. It's the several $B each they have invested into online banking. Phishing reduces confidence and trust, which moves smart folks away from online banking and into lines at physical banks.
[12:33:38] <danwing> Eric Burger: S/MIIME isn't working because we need to update keys and be changed; how is that different from these proposals which also require the same changes?
[12:33:55] <danwing> Nathaniel: most of these proposals don't require changing the MUAs.
[12:34:39] <danwing> Your MTA would do the authz for you -- by the time an MUA receives a message with a signature, it's mostly irrelevant because the MTA has already done the authz.
[12:34:51] <danwing> Michael Thomas: S/MIME solved a different problem.
[12:35:26] <danwing> (?): Phishing works because of human-engineering -- a domain looks like paypal.com, but isn't paypal.com.
[12:35:57] <danwing> The phisher could then send with paypal1.com.
[12:36:22] <danwing> Nathaniel: this proposal allows a bank to tell customers to 'look carefully at the domain.'
[12:37:21] <danwing> Fenton: we expect the bad guys to adapt. Currently, 95% of phishing is from spoofed addresses. The reason phishers are using a spoofed address, instead of a human-engineered address, is because it's easier. But we're going to break phishing based on current traffic.
[12:37:55] <danwing> Fenton: in some of these proposals, the recipient can check the domain's policy.
[12:38:19] <danwing> Nathaniel, Fenton: agreed that if the domain is socially engineered, we can't solve the problem.
[12:38:47] <danwing> Ted Hardie: cites www.qualcomm-is-hiring.com
[12:38:59] <danwing> Ted asks: should we really declare reputation out-of-scope for this WG?
[12:39:54] <danwing> Nathaniel: I see reputation services as part of the ultimate solution. I'm trying to divide and conquer.
[12:40:04] <danwing> Rohan Mahy: standard, bcp, informational, experimental?
[12:40:10] <danwing> Nathaniel: standards-track.
[12:40:37] --- sakai has left
[12:41:20] <danwing> Rohan Mahy: some of the specific proposals don't describe the problem they're solving. This WG needs to scope its work better: which problem it solves and how well (70%, 80%).
[12:41:30] <danwing> Nathaniel: would saying 'we're preventing spoofing of known domains, but not social engineered domains' be useful?
[12:41:31] <danwing> Rohan: yes.
[12:42:01] <danwing> (?): earlier someone said MARID and MASS are different, but that's not true. There is overlap. Describe why MARID doesn't solve the problem.
[12:42:20] <danwing> Nathaniel: there are at least 3 commonalities (PRA, message marking, accredidation)
[12:42:47] <danwing> PHB: accreditation issue is important. want to bind logo to a key.
[12:43:23] <danwing> PHB: there are proposals to make it easier to track registration of look-alike domains, and companies that offer this as a service.
[12:43:59] <danwing> PHB: it must be possible to link to accreditation service. But IETF shouldn't be describing how to *do* accreditation, don't duplicate X.509's expression of, but need to link to it.
[12:44:45] <randy> "Marking message to indicate successful/unsuccessful verification" has a spoofing problem -- I get tons of crap with "x-virus-check: passed (no virus found)" in it
[12:45:27] <danwing> Dave Crocker: this BoF is blowing off important issues.
[12:46:24] <danwing> Crocker: don't react to today's spammer's behavior, and add genuine utility.
[12:47:31] <danwing> Crocker: MTA-to-MTA use of S/MIME and PGP has been done and works fine.
[12:48:07] <danwing> Crocker: We have had difficulty in managing S/MIME and PGP keys. The approaches described here are described for high-volume and high-scale environments.
[12:49:01] <danwing> Crocker: independant of phishing and spam, it is useful to sign messages. However, we need to discuss carefully how the current proposals solve the problem better than PGP or S/MIME.
[12:49:07] <danwing> Nathaniel: agreed
[12:49:45] <danwing> (missed name), Yahoo: signing gives tracability to whoever is phishing using "paypal1.com".
[12:50:33] <danwing> Cullen Jennings: there are comments about level of requirements: The requirements need to be at the (a) reduce phishing or (b) reduce spam level, not at the prevent spoofing one header level.
[12:50:56] <danwing> Jon Callas: phishing is a human engineering problem.
[12:51:18] <danwing> Jon Callas: this is a security method that signs messages in a new way.
[12:51:48] <danwing> Nathaniel: good point.
[12:52:17] <danwing> Dave Crocker: responding to Ted's comment on accreditation services:
[12:52:52] <danwing> any accreditation system has to be based on an identity you believe. What we're building is a building block to such a system.
[12:53:02] <danwing> Nathaniel: yes.
[12:53:14] <danwing> Rohan Mahy: have we articulated requirements?
[12:53:23] <danwing> Nathaniel: we'll have to finish on the mailing list
[12:54:09] <danwing> PHB: phishing is getting more sophisticated using trojans.
[12:54:23] <danwing> PHB: the gap between perceived security of email and actual security of email is significant.
[12:54:42] <danwing> PHB: we can't tell the user 'you're too stupid'.
[12:54:55] --- waynet has left
[12:55:28] <danwing> PHB: concentrate on the domain level identity, as that has historically been successful.
[12:56:05] <danwing> PHB: witness SSL and the padlock icon.
[12:57:43] <danwing> Mike Thomas: regarding reputation/accreditation: we need a way to detect forgery. Once we have that, the spammers and forgers have to get throw-away domains.
[12:58:08] <danwing> problems between domain-level authz and accreditation are similar, but there may be legal differences we're not aware of.
[12:58:46] <danwing> Mike Thomas: divide the problem into two things: authz mail, and later in this WG take on accreditation.
[12:59:22] <danwing> Nathaniel: wants to narrow goal of WG. Nathaniel wants reputation addressed separately.
[12:59:49] <danwing> Fenton: 1. can we do good with a crypto approach w/o accreditation? A: Yes.
[13:00:10] <danwing> 2. Would accreditation fragment this group? Yes, so keep it out.
[13:00:33] <danwing> 3. This BoF is under the Security area (instead of applications). Accreditation seems more an applications-area problem.
[13:01:04] <danwing> Nathaniel: word-smithing charter will be done on the mailing list.
[13:01:15] <danwing> http://www.imc.org/ietf-mailsig/
[13:01:50] <danwing> mailing list: ietf-mailsig@imc.org
[13:01:57] <mengwong> "i would like to encourage those of you who are interested, to participate more on the mailing list; i would also like to encourage those of you who think all this is a total waste of time, to not waste your time."
[13:02:01] <mengwong> -- nsb
[13:02:48] <danwing> (sorry, missed name): we can build goals only by knowing what the problem we're trying to solve is.
[13:03:10] <danwing> Nathaniel: we need a reference arch. for spam finding, and the output of this WG will fit in.
[13:03:16] <danwing> (): I don't see how this WG fits in.
[13:03:18] <danwing> Nathaniel: fair enough.
[13:03:54] <danwing> hum vote: consensus is to move this BoF forward.
[13:04:31] <danwing> Mark (?): some spam traffic is originating from within someone's network via trojans that have been compromised.
[13:04:33] <jis> Apparently subscription to ietf-mailsig doesn't require confirmation
[13:04:47] <jis> (Marcus Leech)
[13:04:55] <danwing> (tx)
[13:05:37] <danwing> Eric Burger: I hummed because this work should be done. Something is better than nothing. But I don't like the existing charter.
[13:07:35] <danwing> PHB: we need a requirements document that shows how this BoF -- and everything else -- fits into the overall architecture to block phishing, spamming.
[13:07:35] --- fluffy has left: Disconnected
[13:07:44] <danwing> Nathaniel: 34 consortia working on spam.
[13:08:04] <danwing> Nathaniel: yes, we need an architecture. The criticism applies to MARID and MASS.
[13:08:13] --- SAH has left
[13:08:58] <danwing> Crispin (?), IACA: much spam doesn't spoof a legitimate address at all. But they generally cannot respond to the proported address they're spoofing. None of the proposals here take that weakness into account. Folks should consider this weakness into a mechanism to formulate this solution.
[13:09:21] <danwing> Nathaniel: challenge-response could resolve this. Expects to see WGs that address C/R.
[13:10:15] <danwing> <missed name>: In favor of moving this BoF forward we can resolve the underlying problem.
[13:10:25] <danwing> wants to see threat model.
[13:11:33] <danwing> Russell Housley:: deliver a threat and requirements document.
[13:12:26] --- tonyhansen has left: Disconnected
[13:12:43] <danwing> Bellovin: requirements document needs to make hard decisions. Stress MTAs or MUAs, for example.
[13:13:26] <danwing> PHB: security isn't the hard part (signature, From: address, etc.), but the big issue is the message encapsulation formats. This encapsulation format is where the proposals diverge in substance.
[13:14:08] <danwing> S/MIME versus headers, based on the 'yuck' in the system. We need to decide which types of canonicalization survive and which don't.
[13:14:11] <hartmans> I think I agree with phb here; a study in what is possible to get through email would be useful
[13:14:22] <hartmans> And may well be necessary.
[13:14:26] <danwing> Nathaniel: that's where Yahoo's DomainKeys deployment can teach us.
[13:15:07] <danwing> Mike Thomas: lock-stepping requirements documents and our work is too slow.
[13:15:42] <danwing> Nathaniel: yes, we need to do this in parallel fashion. Other groups will do a worse job than us.
[13:15:43] <kei> ( Thanks a lot for your contribution(logging)! > danwing )
[13:15:59] <danwing> (sure, no extra charge!)
[13:16:09] --- jis has left: Disconnected
[13:16:13] --- hardie has left
[13:16:20] <danwing> this Jabber log will be posted to the mailing list.
[13:16:30] --- farias555 has left
[13:16:32] --- rand@sendmail.com has left: Disconnected.
[13:16:33] --- johnt has left
[13:18:24] --- warlord has left
[13:20:51] --- nsb has left: Disconnected.
[13:20:57] --- fenton has left
[13:21:02] --- Eliot Lear has left: Disconnected
[13:21:06] --- resnick has left: Disconnected
[13:23:23] --- mengwong has left: Disconnected
[13:26:37] --- jhutz has left: Disconnected
[13:29:14] --- leg has left: Disconnected
[13:34:06] --- ekr has left: Disconnected
[13:35:05] --- kei has left
[13:35:18] --- randy has left: Disconnected
[13:53:03] --- mass has left: Disconnected
[14:09:59] --- galvinjamesm has left
[14:15:09] --- danwing has left: Disconnected
[14:54:47] --- Eliot Lear has become available
[14:54:58] --- Eliot Lear has left
[15:05:15] --- leg has become available
[15:06:12] --- leg has left: Disconnected
[16:44:01] --- fenton has become available
[16:47:02] --- fenton has left
[17:00:01] <hartmans> Yes of course
[17:26:04] --- jhutz has become available
[17:26:42] --- jhutz has left
[18:29:32] --- randy has become available
[18:39:19] --- randy has left: Replaced by new connection
[19:16:37] --- hartmans has left
[22:48:03] --- rlbob has become available
[22:49:04] --- rlbob has left