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

From: Tom Gindin <[email-masked]>
Date: Sun, 1 Jun 2014 22:04:13 -0400

Paul:

        On a technical, or at least quasi-technical point, doesn't usage 3 
say that it must match the "end-entity certificate given by the server in 
TLS"?  That suggests to me that TLSA might need DANE to support another 
usage (perhaps 4), which matches a bare public key as given in RFC 7520. 
This is my first post to DANE, so please forgive me if I'm missing some of 
the history.
        DANE surely should accomodate TLSA, but changing statements about 
extensibility in the existing document to their opposites does not seem 
like the best way to do that.  A revision to 6698 should presumably leave 
the current last sentence of 2.1.1 accurate as it applies to usages 0-3, 
to avoid breaking any existing code that might rely on it.
        So my proposed certificate usage values are:
0       Issuer
1       Server Certificate - to be fully validated
2       Trust Anchor
3       Server Certificate - may be self-signed, no chain validation
4       Public Key
        Certificate usage 4 is used to specify a certificate, or the 
public key of such a certificate, that MUST match the public key given by 
the server in TLS or TLSA.  Unlike  certificate usage 3, this usage 
implies that the server supplies a key with neither validity dates nor 
name in the session negotiation.

Tom Gindin, CISSP
P.S.    The opinions above are mine, and not necessarily those of my 
employer.

From:   Paul Hoffman <[email-masked]>
To:     John Gilmore <[email-masked]>
Cc:     [email-masked]
Date:   05/29/2014 10:01 AM
Subject:        Re: [dane] Extending TLSA RFC to operate with TLS's new 
raw public keys
Sent by:        "dane" <[email-masked]>

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

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

Yep. That is still the plan.

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

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

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

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.

> My coauthors seem to prefer that we just ignore the entire issue,
> 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
> 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.

And you are not.

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

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
_______________________________________________
dane mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dane

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 Jun 2014 02:27:33 +0000

On Sun, Jun 01, 2014 at 10:04:13PM -0400, Tom Gindin wrote:

> On a technical, or at least quasi-technical point, doesn't usage 3 say
> that it must match the "end-entity certificate given by the server in 
> TLS"?

Usage DANE-EE(3) with selector SPKI(1) matches the subject public
key info of the peer.  While as specified in 6698 this SPKI is
expected to be adorned in X.509 finery, it is a natural extension
to allow the same association to apply to bare public keys.

There is simply no need for a new certificate usage here (one for
which selector 0 would make no sense).  Indeed it would force
server operators to needlessly publish the SPKI digest twice:

	example. IN TLSA 3 1 1 {blob}
	example. IN TLSA 4 1 1 {blob}

for no good reason.

> name in the session negotiation.

Those qualifications already apply to usage 3 (ops draft document
which specifies this to be published soon), with SPKI(1), DANE-EE(3)
is already a bare key usage, just sometimes embedded in an X.509
cert.  There is no need for a usage 4 (yet), at least not for this
use-case.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 02 Jun 2014 15:14:31 +0100

Folks,

Can we try get this one settled soon, at least in terms of
any changes to draft-ietf-tls-oob?

The core WG have been waiting on that for quite a while as
its a normative dependency for CoAP.

(So, dane WG chairs - if you could propose a consensus call
for the action to take that'd be great and we can move on.)

Cheers,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 Jun 2014 14:52:15 +0000

> for the action to take that'd be great and we can move on.)

Could you perhaps restate the questions to be considered?

    I think John Gilmore posed two questions:

    * What is the representation of oob public keys in DANE TLSA
      records.  Proposed "3 1 X".

      [FWIW I support this view, with the added observation from
      James Cloos that "3 0 0" can also match raw public keys via
      the enclosed SPKI value].

    * What document should define this representation, and amend
      the restrictive language in 6698 Section 1.3:
	
	   This document only applies to PKIX [RFC5280] certificates, not
	   certificates of other formats.

      and extend the definition of usage 3 or some new [ideally not]
      usage to handle raw public keys.

Are these the right questions?

[ Turf issues aside, there seems to be enough subtle detail in getting
this right that it seems to me that a new DANE WG document, quite possibly
whatever we call the current "ops" draft by the time November rolls around,
is the right place to define this mapping. ]

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 2 Jun 2014 12:53:17 -0400 (EDT)

> to allow the same association to apply to bare public keys.

Not only the natural extension, it was added specifically to accomodate
bare public keys in the future/

> 	example. IN TLSA 4 1 1 {blob}

I agree. One TLSA that covers the SPKI should work for TLS servers that
give out a bare public key or an EE cert.

I'm okay with WH' suggestion of putting this in the soon to be dane ops
document, or with an ERRATA to 6698 or with a new one page RFC.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 Jun 2014 17:29:22 +0000

>       the enclosed SPKI value].

In whatever document ends up publishing the details,  I would say:

    TLS clients that support out of band public keys ([TLS WG
    document reference]) authenticated via DANE TLSA records SHOULD
    NOT employ the "oob public key" TLS extension unless all the
    server's TLSA records are compatible with out of band public
    keys.  The client SHOULD send an SNI extension with the server's
    TLSA base domain even if it is willing or expecting to use out
    of band public keys.

    [ Rationale. ]

    Compatible TLSA records include all records with certificate
    usage DANE-EE(3) and selector SPKI(1) with any matching type.
    Clients MAY also elect to treat records with usage DANE-EE(3),
    selector Cert(0) and matching type Full(0) as compatible,
    provided they are willing and able to extract the public key
    from such a TLSA record for comparison with the server's bare
    out of band public key.

For the server side, I would add:

    Servers that support "oob public key" MAY employ SNI to select
    the correct public key, either by identifying a matching 
    certificate from which to extract the key, or via some other
    mapping from the requested domain to the corresponding key.

-- 
	Viktor.

---

From: John Gilmore <[email-masked]>
Date: Mon, 02 Jun 2014 13:41:56 -0700

>     usage DANE-EE(3) and selector SPKI(1) with any matching type.

TLS servers that offer raw public keys should not restrict their TLSA
records to only those that match raw public keys.  This is not only
unnecessary, but harmful.  It harms interoperability, and it dents the
general applicability strategy of TLSA records, which is that clients
look through the set of returned TLSA records for the one(s) that are
relevant to their current negotiation.

Raw public key support is *negotiated* by the TLS server.  In the
general case, it will likely offer both raw public keys and PKIX
certificates, and the client will choose which option it likes.  So
that the transaction can complete authentication regardless of which
option the client chooses, the server's domain name zone should be
free to publish TLSA records that match raw public keys, TLSA records
that match PKIX certificates, or both.

The TLS server itself should always be free to offer any kind of
authentication that it supports.  The raw public keys draft already
says that it should only offer to negotiate certificate types that it
actually both supports and possesses a relevant key for; that is all
the constraint that needs to be placed on the TLS server.

I do not understand the reference to SNI.  Why is there any greater
need to send an SNI option than in any other TLS negotiation?  Is
there something to say here that wasn't already said in RFC 3546 or
RFC 6066?  e.g. RFC 3546 page 10:

   It is RECOMMENDED that clients include an extension of type
   "server_name" in the client hello whenever they locate a server by a
   supported name type.

   A server that receives a client hello containing the "server_name"
   extension, MAY use the information contained in the extension to
   guide its selection of an appropriate certificate to return to the
   client, and/or other aspects of security policy. 

>     from such a TLSA record for comparison with the server's bare

I think this is a bad idea.  If the TLS server offers a raw public
key, it should not try to authenticate it via a TLSA record that
contains a PKIX certificate.  The intent of raw public keys is to
allow simpler (need I say easier to debug and more secure) clients
that don't need to parse, let alone validate, a PKIX certificate.
This just complicates clients for no gain in interoperability.

