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

From: Kurt Andersen <[email-masked]>
Date: Mon, 9 Dec 2013 13:56:20 -0800

On Mon, Dec 9, 2013 at 12:59 PM, Dave Cridland <[email-masked]> wrote:

>
>
> And in §11, we add a paragraph as first:
>
> <t>For the purposes of this specification, we define an address as having
> been under continuous ownership since a given date if a message sent to the
> address at any point since the given date would not go to anyone except the
> owner at that given date. That is, while an address may have been
> suspended, or otherwise disabled, for some period, any mail actually
> delivered would have been delivered exclusively to the same owner.</t>
>

I agree with this change and think that, in general, Murray's suggested
changes capture the intent of the points I raised. I'm slightly concerned
with the risk of breaking message signatures with this information
(potentially) moving back and forth between extension and header modes
since there is an implication that if it is found in a header then it
should be signed to be considered.

For a security mechanism, I also think that an "unknown" verdict should
translate into a refusal to deliver, but it would be nice to communicate
the ambiguity back to the sender with a distinct response code so that
information was available.  This would also apply to cover the case where
an error causes a ridiculous date-time to be evaluated (circa the epoch,
for instance).

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Dec 2013 14:02:26 -0800

> should be signed to be considered.

Actually I think the opposite is true.  The advice in RFC6376 (Section
5.4.1, to be exact) doesn't include this field in what it recommends be
signed, as it's not part of the core message content.  Further, we're
already talking in this draft about how hashes can be clobbered if the
content is altered in that way.

> an error causes a ridiculous date-time to be evaluated (circa the epoch,
I'm not sure that we should get into specific rejection advice.  Every
operator will have its own sensitivities on this topic as to what it wants
to reveal in terms of the cause for a message rejection.  I don't think we
could really say a "right" thing here.  Anyone else have a thought on this?

-MSK

---

From: Bill Mills <[email-masked]>
Date: Mon, 9 Dec 2013 14:06:44 -0800

Breaking signatures is an excellent reason to prefer the extension over the header. 5.2 does cover this, perhaps not as strongly as it could, but it's covered.

-bill

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

On Monday, December 9, 2013 1:57 PM, Kurt Andersen <[email-masked]> wrote:
 
On Mon, Dec 9, 2013 at 12:59 PM, Dave Cridland <[email-masked]> wrote:

><t>For the purposes of this specification, we define an address as having been under continuous ownership since a given date if a message sent to the address at any point since the given date would not go to anyone except the owner at that given date. That is, while an address may have been suspended, or otherwise disabled, for some period, any mail actually delivered would have been delivered exclusively to the same owner.</t>

I agree with this change and think that, in general, Murray's suggested changes capture the intent of the points I raised. I'm slightly concerned with the risk of breaking message signatures with this information (potentially) moving back and forth between extension and header modes since there is an implication that if it is found in a header then it should be signed to be considered.

For a security mechanism, I also think that an "unknown" verdict should translate into a refusal to deliver, but it would be nice to communicate the ambiguity back to the sender with a distinct response code so that information was available.  This would also apply to cover the case where an error causes a ridiculous date-time to be evaluated (circa the epoch, for instance).

--Kurt

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

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 9 Dec 2013 22:33:35 -0800

> content is altered in that way.

The allusion to signing the header was something that I inferred from the
second example in section 13.2 (top of page 14 in the -04 draft). It may be
worth annotating that example to indicate that this is a hypothetical
scenario and not necessarily recommended.

--Kurt