Subject: [dane] Draft charter

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 12 May 2014 14:32:05 -0400

Dear Colleagues 

As the initial set of tasks set out in our original charter have been either completed or discarded it is time to revisit the charter of the working group.
The chairs have been working with the AD's on a new charter, attached is a draft for the new charter with milestones. 
The goal is to complete the current set of documents this year, and next year work on a revised RFC for DANE that will be published as Internet standard. 

There is lots of options in the proposed charter, some have milestones some do not, when documents/tasks are adopted we will update milestones.

If you have comments/suggestions on the draft charter please share them, the plan is to submit the draft charter to the IESG early next week. 

	Olafur & Warren

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 12 May 2014 19:27:14 +0000

On Mon, May 12, 2014 at 02:32:05PM -0400, Olafur Gudmundsson wrote:

> Objective:
> 
>     ...
>     DANE functionality to their work. In addition the working group
>     will monitor and provide guidance to operators and tool developers.
>     will monitor and provide guidance to operators and tool developers.

The above is a duplicate line.

>     The DANE working group has developed a framework for securely
>     retrieving keying information from the DNS [RFC6698]. This
>     framework allows secure storing and looking up public key
>     information in the DNS. This provides a binding between a domain
>     name providing a particular service and the key that can be used
>     to establish encrypted connection to that service.  

[ The below thoughts are likely too specific to rise to visibility
  in the charter, so are more likely fodder for 6698 revisions. ]

The RFC6698-specified lookup key of _<port>._<proto>.<fqdn> is not
universally applicable.  It works OK for well known services such
as SMTP on ports 25/587 or HTTPS on 443, but is not always well
suited to environments in which service ports are dynamically
registered.  Also, sometimes the verifier wants to authenticate a
TLS client acting on behalf of some domain in an appropriate
capacity.

Applications will in some use-cases need to agree on a lookup key
that is not tied to a numeric port.  It could be a service name or
a client role.  While a generic DANE TLS RFC (e.g. 6698) cannot
anticipate or standardize such alternative lookup keys, a future
update to 6698 should I think mention the need for such bindings,
and encourage applications employing DANE TLSA to define appropriate
alternative lookup keys.  This could be of immediate benefit in
XMPP to authenticate the origin of inbound traffic.

It may also be reasonable to encourage applications to choose either
PKIX-TA/PKIX-EE or DANE-TA/DANE-EE whichever is more appropriate
to the problem at hand.  Mixing the two yields the union of the
interoperability problems and the intersection of the security
features.

-- 
	Viktor.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 12 May 2014 16:21:10 -0400

Thank you Victor 

> The above is a duplicate line.

Fixed in version 03 to be posted soon 

> TLS client acting on behalf of some domain in an appropriate
This also works well for services looked up via SRV records. 
As the SRV contains the port number. 
For a protocol that has some kind of other selector of port, still at the end of the day
the "Server" side has a "known-port" to the client, if the service moves from one port to another port OR
provides service on multiple ports then it is possible that the protocol definition for the DANE variant of that protocol can say
lookup of Authentication records is <Proto>FP at hostname. 

> XMPP to authenticate the origin of inbound traffic.

Interesting are you you are saying we want to examine/specify client side DANE 
records (right now DANE is all about server side records). 

> interoperability problems and the intersection of the security

Are you proposing a BCP ? 
we can add that to the milestones, after the current Operational/Errata document is done. 

	Olafur

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 12 May 2014 20:42:56 +0000

On Mon, May 12, 2014 at 04:21:10PM -0400, Olafur Gudmundsson wrote:

> For a protocol that has some kind of other selector of port,
> still at the end of the day the "Server" side has a "known-port"
> to the client, if the service moves from one port to another port OR
> provides service on multiple ports then it is possible that the
> protocol definition for the DANE variant of that protocol can say

I am mostly pointing out that port is not universally the right
choice.  Sometimes a service name or other identifier is more
appropriate, whether this is the case, or what might be a better
lookup key is application dependent.

One immediate conclusion is that TLS + DANE toolkits (OpenSSL,
GnuTLS, NSS) must not hard-code the mapping from (host, port) to
the corresponding TLSA RRset.  There need to be multiple ways to
get a DANE TLSA authenticated connection, with the application able
to perform the TLSA lookup outside the library, or able to pass-in
a custom lookup domain and TLSA base domain...