There is no gain in interoperability because, if matching a raw public
key in a PKIX certificate is OPTIONAL, then clients can't be depended
upon to extract a key from a PKIX certificate in order to authenticate
the key.  This means that server zones will have to publish a real raw
public key in a TLSA record anytime they want to have interoperability
with raw public key clients.  Given that the server zone must in
practice publish a real raw key, suggesting that clients should
optionally match against a (second) TLSA record containing a
complicated PKIX certificate is a burden without any gain.

>     mapping from the requested domain to the corresponding key.

I think that where the server's public key comes from is irrelevant to
the protocol.  It could have been extracted from a PKIX certificate,
it could have been generated by rolling dice, it could have come from
divine inspiration, thermal noise, or the Linux filesystem.  Why would
we suggest one particular method?

If the point is that the Server Name Indication option sent by the
client might affect the offered key, that's a point.  But the same is
even more true of the offered PKIX certificate in traditional TLS, so
if we feel the need to say this, why aren't we already saying it about
PKIX certificates?

	John

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 Jun 2014 21:13:54 +0000

On Mon, Jun 02, 2014 at 01:41:56PM -0700, John Gilmore wrote:

> records to only those that match raw public keys.

There are no such records.  Records of the form "3 1 X" also match
leaf certificates.

> It harms interoperability, and it dents the

This is not compatible with key rotation or other transitions
between past/present/future TLSA records which result in a subset
of the TLSA records being "active" (matching the server's actual
keys) and another subset being "inactive" (matching either past or
future keys).

Clients MUST be willing to process all TLSA records, or else should
not expect DANE authentication to work.

> certificates, and the client will choose which option it likes.

That's fine "3 1 X" records are compatible with both, but the
presence of records with any other known certificate usage or "3
0 X" records (with the possible exception of X == 0) needs to
suppress client use of oob public keys when the client's "oob"
authentication strategy is DANE.

> So

That's what "3 1 X" records do.  Other records only work with PKIX,
and since these may be the only "active" ones (the mythical
[Rationale] in short form) the client should assume the worst and
not negotiate its way into a dead-end whereby authentication fails.

> authentication that it supports.

Yep, that's fine.

> RFC 6066?  e.g. RFC 3546 page 10:

Some mention of interaction with SNI is perhaps redundant, but IMHO
useful.  Mentioned only because some might think that SNI is only
for certificates and is obviated by "oob" keys, but it is not.

> key, it

["it" is the client here]

> should not try to authenticate it via a TLSA record that

Clients MAY decide whether they are willing to transform "3 0 0"
into the contained "3 1 0".  If the WG feel that contrary to the
observation by James Cloose this is a bad idea, I am not particularly
fixated on this corner case.  However, if clients don't map "3 0 0"
to "3 1 0", then the presence of "3 0 0" in the TLSA RRset should
also suppress use of "oob" keys.

> There is no gain in interoperability [...]

Indeed, it is only a gain in opportunities to use the oob extension,
and thereby make the TLS handshake smaller.

> if we feel the need to say this, why aren't we already saying it about

We are already stating that DANE clients need to use SNI in other
contexts.  I just carried this over to "oob" keys too.  The
observation is inessential if it is considered obvious/redundant.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 3 Jun 2014 01:04:55 -0400 (EDT)

>    TLSA base domain even if it is willing or expecting to use out

Again, I don't see why. If there is one TLSA record that matches the
public key of the server, that's good enough. If you do any kind of TLS
key rollover, the TLS admin better pre-publish the proper TLSA records.

Saying that all TLSA records should be of a type compatible with oob
serves no purpose and could hinder deploymentment of oob TLS.

If a TLS client local policy prefers oob, and it finds only non-oob
compatible TLSA records, it could omit using oob to prevent issues.
But I don't think that is a MUST.

>    mapping from the requested domain to the corresponding key.

I do not see why we need to drag SNI into this. How is SNI different for
bare keys versus certificates? If the client tells the server the SNI,
the server picks the right identity - regardless of the 7250 extension.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 3 Jun 2014 13:08:40 +0000

> key rollover, the TLS admin better pre-publish the proper TLSA records.

Suppose the only one that does is a "DANE-TA(2) Cert(0) SHA2-256(1)".
What then?

	; transition state when updating DNS records prior to new
	; key deployment.
	;
	example.com IN TLSA 3 1 1 {recent past blob}
	example.com IN TLSA 2 0 1 {current blob}

A client that negotiates "oob public key" in this state fails to
authenticate the server.

> serves no purpose and could hinder deploymentment of oob TLS.

Obviously I have a purpose in mind, for some reason it is not
getting through.  I think some others have understood, perhaps they
can have a crack at explaining it to you.

> But I don't think that is a MUST.

We can quibble over MUST vs. SHOULD.  However, and especially
because the point appears to be non-obvious to many, experts
included, it needs to be made.  ALL the TLSA records need to be "3
1 X", possibly also "3 0 0", or else the client SHOULD skip "oob".

> bare keys versus certificates?

It isn't.  I just wanted to spell it out.  DANE clients send SNI, even
if when they use "oob public key".  As in my reply to John Gilmore, if
everyone agrees this is obvious, it is not essential (but harmless, no?).

-- 
	Viktor.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 3 Jun 2014 22:19:20 -0400

John, 
Sorry for the top posting of our main arguments. 
RFC7250 has shipped, please do not hold up the publication. 
We need a quick turnaround to address the issues you identified below. 

As Wes Hardaker commented in a later message we have an “Dane uses and fixes” document in the
queue and adding this to it is appropriate. (dane-ops) 
<more comments inline plan at the bottom> 

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

> The TLS Working Group is in the final stages of approving RFC 7250,
> "Using Raw Public Keys in TLS/DTLS":
> 
> 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 is a major change and specifying how to do other certificate types 
should go through the normal standards process. 
DANE WG is happy to take that on, and this should be processed before we go on to DANE-bis document. 

> 
> 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.
> 
> amend it to include them."  Well, the time has come.  Raw public keys
> DANE", but the DANE TLSA RFC says, "No you can't”.

Lets fix this, based on experience!

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

In the chairs opinion that is a bad idea. 

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

We wish that this had been detected sooner and a corresponding document was in 
the publication queue, we are willing to commit to get this fix ASAP. 

> RFC Editor and release the new RFC.

We think this text is a good starting point, for the OPS document that will update RFC6698

The plan we propose is publish RFC7250 and push the fix out no later than right after the
IETF meeting in Toronto. 

	Olafur & Warren

---

From: James Cloos <[email-masked]>
Date: Tue, 03 Jun 2014 22:23:39 -0400

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

VD> Suppose the only one that does is a "DANE-TA(2) Cert(0) SHA2-256(1)".
VD> What then?

The oob requesting client aborts.  And, perhaps, tries again w/o oob.

Or, if the client also groks oob-via-ldap, it uses the ldap info instead
of the tlsa.

I know (based on your posts) that you don't like that as a possible outcome.  
But for many it is not a big deal.

The RFCs do not need to demand that everyone avoid every possible corner
case.  They instead should explain what occurs when the corners are met.

It is not that we fail to understand the issue, we just don't mind the
possibility that an oob attempt might fail, even where a non-oob wouldn't.

If there are no tlsa records which could work, and if the client can
only do oob via dane, then it should avoid oob for that connection.

If it does not know how to extract an spki from a cert, and every tlsa
which might be for the ee is full cert, then again it should avoid oob.

But if any of the tlsa might be ok, there is nothing wrong with it
trying oob, just in case it might work.

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

---

From: James Cloos <[email-masked]>
Date: Tue, 03 Jun 2014 22:26:37 -0400

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

