Subject: [apps-discuss] RRVS status update and one outstanding question

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 8 Apr 2014 22:20:55 -0700

Colleagues,

The IESG evaluation of the RRVS draft drew one major DISCUSS position from
Pete Resnick.  Bill and I have been talking to him about how to resolve
them, and we have developed a number of edits as a result.  These are
largely editorial but still somewhat significant, and we also believe they
are true to the original intent, so we don't imagine the working group will
object to any of it.

The proposed revision is at:
http://www.blackops.org/~msk/draft-ietf-appsawg-rrvs-header-field.txt

A diff to the last published version can be found at:
http://www.blackops.org/~msk/rrvs-diff.html.

Given that there are no protocol changes, we'll assume the WG is fine with
them unless there's consensus otherwise.

One point did come up upon which we are currently split, and we'd like the
working group's opinion on how to proceed.  Barry points out that we do not
specify what a receiver should do in the case where RRVS is used by a
client that hands a message to an MDA, but the MDA is unable to determine
the result of the continuous ownership test.  This is not a transient
failure, mind you, but rather one where, for example, the receiving ADMD
simply never recorded the mailbox creation date.  It thus cannot ever
answer the question.  Should the receiver reject this message, or deliver
it, or leave this to receiver discretion?

Bill argues that the receiver MUST reject in this case; the goal is to
protect the message against misdelivery, and it's not definitely safe to
deliver it here.  I'm not so sure; if we do that, then no RRVS-protected
message will ever be delivered to that mailbox, and the protocol itself
includes no means of notifying the receiving user that there's a problem.
There's no way for this to get fixed unless the MDA's ADMD invents a
creation time, which also isn't safe.

What are the WG's thoughts here?

-MSK

---

From: Dave Cridland <[email-masked]>
Date: Wed, 9 Apr 2014 09:09:18 +0100

Really? If you default the creation time to the earliest point in time that
account creations were recorded, that's certainly safe.

Any earlier is increasingly unsafe.

Bill's suggestion is equivalent to the default creation time of now, but
that has no advantage over setting it to the earliest time of recording.

The problem for me is that if I send an email to an old contact, marking it
with rrvs on my client, I'd want to know if the rejection were absolute,
because an account is known to have been replaced, or by default because
the time simply isn't known.

Also, it means the best time to use is the latest. I'm on my mobile, so
haven't checked if this is already the case in the draft.

Dave.

---

From: Bill Mills <[email-masked]>
Date: Wed, 9 Apr 2014 09:20:33 -0700

In the end the local site makes the decision, what we're doing here is giving guidance what the site should do in local policy.  

We could add an error case as well.  I'd be fine with that.  It exposes that the site doesn't know the age of the account, which I consider more to be about the site than the account.  The sender then has the option to resend without RRVS.  

-bill

--------------------------------
William J. Mills
"Paranoid" MUX Yahoo!

On Wednesday, April 9, 2014 1:09 AM, Dave Cridland <[email-masked]> wrote:

On 9 Apr 2014 06:21, "Murray S. Kucherawy" <[email-masked]> wrote:
>  There's no way for this to get fixed unless the MDA's ADMD invents a creation time, which also isn't safe.
Really? If you default the creation time to the earliest point in time that account creations were recorded, that's certainly safe.
Any earlier is increasingly unsafe.
Bill's suggestion is equivalent to the default creation time of now, but that has no advantage over setting it to the earliest time of recording.
The problem for me is that if I send an email to an old contact, marking it with rrvs on my client, I'd want to know if the rejection were absolute, because an account is known to have been replaced, or by default because the time simply isn't known.
Also, it means the best time to use is the latest. I'm on my mobile, so haven't checked if this is already the case in the draft.
Dave.

_______________________________________________
apps-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 9 Apr 2014 09:53:34 -0700

On Wed, Apr 9, 2014 at 9:20 AM, Bill Mills <[email-masked]> wrote:

> In the end the local site makes the decision, what we're doing here is
> giving guidance what the site should do in local policy.
>
>
But it's a local policy decision about the security of content they didn't
create.  Unlike things like DKIM and such, the protection is aimed at the
sender, not the recipient.

