Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt

From: [email-masked]
Date: Wed, 11 Dec 2013 15:39:24 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

	Title           : The Require-Recipient-Valid-Since Header Field and SMTP Service Extension
	Author(s)       : William J. Mills
                          Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rrvs-header-field-05.txt
	Pages           : 20
	Date            : 2013-12-11

Abstract:
   This document defines an extension for the Simple Mail Transfer
   Protocol called RRVS, and a header field called Require-Recipient-
   Valid-Since, to provide a method for senders to indicate to receivers
   the time when the sender last confirmed the ownership of the target
   mailbox.  This can be used to detect changes of mailbox ownership,
   and thus prevent mail from being delivered to the wrong party.

   The intended use of these facilities is on automatically generated
   messages that might contain sensitive information, though it may also
   be useful in other applications.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-rrvs-header-field-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rrvs-header-field-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Dec 2013 16:21:52 -0800

>    be useful in other applications.

Addresses the suggested changes received since -04.  Thanks to everyone
that provided comments!

-MSK

---

From: Bill Mills <[email-masked]>
Date: Wed, 11 Dec 2013 21:03:33 -0800

Looks good to me.

-bill

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

On Wednesday, December 11, 2013 4:23 PM, Murray S. Kucherawy <[email-masked]> wrote:

>   be useful in other applications.

Addresses the suggested changes received since -04.  Thanks to everyone that provided comments!

-MSK

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

---

From: Dave Cridland <[email-masked]>
Date: Fri, 13 Dec 2013 14:50:39 +0000

I've read this through (relatively quickly), and nothing huge leaps out at
me. I think it could possibly be clearer on why MTAs should remove the
header fields, but maybe a pointer or two to §15.3 is all that's needed.

In any case, I'm good for this to go forward.

---

From: Kurt Andersen <[email-masked]>
Date: Fri, 13 Dec 2013 08:29:20 -0800

Looks good to me also.

--Kurt Andersen

---

From: "J. Trent Adams" <[email-masked]>
Date: Fri, 13 Dec 2013 09:46:37 -0700

I reviewed the current -05 draft with a fine-toothed comb and have
submitted my shepherd's writeup using the new, simplified writeup
template.  It can be found in the datatracker:

https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/shepherdwriteup/

There are only a couple of nits that need to be addressed, but they're
purely syntax issues.  Specifically, some registry names and sub-tables
referenced in the IANA Considerations section need to be clarified, and
new enumerated error codes need to be requested (since the codes
previously identified in the draft have subsequently been registered). 
I've communicated these issues to Murray and he has already queued them
up for a subsequent revision.

Other than that, everything appears to be in order.  Unless anyone spots
any additional issues needing to be addressed, it looks as if the -05
draft is ready to move to Working Group Last Call (WGLC).

- Trent (as document shepherd)

On 12/13/13 7:50 AM, Dave Cridland wrote:
> I've read this through (relatively quickly), and nothing huge leaps
> out at me. I think it could possibly be clearer on why MTAs should
> remove the header fields, but maybe a pointer or two to §15.3 is all
> that's needed.
>

-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams

---

From: Ned Freed <[email-masked]>
Date: Fri, 13 Dec 2013 08:58:10 -0800 (PST)

I finally got a change to review this more carefully. My comments follow.

The second point in section 5 should state explicitly that it is talking
about the case where the header field is present. As it stands it sounds
wierd, because the combination of the receiver implementing the extension
and the client not using the SMTP parameter doesn't imply that the header(s)
will be present.

I also think it would be clearer if the first paragraph of section 5 said
"implements this specification" rather than saying "implements the RRVS
SMTP extension". The former is more inclusive, and this section is
talking about header handling as well as how the extension works.

Does the first point in section 5.1 regarding role accounts only apply to local
role accounts? Or does this also mean that the RRVS parameter can be dropped
from an address like postmaster@remote-domain? Whenever this sort of thing
comes up, My immediate inclination is always to say "No, you only look at local
parts when you have authority over the domain." But this may be a bit trickier
than it sounds, because what happens when an the next hop for
postmaster@remote-domain doesn't support the RRVS extension?

OTOH, perhaps someone who uses a role account for ordering stuff from Amazon
deserves what they get?

Maybe I'm missing something, but the third point and the last paragraph
in section 5.1 seem to be saying more or less the same thing.

I think some compliance language may be in order in section 9.1 - in
particular, that the extension MUST be dropped and the header MUST be removed
by compliant mailing list expanders.

Since we're defining an authentication-results field for this, I think it would
be very helpful to have an example of its usage in section 13.

Nits:

There' a "that that" in the last paragraph of section 4.

Alaises in misspelled in the title of section 9.2.

That's it!

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 Dec 2013 10:26:36 -0800

Thanks, Ned.  That's all pretty minor stuff; no objections from me and I'd
wager the same from my co-author.  Any objecting to dealing with this all
during or after WGLC?

-MSK

---

From: Bill Mills <[email-masked]>
Date: Fri, 13 Dec 2013 10:31:37 -0800

This all generally looks sane and reasonable.  

One discussion point, I'm concerned if mailing lists are forced to modify headers that it will maybe break DKIM or other signatures to I'd rather leave that as a SHOULD.

-bill

On Friday, December 13, 2013 10:27 AM, Murray S. Kucherawy <[email-masked]> wrote:
 
Thanks, Ned.  That's all pretty minor stuff; no objections from me and I'd wager the same from my co-author.  Any objecting to dealing with this all during or after WGLC?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 Dec 2013 10:44:20 -0800

