Re: [dbound] draft-brotman-rdbd

[Scott Kitterman <[e-mail]>]

On Monday, April 01, 2019 03:44:46 AM Stephen Farrell wrote:
> On 01/04/2019 03:38, John R. Levine wrote:
> > I suppose that if there were some very high value application that
> > depended on rdbd records there might be more of an incentive to use DNS
> > attacks to fake them, but it all seems like a lot of extra work for
> > utterly speculative benefits.
> 
> Questioning the efficacy of rdbd signatures is reasonable but not
> at all the same as a claim to not understand 'em.
> 
> I agree that the efficacy of these signatures isn't a slam dunk.
> The draft says as much. I'd be happy to improve the explanation
> in the text wrt that.
> 
> But the signatures are optional. So if I'm wrong that they're
> useful, then that's ok, you'll be right and they'll not be used.
> Equally, if OTOH but unexpectedly, I'm not wrong, then there'll
> be a method for signing defined as part of the spec.
> 
> What's wrong with that?

It adds some significant complexity to the design.

If the crypto bits have significant utility, then baking the needed protocol 
elements for smooth key rollover (e.g. for DKIM you use a new selector and 
leave both the old and new keys live for $TIME to allow everything that was in 
process to be received and validated before the old key is removed).  Are 
multiple RDBD and RDBDKEY records allowed per domain?

If not, particularly due to cache misalignment, a smooth key rollover will be 
very hard.

Multiple records per domain would also allow for algorithm agility (publish 
both RSA and Ed25519 for transition as needed).

Libraries implementing RDBD would need more dependencies and be more complex 
to deploy.

My suggestion would be to think hard if it's really needed and if so, then 
make it a MUST.  If not, take it out.  It can be added easily enough later, 
right?

I do think the explanation could be clearer.  I was following along with John 
Levine's argument pretty well.  It took me several scans of the draft to 
realize that the signature (RBDB record) is published by the relating domain 
and the public key (RDBDKEY record) is published by the related domain.  Once 
I realized that, it made sense.  A signed record, to the extent you can't 
spoof both domains simultaneously or nearly so, would give added confidence 
that the related domain agrees that that relationship is valid and not just 
examp1e.com claiming to be related to example.com.

As a more general comment, RFC 8301 is the reference for the minimum key size 
of 1024 bits (RFC 6346 is 512).  Also, it might be worth looking at RFC 8463 
(which added Ed25519 to DKIM) to see if there's guidance on putting Ed25519 
public keys in DNS that can be reused.

Personally, I think I like the crypto bit, but if it's in, I'd like to see it 
be a MUST.  Also, do we really need RSA?  There are plenty of Ed25519 
implementations available.  Personally, I think it's simpler to deal with (and 
the public keys are way smaller, which is nice for DNS).

Scott K