Subject: Re: [Lurk] Another outside the "box" use case: DKIM

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Mar 2016 13:29:06 +1100

On 1 March 2016 at 08:09, Stephen Farrell <[email-masked]> wrote:
> DKIM-signing domains sometimes use partner companies to
> e.g. send out marketing crap or userful materials. That
> can be done in various ways but using lurk for DKIM-signing
> without giving the partner a DKIM private key for my domain
> could be yet another use.

Rather than painting every visible object with a targeting beacon, I
think that we should first acknowledge that creating a signing oracle
is - in general - a bad idea.  The reason that we might want to do
this is to take existing practice and clean it up a little.  This
happens a lot for TLS, it has good deployment characteristics (no new
clients), and there's a chance that a standardized protocol won't run
afoul of the many hazards in this space.

Maybe expanding the scope is a good idea, but I would rather target a
very specific use case and get that right; more clients means more
requirements and a greater chance of screwing it up.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Mar 2016 09:33:26 +0000

On 02/03/16 02:29, Martin Thomson wrote:
> this is to take existing practice and clean it up a little. 

I agree.

> This

The same is true of DKIM, though I'm not sure about the scale.

> requirements and a greater chance of screwing it up.

That's fair. I do think we'll be better off though, when doing
a WG charter, if we can say "yeah, we asked about <foo> but there
wasn't real interest"

Cheers,
S.

---

From: Eric Burger <[email-masked]>
Date: Wed, 2 Mar 2016 07:03:01 -0600

Some of those other use cases, like DTLS, may be useful, and it is worth it to think about them now.

The point is as Stephen points out below.  It is as important to say what we are not doing as it is to say what we are.  We are not looking to write down the infinite space of what is *not* LURK. However, it is worth considering some of the major IETF protocols that tend to be delegated, like bulk email (DKIM) and real-time multimedia (STIR).  By deciding if they are in or out of scope now, we can better focus our work on inclusion or, in the cases of DKIM and STIR, say we looked at them and decided that they are not in scope.

> On Mar 2, 2016, at 3:33 AM, Stephen Farrell <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 3 Mar 2016 05:10:09 +1100

> Some of those other use cases, like DTLS, may be useful, and it is worth it to think about them now.

For me, signing oracle protocol for <anything> is likely to be a
mistake.  I think that we can make it work for TLS, and that means
that it works for DTLS too with only a tiny amount of work and no
extra analysis.

I think that once a single case has proven itself, if that happens,
then applying the lessons learned to other applications is possible,
and likely easier.

(I'm not 100% across STIR, but isn't this pretty new stuff?  Can't a
more transparent delegation mechanism be added now, rather than having
to resort to kludge-tastic mechanisms like LURK?)

---

From: "John R Levine" <[email-masked]>
Date: 2 Mar 2016 21:45:10 -0500

> DKIM-signing domains sometimes use partner companies to e.g. send out 
> marketing crap or userful materials. That can be done in various ways 
> but using lurk for DKIM-signing without giving the partner a DKIM 
> private key for my domain could be yet another use.

> I suspect that it'd be considered OTT to use such an interface for 
> DKIM-signing, but who knows?

It's an interesting idea but I doubt DKIM users would consider it worth 
the effort.  DKIM encourages you to have multiple selectors per domain, 
where each selector has a separate verification record in the DNS and 
private signing key.  So you give your partner its own selector and its 
own key, and if they screw up or the job is over, you can delete the 
verification record for that selector without affecting mail signed with 
other selectors.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.