> Interesting are you you are saying we want to examine/specify
> client side DANE records (right now DANE is all about server side records). 

Yes, but we likely can't specify the lookup keys in an application
neutral manner.  Rather we can discuss the problem generally, and
allow individual application protocols to construct appropriate
keys.  Still there could be some guidance on how to apply DANE to
TLS client identity (when the client identity can be mapped to a
suitable name in DNS).

> Are you proposing a BCP? 
> We can add that to the milestones, after the current Operational/Errata
> document is done.

Yeah, something like that, or merge this into the ops draft.

-- 
	Viktor.

---

From: Patrick Ben Koetter <[email-masked]>
Date: Mon, 12 May 2014 22:46:53 +0200

> records (right now DANE is all about server side records). 

I suggested that once to Viktor in an offlist mail, because I think a Receiver
might also want to know, which Sender it talks to.

Thesis: If I were a company to whom suppliers deliver work via email, I'd like
to ensure its really them and not someome else, who sends me the production
plan for some vital component.

BTW: We run a mail gateway for suppliers who must deliver their work via TLS
to their customers. The only way to enforce that is setting a policy on the
sending side. I'd find a policy on the receiving side that incorporates DANE
(if you can do it I require you to use it) attractive.

Also for e.g. banks that need to exchange data between themselves. If
encryption is vital there should be a mutual encryption policy. Each side
should be able to enforce a policy that requires the other party to use
encryption or transport will be rejected.

+1 from my side if that helps to examine the usefulness of client side DANE.

p@rick

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 12 May 2014 17:01:10 -0400

> +1 from my side if that helps to examine the usefulness of client side DANE.

Patrick, 
This is real good input thank you for posting this. 

I'm willing to add text to the charter to address this, 
at the end of paragraph #3: 
"In addition the WG may develop a framework to look up "client" side DANE records for authorization/authentication purposes."

(will finalize after more feedback and talking to Warren) 

	Olafur

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 13 May 2014 08:17:27 +0200

