Re: [dbound] draft-brotman-rdbd

[Stephen Farrell <[e-mail]>]

Hiya,

On 01/04/2019 04:51, Scott Kitterman wrote:
> 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.

True.

> 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?

Yes.

> 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.  

Also a reasonable position.

> It can be added easily enough later, 
> right?

Not sure TBH. I think adding rdbd-signatures later would mean
defining another RRTYPE, which is about as much work as this.
I've no idea how that'd affect deployment either.

> 
> 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.

Will try clarify those issues, thanks.

> Personally, I think I like the crypto bit, but if it's in, I'd like to see it 
> be a MUST.  

Fair enough.

Other inputs on this topic appreciated! I guess the choices are:

1. take out rdbd-signatures entirely, as per John L I guess
2. leave rdbd-signatures optional, as per -01
3. make rdbd-signatures mandatory, as per Scott K

(I consider those are independent of DNSSEC as we're signing
across and not downwards with rdbd-signagures.)

> 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).

True, but I'd argue to keep RSA for now at least as e.g.
openssl's command line tools don't yet have ed25519 (for
internal API reasons, so not clear when that'll be fixed).
RSA could get dropped along the way I guess if things
change sufficiently before this draft is done.

Cheers,
S.


> Scott K
> 
> _______________________________________________
> dbound mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dbound
>