Subject: RE: [ietf-dkim] user level ssp

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 6 Sep 2006 14:16:27 -0700

I have yet to work out if this is a good idea or not.

However there is already a precedent in NSEC3 records.

One thing that we would have to take care to ensure is that there were no undesirable interactions between the two.

Another consideration here that might motivate the change is to prevent zone walking. If the zone is DNSSEC signed and the standard NXT record is used an attacker can read out the list of policy records. Use of NSEC3 avoids this problem. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Wednesday, September 06, 2006 2:00 PM
> To: Michael Thomas
> Cc: IETF-DKIM
> Subject: Re: [ietf-dkim] user level ssp
> 
> 
> On Sep 6, 2006, at 10:14 AM, Michael Thomas wrote:
> 
> >
> > All of this talk about additional requirements for user level ssp 
> > ignores the basic question: should there be any 
> requirements for user 
> > level SSP at all? If so, what are the use cases? I'm not terribly 
> > convinced that even that has consensus -- this is the first that I 
> > even recall the subject being raised.
> 
> When a large financial institution wishes to have a specific 
> email- address receive added assurances via annotations, then 
> having a means to include these addresses within policy 
> satisfies this desire  
> without specific arrangements made separately with each verifier.   
> The current strategies for financial institutions require an 
> assertion that _all_ messages be signed.  Not all messages 
> from a large domain warrant receiving annotations of added 
> assurances however.  Having a means to convey which 
> email-address warrants this annotation can be accomplished via policy.
> 
> Rather than a direct translation into a DNS label, a base32 
> encoding of a SHA-1 hash ensures long local-parts, UTF-8, and 
> subaddress symbols can be handled by this scheme. (SHA-256 
> could be used, but there does not seem to be a need for this extreme.)
> 
> -Doug
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
> 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 6 Sep 2006 15:16:23 -0700

Its rather easier to do in the case of Yahoo mail since the infrastructure is already built out for very large scale and the management of the infrastructure is considerably more homogenous than typical large enterprise deployments.

I would not anticipate an issue but if there were an issue it is entirely practical to have a DNS zone with a large number of entries.

I see the need for per-user policies to be a transitional issue rather than a something you would expect to run for long periods.

Within that 219 million addresses you might find you have the need to define a small number of exceptions.

> [mailto:[email-masked]] On Behalf Of J.D. Falk
> Sent: Wednesday, September 06, 2006 5:18 PM
> To: IETF-DKIM
> On 2006-09-06 14:12, Hallam-Baker, Phillip wrote:
> 
> > Since you can wildcard the most common case one would need 
> 50,000 SSP 
> > records at most. It is likely that they would be generated 
> > automatically as individual mail servers were configured to 
> use DKIM.
> > 
> > BITs are cheap. I see no problem in deploying 100,000 DKIM 
> records in 
> > such a situation.
> 
> How will that scale to the 219,000,000 users that comScore 
> thought Yahoo! Mail had about a year ago?
> 
> (The actual number is a trade secret, but comScore's close 
> enough for this conversation.)
> 
> And, have any actual banks actually asked for this, or is it 
> still entirely theoretical?
> 
> --
> J.D. Falk, Anti-Spam Product Manager
> Yahoo! Communications Platform Team

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 7 Sep 2006 09:15:09 -0700

> [mailto:[email-masked]] On Behalf Of Michael Thomas

> The utility of "I sign some" is not in the policy itself, but in the
> *discovery*
> part of the protocol: when you find _any_ valid record, you 
> know that you can stop looking for one.  Depending on the 
> tree walking aspects of the discovery mechanism, this could 
> be a useful thing. Maybe it would be better to do this by not 
> expressing any  policy/practice in the otherwise valid to get 
> this functionality so as not to confuse the issue with the 
> semantics  of  "I sign some" which doesn't seem to mean much.
> 
> I have no idea what use "I sign no mail" has.

I suggest that we replace 'I sign no mail' and 'I sign some mail' with 'Undefined'.

A policy mechanism with two values is going to be much easier to administer than one with fve degrees of freedom.

One reason I want to insist on the binary choice here is that I want to encourage publication of the only policy that is useful to a receiver. If you allow for a weasel route you are going to have a hard time getting anyone to go all the way. Its like the problem we have with Draft standard and Standard here in the IETF.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 7 Sep 2006 10:18:37 -0700

It would be a big problem because the advice that we have been giving the banks at the Anti-phishing working group for the past three years has been to use one domain exclusively for all their mail.

I don't know whether we need user level policy or not. What I do know is that we can construct a situation where the domain record is the master record and the per-user policy is only consulted if the domain lookup fails and so we don't have to make a decision now.

I suggest we consider support for per user policy at the architectural level but leave it out of the core policy spec in the first instance.