> TLS client identity (when the client identity can be mapped to a

That is something that also applies to SIP, where we have an RFC
about connection reuse in SIP/TLS. For server to server connections
it is important to be able to verify a list of domains each side
is authorized to use. Today we do this with a long list of domains in SAN,
but since my DANE/SIP draft removes that list for server certificates,
we are now in a situation where client certs use SAN and the server,
if using DANE, does not. 

The question it then boils down to is how I verify an incoming connection
from an IP address with a name. Maybe a DNSsec-secured reverse lookup
is a starting point. What's the state of DNSsec in .arpa ?

/O

---

From: Kim Alvefur <[email-masked]>
Date: Tue, 13 May 2014 13:48:14 +0200

On 2014-05-13 08:17, Olle E. Johansson wrote:
> is authorized to use.

This problem applies to XMPP as well.

> is a starting point. What's the state of DNSsec in .arpa ?

Doing a full forward SRV lookup and TLSA lookups on each
_port._proto.srv-target is another possibility, but it may get awkward
for clustered services where incoming and outgoing connections are
handled by different servers.

--
Kim "Zash" Alvefur

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 13 May 2014 13:52:04 +0000

> is a starting point. What's the state of DNSsec in .arpa ?

IP addresses are a terrible identity lookup key, they are often
dynamically assigned, and even when static often controlled by a
different organization than the one actually operating the host.

My thinking on client authentication with DANE is that it works
best when the client represents that is acting as or on behalf of
some domain, and when associated TLSA records are present (lookup
key TBD) authenticates the legitimacy of the client.

For example, with SMTP, clients impute a hostname with EHLO:

	S: 220 s.example ESMTP
	C: EHLO c.example

the server might then perform a lookup (work-around: only if
"c.example IN A ?" returns a validated response, possibly
validated NXDOMAIN or empty):

    _clientauth.c.example. IN TLSA ?

if this yields secure TLSA records, the server requires that the
client presents a matching certificate and infers a secure client
identity.

So for server-to-server, SIP the question I would ask is whether
the application protocol carries some sort of client domain assertion?

If SIP is wrapped in SSL (no STARTTLS unlike SMTP, IMAP, ...) then
the server would always solicit client certs, just in-case, and
verify them once the client indicates its domain in the application
protocol.

-- 
	Viktor.

---

From: Patrick Ben Koetter <[email-masked]>
Date: Tue, 13 May 2014 16:21:36 +0200

> different organization than the one actually operating the host.

ACK

> client presents a matching certificate and infers a secure client

Sidenote: Ask for client certificate only if TLSA is present? I like that.
This would safe us interop errors from clients that can't handle being asked
for a client certificate. 

p@rick

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

-- 
[*] sys4 AG

---

From: James Cloos <[email-masked]>
Date: Tue, 13 May 2014 12:51:25 -0400

>>>>> "OG" == Olafur Gudmundsson <[email-masked]> writes:

OG> Interesting are you you are saying we want to examine/specify client
OG> side DANE records (right now DANE is all about server side records).

We should find a way to do client RRs.  The charter should reflect that.

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

---

From: James Cloos <[email-masked]>
Date: Tue, 13 May 2014 12:59:25 -0400

>>>>> "PBK" == Patrick Ben Koetter <[email-masked]> writes:

PBK> Sidenote: Ask for client certificate only if TLSA is present? I
PBK> like that.  This would safe us interop errors from clients that
PBK> can't handle being asked for a client certificate.

I like that, too, as an option.  But asking every client also should
be possible.  Admin's choice.

-JimC

---

From: James Cloos <[email-masked]>
Date: Tue, 13 May 2014 12:57:17 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD>     _clientauth.c.example. IN TLSA ?

Maybe, in this case, _proto._clientauth.c.example.

Different client protocols may want different TLSAs; an additional level
in the naming would avoid every requestor having to slog through a
potentially long list of TLSA responces to find one which matches.

-JimC

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 13 May 2014 17:13:45 +0000

> potentially long list of TLSA responces to find one which matches.

Yes, of course.  I have not given much thought to the lookup key yet.

-- 
	Viktor.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 13 May 2014 15:43:50 -0400

Dear Colleagues, 

Updated version minor changes, fixed spelling, added text on “client side DANE lookups” without milestones at this point. 
Reworded couple of sentences for readability. 
Attached are both full text of the charter and diff off prior version to this version. 

	Olafur & Warren

On May 12, 2014, at 2:32 PM, Olafur Gudmundsson <[email-masked]> wrote:

> <DANE-charter-2014-02.txt>_______________________________________________
> dane mailing list
> [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 13 May 2014 23:28:28 +0000

On Tue, May 13, 2014 at 03:43:50PM -0400, Olafur Gudmundsson wrote:

> Updated version minor changes, fixed spelling, added text on
> 'client side DANE lookups' without milestones at this point.

This change:

-    By requiring DNSSEC protection for the lookup of the public key
+    By requiring DNSSEC protection for the look-up of the public key

Should I think be reverted, the noun is "lookup" not "look-up".

-- 
	Viktor.

---

From: Andreas Schulze <[email-masked]>
Date: Fri, 16 May 2014 16:09:30 +0200

> Maybe, in this case, _proto._clientauth.c.example.

just to make sure I read above right:

- $client connect from $random_highport to $server:$fix_serviceport.
- $server extract $client_ip and lookup $client_name (PTR)
- $server lookup $fix_serviceport._clientauth.$client_name. for TLSA Record.

right?

Andras

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 16 May 2014 15:09:07 +0000

> - $client connect from $random_highport to $server:$fix_serviceport.

Yes.

> - $server extract $client_ip and lookup $client_name (PTR)

This is often not the right name, if at all possible (in an
application protocol where the client can signal its identity before
STARTTLS) the name should be conveyed by the client.  TLSA records
would authenticate that name.

If the client's name is authenticated, it might be used for access
control and to avoid impersonation.  To mitigate downgrade attacks,
the server would have to be willing to not continue when DNS
resolution (either the forward address lookup or the TLSA lookup)
of the client name fails (note "insecure" or validated NXDOMAIN is
not a failure in this sense, see the DNS error section of the SMTP
draft).

For SMTP, many clients have HELO names whose lookups fail with
NXDOMAIN, but I don't know whether ServFail or similar errors are
also common.  This is more likely to initially be more applicable
to XMPP and SIP, but SMTP might also benefit some day.

> - $server lookup $fix_serviceport._clientauth.$client_name. for TLSA Record.

No server looks up something like:

	smtp._clientauth.$clientname IN TLSA ?

where "smtp" is (one example of) the application service name.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Fri, 16 May 2014 12:32:57 -0400

>>>>> "AS" == Andreas Schulze <[email-masked]> writes:

AS> just to make sure I read above right:

AS> - $client connect from $random_highport to $server:$fix_serviceport.
AS> - $server extract $client_ip and lookup $client_name (PTR)
AS> - $server lookup $fix_serviceport._clientauth.$client_name. for TLSA Record.

Unfortunately unnecessary constraints on the ptr zones are too common to
support sticking tlsas therein.

Client tlsa probably will only work for protocols where the client
claims to be something which can be forward-resolved, such as smtp (helo
name), sip (From: address) or the like.

When clients claim a name which looks like a hostname, the tlsa lookup
could be as simple as:

      _$PROTO._clientauth.$CLAIMED_NAME

The tls cert is likely in such cases to offer $CLAIMED_NAME as CN or
within the dnsnames.

Whether $CLAIMED_NAME is related to the remote ip address is a separate
issue which, if the server checks, can be used as part of the trust
equation.  Just like the current case with mta->mta smtp client certs.

For things like sip, where the claimed name usually looks like an email
address, the left hand side probably ought to be hashed and hexed, as
per the dane drafts for smime and openpgp, and included in the lookup.

The exact query for that case should get some discussion.

Again, whether the remote ip address looks reasonable for the claimed
name is orthogonal to what the cert claims to certify and whether the
tlsa provides a trust path for said cert.  But also again, servers can
use multiple data sources to decide how much they trust any given
credential.

Alternatively, the server might get the claimed name from the offered cert.

Either way, and unlike the server tlsa case, $PROTO should be a name
rather than a port number.  The string should derive from whatever means
led the client to the particular server, such as the protocol specified
in a uri, used for a srv lookup, the keyword in iana's port-numbers
registry, et cetera.  (Which wins in case of conflict?)

-JimC

---

From: Andreas Schulze <[email-masked]>
Date: Fri, 16 May 2014 21:48:18 +0200

> support sticking tlsas therein.

James, Viktor,

thanks for clarification. you mention that the ptr is unusable as base
for a TLSA lookup. You suggest to use the helo name in smtp for example.

I can tell only about smtp but here I don't see a real difference.
Hosts with perfect double dns mostly also use a corresponding helo name
while host without mostly lack also the matching helo name.
(my feeling, no detailed statistics...)

>       _$PROTO._clientauth.$CLAIMED_NAME
I like the phrase CLAIMED_NAME but I see no benefit
on using 'smtp' as $PROTO vs. the numeric portnumber ?

Back to the first: taking the CLAIMED_NAME as base to build a dns label
leave options open, how the server has to construct the label.
Simply using a ptr *may* be an option, but hasn't to be the only one.

To get the clients CLAIMED_NAME a server has multiple choices with  
different weights.

Andreas

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 16 May 2014 20:40:30 +0000

> (my feeling, no detailed statistics...)

Most hosts also don't have TLSA records.  No loss.  This feature
would allow some clients to be "more equal than others".  The server
might then apply special access policies with these "more equal
clients".  Because unlike SIP or XMPP, SMTP is uni-directional,
and the mail transport is store and forward, the potential value
of client authentication for SMTP is more limited than for the
other protocols, but may still be useful.

> on using 'smtp' as $PROTO vs. the numeric portnumber ?

The origin domain is authorizing SMTP clients to act on its behalf,
more so than the right to reach a particular remote port.  This said,
the lookup key will be application-specific, and it is perhaps a bit
early to do a deep-dive into that now...

-- 
	Viktor.

---

From: Petr Spacek <[email-masked]>
Date: Tue, 20 May 2014 16:40:59 +0200

> lookup key is application dependent.

I totally agree, some guidance how to use DANE in application-specific way 
would be handy. An example from Kerberos world:

There is a Kerberos extension called PKINIT [RFC 4556] which relies on secure 
CA certificate distribution. This CA cert is shared by the whole "Kerberos 
realm". Maybe Kerberos protocol should be extended to look-up CA cert in DNS, 
e.g. from
_kerberos.[REALM] IN TLSA ...

I'm sure there will be other cases like that.
(Note: I'm not saying that this particular case cannot be solved in other 
ways, it is just an example.)

-- 
Petr Spacek  @  Red Hat