Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

[Paul Wouters <[e-mail]>]

On Tue, 26 May 2020, Peter van Dijk wrote:

>> So, while my first though was same as Paul’s - this is abuse…  I came to
>> conclusion, it actually isn’t.
>> 
>> That said - I think this needs some modifications:
>> 
>> 1. Bit 7 of the Flags fields needs to be 0.
>
> Definitely - it is not explicit but the examples in draft -00, and the
> PoC code, all use 0 for the flags.

> earlier that whatever flags we might need, it's definitely *not* ZONE
> and SEP.

Now I am all confused again.

I thought my initial reading this was stored inside a DNSKEY was wrong
and things are actually stored in a DS digest. And DS records do not
have flags of the DNSKEY, so why are we talking again about DNSKEY
flags?

                      1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           key tag             |  algorithm    |  Digest type  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                digest  (length depends on type)               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                (SHA-1 digest is 20 bytes)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


We just have the algorithm which would be set to some special value
of "this is not really a hash(DNSKEY)". I dont know what you will use for
keytag. The digest type would also be some strange number meaning
"not really a DNSKEY digest".

So why talk about DNSKEY flags? Where do these appear in the proposal?

If you want the child to confirm the special record in its parent,
then _really_ you should use only CDS, mirroring the exact binary
blob of the parent, and not CDNSKEY/DNSKEY. Why make life harder
by needing to stuff square things into round boxes twice instead of
once?

Paul