Re: mail signing history, was Call for Community Feedback: Retiring IETF FTP Service

[Stephen Farrell <[e-mail]>]

On 18/11/2020 22:17, Michael Thomas wrote:
> 
> On 11/18/20 2:04 PM, Stephen Farrell wrote:
>>
>> Hiya,
>>
>> On 18/11/2020 21:51, Michael Thomas wrote:
>>>
>>> On 11/18/20 1:45 PM, John R Levine wrote:
>>>> On Wed, 18 Nov 2020, Ned Freed wrote:
>>>>> That said, a mechanism for publishing/expiring DKIM private keys is 
>>>>> something
>>>>> the IETF might want to standardize.
>>>>
>>>> I've started to publish my old private keys since I rotate every 
>>>> month but I agree a standard way to tell people where to look would 
>>>> be nice.
>>>>
>>> Why isn't just deleting/replacing the selector sufficient? It's not 
>>> as definitive but it's a lot simpler.
>>
>> Publishing the private key enables various forms of
>> denyability - if someone claims msg1 is original
>> anyone with access to the private can produce a
>> msg2 that seems as cryptographically correct but
>> is clearly bogus (e.g. containing lottery numbers
>> that post-date message timestamps).
> 
> 
> Yes, i acknowledge that above albeit obliquely. What i don't see is how 
> you align providers goals' with individual users' goals.

My guess is that email service providers that are
concerned about potential leakage of message store
content would be motivated to do this so as to
re-assure their users and/or maybe help avoid future
liability (financial or moral).

> 
> 
>>
>> Yes an adversary could have gotten an independent
>> signed timestamp on msg1 before the private was
>> published but that seems low probability.

> It really depends on the worth of the data, right? LEA would certainly 
> do such a thing if they were serveilling somebody.

Sure. The main adversary I had in mind for this mechanism
would be a message (store) leaker, not LEAs. I guess the
idea could be ineffective or even counterproductive
with other threat models, not sure - but would need
checking out, for sure.

>>
>> I'd support development of such a standard if it
>> had a good chance of deployment as I think it'd
>> also encourage key rotation.
>>
> I forget who said that they were surprised about lack of key rotation, 
> but color me completely unsurprised. This is just inertia 101. Maybe 
> large ESP's might get around to automating key rotation, but for the 
> vast majority enterprise this is going to be pretty low down the 
> priority list, and more likely an anti-goal as tracking whether their 
> employees are misbehaving is a feature not a bug.

Agreed. If, however, publishing old private keys is seen
as a way to reduce potential liability, then that might
motivate rotation. (That's my guess, but only a guess.)

Cheers,
S.


> 
> Mike
>