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

From: Warren Kumari <[email-masked]>
Date: Mon, 23 Jun 2014 06:16:01 -0400

Dear DANE WG,

This starts a Call for Adoption for draft-gilmore-dane-rawkeys-00.
The draft is available here:
https://datatracker.ietf.org/doc/draft-gilmore-dane-rawkeys-00/

This document was written in response to a request, and so we are
compressing the more traditional 2 week call for adoption to instead
be a single week.

Please let us know clearly if you *object* to this document being
adopted, with a clear explanation of why.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends Monday 07-Jul-2014.

Thanks,
Warren Kumari
(as DANE WG co-chair)

---

From: Peter Koch <[email-masked]>
Date: Mon, 23 Jun 2014 13:14:14 +0200

> adopted, with a clear explanation of why.

I'd expect the next thing for the IETF is to introduce an objection fee ...

> This call for adoption ends Monday 07-Jul-2014.

?

I've read the draft but not any preceding discussion.  Publishing (not
"authenticating", please) raw keys in the DNS makes a lot of sense IMHO,
but it's not obvious to me why the TLSA RR type is the right one.
The document does not explain why the expansion of the usage "3"
is backwards compatible, i.e., not confusing old clients.

-Peter

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Jun 2014 15:01:58 +0000

> https://datatracker.ietf.org/doc/draft-gilmore-dane-rawkeys-00/

I am a day or two away from essentially compatible language in the
next (04) revision of draft-ietf-dane-ops.

I have no major objections to the substance of the new draft, we'll
mostly just need to decide how it relates to the revised ops draft,
which is now a 6698 update.   We should be able to merge the best
parts of the two parallel treatments, and either expand the coverage
of raw public keys in the ops draft, or shrink it, moving all
coverage of this issue to the new draft.

My technical issue with the new draft was that it seemed to suggest
that any DANE-EE(3) TLSA RR can be used to match raw public keys,
while in fact only DANE-EE(3) SPKI(1) matches raw public keys.

The new draft operates at two layers, on the one hand concretely
extending 6698 to support raw public keys, and on the other hand
generalizing the approach to arbitrary "key material" (conceptually
beyond even raw public keys).  My best guess is that were some
other kind of "key material" to be used with TLS, that is not in
SPKI format, the draft is trying to suggest that we'd use DANE-EE(3)
anyway (but likely with a new selector value, though this is not
stated).  I would for now not try to generalize beyond SPKI.  It
is not clear what those generalizations will really entail or
whether any are likely to happen in the near future.

Since I think "adoption" is not final approval of the content, but
rather agreement that there is useful and relevant material to
build on, while the draft is not done, I support adoption.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 23 Jun 2014 11:58:00 -0400 (EDT)

On Mon, 23 Jun 2014, Viktor Dukhovni wrote:

> SPKI format,

Please note that this is to support non-TLS scenarios where the public
key might not be transfered 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.

> the draft is trying to suggest that we'd use DANE-EE(3)
> stated).

Actually, the intend is to NOT introduce a new selector, especially
for the TLS case to ease migration from PKIX certificate to raw public
key.

>  I would for now not try to generalize beyond SPKI.

I don't think it is?

>  It

Note that these kind of statements during 6698 discussion is what got
us here to begin with. The reluctance of types not involving "PKIX
certification". It would be very ironic to make that mistake twice.

> build on, while the draft is not done, I support adoption.

That's right. And for the record, I support WG adoption of this
document as well.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 23 Jun 2014 11:59:11 -0400 (EDT)

> is backwards compatible, i.e., not confusing old clients.

old clients that did not support bare public key could not even use
TLSA, so how can extending support break older clients?

Paul

---

From: James Cloos <[email-masked]>
Date: Mon, 23 Jun 2014 12:51:21 +0000

>>>>> "WK" == Warren Kumari <[email-masked]> writes:

WK> This starts a Call for Adoption for draft-gilmore-dane-rawkeys-00.

For an intial draft, the document reasonably covers the issues.

The wg should adopt it.

WK> Please also indicate if you are willing to contribute text, review, etc.

I am.

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Jun 2014 17:34:34 +0000

On Mon, Jun 23, 2014 at 11:58:00AM -0400, Paul Wouters wrote:

> key might not be transferred in-band like in the TLS case. That is,

This was not clear.  So the "TLSA" (does not stand for anything)
acronym is not supposed to be understood to apply just to TLS (and
by extension DTLS)?

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?

Recall that we've added a charter goal of defining something for
client authentication, which is likely to reuse RFC 6698 RRDATA,
but will probably carry a different lookup key.

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

-- 
	Viktor.

---

From: John Gilmore <[email-masked]>
Date: Mon, 23 Jun 2014 10:58:10 -0700

> 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.

> 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

---

From: [email-masked] (Martin Rex)
Date: Mon, 23 Jun 2014 23:05:42 +0200 (CEST)

Paul Wouters wrote:
> Peter Koch wrote:

To me this looks like you're talking past each other.

The Selector Type 1 "SubjectPublicKeyInfo" is already defined (Section 7.3)
and explained (Appendic A.1.2.2) in rfc6698:

  https://tools.ietf.org/html/rfc6698#section-7.3
  https://tools.ietf.org/html/rfc6698#appendix-A.1.2.2

Existing TLSA/DANE-aware TLS clients will (silently) assume, that this 
selector refers to a public key that is embedded in a more-or-less regular
X.509 certificate, and that this certificate will appear in the
(PKIX) certification path that the TLS client came up with for
certificate path verification.

The newly envisoned usage scenario seems to be for use by TLS peers
with bare public keys (i.e. that do not exchange any certificates at
all and do not, or not necessarily manage such keys with an X.509 cert
wrapper/container.

In theory, this looks like TLSA/DANE aware clients might get confused,
assuming that they will be able to locate a cert in the computed (or
server-supplied) certificate chain, and fail DANE validation if they
cannot match.  In practice, a guidance for the server admin to supply
cert-based TLSA records might be sufficient, whenever interop with
clients that do not support bare public is desired.

To be usable with bare public keys at all, both, client and server
will have to support bare public keys, and the client will have to
offer their use in ClientHello through a TLS extension and the server
will have to agree using it.  The server does not (currently) learn
whether the client is DANE/TLSA-aware, but certainly knows whether
the client supports and is willing to accept a bare server key in
the TLS handshake.

One common case where the SPKI selector may help in traditional PKIX 
is in CrossCA / Bridged PKI scenarios, or the backward-compatibility-hack
usage scenarios used by a few public CAs these days -- where the current
PKI is normally operated with a 2048-bit self-signed RootCA certificate,
but that new self-signed RootCA cert might not be known to older TLS clients,
and therefore many servers are sending out a crossCA certificate in the
forward certification path of the Server's Certificate TLS handshake
message for the new 2048-bit root that is signed by the old 1024-bit
root that is known to old TLS clients.

One common example is the VeriSign/Symantec
    
  CN=VeriSign Class 3 Public Primary Certification Authority - G5

which exists as a self-signed rootCA cert and as a crossCA cert
signed by the 1024-bit RSA key of the old

  OU=Class 3 Public Primary Certification Authority

And of that latter old VeriSign Root, there exist two different (three if one
includes the jan-2004 expired root in the count) certs with the same
public key (i.e. SubjectPublicKeyInfo) in them:

serial  (md2RSA sig):  70 ba e4 1d 10 d9 29 34 b6 38 ca 7b 03 cc ba bf
serial (sha1RSA sig):  3c 91 31 cb 1f f6 d0 1b 0e 9a b8 d0 44 bf 12 be

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Jun 2014 21:42:22 +0000

On Mon, Jun 23, 2014 at 11:05:42PM +0200, Martin Rex wrote:

> X.509 certificate,

Hence the 6698 update.  If the service is in fact a TLS service,
clients using X.509 handshakes will not see anything new, because
they won't use the new extension to negotiate use of raw public
keys.

> and that this certificate will appear in the

DANE-EE(3) is not PKIX and has no PKIX path.

> all and do not, or not necessarily manage such keys with an X.509 cert

Many clients will support both, and servers even more so may be
willing to use the same public either adorned in X.509v3 finery,
or bare (with or without the emperor's new clothes).

> In theory, this looks like TLSA/DANE aware clients might get confused,

The underlying meaning of "DANE-EE(3) SPKI(1) ?" is unchanged, it
matches a leaf SPKI object in either form.  There is no confusion.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Tue, 24 Jun 2014 00:00:27 +0200 (CEST)

> matches a leaf SPKI object in either form.  There is no confusion.

It will not be possible to use DANE only for bare keys and
traditional PKIX _without_ DANE for certificate-based authentication,
because DANE/TLSA-aware clients, that do not support bare keys in TLS,
would encounter a DANE validation failure with the PKIX cert they get
from the server.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Jun 2014 22:13:14 +0000

> would encounter a DANE validation failure with the PKIX cert they get

This is simply not the case.  The TLSA RRset contains multiple
records.  If the server is designed to serve clients that employ
traditional X.509 handshakes (not just clients that do RPK), then
that server's TLSA RRset needs to include at least one TLSA RR that
matches the server's chain presented in its TLS "certitificate
message".  Typically the same TLSA record:

    _443._tcp.www.example.com. IN TLSA 3 1 1 {SPKI-SHA2-256-digest}

is sufficient to match both the bare key and the *same* key embedded
in an X.509v3 certificate.  If for some reason the "bare" keys are
not available in certificate finery, the RRset needs to list multiple
values:

    _443._tcp.www.example.com. IN TLSA 3 1 1 {crt-SPKI-SHA2-256-digest}
    _443._tcp.www.example.com. IN TLSA 3 1 1 {rpk-SPKI-SHA2-256-digest}

Where the first record is for the leaf certificate and the second
is for the bare key, repeated as necessary for additional certs
and additional bare keys, with the usual transitional states for
key rollover.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Tue, 24 Jun 2014 00:23:57 +0200 (CEST)

> and additional bare keys, with the usual transitional states for

Thank your for agreeing with me.  :)

This is the missing guidance for the server admin that I talked about.

You can not make a DANE/TLSA-aware TLS client that does not support
bare keys at the TLS protocol level, to *not* try matching SPKI TLSA
records to certs exchanged at the TLS protocol level, because it
is not possible to mark an SPKI selector as applying only to bare keys.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Jun 2014 23:00:38 +0000

> Thank your for agreeing with me.  :)

You're welcome.  My expectation is that in most cases, servers that
support both X.509 certs and bare keys, will simply use the keys
embedded in their certs as their bare keys, and the issue will be
moot.

> This is the missing guidance for the server admin that I talked about.

However, explicit guidance would not be out of order.

> is not possible to mark an SPKI selector as applying only to bare keys.

Yes, this is intentional.  Fortunately, we have a TLSA RRset, rather
than a single RR, to work with and it is possible to public
simultaneous associations for multiple "key material" objects.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Jun 2014 10:52:53 +0100

This document seems fine as a start for a WG document. 

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Jun 2014 10:57:58 +0100

On Jun 23, 2014, at 4:58 PM, Paul Wouters <[email-masked]> wrote:

> key might not be transfered in-band like in the TLS case.

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.

--Paul Hoffman

---

From: John Gilmore <[email-masked]>
Date: Tue, 24 Jun 2014 13:52:39 -0700

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

---

From: James Cloos <[email-masked]>
Date: Tue, 24 Jun 2014 19:23:01 -0400

>>>>> "JG" == John Gilmore <[email-masked]> writes:

JG> In amending the TLSA RFC for raw public keys, we could remove those
JG> deliberate restrictions, and then write new deliberate restrictions.
JG> Paul Hoffman's comment above seems to be advocating for that position.
JG> Instead, I am advocating for not adding restrictions that have no
JG> technical or interoperability rationale.

On that topic, not only do I agree that language which tries to restrict
TLSA records to TLS is undesirable, I cannot discern *any* value in such
restrictions.

The software for any protocol which uses x.509 certs or which can handle
spki-formated transmission of public keys should feel to use tlsa records
to authenticate said certs or spkis.  Even if it is a protocol which does
not listen(2) on a fixed port and therefore would need to search for tlsa
records differently than 6698 describes.

If an alternate use of a given dns rr would lead to some sort of conflict
which would break other uses, there would be valid cause to advocate
against such breakage.  But I do not see how using tlsa records for non-
tls protocols would do that.

-JimC

---

From: Tom Gindin <[email-masked]>
Date: Wed, 25 Jun 2014 22:52:32 -0400

James:

        Would not SECSH clients in particular be able to benefit from this 
record type for raw public keys, if supported on an Intranet DNS?

                Tom Gindin
P.S.    The above suggestion is mine, and not that of my employer.

From:   James Cloos <[email-masked]>
To:     John Gilmore <[email-masked]>
Cc:     [email-masked]
Date:   06/24/2014 07:31 PM
Subject:        Re: [dane] Compressed Call for Adoption: 
draft-gilmore-dane-rawkeys-00
Sent by:        "dane" <[email-masked]>

-JimC

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Jun 2014 07:22:54 +0100

Having read the author's message to the mailing list that he intends this draft to update RFC 6698 to apply to unnamed protocols, not just TLS, I rescind my support for the draft. I still fully support updating 6698 to cover "keying material" instead of "certificates" in the manner discussed in the -00 draft. I would also support a different draft that says "the TLSA record can be used in the following protocols in the following fashions".

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 26 Jun 2014 14:26:47 +0000

On Thu, Jun 26, 2014 at 07:22:54AM +0100, Paul Hoffman wrote:

> Having read the author's message to the mailing list that he
> intends this draft to update RFC 6698 to apply to unnamed protocols,
> not just TLS, I rescind my support for the draft. I still fully
> support updating 6698 to cover "keying material" instead of
> "certificates" in the manner discussed in the -00 draft. I would
> also support a different draft that says "the TLSA record can be
> used in the following protocols in the following fashions".

Well, this is not last call, rather a call for adoption.  Perhaps
we can come to rough consensus on this issue after the draft is
adopted?

I can, for example, see using TLSA RRDATA (with a different lookup
key than _port._proto) for cross-realm kerberos without prior manual
keying.  Nico may publish a draft for that at some point...

Now to Paul's point, there will of course need to be a draft
specifying any such use-case.  However, there is perhaps little
harm in allowing the TLSA RRDATA definition in 6698 to not explicitly
exclude other protocols.

To me the part that binds TLSA RRs to transport security is
_port._proto.  The queryname for TLSA RRset is a transport
end-point, hence we're doing transport security.

If instead the DNS lookup were something like:

	_pkcross.athena.mit.edu IN TLSA ?

then we're not doing transport security.  To Paul's point however,
it is a bit less obvious that the various per-protocol specs will
always keep out of each other's way and avoid lookup key collisions
for unrelated services if the RRtype TLSA is SHARED, and only the
various _mumble prefixes differentiate distinct use-cases.

On balance I think it is reasonable to use TLSA RRDATA in more
situations, and support adoption of the draft, which will presumably
evolve to match rough consensus.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Jun 2014 16:49:48 +0100

> we can come to rough consensus on this issue after the draft is

Sure. However, when someone publishes a -00, and during the call for adoption says "and I intend to add a major change that wasn't even hinted at in the -00", I think it is worth the WG to pause a bit.

> keying.  Nico may publish a draft for that at some point...

Absolutely. However, if you're talking about changing the lookup mechanism, then it is no longer a simple change to the the base spec. Thus, my proposal to collect all non-TLS use of TLSA record in a different document.

> harm in allowing the TLSA RRDATA definition in 6698 to not explicitly

RFC 6698 already excludes non-TLS use throughout the document by talking about TLS as the only applicable protocol.

> evolve to match rough consensus.

I'm with you there up to the last bit. It will take much longer to come to consensus on a catch-all document than it will one that, like draft-gilmore-dane-rawkeys-00, is just about allowing raw keys for TLSA for TLS.

--Paul Hoffman

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Jun 2014 08:50:20 -0400

> in SPKI format for verification. It does not suggest non-SPKI formats.

When you write SPKI, do you mean rfc2692/93?  Or something else?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Jun 2014 08:47:48 -0400

I have read draft-gilmore-dane-rawkeys.
I think that some of the goal text in section 4, that explains that this
mechanism can be used for both certificate and raw key based TLS, should move
much earlier in the document.

My impression is that this document does not require any new assigned
numbers or protocol values, but rather simply explains how a raw key can be
contained in a minimal DER encoded format such that it can be contained in
the TLSA record.  I found reading the document difficult as it contained too
many "extende" statements; likely this is because I have not done a TLSA
implementation so I am not sufficiently familiar with the underlying data
structures.

Mention of a way to validate a key by hash is mentioned, but I'm unclear how
that works from my first reading.

I support adoption of this document; it needs a co-author.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 27 Jun 2014 18:21:23 +0000

On Wed, Jun 25, 2014 at 08:47:48AM -0400, Michael Richardson wrote:

> the TLSA record.

More typically, the record will hold a digest, not the full key.
Matching type Full(0) is not recommended, at least for RSA keys,
which are quite large.

> that works from my first reading.

The peer presents the key in-band (TLS handshake, for example).
The client checks that the key matches the hash in the TLSA record.
The TLSA record is a binding between a DNS name and a public key,
so a binding to a key digest (given a strong digest) is just as
good.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Fri, 27 Jun 2014 14:29:27 -0400

>>>>> "MR" == Michael Richardson <[email-masked]> writes:

MR> When you write SPKI, do you mean rfc2692/93?  Or something else?

See section 3 of rfc 7250, now that it is released.

http://tools.ietf.org/html/rfc7250

-JimC

---

From: Paul Wouters <[email-masked]>
Date: Fri, 27 Jun 2014 21:55:15 -0400 (EDT)

> More typically, the record will hold a digest, not the full key.

That's one use - not the exclusive use. A TLSA record can also be
sed to securely publish public keys.

> Matching type Full(0) is not recommended, at least for RSA keys,

Perhaps for use with TLS yes, because the public key is transfered
within TLS already. That might not be true of other protocols that
would like to lookup a public key structure with DANE/DNSSEC.

> so a binding to a key digest (given a strong digest) is just as

That's right.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 27 Jun 2014 21:57:21 -0400 (EDT)

On Wed, 25 Jun 2014, Michael Richardson wrote:

> I found reading the document difficult as it contained too

I agree. I had proposed some alternative text for John. I'll see if we
can figure out a way to make it more readable without the document being
a checklist of corrections for another document.

Paul