> [mailto:[email-masked]] On Behalf Of John L
> Sent: Thursday, September 07, 2006 12:23 PM
> To: Michael Thomas
> Cc: [email-masked]
> > heard of is more aimed at securing things like 
> [email-masked] 
> > without having to say "I sign everything" for the entire 
> domain which 
> > is assumedly a lot harder. The thing about this is that you can 
> > alternately set up a record for 
> [email-masked] or somesuch which would work 
> the same way.
> > I've heard it expressed that that is problematic for some 
> people, but 
> > I frankly don't remember why at this point.
> 
> I think it's a problem for banks that signed up for the 
> $2.99/mo DNS hosting service and can't afford to switch to 
> the $7.99 version.
> 
> R's,
> John
> 
> "Save at the Sign of the Sock"

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 7 Sep 2006 12:19:33 -0700

Arvel,

I think it is reasonable for the sender to say 'here is how you can spot a likely fake'. This statement is tantamount to 'be very suspicious' or even in certain cases 'discard this message' since a fake is almost certainly spam. 

The part that I think SPF folk failed to understand was that the sender can never order the receiver to ACCEPT a message. 

The second issue is the reason why it is very important to avoid suggesting that the sender is in control. I dislike use of the term authorization for the same purpose.

> [mailto:[email-masked]] On Behalf Of Arvel Hathcock
> Sent: Thursday, September 07, 2006 1:30 PM
> To: [email-masked]'
> Subject: RE: [ietf-dkim] user level ssp
> 
> > At base the former seems to move SSP from being a basic means of 
> > checking for rogue mail, into recruiting the receive-side to be an 
> > agent of the From-field domain owner, for enforcing potentially 
> > complex operational rules.
> 
> IMO, "recruiting the receive-side to be an agent of the 
> From-field domain owner" probably goes too far.  I certainly 
> don't feel I am an "agent" of the RFC2821.mail domain owner 
> when I do my SPF checks.  Nor am I the servent of the PRA by 
> virtue of doing Sender-ID.  Rather, those who employ SSP are 
> "agents" working on their own behalf in an attempt to utilize 
> another authenticity vector in order to provide the most 
> trustworthy mail service they can.
> 
> "for enforcing potentially complex operational rules" - SSP 
> is simply an gathering mechanism.  Any complex operational 
> rules are at the discretion of the receiver post-SSP right?
> 
> > Absent compelling demonstration of market need,
> 
> I believe that the need and duty to protect ones domain from 
> unauthorized use is (or should be) presuppositional and 
> therefore needs no demonstration.  However, are you saying 
> that the market has no need for SSP?  What constitutes 
> "compelling" and are we qualified to determine that in the IETF?
> 
> > why are we considering something that, to my knowledge, has no 
> > experiential base for the scale and complexity of the open Internet?
> 
> SPF provides, at least partially, the experiential base for 
> something like SSP doesn't it?  It is deployed widely, is DNS 
> based, and is more complex than SSP.  Yet the market seems to 
> have embraced it.
> 
> --
> Arvel 
> 
> 
> 
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 7 Sep 2006 14:28:10 -0700

OOPs forgot one criteria,

* There is no valid signature

:-)

I think that there will be a lot of value in the 'no I mean it' modifier in the next couple of years. Eventually I hope we can fix the relays and everyone can mean it.

Another semantic difference is that if I see someone claiming to be a target of phishing and I see fake messages I am likely to want to report them.  

> [mailto:[email-masked]] On Behalf Of Steve Atkins
> Sent: Thursday, September 07, 2006 4:32 PM
> To: [email-masked]
> On Sep 7, 2006, at 12:54 PM, Hallam-Baker, Phillip wrote:
> 
> >
> >> [mailto:[email-masked]] On Behalf Of Steve Atkins
> >
> >> On Sep 7, 2006, at 12:28 PM, Hallam-Baker, Phillip wrote:
> >>
> >>>
> >>>> [mailto:[email-masked]] On Behalf Of John Levine
> >>>
> >>> Mostly +1
> >>>
> >>> But there could be utility in the sender saying 'My email
> >> is at very
> >>> serious risk of being impersonated'.
> >>
> >> What is that utility? Please expand on what behaviour you 
> expect from 
> >> the recipient and how that will differ from the case where 
> the sender 
> >> does not say that.
> >
> > If I know that you are a self declared target of phishing 
> and that the 
> > consequences of letting a phish go through are considerably more 
> > serious than a random impersonation spam I can adjust my 
> spam filters 
> > accordingly.
> >
> > In particular I would expect to filter out ALL mail 
> automatically in 
> > the case that ALL the following apply:
> >
> >   * The sender ALWAYS signs
> >   * The sender declares themselves to be at risk of phishing attack
> >   * The content is HTML
> >   * There are URIs in the body of the text message
> >   * The message has not been forwarded by a previously noted 
> > intermediary.
> 
> How does that differ from the case where:
> 
>    * The sender ALWAYS signs
>    * The content is HTML
>    * There are URIs in the body of the text message
>    * The message has not been forwarded by a previously noted 
> intermediary.
> 
> I guess that the real question is  what's the difference 
> between "I always sign"
> and "I always sign and I get phished"?
> 
> The impression I'm getting, from several people, is that "I 
> always sign" is already being written off as likely to be 
> ignored by recipients and that there needs to be a "No, I 
> really mean it!" modifier?
> 
> Cheers,
>    Steve
>