Subject: [dane] DANE Client Authentication draft updated

From: Shumon Huque <[email-masked]>
Date: Tue, 12 Jan 2016 10:15:36 -0500

Hi folks,

We've updated the DANE Client Certificates draft, and also posted a
new draft describing a TLS extension to convey a DANE client identity
to a TLS server.

Reviews/feedback/questions appreciated.

TLS Extension for DANE Client Identity:
https://tools.ietf.org/html/draft-huque-tls-dane-clientid-00

  Describes a new (D)TLS extension to convey a DANE client
  identity. This enables the use of raw public key client
  authentication with DANE. It also helps client certificate
  authentication work better and more efficiently.

  (We'll post this to the TLS working group also.)

TLS Client Authentication via DANE TLSA Records:
https://tools.ietf.org/html/draft-huque-dane-client-cert-02

  This is an update of the DANE client certificates draft
  we introduced just before IETF93. It is now renamed to
  "TLS Client Authentication" because it deals with more
  than just client certificates, treating raw public key
  auth on par with the former throughout (rather than mostly
  as a footnote in the earlier version). It references the
  TLS extension draft and updates the expected protocol behavior
  accordingly. There are also updated references to documents
  that have now become RFCs (notably 7671 - DANE Updates and
  Ops guidance).

--
Shumon Huque

---

From: James Cloos <[email-masked]>
Date: Tue, 12 Jan 2016 15:05:51 -0500

For draft-huque-dane-client-cert I'd still prefer RR names like:

 _smtp._client.example

for the cert provided by an smtp client which HELO/EHLOs as example.
And similarly for other protocols.  Rather than things like _smtp-client.

Putting all of the client TLSAs under a single label allows (but
obviously does not require) them to be in their own zone.

Than can be useful.

And in the case where the proposed tls extension is not used, it should
be OK for the name to be in CN, too.  So something like 'MUST be in
either dnsName or CN, but SHOULD be in the dnsName'.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Shumon Huque <[email-masked]>
Date: Tue, 12 Jan 2016 17:21:44 -0500

> obviously does not require) them to be in their own zone.

Thanks for the feedback. I had the _service._client form in an earlier
version of this draft but Viktor talked me out of it, on the grounds of
insufficient usefulness and unneeded complexity. I'd be interested in
hearing other opinions on this point also.

On the "_smtp-client" label choice, I had originally used just "_smtp", but
a colleague more plugged into IANA service name registration procedures
advised me that I should choose a different client specific label. The
"_smtp" label is a server side label with an associated server side port,
and that reusing that label for a client identifier would elicit objections.

Than can be useful.
> either dnsName or CN, but SHOULD be in the dnsName'.

Current IETF specs strongly discourage putting domain name identifiers
in the subject CN (see RFC6125 for example), which I agree with, and
whose lead I followed. I suspect that DANE client certificates is enough
of a green field application, that there aren't backwards compatibility
concerns that would prove to be impediment here. Even if you were using
public CAs, practically all of them today can issue domain names in
dNSName. SRVName unfortunately is a real world impediment for some
parties, which is why that one isn't a MUST.

What specific concerns did you have in mind with disallowing CN?

-- 
Shumon Huque

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 12 Jan 2016 18:32:34 -0500

> On Jan 12, 2016, at 5:21 PM, Shumon Huque <[email-masked]> wrote:
> 

The reason I talked you out of it, is that I wanted the query-domain for
client TLSA records to be the same as the SRV-ID.  Injecting a sub-domain
makes it more difficult to use the names in question if SRV-ID is
what's in the certificate.

Using the SRV-ID as the query domains is not an absolute requirement, but
it is a simplification that should not be discard too lightly.  Trade-off
judgement call...

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 13 Jan 2016 01:31:52 -0000

>and that reusing that label for a client identifier would elicit objections.

Yes, no kidding.

In the DNS, service names only appear as subnames of transport names.
So one possibility would be to register smtp-client as a service name,
so the DNS label would be _smtp-client._tcp.whatever.example.

On the other hand, these certificates aren't identifying services,
they're identifying clients, and unless I misunderstand, it should be
equally useful to identify clients for POP, IMAP, submission, and
anything else that can do TLS.  The list of service names already has
a fair number of client names, with the naming utterly inconsistent,
some with a trailing c, some with trailing "client", trailing
"-client", trailing "-cl", and a few just random acronyms.

