Steve,
Going through the comment reproduced below (which
is attached to the ballot with Ned's replies), it looks like Ned
concurred with you on adding text for privacy considerations in
general and on adding some text describing the risk with
source-routed address matching issues. This general text does
seem to be present in Section 6.2, along with a description of how a
source-routed address might be used in an attack using a spurious
disposition-notification-to added to the envelope.
As you know, Ned is actually the shepherding AD on this;
I brought it forward in his absence after a request by Greg. If this
does not handle your issue, can you suggest specific text, and
cc: Greg, so that he can respond?
thanks,
Ted Hardie
Steve:
>> This section:
>
>> The comparison of the addresses should be done using only the addr-
>> spec (local-part "@" domain) portion, excluding any phrase and route.
>> The comparison MUST be case-sensitive for the local-part and case-
>> insensitive for the domain part.
>
>> has security implications -- a source-routed address is not necessarily
>> the same as the absolute address with the same name.
>
>Um, well, actually, we have been saying that it is supposed to be the same,
>going back as far as RFC 1123. A source route is supposed to be merely a
>routing indicator that may or may not even be honored, it is not
supposed to b
>e
>a namespace qualifier.
>
>While I've seen considerable unevenness in support for source routes over the
>years, I can't recall a case where I found one being used to
qualify addresses
>as belonging to a separate namespace. (The same cannot be said of %
hacks or !
>paths, of course -- they were commonly used for that. And don't get
me started
>about X.400...)
From an architectural perspective, you're absolutely right. But I'm
talking about this from a security and privacy perspective, and the bad
guys break the rules. This is just one way to accomplish the privacy
violation described below.
>
>I guess I have no real problem with noting this as a possible issue, but
>I really think it is an entirely academic one at this point.
>
>> More generally, there are privacy issues with MDN -- the recipient may
>> not want the sender to know when he or she is receiving or reading
>> email. The draft implicitly recognizes that, in the rules requiring
>> explicit consent for MDNs. That broader issue isn't mentioned in the
>> Security Considerations, and should be -- my example is just one
>> instance of a privacy problem.
>
>OK, I'll if I can't work up some text.
>
> Ned
At 11:19 AM -0400 08/18/2003, Steve Bellovin wrote:
Am I missing something? As best I can tell, my comments on
draft-vaudreuil-mdnbis are not addressed in the latest draft.
--Steve Bellovin, http://www.research.att.com/~smb