VD> It isn't.  I just wanted to spell it out.  DANE clients send SNI,
VD> even if when they use "oob public key".  As in my reply to John
VD> Gilmore, if everyone agrees this is obvious, it is not essential
VD> (but harmless, no?).

Just as a point of reference, SNI is irrelevant for all of my tls
servers and their tlsa records.

I'm sure I'm not alone in that.

So I also do not understand why the oob document(s) should need to say
anything about sni.

-JimC

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Jun 2014 02:55:35 +0000

> But for many it is not a big deal.

Authentication unnecessarily failing is indeed a big deal.  There isn't
always a user to click OK, and stateful fallback is a pain to get right
and opens up opportunities for downgrade attacks.

Unreliable authentication protocols that fail even when both sides
are doing everything right are broken by design.

Needless corner cases need to be rounded out.  I am willing to say
"SHOULD" rather than MUST, but otherwise, I am not giving up without
a better argument than "IETF security protocols sport broken corner
case by design" and we're used to it.  Just like we're used to
broken implementations I guess.  I am from a design and implementation
culture where we do it well, or not at all.

The onus to get this corner case avoided needs to be either on the
client or on the server.  The client-side solution is simpler:

    * Avoid "oob public key" negotiation when authentication is
      via DANE and TLSA records may require a full certificate.

The server-side solution is more complex:

    * When publishing any "3 1 X" TLSA records, always publish
      records that match the current leaf keys.  When transitioning
      to/from "3 1 X" TLSA RRs to other usage/selector pairs, change
      one thing at a time.  Either change the keys while keeping
      the set of usage/selector pairs fixed (publishing these for
      both new and old keys during the transition), or else keep
      the keys fixed and publish both new and old usage/selector
      combinations during the transition.

If the group strongly prefers the server-side approach, speak up.
Silence on the issue leads to security protocol implementations
that break for no good reason for a multiple of the TLSA RR TTL.

The OPS draft needs to advise the use of either or both of the
above approaches.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Wed, 04 Jun 2014 03:38:54 -0400

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

Perhaps I worded poorly.  Trying again.

It is OK for some document -- esp if it is a BCP -- to say that doing
certain things can prove problemantic.

But even for a tls client which likes to try oob, and which only uses
dane to verify oob, it is not unreasonable to try oob and if it fails
try normal tls.  Without any need for user clicking, et alia.

That procedure should be rare; it SHOULD only occur when a destination
is changing from supporting oob to not supporting it, and even then
only if the dns got changed before the server's config.

OTOH, multiple types of tlsa can exist for servers which support both
oob and full cert clients.  Such servers may want to specify type 0,
1 or 2 for the full cert clients and type 3 for the oob clients.

I'm an example, in fact.  My web server has a paid cert for
compatibility reasons, and I publish a 111 for it.  Since I'm wasting
money on the cert, full-cert clients might as well pkix verify it.
But since I'm fine with oob, once that becomes available for my sw
I'd be happy to add a 311 to support it.  I'm certain other sites will
have similar objectives.

Avoiding oob in that case makes oob less useful than it might be.
Especially if oob-only clients show up.

Sites like goog may have the same ideas even for their MXs.

Because tlsa mis-configuration should be so rare, it also is OK for a
client which finds itself in such a circumstance to abort completely.
Oob-only clients will have to.

Either way, some alert -- popup, email, syslog, whatever -- is good.
But if the client prefers to retry w/o oob doing so generally should not
require user intervention.  The fact that it occurred is strong evidence
that the site is transitioning away from oob.

VD> Authentication unnecessarily failing is indeed a big deal.

But this particular case should be most unusual.

Most changeovers will follow the add-new-tlsa, change-server-config,
remove-old-tlsa pattern.  Telling clients never to try oob when multiple
tlsas are present means that transitions *to* oob would break if the
middle step is change-server-only-to-do-oob or add-oob-too.

I have no objection to a document explaining to server admins what is
likely to work and what is likely to fail.  And how each potential
failure is likely to present.  And although it seems like miniscule
should is enough when advising admins how best to deploy, I won't argue
against SHOULD in such a document.

But telling clients they cannot TRY, or even SHOULD NOT TRY, just
because a mis-configuration is possible, is too much.

Even if all of the tlsas *are* 31x, there is no guarantee any will
match.  That failure case is really no different than the no-ee-spki-
matches failure case, except that clients which can do both oob and
full could, in the latter case, fall back to full and try again.  That
also might fail.

I should note that I only just considerred the idea of oob-only.  I
think that I've edited that concept into the above missive, but I'm
way too tired to be sure.

-JimC

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Jun 2014 13:58:50 +0100

Thanks Olafur,

Now that the DANE WG are going to address this issue,
I think that means that John can send his approval
for auth-48 for oob and we can move it forward.

Cheers,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Jun 2014 13:44:41 +0000

> only if the dns got changed before the server's config.

If implementors don't think the issue though, they might well fail
and not retry.  I've seen enough "naive" and "cargo cult" code in
this space to be skeptical of likely implementation quality in the
absence of specific guidance.  Thus the OPS BCP should provide
specific guidance, alerting implementors to the issue, and advising
them of the simplest solution (skip oob when somewhat likely to
fail and the client implements use of PKIX certs).

> 1 or 2 for the full cert clients and type 3 for the oob clients.

You may recall my observations about mixing models ("PKIX" vs.
"DANE").

> compatibility reasons, and I publish a 111 for it.

You allowed to needlessly torment users whose trusted CA list does
not include your issuing CA. :-)

> Since I'm wasting

This rationale is generally flawed, because were DNSSEC compromised,
the attacker would replace your 111 with a 311 of his choice.  Thus
the "111" is only useful in applications that refuse to mix models,
and only honour PKIX usages.

It is hard to say what the right policy is for browser-oriented
web sites, there is no application-specific definition of how or
whether browsers are to implement DANE authentication.  RFC 6698
is a generic template for application protocols, and does not
define browser behaviour.

> I'd be happy to add a 311 to support it.  I'm certain other sites will

If you're publishing 311, you obviate the 111 record, unless in fact
some specification appears that mandates PKIX usages in browsers, in
which case your "311" would only apply to some other class of clients.

> Especially if oob-only clients show up.

For single-model clients (those that only support PKIX usages or
those that only support DANE usages) the TLSA RRs for the unsupported
model are "unusable".  I should perhaps have mentioned (and will
in the BCP) that one first discards "unusable" TLSA RRs and only
then considers whether the *remaining* RRs are "oob compatible". 

> Sites like goog may have the same ideas even for their MXs.

Well, for SMTP, their only choices are DANE-TA or DANE-EE.  There
is no reason to mix the two.  The rationale for DANE-TA is operational,
you get to decouple server certificate updates from DNS updates, no
DNS changes for server key rotation:

	_25._tcp.mx1.example.com. IN CNAME dane-ta._tlsa.examle.com.
	_25._tcp.mx2.example.com. IN CNAME dane-ta._tlsa.examle.com.
	...
	_25._tcp.mxN.example.com. IN CNAME dane-ta._tlsa.examle.com.
	dane-ta._tlsa.example.com. IN TLSA 2 0 1 {blob}

if one publishes "311" along with it, all the benefit is lost, and
there is no reason whatever to also publish the "2 0 1".

> Oob-only clients will have to.

I've not introduced "misconfiguration" as a use-case.  All the
corner cases were properly configured.  Servers that need to support
"oob only" clients will need to publish "311" records, if they do
so in combination with other records, only "oob only" clients will
negotiate "oob".  Oob-only clients will find all incompatible TLSA
RRs unusable.  They can't do what I suggest and negotiate X.509
certs, so they are out of scope.