To minimize the chaos I'd suggest registering a psedudo-service name
"client", always used with the actual service name as its subname.
So for my SMTP, POP, IMAP, and SUBMIT clients, the names would be

 _smtp._client._tcp.whatever.example
 _pop3s._client._tcp.whatever.example
 _imaps._client._tcp.whatever.example
 _submission._client._tcp.whatever.example

I suppose you could use the port number like RFC 6698 does but that
seems wrong since the server picks the port number.  If a SRV record
says that the server is, say, running pop3s on port 1234, the client
is still doing pop3s and can't rename its TLSA record on the fly.

Registering the service name is easy, just a few paragraphs in the
IANA considerations section.

R's,
John

---

From: Shumon Huque <[email-masked]>
Date: Tue, 12 Jan 2016 20:47:21 -0500

> it is a simplification that should not be discard too lightly.  Trade-off

Ah yes, thanks for reminding me. I agree this is a useful rationale for
keeping
the form the way that it is.

-- 
Shumon Huque

---

From: Shumon Huque <[email-masked]>
Date: Tue, 12 Jan 2016 21:03:26 -0500

> so the DNS label would be _smtp-client._tcp.whatever.example.

I would say "only appear *today* under transport names", but this isn't a
hard and fast requirement. We should feel free to construct TLSA owner
names in a form that makes sense for the specific application. For the
purposes of this draft, including a transport label might make sense if
we expected clients to have distinct transport protocol specific
authentication
credentials for the same application. This seems unlikely to me.

> "-client", trailing "-cl", and a few just random acronyms.

Yeah, I noticed the inconsistency too - a bit unfortunate!

>  _submission._client._tcp.whatever.example

See Viktor's previous note about why we excluded a _client label.

> is still doing pop3s and can't rename its TLSA record on the fly.

Right, we arrived at the same conclusion, and hence excluded the port
number from the client record name.

-- 
Shumon Huque

---

From: Kim Alvefur <[email-masked]>
Date: Wed, 13 Jan 2016 03:10:12 +0100

On 01/12/2016 11:21 PM, Shumon Huque wrote:
> On the "_smtp-client" label choice,

That seems like it will cause confusion considering _xmpp-client is used
in the XMPP world to refer to where the end-users connect their user
agents to, so basically equivalent to _submission in email.  And then
there's _xmpp-server for communication between servers.

FWIW, I would suggest _smtp-out as a less confusing label.

The word "client" is a bit ambiguous whether it refers to a user agent
or a server in the process of connecting to another server. It would
help to be more explicit about which one of these are being referred to,
or if it applies to both.

Client-DANE in the later context, enabling mutual authentication between
SMTP servers could be a nice improvement / complement to SPF & co.

-- 
Kim "Zash" Alvefur

---

From: Shumon Huque <[email-masked]>
Date: Tue, 12 Jan 2016 21:27:25 -0500

> there's _xmpp-server for communication between servers.

Yeah, I'm aware of that. I think the XMPP community made an
unfortunate choice in those names  - I might have suggested
"_xmpp-c2s" and "_xmpp-s2s" instead.

As John Levine points out, the client service name choices are already
all over the map in the current IANA service registry, so ...

The _smtp-client record was just an example we used in the draft.
We weren't trying to impose a uniform convention for IANA client
application labels here (probably not the right place to do so), but
perhaps we can consider making a recommendation in the IANA
Considerations section of the draft.

> or if it applies to both.

In my opinion, it covers any entity acting as a client, so it covers both
the cases you outline. I'm not sure we need to make a distinction in
the draft.

> SMTP servers could be a nice improvement / complement to SPF & co.

Glad to hear it. That's one of the use cases that this draft had in mind.

-- 
Shumon Huque

---

From: "John R Levine" <[email-masked]>
Date: 12 Jan 2016 21:32:19 -0500

> hard and fast requirement. ...
> We should feel free to construct TLSA owner names in a form that makes 
> sense for the specific application.

They've appeared under transport names for the past 15 years, which means 
that people have expectations about how they're used which I would not 
casually ignore.

There are a lot of other prefixed names floating around the DNS.  If 
someone attempted to use a client name like _spf or _sip or _domainkey or 
_dmarc or _adsp or _vouch they and their users would experience an 
eternity of pain from name collisions.

