Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00

[John Gilmore <[e-mail]>]

> So if the scope of RFC 6698 is not TLS, is it just any application
> where the 6698 RRDATA format seems to be useful?

"What is the scope of the TLSA record?" is a great question to ask
ourselves.  (We may not ultimately need to answer it clearly; we may
agree to hold different opinions.)

My goals in the draft were, 

  first, to enable the use of DNSSEC/DANE with TLS raw public keys;

  second, to repeal the statements in RFC 6698 that prevent the use of
  the TLSA record with keys that aren't in PKIX certificates.

I only took on the second goal because it was required to enable the
first goal.  But once we have opened the door to raw public keys for
TLS (at port numbers where TLS is used), I saw no reason to add
restrictive language preventing anyone from using raw public keys at
other ports or for other protocols.  The name-prefixed design of the
TLSA record tends to prevent such other uses from causing any
problems to its main use with TLS.

I see the goal of IETF standards as enabling interoperability.  Where
restrictions on user choices are needed to enable interoperability, we
restrict them (e.g. with MUSTs or MUST NOTs).  Where interoperability
is not threatened, we need not and should not restrict users to only
the usages and protocols that we have in mind today.

> So for example, would it apply to publishing KDC public keys for
> cross-realm pkinit?  Does it matter whether the lookup key for the
> RRDATA would likely not be "_port._proto.domain", or would that
> make the Kerberos cross-realm key use-case fall outside this update
> to 6698.   In other words does the new draft only apply to some
> kind of transport layer security (lower case to distinguish from
> TLS) where the end-point identity is necessarily _port._proto,
> with with a TLSA-like RRDATA format?

When I was working on Kerberos many years ago, the KDC was running on
a particular, standardized port (UDP port 88).  So it probably would
fit into the TLSA scheme at _88._udp.example.com if we wanted it to.

A larger issue with Kerberos at that time was the protocol's
insistence that Kerberos "realms" are not "domain names".  To
emphasize that distinction, the Kerberos documentation and common
usage tended to make realms names UPPERCASE.  At the time, that seemed
to me to be a relatively useless distinction, but I was a newcomer to
Kerberos.  At Cygnus, we evolved the Kerberos software such that if
you chose to make your realm name match your domain name, the software
would do useful things by default, that would require
pre-configuration if your realm name did not match your domain name.
I do not know if that usage has caught on.

In the Raw Public Keys draft, I had no intent to change the TLSA
requirement for a _port._proto prefix, so if Kerberos realm
authentication with TLSA ultimately ends up requiring such a change,
the future DANE Kerberos draft itself will probably have to relax that
requirement.

	John