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