> For the purposes of this draft, including a transport label might make 
> sense if we expected clients to have distinct transport protocol 
> specific authentication credentials for the same application. This seems 
> unlikely to me.

It has very little to do with distinct transport protocols, and everything 
to do with avoiding name collisions.  Nobody runs POP or IMAP over UDP, 
but the SRV names are still _pop3._tcp and _imap._tcp.

If your names are subnames of _tcp or another transport, you know that the 
only names you can collide with are ones in the IANA services list, and 
you can easily register yours to tell people about them.  If they aren't, 
they could collide with anything.  Dave Crocker has been working on a 
registry for general prefixed names, but it's not likely to exist any time 
soon.

> See Viktor's previous note about why we excluded a _client label.

I saw it, and I have to say it strikes me as penny wise and pound foolish. 
You're getting a tiny simplification in code that for the most part hasn't 
even been written yet, at the cost of having to deal with potential 
collisions with every future use of prefixed names.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 12 Jan 2016 21:44:56 -0500

> 
> On Jan 12, 2016, at 9:32 PM, John R Levine <[email-masked]> wrote:
> 
> They've appeared under transport names for the past 15 years, which means that people have expectations about how they're used which I would not casually ignore.

And yet client identities are not really transport-specific.

> 
> There are a lot of other prefixed names floating around the DNS.  If someone attempted to use a client name like _spf or _sip or _domainkey or _dmarc or _adsp or _vouch they and their users would experience an eternity of pain from name collisions.

Only if there are TLSA records for those names.

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 12 Jan 2016 21:52:36 -0500

On Tue, Jan 12, 2016 at 9:44 PM, Viktor Dukhovni <[email-masked]>
wrote:

> > They've appeared under transport names for the past 15 years, which
> means that people have expectations about how they're used which I would
> not casually ignore.
>
> _dmarc or _adsp or _vouch they and their users would experience an eternity
> of pain from name collisions.
>

Right.

Also recall that the proposed owner name is: _service.[client-domain-name].
So a zone operator can define client domain name structures in a way that
can address any namespace collision issues they wish to avoid. Presumably,
an "_spf.device1.dept.example.com" TXT record would be about SPF rules
pertaining to device1.dept.example.com, so there is likely not an issue with
it co-existing with a client TLSA record at that same name.

-- 
Shumon Huque

---

From: "John Levine" <[email-masked]>
Date: 13 Jan 2016 05:29:47 -0000

In article <[email-masked]> you write:
>> They've appeared under transport names for the past 15 years, which means that people have expectations
>about how they're used which I would not casually ignore.
>

Hi, Viktor.  As I said in the message to which you just responded, two
paragraphs below the one you quoted:

 It has very little to do with distinct transport protocols, and
 everything to do with avoiding name collisions.  Nobody runs POP or
 IMAP over UDP, but the SRV names are still _pop3._tcp and _imap._tcp.

>> There are a lot of other prefixed names floating around the DNS.  If someone attempted to use a client
>name like _spf or _sip or _domainkey or _dmarc or _adsp or _vouch they and their users would experience
>an eternity of pain from name collisions.
>

Well, OK.  How much do you want to bet that there won't be, ever, for
those names and for anything else for which someone uses a prefixed
name?  We can easily avoid this problem now, or painfully sort of work
around it in the future.  I don't see that as a hard choice.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 13 Jan 2016 05:41:09 -0000

>it co-existing with a client TLSA record at that same name.

I admire the faith you have in DNS operators, but find it baffling.
For a lot of the ones I know, their heads would explode at having to
mix TXT SPF records for the incoming mail and TLSA for the outgoing
mail at the same names in the same zone files.  They'd probably try
to kludge it with CNAME and break everything.

We already have a managed service namespace, which you can use with
trivial ease as _<service>._client._tcp.<domain>.  But I'm hearing no,
to save 12 characters in the domain name, and 12 lines of code in the
clients, we'll tell people to make up random prefixed names and when
the collisions inevitably happen, it won't be our problem.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Jan 2016 05:53:22 +0000

>  IMAP over UDP, but the SRV names are still _pop3._tcp and _imap._tcp.

That's because SRV records are a generic (somewhat over-engineered)
construction, and we're stuck with separate:

	_kerberos._udp.realm.example. IN SRV 100 0 88 kdc1.example.
	_kerberos._tcp.realm.example. IN SRV 100 0 88 kdc1.example.

