> I don't see any HTTPS requirement in 6698, just TLS. Thus, SMTP
> with STARTTLS on port 25 is using TLSA records, as is XMPP.
Right.
> What additional protocols over TCP that employ certificates, but not
> TLS did you have in mind?
Well, the obvious ones are IPSEC, OpenPGP, and SSH. VoIP and other
chat protocols are other obvious apps, though crypto for them is
currently fragmented (partly as a result of a lack of good key
distribution). We have people working on drafts and/or
implementations for various of these protocols, but the base document
still inappropriately says "this can only be used for TLS".
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. Once people get used to
publishing DANE keys for TLS, they might well be happy to publish
DANE keys for SSH too.
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? There never was a requirement for TCP,
considering DTLS doesn't use it and DTLS was in RFC 6698 (see section
3).
In general I don't think that IETF standards should be written to
limit their applicability to a single application. 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?
DANE could be widely usable to provide access to crypto keys and
authentication thereof for almost ANY kind of crypto protocol. 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. 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.
John
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