> We could add an error case as well.  I'd be fine with that.  It exposes
> that the site doesn't know the age of the account, which I consider more to
> be about the site than the account.  The sender then has the option to
> resend without RRVS.
>
>

That's a possibility.  What do others think?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 9 Apr 2014 09:56:35 -0700

On Wed, Apr 9, 2014 at 1:09 AM, Dave Cridland <[email-masked]> wrote:

> Really? If you default the creation time to the earliest point in time
> that account creations were recorded, that's certainly safe.
>

Sure, that's possible.  But what if you don't know what that timestamp was
either?

> The problem for me is that if I send an email to an old contact, marking
> it with rrvs on my client, I'd want to know if the rejection were absolute,
So just to be clear, you're talking about two response codes for a mailbox,
one that indicates "no" and one that indicates "not known"?

> haven't checked if this is already the case in the draft.
It's not yet.  This is the only outstanding issue.

-MSK

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 9 Apr 2014 21:02:30 +0200

You do know that. Maybe you don't know when the RRVS-capable software was 
first deployed at the relevant site, but you certainly know when it was 
written.

Arnt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 9 Apr 2014 12:44:32 -0700

> first deployed at the relevant site, but you certainly know when it was
I'm not sure what you mean by that.  Are you saying that if you don't have
an explicit date recorded for a given mailbox, you select some locally
obvious couldn't-possibly-have-been-earlier-than-this date, and use that?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 9 Apr 2014 19:50:58 -0000

> Barry points out that we do not
>the result of the continuous ownership test.

There's two failure modes here, one where the wrong user gets someone
else's message, another where the right user loses his own message.
Which is th worse problem depends on what the message is about.  For
example:

* Your account at Foo Bank needs attention, check the web site

* The recovery password for your Foo Bank account is swordfish

In the first case, the amount of info leaked to the wrong recipient is
low, and the potential value to the right recipient is high (e.g.,
move money from savings to checking today or we'll charge you four $35
bounce fees.)  In the second case, it's better to lose it and wait for
the customer to call or something.

I have no idea which will be more typical of RRVS traffic, and I don't
think anyone else does either.  I'd document it as a security issue
and leave it as an implementation decision.

R's,
John

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 9 Apr 2014 22:03:06 +0200

On Wednesday, April 9, 2014 9:44:32 PM CEST, Murray S. Kucherawy wrote:
> I'm not sure what you mean by that.  Are you saying that if you 
> don't have an explicit date recorded for a given mailbox, you 
> select some locally obvious 
> couldn't-possibly-have-been-earlier-than-this date, and use 
> that?

More or less. I am assuming (based on someone's argument) that if you don't 
know the actual date, then the date must be from before you started 
recording, and you can use the start of recording as a reasonable proxy.

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Wed, 9 Apr 2014 21:12:33 +0100

On 9 April 2014 20:44, Murray S. Kucherawy <[email-masked]> wrote:

> On Wed, Apr 9, 2014 at 12:02 PM, Arnt Gulbrandsen <
> [email-masked]> wrote:
>

It's actually the earliest possible
couldn't-possibly-have-been-*later*-than-this date.

So for the "when we started recording account creation", this is the
earliest date for which we know an account was not created afterward unless
explicitly recorded.

Dave.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 9 Apr 2014 14:10:24 -0700

Could you phrase that in prose fit for a draft?  :-)  I think I get what
you're suggesting but I'm not certain.

I feel as though we'll ultimately need to accommodate the case where the
answer is "I don't know" to all forms of the question, even the case you're
talking about (e.g., where the operator has no idea how to figure out what
an earliest possible couldn't-possibly-have-been-*later*-than-this date
might be).  Something like this is what I have in mind so far:

(1) use the account creation/reassignment date, if you know it; OTHERWISE
(2) use the earliest possible couldn't-possibly-have-been-*later*-than-this
date, if you know it; OTHERWISE
(3) return a bounce with an enhanced status code indicating the MDA is
unable to comply with the query, so either give up or try again without
RRVS.

-MSK

