Re: one can re-sign without a permission to re-sign header

On 5/1/14 2:54 PM, John Levine wrote:
>> author's site. That shouldn't require the mailing list to communicate
>> with the author's site, but it might require the author's site to get
>> something from the mailing list's site.
>>      
> That seems overcomplicated.  Just make the expiration time fairly
> short, since it's a rare mailing list that takes more than a day to do
> its thing.
>
>    
>>> Perhaps it's time for a more concrete proposal to be written down.
>>>        
> It occurred to me that there's a very simple way to do this:
>
> http://datatracker.ietf.org/doc/draft-levine-may-forward/
>    

On 5/1/14 2:54 PM, John Levine wrote:
>> author's site. That shouldn't require the mailing list to communicate
>> with the author's site, but it might require the author's site to get
>> something from the mailing list's site.
>>      
> That seems overcomplicated.  Just make the expiration time fairly
> short, since it's a rare mailing list that takes more than a day to do
> its thing.
>
>    
>>> Perhaps it's time for a more concrete proposal to be written down.
>>>        
> It occurred to me that there's a very simple way to do this:
>
> http://datatracker.ietf.org/doc/draft-levine-may-forward/
>    

I don't see any replay protection in here at all. Nothing that says to 
keep the signature expiration relatively short, and nothing which a 
mailing list recipient could not subsequently use to send spam. The 
first issue just needs a mention. It's the second issue that needs to be 
addressed IMO:

As an originating site, I do not want to give permission to forward to 
just anyone. I want to indicate that I was sending to someone in 
particular, e.g., [email protected], and *[email protected]* has permission to 
forward. (An originating site should be  fine with their being a 
subsequent re-forwarding, say [email protected] sending to [email protected] which 
forwards, but I think they'd expect [email protected] to have given 
permission to [email protected] to re-forward, and the eventual recipient will 
be able to see that chain.)

That's why I suggest that the originating site is going to want to talk 
to the mailing list site: "This message was sent from user@mydomain to 
[email protected]. You had better see my signature *and* received it from 
a.example." Your proposal doesn't do that.

Maybe people who are now setting p=reject don't care. Maybe all they 
care about is a short-lived signature and permission to re-forward. But 
I don't think that's likely to be true. I think they care about the 
replay problem. Otherwise, it's inviting spammers to subscribe to 
(especially well-used) mailing lists so that they can get and endless 
supply of replayable signatures.

I wouldn't bother with what you've proposed.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822