Re: [Dance] DANCE Architecture draft


> On 14 Nov 2022, at 14:01, Rick van Rein <rick@openfortress.nl> wrote:
> 
> Hi,
> 
>> My suggestion was to
>> - Create a separate “how to dance” document with advice on how to adopt this to various protocols and what needs to be covered in more use-case specific drafts
> 
> That sounds like a good idea, and it should be open for later additions if at all possible.
Thanks

> 
> The examples in draft-ietf-dance-client-auth are very loose, and I would argue
> that strong prescriptive examples are ideal from the perspective of interop.
That’s not the draft that was in topic for this mail :-)

> 
>> In addition we discussed a more generic “confirming email-style identifiers with Dance” draft and had people in the room willing to start with that. This could potentially apply to authenticating for SMTP/Submission, SIP ua to registrar/proxy and similar use cases.
> 
> Yes, gladly.  This is what I've always thought when I hear the term
> Client DANE (the devices would have been my second, also very useful,
> case).
In order for me to get anywhere with the edits, I would like for us to keep discussions on topic.
Your response contains a lot of information that’s worthy of discussion, but it’s impossible for
me to sort out if you want this in the architecture draft or if you’ve started other work…

I will try to comment separately on those where I personally am able to comment :-)

/O

> 
> I think the distinction is that this is not a host-wide but a user-specific
> form, and its DNS naming could be
> 
> [service]._user.[domainname]  IN TLSA  x x x xxxx
> 
> Where Root/Intermediate CA certificates are a useful form because they are
> permissive for many protocols.
> 
> Wildcards might be used to say things that apply to a plethora of
> services,
> 
> *._user.[domainname]  IN TLSA  x x x xxxx
> 
> These cover-all would be overridden under DNS rules for more special services,
> 
> xmpp._user.[domainname]  IN TLSA  x x x xxxx
> 
> And they could be forbidden under DNS rules for other services, perhaps for
> SMTP becauses the mail protocol for users is called "submission" and "smtp"
> is reserved for mta2mta,
> 
> smtp._user.[domainname]  IN TXT "Client DANE wildcard blocked"
> 
> 
> Playing with these special kinds also brings up other values for the "x x x"
> entries, which I think would be useful.  We might also think about the use of
> CNAME and DNAME references, which a DNS server normally handles.
> 
>> I will try to put up a skeleton for a “how to dance” document on the git repo soon and skeleton for the use cases so I can start cutting things out of architecture and put into those skeletons for further work by the group.
> 
> Lovely.  I already wrote to a few issues that I might be able to help with.
> 
> I would also like to add LDAP, because it is such a potent database, esp.
> when the Client Identity is known.
> 
>> Any help with this is of course very appreciated.
> 
> I intend to keep you happy :)
> 
>> During the WG meeting I suggested to do a massive edit of the architecture draft
> 
> I have a few suggestions, but please let me know if I missed documentation
> (or perhaps am repeating past discussion).  Will send text or PRs when
> requested.
> 
> 1. Be explicit about authentication/authn vs. authorization/authz.  While
> authn is the responsibility of TLS, authz is an application matter.  As an
> example, the lookup of client names in a list is a very specific example of
> authz, and I would rather see it changed into something like "the application
> makes an authorization choice".  The term "DANE preauthorization" confuses me.
> I don't know how authz would apply when a DNS wildcard is used.
> 
> 2. Comparison of dane_clientid to [a list of] client domains... are you trying
> to (a) match the domain part after Client DANE labels [that would be authn] or
> (b) match the Client DANE labels [that would be authz] or both [that's mixed]?
> Since not all Client DANE labels end with a _device or _service or _user in the
> same place it may be possible to do naughty things to any check on them.
> 
> 3. "DNS records should be validated by the DNS stub resolver, using the DNSSEC protocol."
> This is a case where "should" can be written "SHOULD" or "MUST".  For more detail,
> these lyrics from draft-vanrein-dnstxt-krb1 may help:
> 
>    <t>Since DNS in general cannot be considered secure, the client MUST validate
>    DNSSEC and it MUST dismiss any DNS responses that are Insecure, Bogus or
>    Indeterminate [Section 5 of <xref target="RFC4033"/>].  Only the remaining
>    Secure responses are to be taken into account.  This specification does
>    not require that the DNS client validates the responses by itself, but a
>    deployment of _kerberos TXT records SHOULD NOT accept DNS responses from
>    a trusted validating DNS resolver over untrusted communication channels.</t>
> 
> 4. On privacy of identity: Hashing a userid does not always help.  If it's a
> predictable form itl1235123 then iteration is very easy.  And because it'd be
> a static substitution it wouldn't add dynamicity.  You might consider a * for
> the client name, and otherwise benefit from TLS 1.3 encryption of the clicert.
> 
> 5. On DNS scaling: TLS may be slowed down, I am not sure about DTLS.  Recurring
> DNS queries on the same DNS server may be a hint to delay traffic.  Bloom filters
> can make such hold-back fairly easy to implement.  Question: Is this sufficiently
> in the interest of the TLS server operator?
> 
> 
> I hope this helps!
> -Rick
> 
> -- 
> Dance mailing list
> Dance@ietf.org
> https://www.ietf.org/mailman/listinfo/dance