> middle step is change-server-only-to-do-oob or add-oob-too.

This glosses over key details.  For servers that publish only "3
1 X" records, transitions from one set of "3 1 X" records to another
just change the number of "3 1 X" records seen, and nobody suspends
use of "oob".  The only time use of "oob" is discouraged for clients
that support both "oob" and not, is when the transition mixes
(usable) TLSA usage/selector combinations.

> against SHOULD in such a document.

I will expand the advice (already needed for key rotation and digest
agility) for servers that covers how to transition between old and
new key material or TLSA RR types.  The same "product set" approach
combined with "change one feature at a time" indeed reduces potential
impact on clients that implement or honour only a subset of the
published record types.

> because a mis-configuration is possible, is too much.

What you characterize as a misconfiguration is not, unless we define
new server-side obligations.  Transition states are not misconfigurations.

If you are suggesting that the strategy I have in mind for "safe"
TLSA RRset updates is be a mandate, we can discuss that.  If indeed
the server is obligated to avoid non product-set mixed states, then
clients can always expect each C/U/M combination to contain at
least one RR that matches the servers "active" chain.

I've never seen such a requirement stated in any DANE WG document.
I am open to defining such a requirement, and publishing a methodology
for transitions between parameter sets that never violates such a
requirement.

> match.

Now we're talking misconfiguration, that's the server's fault.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 4 Jun 2014 10:22:33 -0400 (EDT)

On Wed, 4 Jun 2014, Viktor Dukhovni wrote:

> (skip oob when somewhat likely to fail and the client implements use of PKIX certs).

It's not "likely to fail" when there is an exising "3 1 x" TLSA record
published!

>> money on the cert, full-cert clients might as well pkix verify it.

And trust one of the 600 (give or take a 100) CAs to not be compromised?
I would argue that if you are using oob, but also want compatibility
with classic X.509 certificates, you should use the same "3 1 x" record,
and ignore all pkix verification.

the only reason to pick something else is if you want the trust anchor
to be a CA and not an EE cert. In which case, why are you doing
oob+dane?

> there is no reason whatever to also publish the "2 0 1".

You can still pin to a single CA for "classic x.509" and pin to a pubkey
for "oob". But you are right in that it is only postponing the
inevitable administration that is needed to publish just TLS public keys
and not legacy CAs.

> The only time use of "oob" is discouraged for clients

Still don't see that :P

> Now we're talking misconfiguration, that's the server's fault.

Leaves me puzzled even more about what you _are_ trying to convey as
the requirement for not mixing "3 1 x" and other types.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Jun 2014 14:44:08 +0000

> It's not "likely to fail" when there is an exising "3 1 x" TLSA record

Sure it is, those record might match only a future or past server
key when other RR parameter combinations are also present.  Unless
we define such transitions as invalid, and publish server-operator
guidelines that place the burden on the server to avoid such states.

Is that the WG's preference?  I can strengthen the key rotation
guidelines in the OPs draft (looks like it is about to morph into
a standards track 6698 update) to require server operators to avoid
transition states in which any of the published C/U/M combinations
match only future or only past keys.  This requires some attention
to detail when updating TLSA RRs, and a tricky process when
switching from "311" to "201":

    1. 311 old self-signed leaf

    2. 311 old leaf + 311 new DANE-TA issued leaf  (wait for 1 to age out
       then deploy new cert chain).

    3. 201 new DANE-TA issued chain (previously published as 311 in step 2).

at each stage there are now C/U/M combinations that don't match
any "active" key.

> the requirement for not mixing "3 1 x" and other types.

Consider the above transition from a 311 self-signed cert to a
DANE-TA(2) issued cert, in which the server operator is in a hurry,
and we've not yet mandated the above process:

    1. 311 old self-signed leaf

    2. 311 old (still active) leaf + 201 planned TA

	(wait for 1 to age out, then activate new chain).

    3.  Drop 311 leaving only 201.

This this, "oob" clients lose at step 2 when the new chain is
activated, but the RRset has "311" only for obsolete keys and a
"201" for the active keys.  Note, this is not a "misconfiguration"
in any sense with respect to 6698, and is not a problem prior to
the introduction of "oob" negotiation.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Jun 2014 15:47:17 +0000

> least one RR that matches the servers "active" chain.

Sorry, the C/U/M abbreviation (created in error) is likely opaque.
I meant:

	U/S/M

	* U = usage
	* S = selector
	* M = matching type.

instead while thinking "certificate usage" I typed C/U/M.  It is
possible (with care) to ensure that server TLSA records always
contain at least one "active" record per U/S/M.  We can recommend
appropriate record management strategies to server operators.

That way no matter which subset of U/S/M values a client either
supports or elects to use, authentication will succeed.