with the only benefit of this separation being the ability to
discover that a given realm has no UDP-based or has no TCP-based
KDCs.  None of this is especially relevant for clients.

So we can keep the client TLSA record query name simple with:

    ; TLSA RRtype sufficient to distinguish this from all
    ; other uses of the name, and any collisions with server
    ; names with look like _port._proto.server.example.
    ;
    _application.box.example. IN TLSA 3 1 1 ...

or we inject additional labels, making the name further removed
from identifying a DANE application at a given DNS node:

    _application._tcp._client._dane.box.example. IN TLSA 3 1 1 ...

because _client might be used in non-dane contexts, and we want to
distinguish TCP from UDP, ...  But what's the real benefit to all
this?  We're publishing TLSA records for "application" on "box.example",
is any  of the other baggage really helpful?

With enough such labels, we don't need a TLSA RRtype, just use TXT,
and encode the data in JSON.

    _application._tcp._client._tlsa._dane.box.example. IN TXT "{usage=3, selector=1, mtype=1, data=...}"

The point I'm trying to make is that given the base domain, an
application-specific initial _label, an the TLSA RRtype, we have
all the essential distinguishing identifiers and anything else is
baggage that needs justification.  

James makes a plausible point about _client as a way to carve out
a zone for clients, but because unlike SMIME/A or OPENPGPKEY the
base domain is here typically not a zone apex, but rather a specific
host, carving out a new zone under each host scales poorly.  And
this takes away the simplicity of an identity mapping between the
query domain and the corresponding SRV-ID.

So I while I am sympathetic to his argument, I don't think it holds
up in the end.

If we start injecting _proto, and various additional labels, I am
pretty we'd be overdoing the design.  There has be a good reason
for these, beyond superficial similarity to server use-cases that
are not actually analogous.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 13 Jan 2016 05:56:44 -0000

>or if it applies to both.

That part shouldn't be hard -- in any TCP session, one end is
listening and the other connects to it.  By definition the listening
end is the server and the connecting end is the client.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Jan 2016 06:01:02 +0000

> to kludge it with CNAME and break everything.

The TXT SPF records will be a the zone apex.  The _smtp-client (or
just _smtp) prefix will be for each client MTA!  There's little
opportunity for collisions, except at domains with just a single
node at the zone apex holding all the records and not even using
a hostname under the domain for outgoing connections as a mail
client.  If that domain operator needs CNAMES for the client
TLSA record (to where???) they can create a suitable sub-domain
for the client name.

	; zone apex MX record
	example.com. IN MX 0 smtp.example.com.

	; zone apex SPF record
	_spf.example.com. IN TXT ...

	; MX host A record
	smtp.example.com. IN A 192.0.2.1[

	; SMTP client
	_smtp.smtp.example.com. IN TLSA 3 1 1 ...

	; SMTP server
	_25._tcp.smtp.example.com. IN CNAME _smtp.smtp.eample.com.

> the collisions inevitably happen, it won't be our problem.

It is zero extra lines of code, but what do these extra bytes buy us?

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 13 Jan 2016 06:42:21 -0000

>with the only benefit of this separation ...

The benefit of putting the service name behind a transport name is to
put the service names in a separate namespace where they don't collide
with anything else and they're already managed by IANA.

>because _client might be used in non-dane contexts,

No, it's _application._client._tcp.box.example, and it's because
someone might use _application in other contexts.

> and we want to distinguish TCP from UDP, 

Not really.

> ...  But what's the real benefit to all this?

You're avoiding name collisions down the road.

>host, carving out a new zone under each host scales poorly.

Surely we don't have to review the difference between name components
and zone cuts. Nobody has proposed putting a new zone under each host
name.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Jan 2016 07:04:40 +0000

> You're avoiding name collisions down the road.

Please don't get me wrong, I'm not zealous about this, just don't
yet see any value in the additional labels, and surely we should
add them for a good reason.  I would expect the RRtype to provide
all the collision avoidance that's required.  Plus the fact that
these are intended to be host-specific records, while, the various
proposed example collisions are generally published at the parent
domain of the various hosts.

If we have to insert "_client" and that's the WG consensus, fine,
just extra bits on the wire.  As for "_tcp", that is really just
excess baggage.  Once we move move away from port numbers to
application names the transport protocol to disambiguate numeric
ports really does not seem at all helpful.

Anyone voting for application OIDs to avoid collisions?  The OID
space is plausibly in better shape than the flat IANA service name
registry...

> and zone cuts. Nobody has proposed putting a new zone under each host

I guess James is "nobody". :-)