On Wed, Apr 9, 2014 at 1:12 PM, Dave Cridland <[email-masked]> wrote:

>>> You do know that. Maybe you don't know when the RRVS-capable software
>>> was first deployed at the relevant site, but you certainly know when it was
>>> written.
>>>
>>>
>> I'm not sure what you mean by that.  Are you saying that if you don't
>> have an explicit date recorded for a given mailbox, you select some locally

---

From: Hector Santos <[email-masked]>
Date: Sat, 12 Apr 2014 09:08:48 -0400

I've been wondering how to phrase my question(s). I guess I'm not 
quite following.  Is the suggestion below a design suggestion or 
protocol logic for a "Partial Support" of the protocol?

The RRVS implementation will most likely need to add a new field or 
two.  Also, to do it correctly, the first time records 
update/conversion will be needed to fill in these fields from "almost 
near, make sense" timestamps, i.e. in our cases, we have several 
fields to use:

       LastCall
       LastUpdate
       VericationDate

But if you don't have these or have yet to do a design change, you can 
do "partial support" by returning a negative response when used 
against your system?

Finally,  a few more questions:

1) Is there some open source code out there to see if how this is 
being implemented?

2) Is there a method to test this against other sites, also without 
exhausting many new accounts?  Like at facebook, i created a bunch of 
new [email-masked] signups to see if it was sending the RRVS 
during the email confirmation.

thanks

On 4/9/2014 5:10 PM, Murray S. Kucherawy wrote:
> Could you phrase that in prose fit for a draft?� :-)� I think I get
> what you're suggesting but I'm not certain.
>
> I feel as though we'll ultimately need to accommodate the case where
> the answer is "I don't know" to all forms of the question, even the
> case you're talking about (e.g., where the operator has no idea how to
> figure out what an earliest possible
> couldn't-possibly-have-been-*later*-than-this date might be).�
> Something like this is what I have in mind so far:
>
> (2) use the earliest possible
> couldn't-possibly-have-been-*later*-than-this date, if you know it;
> OTHERWISE
> unable to comply with the query, so either give up or try again
> without RRVS.
>
> -MSK
>
>
>
> On Wed, Apr 9, 2014 at 1:12 PM, Dave Cridland <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On 9 April 2014 20:44, Murray S. Kucherawy <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         <[email-masked] <mailto:[email-masked]>>
>         wrote:
>
>             You do know that. Maybe you don't know when the
>             RRVS-capable software was first deployed at the relevant
>             site, but you certainly know when it was written.
>
>
>         I'm not sure what you mean by that.� Are you saying that if
>         you don't have an explicit date recorded for a given mailbox,
>         you select some locally obvious
>         couldn't-possibly-have-been-earlier-than-this date, and use that?
>
>
>     So for the "when we started recording account creation", this is
>     the earliest date for which we know an account was not created
>     afterward unless explicitly recorded.
>
>     Dave.
>
>
>
>

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Apr 2014 10:14:12 -0700

On Sat, Apr 12, 2014 at 6:08 AM, Hector Santos <[email-masked]> wrote:

> But if you don't have these or have yet to do a design change, you can do
> "partial support" by returning a negative response when used against your
> system?
>

As I've said before, if you don't have the infrastructure to answer the
RRVS question, you would simply not advertise the RRVS extension and ignore
the header field.

Finally,  a few more questions:
>
> 1) Is there some open source code out there to see if how this is being
> implemented?
>

Not that I know of.  This would be hard to do given the non-extensibility
of most open source implementations, at least as far as SMTP extensions go.

> exhausting many new accounts?  Like at facebook, i created a bunch of new
> [email-masked] signups to see if it was sending the RRVS during
> the email confirmation.
>

Facebook won't send RRVS header fields (the current implementation) except
by private agreement right now.  I don't know what others are doing.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Sun, 20 Apr 2014 20:31:39 -0700 (PDT)

> That's a possibility.  What do others think?

Frankly, I think we've reached the point where we're overdesigning things.

If I'm running a site with a bunch of mailboxes, exactly why would it
ever be to my advantage to ever bounce mail with this error?

				Ned