If use of such strategies becomes a *requirement* (failure to do
so is a "misconfiguration), then I'm open to relaxing the client
"oob" constraints from "SHOULD NOT" (under list of conditions) to
"may choose not to" (under list of conditions just in case the
server fails to handle state transitions properly).  Clients that
decide to proceed with "oob" anyway (but are capable of handling
X.509 chains), should then retry without "oob" if authentication
fails.

If on the other hand servers are not required to enforce the above
requirement (each U/S/M contains an "active" record).  Then (under
list of conditions where server's chain is mixed, ...) clients
capable of both "oob" and not "oob" have no reason to go out of
their way to shoot themselves in the foot with "oob" and needing
to fall back.  The "oob" extension in that case is just a minor
optimization that is best skipped when potentially problematic.

-- 
	Viktor.

---

From: "Simon Arlott" <[email-masked]>
Date: Thu, 5 Jun 2014 12:47:58 +0100

>       via DANE and TLSA records may require a full certificate.

If at least one TLSA record is DANE-EE(3) then a full certificate
is not required for that record.

Why do you need to restrict the client behaviour when the other
currently defined record types are also present?

What is the intended behaviour of the oob-capable client when new
TLSA record types are defined? Do those records also cause it to
refuse to do OOB or does it ignore them?

-- 
Simon Arlott

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Jun 2014 15:11:45 +0000

> is not required for that record.

This is false.  Firstly because one cannot match a public key
against a "3 0 [12]" record.  Secondly, because during transitions
between old and new keys which don't preserve the U/S/M combinations
used (old key "3 0 1", new key "3 1 1" not yet deployed) some of the
TLSA records don't match the server's change, and this may be true
for all records with a particular U/S/M combination (until the new
key is deployed).

Due to DNS caching, keys rollover and TLSA record updates are not
synchronized.

> currently defined record types are also present?

Because I've written an i's dotted/t's crossed DANE implementation
and have thought through the details that many folks are glossing
over.  Some are with me on the fine details but suggest that the
client should instead fail and retry.  But then, clients need to
know that they should be prepared to retry without oob if they
prefer that for some reason to suppressing oob.

The text can offer clients a choice.

   * Suppress oob public keys when it might well lead to authentication
     failure with servers rolling over keys and the client can handle full
     cert chains.

  * Otherwise, be prepared for authentication to fail, and retry without
    "oob".

Predicated on the existence of "usable" records other than "3 1 X"
and possibly "3 0 0" if the client is prepared to use that with
oob.

Finally, the WG could decide that servers which publish U/S/M
combinations in their TLSA RRset that contain only future or only
past keys are "misconfigured", and that servers SHOULD NOT do that.
In that case arguably the burden to get this right is on the server
and the client can be let off the hook.

I will also add language to the ops draft explaining how servers
can avoid such problem TLSA records and that they SHOULD do so.
(or at least at that it is strongly RECOMMENDED that they do so).

The rationale is that servers have no knowledge of which combinations
of usages, selectors or matching types are unsupported, administratively
disabled or otherwise unavailable/ignored by the client.  The safest
assumption is that each U/S/M combination might be the only one
supported by a given client, and therefore should always match
current (not future or past) server keys.

Still, I am not sure that server operators will reliably "get the
memo".  And thus client caution is approriate where there is little
to lose by suppressing a minor TLS optimization.

> refuse to do OOB or does it ignore them?

No, "unusable" TLSA records (not recognized by the client that could
never be used for matching whether a full cert chain or a bare key
is negotiated) are ignored first.  The language in the ops draft
will spell this out.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 5 Jun 2014 13:51:27 -0400 (EDT)

>     failure with servers rolling over keys and the client can handle full

You'd have to carefully lay out which kind of failures, eg BOGUS versus
missing "3 1 x" TLSA record.

>  * Otherwise, be prepared for authentication to fail, and retry without

It all seems local policy to me that does not need to be specified in
the document.

> past keys are "misconfigured", and that servers SHOULD NOT do that.

Why does the WG need to decide that? It's simply the case now?

AFAIK, all thoughout DANE the policy is "grab the TLSA RRset - if you
find no usable record, authentication fails".

No one prevents you from writing a TLS client that first checks for TLSA
"3 1 x" records usable for oob before starting a connection, and if you
fail to find these records to start TLS without the oob extension. The
problem I have is your desire to drop oob when finding a non-"3 1 x"
record AND a "3 1 x" record, and argue that the latter record "might be
incorrect and the server admin might not realise this when he updated
the other type of TLSA record and therefor we should not allow mixed
types ever".

> and the client can be let off the hook.

I don't see why this is ever NOT the case.

> current (not future or past) server keys.

For any set of X TLSA records of various types, to rollover you add a
matching X sets of TLSA records with the new pubkey/cert/chain record.

T=1 one set of TLSA records in DNS.
T=2 prepare new certs/pubkeys - add another whole st of TLSA records in DNS.
T=3 wait for 2x TTL
T=4 update the key/cert of the TLS server(s) - Take as long as you want
T=5 all TLS servers only have the new cert/key, so remove the old set from T=1 from DNS

Where in all of this MUST we say "should always match  current (not future or past) server keys."

> And thus client caution is approriate where there is little

That's your personal subjective value judgement. I would say, when the
operator publishes a TLSA record to match SPKI, they are working hard to
get rid of this legacy X.509 container disaster using a very important
new TLS extension.

Restricting the TLSA RRset or pro-actively dropping the oob extension
based on a mixture of TLSA U/S/M records is undesirable, and your
justification of "the admin might make an erorr" is an extremely weak
reason for it.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Jun 2014 18:24:15 +0000

> It all seems local policy to me that does not need to be specified in

Leaving key implementation correctness details out of documents
leads to shoddy non-interoperable implementations.  The issues are
somewhat subtle, and clearly not obvious to many.  My plan is to
explain the issues and offer clients a choice.

> Why does the WG need to decide that? It's simply the case now?

No it is not.  Look at the verification logic in the appendix that
loops over all the records.  There is no expectation that every
TLSA RR reflects current reality, nor can there be.  All that's
required is that *at least one* TLSA record matches the server
chain.  To enable key rotation, some records will not, and there
is no guidance on how to do key rotation in a way that supports
all possible subsets of supported U/S/M values.

> find no usable record, authentication fails".

This leaves all the relevant details to the point of vacuous
irrelevance.  This is a subtle topic that requires attention to
detail.

> The problem I have is your desire to drop oob when finding a non-"3 1 x"
> the other type of TLSA record and therefore we should not allow mixed
> types ever".

Not just "might", will be incorrect a non-trivial fraction of the
time, unless we specify new server-side requirements.

> I don't see why this is ever NOT the case.

Because there is nothing in any DANE document that encourages, let
alone obligates the server to ensure the necessary invariants.
Left to their devices server operators will publish the problematic
RRsets (which cause no obvious problems without "oob").

> matching X sets of TLSA records with the new pubkey/cert/chain record.

Suppose the goal is to switch a TA-issued cert (previous self-signed)
and publish a DANE-EE(2) association, from a current "3 1 1" leaf
cert.  This can't be done while preserving the stated invariant
without a non-obvious intermideate stage in the DNS keys, because
the self-signed initial cert has no TA.

    Initial:

		IN TLSA 3 1 1 {legacy EE blob}

    Intermediate:

		IN TLSA 3 1 1 {legacy EE blob}
		IN TLSA 3 1 1 {EE association for new TA issued chain}

    [switch keys]

    Final:

		IN TLSA 2 0 1 {TA cert blob matching new chain}

While a simple key rotation looks like:

    Initial:

		IN TLSA 3 1 1 {legacy EE blob}

    Intermediate:

		IN TLSA 3 1 1 {legacy EE blob}
		IN TLSA 3 1 1 {new EE blob}

    [switch keys]

    Final:

		IN TLSA 3 1 1 {new EE blob}

> get rid of this legacy X.509 container disaster using a very important

Most operators who publish "3 1 X" will publish *ONLY* "3 1 X" and
my oh-so-subtle comments won't apply.  The deployment of "oob" will
not be in any way reduced.  By making it safer to deploy "oob" (not
causing unnecessary outages) I am on your side.

> justification of "the admin might make an erorr" is an extremely weak

And yet you're simply wrong about that.  Somewhere, either the
client or the server or both need to do some non-obvious things
(that I plan to write down) to make sure DANE works reliably (always
when everyone does what's expected of them and written down).
Authentication protocols that fail in non-obvious corner-cases are
not progress.

The WG can help shift the balance of the burden to either the client
or the server.  My plan is encourage caution on both sides.  The
consequence of caution will be fewer users spending sleepless
nights debugging non-obvious problems while cursing the designers
of the fragile systems they've saddled with supporting.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 5 Jun 2014 14:56:19 -0400 (EDT)

On Thu, 5 Jun 2014, Viktor Dukhovni wrote:

> chain.

Right. Which is why you can have mixes of types/selectors/usage.

> RRsets (which cause no obvious problems without "oob").

TLSA records are not TLS client remote configuration records.

I think it is a bad idea to allow a TLSA record to modify TLS client
behaviour for TLS extensions. TLSA is to authenticate, not to configure.

> 		IN TLSA 2 0 1 {TA cert blob matching new chain}

Why can't I do:

     Initial:

The only requirement is to ensure old TLSA RRsets without the new
TLSA record do not live anywhere in cache anywhere when the new TLS
cert/key/chain is deployed on the server.

> causing unnecessary outages) I am on your side.

Most operators who want to get rid of X.509 containers and uselessly
expiring X.509 certificates (Like Yahoo yesterday?) and wanting to
deploy oob will first use a DANE-EE SPKI on a full cert, and do any kind
of CA/TA based matching anyway?

> (that I plan to write down)

I have no problem writing down the non-obvious. I just disagree with
your proposed TLS client behaviour.

I think we both understand each other's viewpoint. It's time for others
to chime in.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Jun 2014 19:25:33 +0000

> TLSA records are not TLS client remote configuration records.

That claim is not universal.  For a DANE-capable SMTP client TLSA
records actually set a bunch of TLS policy.  The "discovery" vs.
"lookup" non-issue.

> behaviour for TLS extensions. TLSA is to authenticate, not to configure.

Authentication is behaviour.

>  		IN TLSA 2 0 1 {TA cert blob matching new chain}

Well, now before the switch you have a "2 0 1" U/S/M with no active
keys.  A transition in the opposite direction would break with
"oob" clients because it would be the "3 1 1" that matches "future"
keys.  The safe version of the reverse change looks like:

  Initial:

	IN TLSA 2 0 1 {legacy TA blob}

  Intermediate:

        IN TLSA 3 1 1 {EE association for legacy TA issued chain}
	IN TLSA 3 1 1 {future EE blob}

  [switch keys]

  Final:

Had the intermediate listed the original "2 0 1" for the legacy
chain, "oob" clients would lose.

> of CA/TA based matching anyway?

Right, they'll publish "3 1 1", but for some time the actual TLS
handshake will exchange certs containing the SPKI, rather than bare
SPKI.  Eventually clients will start optimizing out the certs.

> your proposed TLS client behaviour.

First correct, then optimized.  Note the definition of "3 1 1"
already (once the SMTP and OPS drafts are adopted) largely ignores
the cert content (names and expiration, re Yahoo).  So the main
difference between now and a future client that uses bare keys is
that the server sends less data from which the client extracts the
SPKI (an optimization).

-- 
	Viktor.

---

From: John Gilmore <[email-masked]>
Date: Thu, 05 Jun 2014 15:27:14 -0700

> try normal tls.

The TLS Raw Public Keys (RPK) draft RFC does not require clients to
retry failed negotiations.  If it should, we had better fix it very
soon, because it is a single approval from publication.

It requires that servers only select RPK if they actively have a key
usable with RPK (they send that key in the same message where they
select RPK).  It currently does not require clients to do the same.

But let's look closer at the protocol negotiation to see where it's
easiest to fix this situation.

Clients that lack software support for PKIX should never offer the
PKIX server certificate type in the TLS negotiation.  Clients that
lack software support for RPK should never offer to negotiate RPK
server certificates in the TLS negotiation.  This is
non-controversial, and is required by RFC 7250.

Should clients that lack any Trust Anchors never propose PKIX server
certificates?  Currently, such clients *do* negotiate PKIX and then prompt
the user to validate the certificate that arrived during the PKIX
negotiation.  (You can verify this by emptying your browser's list of
trust anchors and then accessing an TLS website.)

Should clients that lack any way to validate a RPK never propose RPK?
Since we have no such clients as yet, we could decide this.  For
example, a client may not have a preconfigured public key for this
server, but it may have a DNSSEC resolver and DANE support.  But when
it starts the TLS session, it will probably not know whether there are
any TLSA records that support Raw Public Keys.  It sends its server
certificate format options in the very first message in the TLS
exchange.  So, to positively know whether TLSA records exist and
support RPK, it would have had to begin and finish a DNSSEC TLSA
lookup, and evaluate the results with an eye toward RPK, before
beginning *every* TLS exchange it initiates.  I think we want to avoid
that.

Restating, the situation in question is when the client supports
DNSSEC and DANE, has TLS software support for both PKIX and RPK, and so
does the server, but the published TLSA records may not offer a way to
verify the RPK that the server sends.

In such a situation, Viktor proposes (if I understand his messages)
that the client should offer support for PKIX and RPK server
certificates; that the server should select RPK and send an RPK; that
the client should then do the TLSA lookup, the client should notice
that there is no way to authenticate the RPK it received, and then the
client should terminate the TLS exchange and retry, offering only PKIX
support.  This proposal adds a retry requirement that currently does
not exist in either the TLS RFC or the TLS RPK RFC.

My proposal to handle this situation is that the client should offer
support for PKIX and RPK server certificates; that the server should
select PKIX and send a PKIX certificate chain, the client should then
do the TLSA lookup, and that then the client should then validate the
certificate chain using the TLSA records.

This proposal treats the situation as a server misconfiguration.  If
the server will choose to negotiate RPK but does not have a TLSA
record published that can validate RPK, it is misconfigured.  Clients
are not required to retry in order to attempt to bypass server
misconfiguration.  Persistent client failure will (eventually) alert
the server operator to their error, and they will either fix the
TLS server to not offer a RPK, or will fix the domain to include TLSA
records that authenticate the server's RPK.

	John

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Jun 2014 23:25:09 +0000

> soon, because it is a single approval from publication.

I think that's OK.  It is just DANE authentication "RPK" clients
that need to be aware of the potential reduction in "usable" TLSA
RRs when negotiating "RPK" and either avoid negotiating "RPK" when
authentication might fail, or be willing to retry without "RPK".

Therefore, this seems like a rather DANE-specific issue, to be
defined in a DANE document for interoperability with "RPK", so it
is not obvious that the DANE-specific issues need to be explicitly
stated in the "oob mechanism" independent RPK docuemnt.

There are also timing subtleties, are TLSA records located before
the TLSA handshake or during the handshake once the server provides
key material.  If the latter (which I don't recommend for reasons
that are TMI for this thread), then the client can only retry, it
is too late to suppress RPK in the TLS HELLO.  The short version
is of course that for clients capable of X.509 server gymnastics,
if the TLSA lookup is delayed, then the client might discover
complete lack of any "3 1 X" (or whatever compatible U/S/M applies)
RRs, and will have to retry without RPK simply because the lookup
is too late.

Assuming clients that support both certs and RPK are not silly
about TLSA record lookup timing, the issue becomes moot if there
is a new published requirement on servers to ensure that every
U/S/M combination contains some record that matches the server's
current chain.  I assume there'll be some further discussion about
the merits and sufficiency of such a requirement on servers to
obviate complications for clients.

> certificates?

No, because with DANE server certificates are not necessarily PKIX.
Usages 2/3 don't require any TAs on the client side.  The default
Postfix configuration ignores all system provided TAs, and the TA
list is empty, and yet we do DANE with "PKIX" certificate chains
validated via DANE-TA(2) or DANE-EE(3) TLSA RRs.

> Currently, such clients *do* negotiate PKIX and then prompt

With DANE, authentication of cert chains is possible without any
PKIX CAs.

> Should clients that lack any way to validate a RPK never propose RPK?

DANE makes it possible to validate RPK via DANE-EE(3)/SPKI(1)
associations.  However, there are some subtleties we need not
repeat the details of when the server TLSA RRset is "mixed".

> For
> any TLSA records that support Raw Public Keys.

The tentative consensus here (DANE WG) appears to be that there is no
new TLSA RR type that represents an RPK-specific association.  Rather,

	DANE-EE(3) SPKI(1) MTYPE(0|1|2)

is equally usable to match a public key embedded in a certificate
or a raw public key.

> It sends its server

The DNS lookup is necessary, but the results can be cached for the
TTL in any local resolver, or the application, or both.  Postfix
caches TLSA RRs in the application (for the shorter of the TTL,
100 seconds, or the lifetime of the SMTP delivery agent).

> verify the RPK that the server sends.

[ Or in some corner cases, the client might not be able to tell
whether the server can be authenticated with RPK, unless we place
new requirements on the server.  We can for now collapse this into
the above case. ]

> certificates;

No, that's not my proposal.

I am proposing that the client should have the TLSA records on hand
*before* the handshake, it will always need them after, and doing
the lookup (with whatever caching is applicable) earlier makes
things much easier.  Therefore, I am also proposing that the client
in fact NOT offer RPK to the server, if success to authenticate
the servers TLSA RRset with RPK is a proper subset of case in which
it succeeds had it negotiated PKIX certs instead.

Alternatively, (don't know why this is attractive) the client might
be willing to reconnect and retry.  Finally, if we define server
TLSA RRsets that put clients into this position as "misconfiguration",
then perhaps we can relieve clients of the burden.

> This proposal adds a retry requirement that currently does

I am not at all fond of retries.  I am guessing you're not either.

> certificate chain using the TLSA records.

You're saying that the server should know the sorry state of its
DNS TLSA RRs as seen by the client.  This is likely impractical.
Servers just have key material and do TLS handshakes they are
DNSSEC/DANE agnostic.  They have no idea what mechanism if any the
client is planning to use to authenticate the server's keys/certs.

> If
> record published that can validate RPK, it is misconfigured.

The sentiment is well motivated, but this is likely rather impractical.

> Clients
> misconfiguration.

Again, at the moment, the problem cases are NOT server misconfiguration,
we'd have to define new server configuration requirements to make
it so.  Requirements that burden the server with knowing what
authentication mechanisms clients might be using and with knowing
how their DANE TLSA records are configured, ... are I think not realistic.

Requirements on the content of the TLSA RRs as published are an
option.  I am planning to write up said server requirements as
strong recommendations, but for the moment at least, also publish
client recommendations that scale back "opportunistic RPK" (use of
RPK when either RPK or PKIX are options) when it doubt.  This avoids
retries, and has little impact on use of RPK (in most cases servers
will have either no or only RPK-compatible TLSA RRs).

"Opportunistic RPK" clients should perform TLSA lookups before the
handshake.

> Persistent client failure will (eventually) alert

Perhaps, though initially the volume of clients failing will be
rather low, and server operators will blame the bleeding-edge
clients (it works for everyone else).

-- 
	Viktor.

---

From: John Gilmore <[email-masked]>
Date: Thu, 05 Jun 2014 17:21:44 -0700

> queue and adding this to it is appropriate. (dane-ops) 

Today I read the dane-ops-03 document.  The latest is from February,
which seems rather old.  Also, it is designed to be a Best Current
Practice, and it does not update the DANE TLSA RFC 6698.

It has been argued by an RFC 6698 co-author that only an RFC which
"Updates: 6698" and goes through "the IETF community" and the DANE WG
can amend the strong statements in RFC 6698 that invalidate any
DANE protocol use that doesn't involve PKIX.  He said:
> Under no circumstances should RFC 6698 be updated in the fashion
> that John suggests below. The IETF community did not have an
> opportunity to review the proposed changes, the draft in question
> never mentioned that it would update RFC 6698, and the DANE WG was
> only informed of this during AUTH48.
>
> The authors could, and should, simply do a short Internet Draft that
> updates RFC 6698. Many / most of us would support that.

The Dane-Ops Draft doesn't meet these criteria.  So, either that
co-author would have to recant his previously expressed stance in
order to resolve the "TLSA for raw public keys" issue in the Dane-Ops
Draft; or else Dane-Ops would have to become a standards-track
protocol spec, not a BCP.  Perhaps if the WG agrees with this
co-author, the only thing is to ignore Dane-Ops and instead write a
new 2-page Internet-Draft.

Also, various people in the DANE WG have different ideas on how to
represent Raw Public Keys (RPKs) in TLSA records, what operational
constraints to put on TLSA records involving RPKs, and even how the
TLS protocol itself should evolve to require retries when using
RPKs. It seems a bit too early to say, "just release RFC 7250, it
won't need any more changes" when these issues have not been resolved,
nor even extensively explored.

I thought that we had consensus that just publishing a "3 1 x" key
would suffice, but it has become clear that others have very different
ideas, including "4 1 x" records, "1 1 x" records, etc.

I think that the real stumbling block here is the attitude that "DANE
is only for PKIX", which some WG participants came in with, which was
embedded into what became the primary DANE RFC (TLSA RFC 6698), and
which some continue to argue for.  Until and unless that attitude
is definitively repudiated by the WG in toto, I suspect that we will
continue to have problems reaching consensus whenever any IETF member
tries to use DNSSEC for a protocol (like Raw Public Keys) that does
not use PKIX certificates.

	John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Jun 2014 01:11:21 +0000

> Practice, and it does not update the DANE TLSA RFC 6698.

Indeed, sorry about that, since just before London, we've focused
primarily on the SMTP draft, to the detriment of progress on the
ops draft.  Cycles were limited.  This is about to change...

In particular the ops draft will shortly be revived from limbo,
changed to standards track and will update 6698.

> nor even extensively explored.

You'll find that there is little support for RPK formats other than
"3 1 X", despite a small number of suggestions to the contrary.  A
consensus around "3 1 X" is I think a safe bet.

It is also not clear that "RPK" is fundamentally dependent on an
extant definition of how it is to be used with out of band DANE
authentication.  The base specification it seems is mechanism
neutral.  So the specifics of associated TLSA RR formats are only
an issue for DANE clients, thus not unreasonably defined in a
related new DANE WG document.

> is only for PKIX",

That may be true of some past history, but I've seen very little
of that here in the last year a bit that I've been active in this
group.  DANE is not only for PKIX, but RFC 6698 as it stands does
not currently describe associations to objects other than X.509
certificates.  We'll address extending the definition to RPK in
the ops draft, or a separate document if there's a strong preference
for that.  Since some of the content would overlap with related
material in the ops draft, I'd prefer to not split this out.

> Until and unless that attitude

We should not confuse the circumscribed scope of 6698, which looks
today to be more a matter of caution to not overreach, rather than
any specific bias in favour of a particular key management approach.

There could have been some players who during the development of
6698 had an agenda in one direction or another, but the document
itself is at worst too narrow, rather than biased.

It also does not consider the opportunistic use-case and various
other issues that would probably have further delayed adoption.

RPK via "3 1 X" is a natural extension of 6698 to include in a 6698
update.  If new certificate usages are needed in the future for
more radically different use-cases, these can be added in separate
documents or in any future comprehensive updates.

Bottom line, I've not run into any difficulties agenda-driven
conspiracies here yet.  I'd like to add RPK support to Postfix at
some point, once code for this is available (in OpenSSL).

You'll likely find more resistance to RPK from some of the various
toolkit maintainers (of OpenSSL, NSS, GnuTLS, ...) than on the DANE
WG, where I expect RPK has a decent body of support.  Like RPK DANE
TLSA is a departure from the established order, and the two share
common use-cases.

-- 
	Viktor.

---

From: John Gilmore <[email-masked]>
Date: Thu, 05 Jun 2014 18:22:43 -0700

> The safe version of the reverse change looks like:
[I believe he's referring to upgrading a site from a TA-certified key to an
end-entity-certified key.]
> chain, "oob" clients would lose.

I don't understand this assertion.  Viktor, why would "oob" (RPK)
clients lose (fail?) if the domain name also included a TLSA 2 0 1
record?  My belief is that the RPK client would ignore that 2 0 1
record, either because the client doesn't implement PKIX, or because
the client is in the middle of an RPK TLS transaction and that record
is not relevant to that transaction.

This seems to be the central puzzle in trying to understand your
concerns with mixing RPK and PKIX TLSA records, so if you could
clearly explain why you think this case fails, it would help.

	John

---

From: John Gilmore <[email-masked]>
Date: Thu, 05 Jun 2014 18:30:11 -0700

> client is planning to use to authenticate the server's keys/certs.

I agree that the server software should not be trying to figure out
"TLSA RRs as seen by the client".  The server may not have access to
the same DNS servers as the client.  The best that we can ask is
that the system administrator of the server "keeps in mind" the
public configuration of the TLSA records that relate to the server.

I would be surprised to hear anyone in this group claiming that the
TLS server can be configured completely independently of the TLSA
records published in its domain.  In particular, the keys used in the
TLSA records and in the TLS server have to be coordinated so that they
match.  If they are not coordinated, DANE will never work with that
TLS server.

So, given that the people who configure the server must already know
whether their domain is publishing TLSA records that authenticate
their PKIX certificate, why is it such a stretch for the people who
configure the server to also know whether their domain is publishing
TLSA records that authenticate an RPK used by the server?

	John

---

From: John Gilmore <[email-masked]>
Date: Thu, 05 Jun 2014 18:40:54 -0700

> past keys are "misconfigured", and that servers SHOULD NOT do that.

I don't understand how any crypto protocol can succeed when it
authenticates only past or future keys, not the keys in present use.

Can you explain why you think such a server is NOT misconfigured?  Or
perhaps you will agree that this is misconfiguration, but you think
that for some reason that you can state, many people will foolishly
misconfigure their servers this way, such that the protocol should
gracefully handle that "common misconfiguration" case?

Struggling to understand,

	John

---

From: John Gilmore <[email-masked]>
Date: Thu, 05 Jun 2014 18:54:08 -0700

> key material.  If the latter (which I don't recommend...

It is my belief that the reason we have no web browsers that support
DANE is because it would likely reduce the latency of web transactions
that involve https.  Browser vendors compete on how quickly they can
go from the user typing "eff.org" to showing the EFF home page.  They
use all kinds of tricks (like doing DNS lookups on the part before the
first slash, while the user is still typing the rest of the URL; or
matching on the URLs of previous visits from this browser), to reduce
that latency.

If clients that support DANE and RPK require that a full DNSSEC TLSA
lookup begins and ends before the client can start any TLS negotiation
-- even to sites that are not using raw public keys -- then this
latency will increase.  Which means even less chance of practical
adoption of DANE (and less chance of practical adoption of RPK) in the
real world web browsers.

That's why I am trying to avoid such a requirement.  DANE is a good
idea, but to the extent that we require them to be slower than the
currently widespread TLS implementations, DANE may never be adopted in
realtime clients that have a user watching them run.

	John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Jun 2014 02:31:14 +0000

> authenticates only past or future keys, not the keys in present use.

Not *only*, rather concurrently both present and either past or
future keys (possibly all three, but that's generally unnecessary).

> Can you explain why you think such a server is NOT misconfigured?

During administrative changes in the TLSA RRset, given the asynchronous
nature of DNS data propagation, one needs to insert future data before
removing present data.  Once the new keys are in place, one can remove
past data.  At various stages clients see one of:

	* (old) present
	* (old) present + (new) future
	* (old) past + (new) present
	* (new) present

No *proper* subset of the TLSA RRs is currently mandated to contain
a record matching the server chain.  Only the *complete* RRset of
a correctly configured server must contain *at least one* matching
record.  If the usage/selector/mtype combinations for "old" and
"new" chains are not identical (one to one correspondence) then a
client that employs a proper subset of the TLSA RRs (say because
RPK is only capable of matching "3 1 X"), then it might be that
this subset contains only past or only future keys and authentication
fails.

> Or

No it is not misconfiguration as currently defined.  We could
publish operational requirements that make it a misconfiguration
or at least a violation of best practice.

Is that enough for clients to throw caution to the wind and assume
consistent BCP TLSA RR practices on the server side?  Perhaps it
is safer for the client to forgo an optimization and just negotiate
X.509 in some edge cases that will be rare, but not unlikely
enough to not cause people real support issues.

The best example for PRK is a transition from a current "2 0 1" TLSA
RRs to future "3 1 1" RR.  The administrator needs to know to do:

    Initial:
	IN TLSA 2 0 1 {old TA}

    Intermediate:
	IN TLSA 3 1 1 {switch to old leaf}
	IN TLSA 3 1 1 {new leaf}

    Final:
	IN TLSA 3 1 1 {new leaf}

rather than the more naively obvious:

    Initial:
	IN TLSA 2 0 1 {old TA}

    Intermediate:
	IN TLSA 2 0 1 {old TA}
	IN TLSA 3 1 1 {new leaf}

    Final:
	IN TLSA 3 1 1 {new leaf}

because here, until the new leaf is deployed after the original
TTL expires, PRK clients might conclude that it is safe to use PRK,
but it is not because the server's current (old) key can't be
matched via an EE SPKI association.

Asking the server operator to disable PRK (which be negotiated
automatically in some toolkit whenever the client asks just because
the server also has the feature) when the published TLSA records
might not be PRK friendly is I think a greater burden than asking
for care in how DNS records are updated.

This is an operational issue for both client and server, someone
has to do the heavy lifting.  I think the client should not be
entirely off the hook, because PRK for clients that support both
X.509 and PRK is an optional optimization.

The impact will be low, because servers that support "3 1 X" will
most often only support "3 1 X", and the "mixed" RRsets will be
very rare.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 6 Jun 2014 11:25:26 -0400 (EDT)

> consensus around "3 1 X" is I think a safe bet.

It is not a safe bet. We only need one external requirement, like PCI-DSS
or the EV consortium to start dictating one has to publish and match a
full certificate to get their goodies like a green url bar. Then you
would need a mix of TLSA types to support both the PKIX/CABforum/EV
universe and raw public keys. And by not allowing that, or by stating
a mixed TLSA RRset means sacrificing raw public keys, the result would
force everyone to be stuck with full PKIX validation.

In other words, your 'optimization' can be harmful. You're still welcome
to code that into your software. But you can't standardize it.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 6 Jun 2014 11:35:04 -0400 (EDT)

> matched via an EE SPKI association.

Okay, I understand this example now and your desire to not mixup TLSA
types. However, the operations document could simply advise not to
combine a key rollover with a usage/type/selector rollover at once,
which seems more appropriate than banning all other valid scenario's
that mixup type such as:

  	IN TLSA 2 0 1 {current TA}
  	IN TLSA 3 1 1 {current leaf}

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Jun 2014 15:44:17 +0000

> >consensus around "3 1 X" is I think a safe bet.

A safe bet that this becomes the standard encoding of RPK TLSA records.

> full certificate to get their goodies like a green url bar.

Which little bearing on how to publish the RPK records.

> Then you
> universe and raw public keys.

Encoded as "3 1 X" which was the limited scope of that comment.

> And by not allowing that, or by stating

That's a separate question than the one under discussion.  The
hypothetical seems rather conspiratorial.  In a conspiracy more
likely these various actors, if they were acting to thwart DANE
adoption, would simply erect barriers to all use of DANE TLSA.
(Perhaps they're doing that already).  Just preventing use of RPK
seems like a rather modest goal if DANE "3 0 1" and "2 0 1" are
are left standing and become popular.

You can at least relax in my case, I am not part of any X.509
cospiracy. :-)  Rather, I just work to be sure that things actually
work in all cases, including the corner ones.

> to code that into your software. But you can't standardize it.

Just to be clear I see RPK as an optimization, and my suggested
suppression of RPM with mixed TLSA RRs as forgoing the optimization.

However, we should tackle this point in the new thread I started,
after refocusing the arguement, it seems to be making better
progress.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Jun 2014 16:00:03 +0000

>  	IN TLSA 3 1 1 {current leaf}

I am not suggesting to ban mixed TLSA RRs. Rather, I was suggesting
that clients encountering mixed TLSA RRs might want to avoid RPK, but
we'll handle that question in the other thread.

To your point about transitions and changing one thing at a time,
yes that's the right high-level description of the BCP TLSA RRset
change strategy.  Keep all other things fixed and apply one of:

    * Add future keys presented with the same U/S/M combinations as
      existing keys.

    * Remove all U/S/M combinations for legacy keys leaving only
      current keys.

    * Add new U/S/M combinations that match the same keys as existing
      U/S/M combinations.

    * Remove all records with a given U/S/M combination.

    * Or combine the two previous and replace one U/S/M combination with
      another, while still matching the same set of keys.

The required invariant is that at all times each currently published,
or not yet expired from DNS caches, U/S/M combination comtains at
least one record that matches the current server keys.

Whether or not client RPK behaviour includes any work-arounds for
"mixed" TLSA RRsets, the above should be a BCP for server TLSA RRset
management.

-- 
	Viktor.