-- 
	Viktor.

---

From: "Wiley, Glen" <[email-masked]>
Date: Wed, 13 Jan 2016 14:41:15 +0000

>domain of the various hosts.

RRtype is sufficient for collision avoidance, I don¹t think we gain
any practical benefit by adding the other labels.

<snip>

---

From: "John Levine" <[email-masked]>
Date: 13 Jan 2016 16:32:35 -0000

>any practical benefit by adding the other labels.

Oh, OK.  How about inventing a TLSACLIENT RRtype and use no prefix
labels at all?

I don't think that's a very good idea, but I'd be interested to hear
if other people agree, and if so, why.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Jan 2016 18:14:28 +0000

On Wed, Jan 13, 2016 at 04:32:35PM -0000, John Levine wrote:

> >RRtype is sufficient for collision avoidance, I don?t think we gain

Well, we still a service-specific prefix, because we're signalling
the public keys for clients of a particular service on a particular
network node.  Clients for different services may well have different
certs/keys.

The main argument that supports more than just a single service
prefix (if those are actually prone to collisions with various
other common prefixes like _spf, _dkim, ...) is that CNAMES are
quite useful with TLSA RRs when the payload is a trust-anchor digest
that should just be and managed in one place.

Thus if we really believe that there's a collision problem on just
the prefixed names, so that potential application client prefixes
(of the form suggested in the draft) already have existing non-TLSA
records, then it would be better to have just one additional label:

    _service._client.node.example. IN TLSA ...

So that one can create CNAME records:

    _service._client.node.example. IN CNAME _dane.example.

I still don't see any use for _tcp/_udp in there.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 13 Jan 2016 20:06:17 -0000

>    _service._client.node.example. IN TLSA ...

Ah, we're getting closer.

>I still don't see any use for _tcp/_udp in there.

RFC 6698 has _tcp _udp and _sctp protocols as part of the names for
TLSA.

It seems rather odd to have the protocol name for the server
certificate but not for the client.

R's,
John

PS: In case it's not clear, I'm not proposing that client certs use
port numbers, for reasons that I hope are obvious.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Jan 2016 22:37:00 +0000

> Ah, we're getting closer.

Well, I can live with the above, *if* there's a good reason to
expect conflicts that block use of CNAMEs.

> RFC 6698 has _tcp _udp and _sctp protocols as part of the names for

For a good reason, because the full prefix is "_<portnumber>._<proto>".
Without "_proto", we get TLSA records applied to the wrong service
endpoint, because UDP ports with the same number don't reach have
the same service as the TCP ports.

> certificate but not for the client.

Because the client prefix-label a service *name*, so so the port
collision issue goes away.  We should not cargo-cult designs,
the rationale has to carry over logically, and false analogies
need to be avoided.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 14 Jan 2016 01:01:38 -0000

>the rationale has to carry over logically, and false analogies

One man's cargo cult is another man's namespace management.  Every
existing use of _<service> names is behind a _<proto> name, and there
seems to me considerable merit to keep it that way, at the trivial
cost of a possibly uninteresting _tcp or _udp in the name.  If the
extra five bytes is an issue, I suppose we could use _c rather than
_client for the client tag.

While saving five characters was a big deal when I was programming
PDP-8's almost 50 years ago, I don't get it now.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Jan 2016 20:19:12 -0500

> On Jan 13, 2016, at 8:01 PM, John Levine <[email-masked]> wrote:
> 

This forces clients that use both TCP and UDP to publish their TLSA
records twice (or better publish one as a CNAME for the other, or
make both CNAMEs to a third thing).  Is this really worth it?

Folks are having a hard enough time publishing correct TLSA records,
and remembering to change all the copies.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 14 Jan 2016 02:49:10 -0000

>make both CNAMEs to a third thing).  Is this really worth it?

How much of a problem has it been for TLSA server records?  I honestly don't
know but I'd be surprised if the answer were other than "not much".  

Creating the certificate and turning that into the right hex for the
TLSA master record seems vastly harder than adding a CNAME which, if
you are right that nobody ever does anything different on TCP and UDP,
could be added mechanically.

R's,
John