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

[John Gilmore <[e-mail]>]

Paul Wouters said:
> > Please note that this is to support non-TLS scenarios where the public
> > key might not be transferred in-band like in the TLS case. That is,
> > the draft extends 6698 to support publishing any kind of public key
> > in SPKI format for verification. It does not suggest non-SPKI formats.

Paul Hoffman said:
> I see nothing in the draft that suggests that it would update 6698 to
> cover any protocol other than TLS and DTLS. If the WG adopts the
> document, the document should be clearer that the keying material is
> only for TLS and DTLS. Any other use would require a different
> protocol document that would use a different RRtype (even if that
> RRtype uses the same record format.

I see two issues mentioned here.  One is whether the TLSA record
should be deliberately restricted by the WG to never be used by
any protocol other than TLS.  The second is whether TLS always
transfers the public key in-band (thus obviating the need for a way
to publish a TLS key in the DNS).

On the first issue, we are already having to amend the TLSA RFC to
remove deliberate restrictions that were written into it.  I have not
seen any way that these restrictions improve interoperability; in
fact, they detract from interoperability by blocking usages that would
work technically.  The Raw Public Keys TLS extension would not have
needed to amend the TLSA RFC at all, if the TLSA RFC did not contain
explicit wording excluding the use of key formats other than a single
choice.  It could have merely been an add-on extension, if not for
those few restrictive sentences.

In amending the TLSA RFC for raw public keys, we could remove those
deliberate restrictions, and then write new deliberate restrictions.
Paul Hoffman's comment above seems to be advocating for that position.
Instead, I am advocating for not adding restrictions that have no
technical or interoperability rationale.  It is not the role of an
IETF working group to tell users that they are not allowed to use a
protocol that would work for them and that would interoperate cleanly
with other users.  It's like a WG saying, "You can't use the ssh
protocol to implement rsync or git, because ssh is only designed for
interactive shells.  Each of those applications has to design their
own ssh-equivalent protocol", or "The ntpdate program can't use the
NTP protocol to get a single estimate of the current time, because the
protocol is only designed for doing long-term synchronization among
multiple time servers".  To quote Dennis Allison, we should be
standing on each others' shoulders, not each others' toes.

The second issue is the use of the TLSA record to publish a key in its
entirety, rather than to merely authenticate the key with a hash value.
RFC 7250 (raw public keys) specifies that the server will send its raw
public key to the client, in the TLS transaction.  So, in the current
case, authenticating that key is all that is absolutely required.
However, there is a separate TLS WG draft,
draft-ietf-tls-cached-info-16.txt, which provides a way to reduce the
bandwidth required.  It has the client send a hash of the server's raw
public key (or cert chain) that it already knows.  If the server
agrees that that's the public key, it agrees and does not send the
server's public key (or certificate chain) in the TLS transaction.

This draft is optionally used by CoAP without DANE, using a pre-cached
server public key, but its protocol extension can also be used with
DANE.

When this draft TLS extension is used with DANE, the client has the
option to do a TLSA domain lookup first, then, if it receives a full
public key in that TLSA RRset, it can hash the public key and send
that hash when starting the TLS transaction.  If the server agrees
that that hash matches its current public key, it sends back agreement
and doesn't send another copy of the key.

While highly interactive applications like web browsers might not want
to serialize the TLSA lookup and the TLS transaction, serializing them
to reduce transmitted bytes might be a popular implementation choice
for a queued near-realtime application like SMTP, or for a background
operation like checking for or downloading software or firmware
updates.

This is another case (like the ssh example above) where the existing
TLSA protocol provides an easy way to do what is needed to use this
cached-info TLS protocol variant (authentically publish the whole raw
public key).  If we were to add more restrictive wording to the TLSA
definition (for example, if we restricted TLSA to merely being usable
for authentication, never for publication) then that restriction would
prevent users from interoperably doing an obvious thing that they wish
to do.  I suggest that we avoid adding such restrictions.

	John