Re: [Ietf-dkim] Rechartering

[Scott Kitterman]

On Saturday, December 3, 2022 2:35:55 PM EST Jon Callas wrote:
> > On Dec 3, 2022, at 11:01, Stephen Farrell 
> > wrote:
> > 
> > One nit though, that you should feel free to ignore if it
> > was discussed already - the phrase "in a secure way" doesn't
> > quite capture what the DKIM WG was trying to produce, e.g.
> > we consider unsigned DNS fine for DKIM public keys, even
> > though that'd not be described as "secure."
> > 
> > Maybe s/in a secure way/using a lightweight cryptographic
> > mechanism/ would be better? But again, it's a nit.
> 
> Agreed, and we need some other weasel word than "lightweight" because there
> are lots of people working on "lightweight" symmetric ciphers. Something
> like "appropriate"?
> 
> Y'all know this is one of the many bees in my bonnet -- DKIM doesn't need a
> signature that is secure for a year (or more), it needs one that is secure
> for somewhere between a minute and a week.
> 
> Moreover, one of the ways that we could deal with some of the knock-on
> issues of not wanting DKIM to be a non-repudiation system (the Podesta
> Problem) is to use signatures that could be  forged by someone who put a
> CPU(s)-week's effort into it after the fact.
> 
> Even if we never get around to the actual issues, we don't want to cut off
> someone in the future at the knees.

If you want to avoid such problems, you can do so already.  Script your mail 
server/DNS to publish a new key at a new selector weekly and then at the end 
of the second week, replace the public key with the private key.  That will 
guarantee that any signatures more than two weeks old can be repudiated, but 
still work for normal email transit times.

IETF doesn't need to do anything for domains which which to create DKIM 
signatures with a very limited temporal validity.

Scott K


___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Jon Callas]

> On Dec 3, 2022, at 11:42, Dave Crocker  wrote:
> 
> On 12/3/2022 11:35 AM, Jon Callas wrote:
>> Agreed, and we need some other weasel word than "lightweight" because there 
>> are lots of people working on "lightweight" symmetric ciphers. Something 
>> like "appropriate"?
>> 
>> Y'all know this is one of the many bees in my bonnet -- DKIM doesn't need a 
>> signature that is secure for a year (or more), it needs one that is secure 
>> for somewhere between a minute and a week.
> 
> transit-time, cryptographic authentication ?
> 

I like that.

Jon
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 12/3/2022 11:35 AM, Jon Callas wrote:

Agreed, and we need some other weasel word than "lightweight" because there are lots of people 
working on "lightweight" symmetric ciphers. Something like "appropriate"?

Y'all know this is one of the many bees in my bonnet -- DKIM doesn't need a 
signature that is secure for a year (or more), it needs one that is secure for 
somewhere between a minute and a week.


transit-time, cryptographic authentication ?

d/

ps. technical docs that are security related tend to do better when they 
don't use the word 'security' as a technical term meant as a specific 
reference...


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Jon Callas]

> On Dec 3, 2022, at 11:01, Stephen Farrell  wrote:
> 
> One nit though, that you should feel free to ignore if it
> was discussed already - the phrase "in a secure way" doesn't
> quite capture what the DKIM WG was trying to produce, e.g.
> we consider unsigned DNS fine for DKIM public keys, even
> though that'd not be described as "secure."
> 
> Maybe s/in a secure way/using a lightweight cryptographic
> mechanism/ would be better? But again, it's a nit.

Agreed, and we need some other weasel word than "lightweight" because there are 
lots of people working on "lightweight" symmetric ciphers. Something like 
"appropriate"?

Y'all know this is one of the many bees in my bonnet -- DKIM doesn't need a 
signature that is secure for a year (or more), it needs one that is secure for 
somewhere between a minute and a week. 

Moreover, one of the ways that we could deal with some of the knock-on issues 
of not wanting DKIM to be a non-repudiation system (the Podesta Problem) is to 
use signatures that could be  forged by someone who put a CPU(s)-week's effort 
into it after the fact.

Even if we never get around to the actual issues, we don't want to cut off 
someone in the future at the knees.

Jon

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Stephen Farrell]

Hiya,

On 03/12/2022 06:38, Murray S. Kucherawy wrote:

I've placed what I believe is the text that is closest to consensus in the
datatracker:

https://datatracker.ietf.org/doc/charter-ietf-dkim/

Please provide comments or criticism soon.  Once it appears to be stable
relative to this audience, I'll send it on its way for internal (IESG) and
then full IETF review.


That seems to fairly reflect the discussion on the list,
though I've only been skimming it.

One nit though, that you should feel free to ignore if it
was discussed already - the phrase "in a secure way" doesn't
quite capture what the DKIM WG was trying to produce, e.g.
we consider unsigned DNS fine for DKIM public keys, even
though that'd not be described as "secure."

Maybe s/in a secure way/using a lightweight cryptographic
mechanism/ would be better? But again, it's a nit.

Cheers,
S.

PS: I'm not convinced there's a useful solution to be found
for these replay problems, but the charter seems to me to
allow for that outcome, so is fine.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Dave Crocker]

On 12/2/2022 10:38 PM, Murray S. Kucherawy wrote:
I've placed what I believe is the text that is closest to consensus in 
the datatracker:


+1


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Laura Atkins]

> On 3 Dec 2022, at 06:38, Murray S. Kucherawy  wrote:
> 
> I've placed what I believe is the text that is closest to consensus in the 
> datatracker:
> 
> https://datatracker.ietf.org/doc/charter-ietf-dkim/ 
> 
> 
> Please provide comments or criticism soon.  Once it appears to be stable 
> relative to this audience, I'll send it on its way for internal (IESG) and 
> then full IETF review.
> 
> Should you wish to serve as a co-chair, or nominate someone for that 
> position, please contact me off-list.

+1

laura

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Scott Kitterman]

On Saturday, December 3, 2022 5:33:27 AM EST Alessandro Vesely wrote:
> On Sat 03/Dec/2022 07:38:24 +0100 Murray S. Kucherawy wrote:
> > I've placed what I believe is the text that is closest to consensus in the
> > datatracker:
> > 
> > https://datatracker.ietf.org/doc/charter-ietf-dkim/
> > 
> > Please provide comments or criticism soon.
> 
> Please add the other Wei's I-D:
> https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/

I agree.

I still think limiting the backward compatibility language to DKIM is too 
narrow.

Scott K 


___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Rechartering

[Alessandro Vesely]

On Sat 03/Dec/2022 07:38:24 +0100 Murray S. Kucherawy wrote:
I've placed what I believe is the text that is closest to consensus in the 
datatracker:


https://datatracker.ietf.org/doc/charter-ietf-dkim/

Please provide comments or criticism soon.



Please add the other Wei's I-D:
https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/


Best
Ale
--





___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim