Subject: [dane] Extending TLSA RFC to operate with TLS's new raw public keys

From: John Gilmore <[email-masked]>
Date: Thu, 29 May 2014 01:05:17 -0700

The TLS Working Group is in the final stages of approving RFC 7250,
"Using Raw Public Keys in TLS/DTLS":

  https://www.rfc-editor.org/authors/rfc7250.txt

The draft modifies the TLS protocol to allow clients and servers to
negotiate and exchange types of authentication material other than
PKIX certificate chains, and defines a format for exchanging a raw
public key.  These public keys are authenticated "out of band",
outside the TLS protocol, for example by prior administration (in some
Internet-of-Things cases), or by the use of DANE.  Paul Wouters was
the main author, and the protocol and document were significantly
improved by several co-authors from the TLS WG.

In reviewing the draft, I noticed that it doesn't ever describe how
you store such a public key in a TLSA record.  And the TLSA RFC 6698
explicitly specifies that TLSA records can ONLY store PKIX
certificates!  The relevant sections are:

RFC 6698 Sec. 1.3:

   This document only applies to PKIX [RFC5280] certificates, not
   certificates of other formats.

RFC 6698 Sec. 2.1.1:

   The certificate usages defined in this document explicitly only apply
   to PKIX-formatted certificates in DER encoding [X.690].  If TLS
   allows other formats later, or if extensions to this RRtype are made
   that accept other formats for certificates, those certificates will
   need their own certificate usage values.

I remember fighting this fight in the DANE WG, and the result was
something along the lines of "We'll narrow the RFC now, and then
if-and-when raw public keys are approved by the TLS WG, then we'll
amend it to include them."  Well, the time has come.  Raw public keys
are approved by the TLS WG.  The trouble is that nobody has bothered
to amend the TLSA RFC, so the new draft RFC tells people "just use
DANE", but the DANE TLSA RFC says, "No you can't".

I propose to add some text to the draft RFC 7250 that extends RFC 6698
by defining how raw public keys are stored in TLSA records.

My coauthors seem to prefer that we just ignore the entire issue,
issue RFC 7250, and ignore the conflict between the two.  As someone
who learned most of what I know about protocols (and the Internet)
from reading Saint Jon Postel's clearly written RFCs, I would hate to
inflict that on future readers.  We should not release documents that
contain deliberate incompatabilities.

We think RFC 7250 is ready to go except for this remaining issue.  It
has been approved by the TLS WG, the IESG, the RFC Editor, and all the
co-authors but me.

Here's my proposed wording change for RFC 7520.  Improvements welcome.
Start from this version:

  https://www.rfc-editor.org/authors/rfc7250.txt

Section 4.4.
OLD (entire section):
   When the TLS server has specified RawPublicKey as the
   server_certificate_type, authentication of the TLS server to the TLS
   client is supported only through authentication of the received
   client SubjectPublicKeyInfo via an out-of-band method.

NEW (entire section):
   When the TLS server has specified RawPublicKey as the
   server_certificate_type, authentication of the TLS server to the TLS
   client is supported only through authentication of the received
   client SubjectPublicKeyInfo via an out-of-band method.

   In order to support out-of-band authentication via DANE [RFC6698],
   this document extends the DANE TLSA record definition to allow such
   records to describe raw public keys as well as PKIX [RFC5280]
   certificates.  This extension does not define any new field values;
   it merely defines how existing fields are processed when being
   matched to raw public keys provided by TLS servers.

   A raw public key is represented in a TLSA record by specifying a
   certificate usage of 3 (domain-provided), a selector of 1
   (SubjectPublicKeyInfo), and a matching type of 0.  The
   SubjectPublicKeyInfo that holds the public key is placed in the
   certificate association data.  Matching types other than 0 may also
   be used, by placing the corresponding hash value into the
   certificate association data.

   DANE [RFC6698] section 1.3 is extended to say:

      This document only applies to raw public keys and to PKIX
      [RFC5280] certificates, not certificates of other formats.

   DANE section 2.1.1 is extended to say:

      The certificate usages 0, 1 and 2 defined in this document
      explicitly only apply to PKIX-formatted certificates in DER
      encoding [X.690].  If TLS allows other formats later, or if
      extensions to this RRtype are made that accept other formats for
      certificates, those certificates will need their own certificate
      usage values.

   In DANE section 2.1.1, in addition to the definition of certificate
   usage 3 with TLS servers that use PKIX certificates, certificate
   usage 3 may also be used with TLS servers that use raw public keys:

      3 -- Certificate usage 3 is also used to specify a raw public key
      that MUST match the raw public key presented by the server in
      TLS.  When the TLS server provides a raw public key, there is no
      PKIX certificate and no PKIX validation is done; the TLS
      server's raw public key MUST match the raw public key provided in
      the TLSA record.  This certificate usage is sometimes referred
      to as "domain-issued" because it allows a domain administrator
      to directly certify a domain's public keys.

I believe that this wording reflects the up-to-now tacit consensus on
how the DANE WG expects TLS raw public keys to be represented and
processed in TLSA records.  In the absence of significant dissent or
further improvements, I propose to provide the above updates to the
RFC Editor and release the new RFC.

	John

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 29 May 2014 07:00:21 -0700

On May 29, 2014, at 1:05 AM, John Gilmore <[email-masked]> wrote:

> amend it to include them."  

Yep. That is still the plan.

> Well, the time has come.  Raw public keys

Anyone could have started the process for an update to 6689 to reflect this. They haven't yet.

> by defining how raw public keys are stored in TLSA records.

That is a horrible abuse of the RFC publication process. That is, instead of you asking for IETF review of your idea, you are trying to slip in a significant technical change with no community review.

> issue RFC 7250, and ignore the conflict between the two.  

What conflict? DANE is clearly defined. If you want to update the definition (and many of us would support that), write the one-page Internet Draft to do so.

> As someone

And you are not.

> RFC Editor and release the new RFC.

As co-author of RFC 6689, I fully disagree. The correct way to update RFC 6698 is with a new RFC that has community review.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 29 May 2014 14:16:27 +0000

On Thu, May 29, 2014 at 01:05:17AM -0700, John Gilmore wrote:

> you store such a public key in a TLSA record.

I think there is an obvious format, that should be spelled out
explicitly in some suitable document.  Namely the same format as
for the SPKI of a leaf certificate with any supported matching
type:

    ; Match SPKI of a certificate or just the bare public key
    _25._tcp.mx1.example.com IN TLSA DANE-EE(3) SPKI(1) ? {blob}

DANE TLS clients that also support the new TLS oob public key
extension can include it in their client HELLO, provided every RR
in the TLSA RRset is a "3 1 X" RR (they must perform the DNS lookup
before client HELLO).  If any of the RRs have a different usage,
then a full leaf certificate may be required, and the client MUST
NOT signal oob public key support (since the client would potentially
be unable to match a subset of the TLSA records, which may the
currently active configuration).

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 29 May 2014 12:59:06 -0400 (EDT)

>    _25._tcp.mx1.example.com IN TLSA DANE-EE(3) SPKI(1) ? {blob}

Where is this not clear in the existing DANE RFCs?

> currently active configuration).

Can you explain why that is needed? I would envison people to migrate
from full certs to bare keys to have both available in their TLS server
and in their TLSA record set.

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 29 May 2014 18:03:56 +0000

> Where is this not clear in the existing DANE RFCs?

Per John's note, the existing RFCs specifically exclude bare SPKI,
though otherwise I agree, the mapping is fairly natural/obvious.

> and in their TLSA record set.

The server will indeed have full certs and corresponding or
independent bare keys.  However all the TLSA RRs MUST be "3 1 X"
RRs (matching all the deployed certificates and public keys),
or else clients MUST NOT indicate support for "oob public key".

The point being that the client does not know which TLSA RRs are
"live" and which are "legacy" as a result of key rotation.  If all
the "3 1 X" records are legacy, and only "3 0 1" or "2 0 1" RRs
are "live", the client will fail to authenticate the server if it
learns only the public key of the live leaf certificate.

A client that negotiates "oob public key" can only learn the
server's leaf SPKI, so this needs to be sufficient to perform
authentication, which is only true when *all* the authentication
records are "3 1 X".

-- 
	Viktor.

---

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

> Per John's note, the existing RFCs specifically exclude bare SPKI,

I think that's still up for discussion. But your above comment made it
appear you thought something else was missing, something about leaf
certificates and selector SPI?

> or else clients MUST NOT indicate support for "oob public key".

A client can indicate support for oob public key that is not based on
DANE.

> "live" and which are "legacy" as a result of key rotation.

Why does that matter? the client receives either the server's full
certificate or its 'bare key certificate'. It looks throug the list of
obtained TLSA records and looks if anything matches. It does not need
to prove every TLSA record is valid.

Also, all TLSA records are "live", and I don't understand your
terminology of "live" versus "legacy" at all.

>  If all

If the client only has a bare public key of the server and the TLSA record
is only "2 x x" the setup is broken. sure. Don't do that? If there is a
"3 x x" TLSA record, there is no issue.

If the client has the full public cert of the server, then any of the
certificate usage TLSA types could be used, and there is no issue.

> authentication, which is only true when *all* the authentication

Why isn't only _one_ TLSA record of type "3 1 x"  good enough? Why can't
the admin publish a "3 1 x" and a "1 x x" or "2 x x" ?

So you brought up John's point (which all centers around "can we call a
ASN.1 SPKI a 'certificate'") and a new issue which I completely don't
understand why it is an issue.

Paul

---

From: John Gilmore <[email-masked]>
Date: Thu, 29 May 2014 23:16:58 -0700

> That is a horrible abuse of the RFC publication process. That is, instead of you asking for IETF review of your idea, you are trying to slip in a significant technical change with no community revi…

Hi Paul, nice to see you.

If I had wanted to slip something past the DANE WG without IETF
review, why would I post the above message to the DANE WG?

I am *asking* for review by the DANE WG.  Not circumventing review.  I
saw an issue that the DANE WG should know about, in an RFC from a
different WG, and I brought it to the DANE WG's attention.  Is there
something wrong with that?

Is your complaint that you want a few-paragraph DANE RFC that makes the
update, rather than a few paragraphs in the TLS Raw Public Keys RFC?
I.e. is this a turf battle over which WG gets to claim the document?

Or, do you have an actual, substantive, technical issue with the
proposed extension of the DANE TLSA records?

	John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 30 May 2014 14:07:56 +0000

> A client can indicate support for oob public key that is not based on

Yes, of course.  But if the client intends to perform DANE
authentication, it should not preclude verification via any RRs
that require a full certificate chain.  In practice, server RRs
for servers that want to support the new TLS extension will be all
"3 1 X" for both "active" and "legacy" keys, but (DANE-aware)
clients will need to be prepared for exceptions.

> certificate or its 'bare key certificate'. It looks through the list of

There may be no records that match the SPKI of the active public
key.  You're not thinking sufficiently clearly about the full TLSA
record lifecycle, key rotation, changes in usage/selector over
time, ...

> terminology of "live" versus "legacy" at all.

Not all server keys are "live" some will refer to the previously
fielded key, to accomodate key rollover.

> "3 x x" TLSA record, there is no issue.

Not true, firstly because it needs to "3 1 X" not "3 X X", but also
because even "3 1 X" may describe a stale configuration that is no
longer active.

> the admin publish a "3 1 x" and a "1 x x" or "2 x x" ?

Because there is no guarantee that that particular RR still matches
the server's chain.  All we know is that *some* RR is supposed to
match the chain, during key rotation, some do not.

The ones that do not might be "legacy" or might be "future" (keys
that are no longer deployed, or keys soon to be deployed).

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 30 May 2014 14:15:16 +0000

> proposed extension of the DANE TLSA records?

Turf wars aside, either the TLS extension document could document
the DANE implications (including the point about when it is safe
to signal "oob public key" when the client intends to use DANE
auth) or a new DANE draft gets to document the TLS implications
(including that same point).

So some overlap is unavoidable.  For example, the SMTP and OPS
drafts already talk about requiring "2 X Y" trust anchor certs in
server_certificate TLS messages, these are optional with PKIX.

My gut feeling is that since the issue applies only to clients for
which "oob" means "DANE", there should at least be a DANE WG document
that covers this perhaps among other topics.

Would it be a problem if this got covered consistently in multiple
documents?  From the perspective of an implementor it would be
helpful to see this covered in which-ever document I happened to
be reading when adding bare public key support.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 May 2014 14:28:33 -0400 (EDT)

> be reading when adding bare public key support.

The bare public key document could refer to an ERRATA for 6698 that
states an ASN.1 SPKI structure is to be considered a "PKIX certificate"
in the context of TLSA certificate usage selectors?

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 30 May 2014 18:44:03 +0000

> in the context of TLSA certificate usage selectors?

Two problems with that:

    * The ERRATUM will likely be rejected, because the restriction was
      intentional.

    * This is the obvious part of how to use "oob public key" with
      DANE, and need hardly be explained.  The non-obvious part is the
      need to only signal "oob public key" support in the client
      when server's TLSA RRs contain *only* "DANE-EE(3) SPKI(1) ?"
      records.  I'll leave to the authors of that draft to decide
      whether that should be explained in their draft, or in a
      suitable separate DANE WG document.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 May 2014 14:50:17 -0400 (EDT)

>    * The ERRATUM will likely be rejected, because the restriction was

There is/was no restriction. It is a clarification. Note that the
certificate type 3 explicitely excludes "PKIX validation" to allow for
a 'certificate' containing just a SPKI, and now what normal "PKIX
validation" would deem as "minimal required".

>      records.

This is the third time you mention this and the third time I have to ask
you why. It is perfectly normal to NOT HAVE TLSA RECORDS and rely on a
firmware public key, and still signal and use "oob public keys". Please
try and explain why you are trying to add restrictions on the set of
TLSA records to support "oob public key" (which can happen on its own,
along with regular full cert support, with or without DANE)

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 30 May 2014 19:03:20 +0000

On Fri, May 30, 2014 at 02:50:17PM -0400, Paul Wouters wrote:

> you why.

That is, the third time you've failed to understand. :-(

The context as stated before, is clients for which "oob" means DANE
auth, and the restriction is for that case only.

> Please

Clients for which DANE auth is the authentication mechanism MUST
NOT exclude any "usable" TLSA RRs from the potential set of matching
records by negotiating "oob public key" which is only compatible
with "3 1 X".  The reason, as before, is that there is no a-priori
way to determine which subset of the TLSA RRs is sufficient to
authenticate the server.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Fri, 30 May 2014 15:02:22 -0400

Some thoughts on this:

A 3 0 0 tlsa will work as well as a 3 1 x.  The client can pull the spki
out on its own.

I find both possibilities,  incorporation in the tla rfc or a new rfc
from us equally accecptable methods of publication.  As long as our
input is reflected.

It is not that *all* tlsas need to be limited just because the server
supports the oob methods.  Rather, *at least one* of the published tlsas
must be usable (3-0-0 or 3-1-x and secure in this case) and match.

Should a different kind of bare key show up, one which doesn't look like
the spki blob expected by x-1-y tlsa (openssh keys would be interesting),
we can publish an rfc defining matching type 2.  But given:

,----< excerpt from draft-ietf-tls-oob-pubkey-11.txt >
| namely, the SubjectPublicKeyInfo structure of a PKIX certificates
| that carries the parameters necessary to describe the public key.
`----

we do not need match 2 for this.

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 30 May 2014 19:28:40 +0000

> A 3 0 0 tlsa will work as well as a 3 1 x.  The client can pull the spki

Not true.  When the server presents only the SPKI (no certificate
wrapped around it), the client cannot magically reconstruct the
enclosing certificate.

> must be usable (3-0-0 or 3-1-x and secure in this case) and match.

Not true.  If the server's "3 1 x" RRs reflect only keys that were
active in the past, or only keys that will be active in the future,
while the currently active certificate key matches other TLSA RRs
((usage, selector) != (DANE-EE(3), SPKI(1)) then the client loses
if it negotiates "oob public key" and server only presents a leaf
SPKI instead of a leaf cert.

I wish folks would take a moment to think this through, it is not
that hard.  If you still don't see it, you've not thought about it
hard enough yet.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 30 May 2014 19:50:47 +0000

> wrapped around it), the client cannot magically reconstruct the

Oops, sorry, yes as a special case "3 0 0" still works.  I tend to
block the the mtype 0 TLSA RRs from my mind.

So indeed the "oob public key" compatible RRs are:

	3 0 0
	3 1 X

-- 
	Viktor.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 30 May 2014 16:05:38 -0700

John Gilmore <[email-masked]> writes:

>> That is a horrible abuse of the RFC publication process.
>
...
> I am *asking* for review by the DANE WG.

Another option: put a note about it in the dane-ops draft, which was
discussed at the last WG meeting as potentially being more than an -ops
document in the first place (extending DANE not just defining
operational characteristics).  We're over due for getting that out the
door too.
-- 
Wes Hardaker
Parsons

---

From: James Cloos <[email-masked]>
Date: Fri, 30 May 2014 19:43:06 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

>> A 3 0 0 tlsa will work as well as a 3 1 x.  The client can pull the spki

VD> Not true.  When the server presents only the SPKI (no certificate
VD> wrapped around it), the client cannot magically reconstruct the
VD> enclosing certificate.

Yes true.  When the server presents the SPKI, and the tlsa has the whole
cert, the client can extract the spki from the tlsa-provided cert and
compare them.  That is no different from the case where the server
presents a whole cert but the tlsa match type is 1.  Either way the
client needs to know how to extract an SPKI from a cert.

>> must be usable (3-0-0 or 3-1-x and secure in this case) and match.

VD> Not true.  If the server's "3 1 x" RRs reflect only keys that were
VD> active in the past, or only keys that will be active in the future,
VD> while the currently active certificate key matches other TLSA RRs
VD> ((usage, selector) != (DANE-EE(3), SPKI(1)) then the client loses
VD> if it negotiates "oob public key" and server only presents a leaf
VD> SPKI instead of a leaf cert.

That is irrelevant.  Config errors like that will happen w/o oob just as
much as with.  And clients need to decline then, too.  The fact that an
oob client which expects to use tlsa to validate the spki needs a tlsa
which works with that should be noted, but we (the wg) don't need to
do any more than mention it.

-JimC

---

From: James Cloos <[email-masked]>
Date: Fri, 30 May 2014 19:44:27 -0400

>>>>> "WH" == Wes Hardaker <[email-masked]> writes:

WH> Another option: put a note about it in the dane-ops draft, which was
WH> discussed at the last WG meeting as potentially being more than an -ops
WH> document in the first place (extending DANE not just defining
WH> operational characteristics).

That sounds like a valid compromise.

-JimC

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 31 May 2014 01:10:48 +0000

> do any more than mention it.

It is not a configuration error, rather a valid transition state,
that clients must support.  With DANE, I don't expect clients to
be statically configured for each "oob public key" destination.

Rather, clients will be capable of "oob public key" support, and
of DANE, and will use the two in combination when it makes sense.
Thus, if a client sees only "3 1 X" or "3 0 0" TLSA RRs, and using
DANE for authentication, it can go ahead and use "oob public key".
If the TLSA records don't include any of the above, or are mixed,
the client must not negotiate "oob public key".

The idea is that clients will offer "oob public key" when possible,
which might lead to wide-scale use of the extenion.  Otherwise, it
is just a curiousity.

-- 
	Viktor.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 30 May 2014 18:35:06 -0700

-----Original Message-----
From: dane [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
Sent: Thursday, May 29, 2014 7:16 AM
To: [email-masked]
Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public
keys

> you store such a public key in a TLSA record.

I think there is an obvious format, that should be spelled out explicitly in
some suitable document.  Namely the same format as for the SPKI of a leaf
certificate with any supported matching
type:

[JLS] That may be one obvious format.  I think that an even better format
would be to define a new TLSA certificate type so that the client will know
that an OOB bare key is what is coming.   Thus

    ; Match SPKI of a certificate or just the bare public key
    _25._tcp.mx1.example.com IN TLSA DANE-BARE-KEY(4) SPKI(1) ? {blob}

This means that there is no overlap between those that are planning to do
PKIX and those that are planning to do bare keys both in the filtering of
the information and publishing of the data.  Both could be offered, and the
DANE query would allow a client to know that OOB is going to be acceptable.

Jim

DANE TLS clients that also support the new TLS oob public key extension can
include it in their client HELLO, provided every RR in the TLSA RRset is a
"3 1 X" RR (they must perform the DNS lookup before client HELLO).  If any
of the RRs have a different usage, then a full leaf certificate may be
required, and the client MUST NOT signal oob public key support (since the
client would potentially be unable to match a subset of the TLSA records,
which may the currently active configuration).

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 31 May 2014 02:41:34 +0000

>     _25._tcp.mx1.example.com IN TLSA DANE-BARE-KEY(4) SPKI(1) ? {blob}

This I think adds no value over DANE-EE(3) and needlessly makes
server operators publish two records where one will do.

It should be possible for clients to offer the new TLS extention
when it is compatible with the server's TLSA RRs and to authenticate
the server either based on a full X.509 cert or a bare SPKI.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Sat, 31 May 2014 14:58:08 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> If the TLSA records don't include any [3-0-0 or 3-1-x], or are
VD> mixed, the client must not negotiate "oob public key".

That is a valid point, but if they are mixed, the clients can try, and
if the offered key doesn't match the suitable tlsas, it can drop the
connection and try again without specifying the extension.

When properly configured, if the server's only current cert(s) is full,
then the server should not agree to the tls extension.  The need to drop
and restart should be rare.

-JimC

P.S.  Sorry for replying yesterday before I read your corretion re 3-0-0.
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 31 May 2014 19:37:08 +0000

> connection and try again without specifying the extension.

To what end?  The server recently had, has now or soon will have
TLSA records that require full certificates.  The server should be
able to offer a matching certificate, containing a suitable key.

I am not a fan of various fallback schemes and associated downgrade
attacks.

> and restart should be rare.

The need for the client to not offer "oob public key" will also be rare,
generally servers won't have mixtures of different C/U values across
key rollover.  Some sites will have only "2 0 1" records:

    ;; Key rollover state:
    ;; Current and either future or recent past associated data
    example.com. IN TLSA DANE-TA(2) Cert(0) SHA2-256(1) {blob1}
    example.com. IN TLSA DANE-TA(2) Cert(0) SHA2-256(1) {blob2}

while other sites will have only "3 1 1" records:

    ;; Key rollover state:
    ;; Current and either future or recent past associated data
    example.com. IN TLSA DANE-EE(3) SPKI(1) SHA2-256(1) {blob1}
    example.com. IN TLSA DANE-EE(3) SPKI(1) SHA2-256(1) {blob2}

and the mixed cases will only be seen briefly in transition between
the two models.  That said, transitions should not be disruptive.

A client that sees:

    ;; Trust model rollover state:
    ;; Current and either future or recent past associated data
    example.com. IN TLSA DANE-TA(2) Cert(0) SHA2-256(1) {blob1}
    example.com. IN TLSA DANE-EE(3) Cert(1) SHA2-256(1) {blob2}

has no idea whether the "3 1 1" record is sufficient for authentication,
and should simply not offer to negotiate bare public keys (unless it
it is statically configured to authenticate these by other means, and
the DANE records are largely out of scope).

-- 
	Viktor.