Re: [Dance] DANCE Architecture draft

[Rick van Rein <[e-mail]>]

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.

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.

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

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