There are two sides tugging at this in the document.  We acknowledge that
DKIM signatures might be invalidated, but we also say that one way to make
sure the content of it can be trusted is to sign it.  Also, the prose of
DKIM (for example) suggests that this isn't an appropriate header field to
sign in the first place because it's not part of the core message content.

I'm starting to think the text about signing the field as a way of proving
its authenticity might need to go.  That way removal of the field doesn't
affect anything.  Anyone else have a thought here?

On Fri, Dec 13, 2013 at 10:31 AM, Bill Mills <[email-masked]> wrote:

> One discussion point, I'm concerned if mailing lists are forced to modify
> headers that it will maybe break DKIM or other signatures to I'd rather
> leave that as a SHOULD.
>
>
>
> -bill
>
>
>  Thanks, Ned.  That's all pretty minor stuff; no objections from me and
> I'd wager the same from my co-author.  Any objecting to dealing with this
> all during or after WGLC?
>
> -MSK
>
>

---

From: Bill Mills <[email-masked]>
Date: Fri, 13 Dec 2013 10:53:07 -0800

We should say it should not be part of the DKIM signature.  This makes sense because we're saying the header is in fact ephemeral and for the use of the mailers and not the end user or MUA.

There's little impact of having it outside the DKIM signature.  The only thing I can think of is that if an MX is checking DKIM to decide if it will honor RRVS then an attacker could probe account age if they could intercept mail in transit.  Not a big problem.

-bill

On Friday, December 13, 2013 10:44 AM, Murray S. Kucherawy <[email-masked]> wrote:
 
There are two sides tugging at this in the document.  We acknowledge that DKIM signatures might be invalidated, but we also say that one way to make sure the content of it can be trusted is to sign it.  Also, the prose of DKIM (for example) suggests that this isn't an appropriate header field to sign in the first place because it's not part of the core message content.

I'm starting to think the text about signing the field as a way of proving its authenticity might need to go.  That way removal of the field doesn't affect anything.  Anyone else have a thought here?

---

From: "J. Trent Adams" <[email-masked]>
Date: Fri, 13 Dec 2013 11:56:58 -0700

On 12/13/13 11:44 AM, Murray S. Kucherawy wrote:
> There are two sides tugging at this in the document.  We acknowledge
> that DKIM signatures might be invalidated, but we also say that one
> way to make sure the content of it can be trusted is to sign it. 
> Also, the prose of DKIM (for example) suggests that this isn't an
> appropriate header field to sign in the first place because it's not
> part of the core message content.
>
> I'm starting to think the text about signing the field as a way of
> proving its authenticity might need to go.  That way removal of the
> field doesn't affect anything.  Anyone else have a thought here?

First, I think that this is an issue we can address within WGLC and
shouldn't hold up the process.

As far as a possible solution, it might be possible to explore allowing
for a DKIM signature dedicated to the RRVS header, which is separate
from the main signature.  That would allow the RRVS signature to break
while allowing the main content signature to remain valid.

FFT,
Trent

>
>
> On Fri, Dec 13, 2013 at 10:31 AM, Bill Mills <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     One discussion point, I'm concerned if mailing lists are forced to
>     modify headers that it will maybe break DKIM or other signatures
>     to I'd rather leave that as a SHOULD.
>
>
>      
>     -bill
>
>
>     On Friday, December 13, 2013 10:27 AM, Murray S. Kucherawy
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     Thanks, Ned.  That's all pretty minor stuff; no objections from me
>     and I'd wager the same from my co-author.  Any objecting to
>     dealing with this all during or after WGLC?
>
>     -MSK
>
>
>     On Fri, Dec 13, 2013 at 8:58 AM, Ned Freed <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
J. Trent Adams

---

From: "John Levine" <[email-masked]>
Date: 13 Dec 2013 19:14:55 -0000

>affect anything.  Anyone else have a thought here?

I'm trying to think of evil things that a Bad Person might do with a
fake RRVS header, and none of them are very evil.  Either the fake
header has a very old date, so the message bounces needlessly, or it
has a very recent date so it's delivered like it would be if there
were no RRVS header or the recipient didn't interpret them.

I'd lose the signing language, or perhaps reverse it to say don't sign
the RRVS header so that gateways that delete the header won't break
the signature.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 13 Dec 2013 19:16:08 -0000

>while allowing the main content signature to remain valid.

You could certainly do two signatures, one with the RRVS header and
one without, but I'm still not sure that solves a problem worth
solving.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 Dec 2013 12:14:59 -0800

Right, I'll remove that advice in the next version. Thanks!
On Dec 13, 2013 10:53 AM, "Bill Mills" <[email-masked]> wrote:

> We should say it should not be part of the DKIM signature.  This makes
> sense because we're saying the header is in fact ephemeral and for the use
> of the mailers and not the end user or MUA.
>
> There's little impact of having it outside the DKIM signature.  The only
> thing I can think of is that if an MX is checking DKIM to decide if it will
> honor RRVS then an attacker could probe account age if they could intercept
> mail in transit.  Not a big problem.
>
> -bill
>
>
> that DKIM signatures might be invalidated, but we also say that one way to
> make sure the content of it can be trusted is to sign it.  Also, the prose
> of DKIM (for example) suggests that this isn't an appropriate header field
> to sign in the first place because it's not part of the core message
> content.
>

---

From: Kurt Andersen <[email-masked]>
Date: Fri, 13 Dec 2013 12:44:59 -0800

On Fri, Dec 13, 2013 at 12:14 PM, Murray S. Kucherawy
<[email-masked]> wrote:
>> We should say it should not be part of the DKIM signature.

I'd be inclined to agree with Bill: "We should say it should not be
part of the DKIM signature." which is a stronger position than just
removing any references to it.

--Kurt