On Thu, May 14, 2015 at 06:28:49PM -0700, John Gilmore wrote:
> > What additional protocols over TCP that employ certificates, but not
> > TLS did you have in mind?
Sorry about that, I should have included UDP also, as TLSA records
include the transport layer protocol in the owner label, so I don't
see any reason to exclude DTLS over UDP.
> Well, the obvious ones are IPSEC, OpenPGP, and SSH.
Does it make sense to specify IPSEC keys on a port by port basis?
And if so, how does one distinguish between an application willing
to talk TLS on a given port, from an O/S stack willing to do IPsec?
This is important, because the keys are not necessarily available
to both, and client applications may insist on TLS, when the TLSA
record is hypothetically intended to be used with IPSEC.
So I'm fairly sure that IPSEC requires a separate record type (not
TLSA). I believe Paul Wouters is doing some work on DANE and IPSEC,
so I'll further discussion to him.
Similarly, PGP is not a transport protocol, and there are separate
efforts to use DANE for S/MIME and PGP, but with new records distinct
from TLSA.
Which leaves SSH. SSH is connecting to a transport endpoint, so
if someone wanted to standardize SSH with TLSA records (and possibly
even DANE-TA(2) CAs?), that might be possible, despite the fact
that the security protocol is neither TLS nor DTLSA. I think such
an extension of TLSA can be added at that time if it makes more
sense to overload TLSA than introduce a dedicated RRtype.
Any security protocol that supports "2 0 1" TLSA records has to
deal with X.509 certs and trust anchors and certificate chains,
and are we really going to design more of these that are not
TLS/DTLS? If it only supports "3 1 1" then perhaps TLSA is
not the most appropriate RRtype.
So I'm with you on DTLS, but I am rather sceptical about extending
the TLSA RRtype much more broadly. It is easy enough to write up
a spec for a new RRtype that applies to some other (than TLS/DTLS)
transport security mechanism, and such a spec would be able to omit
features of TLSA that are a poor fit.
> SSH has its own keying record (SSHFP, RFC 4255) but it only provides
> for communicating a fingerprint, not for the actual public key.
> DANE could be used to publish the entire public key if desired; and
> SSHFP doesn't seem particularly popular.
Largely (catch-22 perhaps) because DNSSEC is not yet terribly
popular. And there's not too much demand for ad-hoc inter-domain
SSH. I don't SSH to google.com, but I send them email and visit
their website.
> Once people get used to
> publishing DANE keys for TLS, they might well be happy to publish
> DANE keys for SSH too.
If DANE for SMTP helps to drive DNSSEC adoption, perhaps more folks
will publish SSHFP, I don't see a compelling case for TLSA with
SSH, the fingerprints are really good enough, the main obstacle is
DNSSEC not lack of support for publishing the full key.
> I thought the idea of your draft's "raw public key" text is to
> eliminate the requirement for certificates, so why ask about protocols
> that use certificates?
It is to allow the use of RFC7250 raw public keys (no certificates),
but still at this time in the context of TLS (or DTLS).
> In general I don't think that IETF standards should be written to
> limit their applicability to a single application.
Indeed, thus DANE TLSA for SMTP, XMPP, HTTP and also application
protocols that use SRV records with TLS (IMAP, ...).
> In 1985 I could've
> written the BOOTP spec (RFC 951) to insist that people should never
> use it for anything but the narrow application it was intended for
> (helping diskless workstations boot up from their server). Happily,
> Bill Croft and I didn't, and almost 10 years later, someone else built
> DHCP on top of BOOTP. Now billions of cellphones use DHCP to get an
> IP address when they connect to a WiFi access point. Why would I have
> wanted to rule out that outcome? Perhaps in some crabbed attempt to
> constrain competitors so I could sell more diskless workstations?
Many thanks for all those diskless Sun3/50's by the way! They got
me started down my eventual career path.
> DANE could be widely usable to provide access to crypto keys and
> authentication thereof for almost ANY kind of crypto protocol.
Indeed, and thus there's work on SMIMEA, OPENGPGKEY, ... and
opportunities for any additional RRtypes that make sense.
So the key question is whether for a protocol that is neither TLS,
nor DTLS and wants to just use bare public keys (ditch the X.509
PKI legacy bloat) does it make sense to use TLSA records with all
their permutations of parameters, or might there instead be a new
(still application neutral) RRtype for "dane public keys"?
_4242._tcp.newcrypto.example.com IN DANEPKEY <matching-type> <data>
in which the DANE-EE(3) and SPKI(1) are fixed and implicit?
> But if
> the working group that designed it insists that it's "only to be used
> to support our favorite toys and no others," then people looking for a
> crypto key access / authentication protocol will go elsewhere.
Well, DANE is not just for TLS. Rather at present, TLSA records
are just for TLS/DTLS. So the key question is whether that's a
good fit for other use-cases. The draft extends "3 1 1" to work
with TLS and RFC7250's bare keys, it is a start.
How would one signal which security protocol to use with a particular
transport end-point? Having TLSA signal the use of TLS is potentially
helpful if the same application also supports other encapsulations.
> Who needs the hassle of adopting a protocol where you have to fight all
> the time with the designers over the simplest things? Protocols,
> especially poor ones, are easy enough for new implementers to design,
> that we should put few barriers in the way of re-using an existing
> protocol that has stood the test of time.
So bottom line, I am actually open to allowing "3 1 1" to be
overloaded, for non-TLS "just key" purposes, but honestly sceptical
that it is a good fit.
It would be good to explore this with a real (non-hypothetical)
use-case for an application whose designers/developers want to use
DANE for key management. I don't see real obstacles to writing
another draft later that updates 6698 again, if that turns out to
be a fruitful direction.
At present, I think the right thing to do is to make sure that the
RFC 7250 use-case is adequately covered.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
